เมื่อ Dashboard ของ SCADA หรือ HMI ต้องแสดงค่าเซ็นเซอร์ที่เปลี่ยนแปลงทุกวินาที หรือเมื่อผู้ควบคุมต้องการเห็นสถานะเครื่องจักรแบบเรียลไทม์บนเว็บเบราว์เซอร์ โปรโตคอลแบบเดิมอย่าง HTTP Request-Response ก็เริ่มไม่เพียงพอ WebSocket (RFC 6455) จึงกลายเป็นหัวใจสำคัญของการสร้างระบบติดตามและควบคุมโรงงานผ่านเว็บที่ตอบสนองแบบทันที (Real-Time)
WebSocket คืออะไร และทำไม IIoT ถึงต้องการ
WebSocket เป็นโปรโตคอลสื่อสารแบบ Full-Duplex (สองทางพร้อมกัน) ที่ทำงานบน TCP Connection เดียว แตกต่างจาก HTTP แบบดั้งเดิมที่เป็น Request-Response (ฝั่ง Client ถามแล้ว Server ตอบ แล้วปิดการเชื่อมต่อ) WebSocket เปิดการเชื่อมต่อครั้งเดียวแล้วคงไว้ตลอดเวลา (Persistent Connection) ทำให้ทั้งสองฝั่งสามารถส่งข้อมูลหากันได้ตลอดเวลาโดยไม่ต้องรอฝั่งใดฝั่งหนึ่งเริ่มก่อน
การสร้าง WebSocket Connection เริ่มต้นด้วย HTTP Upgrade Handshake – Client ส่ง HTTP Request พร้อม Header Upgrade: websocket เมื่อ Server ตอบรับ (HTTP 101 Switching Protocols) การเชื่อมต่อก็เปลี่ยนจาก HTTP ไปเป็น WebSocket ทันที จุดนี้สำคัญเพราะทำให้ WebSocket สามารถทะลุผ่าน Firewall และ Reverse Proxy มาตรฐานได้โดยใช้พอร์ต 80 หรือ 443 เหมือนเว็บไซต์ทั่วไป
เปรียบเทียบวิธีการสื่อสาร Real-Time ใน IIoT
| วิธีการ | ทิศทาง | Overhead/ข้อความ | Latency | การใช้ทรัพยากร |
|---|---|---|---|---|
| HTTP Polling | Request-Response | ~500-800 bytes (Header ซ้ำทุกครั้ง) | สูง (รอทุก N วินาที) | สูงมาก |
| Long Polling | ครึ่งสองทาง | ~500-800 bytes | ปานกลาง | สูง |
| SSE (Server-Sent Events) | Server > Client เท่านั้น | ต่ำ | ต่ำ | ปานกลาง |
| WebSocket | Full-Duplex (สองทาง) | 2-10 bytes (Frame Header) | ต่ำมาก | ต่ำ |
| MQTT | Pub/Sub | 2 bytes (Fixed Header) | ต่ำมาก | ต่ำ |
จะเห็นว่า WebSocket มี Frame Header เพียง 2-10 bytes เมื่อเทียบกับ HTTP ที่มี Header หลายร้อยไบต์ต่อคำขอเดียว ในระบบที่ส่งข้อมูลเซ็นเซอร์ 1,000 ครั้งต่อวินาที ความแตกต่างนี้หมายถึงการประหยัดแบนด์วิดท์ได้มหาศาล
การใช้งาน WebSocket ใน Smart Factory
1. Real-Time SCADA Dashboard บนเว็บเบราว์เซอร์
แทนที่จะติดตั้งซอฟต์แวร์ SCADA แบบเดิมบนคอมพิวเตอร์เฉพาะ วิศวกรสามารถสร้าง Dashboard บนเว็บที่แสดงค่าเซ็นเซอร์ สถานะเครื่องจักร และ Alarm แบบเรียลไทม์ผ่าน WebSocket ทำให้เข้าถึงได้จากทุกอุปกรณ์ที่มีเว็บเบราว์เซอร์ รวมถึง Tablet และ Smartphone
2. การสั่งการและควบคุม (Command & Control)
เนื่องจากเป็น Full-Duplex ผู้ควบคุมไม่เพียงแต่ “ดู” ข้อมูลได้แบบเรียลไทม์ แต่ยังสามารถ “สั่ง” เปิด-ปิด Valve หรือปรับ Setpoint ได้ทันทีโดยไม่ต้องเปิด Connection ใหม่
3. MQTT over WebSocket
โบรกเกอร์ MQTT สมัยใหม่รองรับการเชื่อมต่อผ่าน WebSocket ทำให้เว็บแอปพลิเคชันสามารถ Subscribe Topic ของ MQTT ได้โดยตรงผ่านไลบรารี เช่น Paho.js โดยใช้ URL ในรูปแบบ wss://broker.example.com:8883/mqtt – เป็นการผสานจุดแข็งของทั้งสองโปรโตคอลเข้าด้วยกัน
โครงสร้าง WebSocket Frame
เมื่อสร้าง Connection สำเร็จแล้ว ข้อมูลที่ส่งกันจะอยู่ในรูปแบบ Frame ที่มีโครงสร้างกระชับ:
- FIN + Opcode (1 byte) – ระบุประเภทข้อมูล (Text=0x1, Binary=0x2, Close=0x8, Ping=0x9, Pong=0xA)
- Mask + Payload Length (1-9 bytes) – ความยาวข้อมูล (7 bit, 7+16 bit, หรือ 7+64 bit)
- Masking Key (4 bytes) – เฉพาะฝั่ง Client ต้อง Mask ข้อมูลเพื่อความปลอดภัย
- Payload Data – ข้อมูลจริง
การรองรับ Binary Frame ทำให้ WebSocket เหมาะกับการส่งข้อมูลที่มีประสิทธิภาพสูง เช่น ภาพจากกล้องตรวจสอบคุณภาพ หรือ Time-Series Data ที่เข้ารหัสในรูปแบบ Protocol Buffers / MessagePack ได้โดยตรง
กลไกความน่าเชื่อถือ: Ping/Pong และ Reconnection
WebSocket มีกลไก Ping/Pong Control Frame ในตัว ทำหน้าที่เหมือน Heartbeat – ฝั่งหนึ่งส่ง Ping อีกฝั่งต้องตอบ Pong ภายในเวลาที่กำหนด หากไม่ตอบ แสดงว่า Connection ขาดหายไปแล้ว แอปพลิเคชันที่ดีควรส่ง Ping ทุก 30-60 วินาทีเพื่อคงการเชื่อมต่อไว้ และตรวจจับการขาดการเชื่อมต่อได้เร็ว
สำหรับการ Reconnection แบบอัตโนมัติ มักใช้เทคนิค Exponential Backoff – รอ 1 วินาที then 2 then 4 then 8 then สูงสุด 30 วินาที เพื่อไม่ให้ Server โดน Storm ของการเชื่อมต่อใหม่พร้อมกันเมื่อ Network กลับมา
ความปลอดภัย: wss:// และ Authentication
[!] ข้อควรระวัง: อย่าใช้
ws://(ไม่เข้ารหัส) ในสภาพแวดล้อมการผลิต! ใช้wss://(WebSocket Secure over TLS) เสมอ เพราะข้อมูล Full-Duplex ที่ส่งไปกลับไม่ได้เข้ารหัสจะถูกดักจับได้ง่าย (Man-in-the-Middle)
แนวทางความปลอดภัยที่ควรปฏิบัติ:
- TLS Encryption: ใช้ wss:// บนพอร์ต 443 เสมอ
- Token Authentication: ส่ง JWT หรือ Token ในช่วง Handshake (ผ่าน Header หรือ Query Parameter)
- Origin Validation: Server ตรวจสอบ
Origin Headerเพื่อป้องกัน Cross-Site WebSocket Hijacking - Rate Limiting: จำกัดจำนวน Message ต่อวินาทีเพื่อป้องกัน DoS
- Message Size Limit: กำหนดขนาด Payload สูงสุดเพื่อป้องกันการโจมตีด้วย Frame ขนาดใหญ่
Key Takeaways
- Full-Duplex สองทาง: เปิด Connection ครั้งเดียวแล้วส่งข้อมูลหากันได้ตลอดเวลา ทั้งดูข้อมูลและสั่งการพร้อมกัน
- Overhead ต่ำมาก: Frame Header เพียง 2-10 bytes เทียบกับ HTTP หลายร้อยไบต์ ประหยัดแบนด์วิดท์ในระบบที่ส่งข้อมูลบ่อย
- ทะลุ Firewall ได้: ใช้ HTTP Upgrade Handshake ทำงานบนพอร์ต 80/443 เหมือนเว็บทั่วไป ไม่ต้องเปิดพอร์ตพิเศษ
- MQTT over WebSocket: ผสานจุดแข็ง Pub/Sub ของ MQTT เข้ากับการเข้าถึงผ่านเว็บเบราว์เซอร์
- Binary Frame: รองรับข้อมูล Binary เช่น ภาพ และ Time-Series ที่เข้ารหัสกระชับได้โดยตรง
- ต้องใช้ wss://: เข้ารหัส TLS เสมอในสภาพแวดล้อมการผลิต พร้อม Token Auth และ Origin Validation
WebSocket ไม่ได้มาแทน MQTT หรือ OPC UA ในระดับ Field Device แต่อยู่ในชั้น Application/Presentation Layer ที่เชื่อมระหว่าง Backend กับ Frontend ของระบบติดตามและควบคุม สำหรับโรงงานที่ต้องการ Web-Based HMI หรือ Dashboard ที่ตอบสนองแบบเรียลไทม์ WebSocket คือโปรโตคอลที่ตอบโจทย์ได้ดีที่สุดในปัจจุบัน