บทวิเคราะห์: WebSocket แก่แล้วจริงหรือ — Head-of-Line Blocking, WebTransport บน QUIC และอนาคต Dashboard แบบ Real-Time ของโรงงาน

เกือบทุก dashboard แบบ real-time ในโรงงานที่คุณเคยเห็น — Andon board, OEE monitor, energy wall — ส่วนใหญ่ใช้เทคโนโลยีเดียวกันใต้ฝาครอบ: WebSocket โปรโตคอลจากปี 2011 (RFC 6455) ที่เปิดช่องทางสองทางถาวรบน TCP ทำให้เซิร์ฟเวอร์ push ข้อมูลหา browser ได้โดยไม่ต้อง polling คำถามคือ ในปี 2026 ที่ HTTP/3 และ QUIC (RFC 9000) กลายเป็นมาตรฐาน และ W3C เพิ่งประกาศ WebTransport Working Draft ใหม่ล่าสุดเมื่อมีนาคม 2026 — เราควรยังวางแผนสถาปัตยกรรม real-time บน WebSocket อยู่ไหม

ปัญหาเก่าที่ยังอยู่: Head-of-Line Blocking

จุดอ่อนของ WebSocket ไม่ได้อยู่ที่ตัวโปรโตคอลเอง แต่อยู่ที่ฐานรากคือ TCP ซึ่งรับประกันการส่งถึงตามลำดับ (in-order delivery) เมื่อ packet หนึ่งสูญหาย ทุก byte ที่มาถึงแล้วหลังจากนั้นต้องรอ retransmission แม้ข้อมูลเหล่านั้นจะเป็นคนละ message ก็ตาม — นี่คือ head-of-line blocking ใน dashboard ที่มีทั้งกราฟ trend ชุดใหญ่และ alarm วิกฤตที่ห้ามดองเลย การที่ alarm ติดค้างอยู่หลังกราฟที่กำลัง retransmit คือความเสี่ยงจริงของระบบ monitoring

QUIC แก้ปัญหานี้ที่ราก: stream ที่แยกกันบน connection เดียวมีการรับประกันการส่งถึงแบบอิสระ ข้อมูลของ stream 2 ไม่ต้องรอ stream 1 ที่กำลังส่งใหม่ WebTransport ตาม Working Draft ของ W3C (มีนาคม 2026) ยกระดับความสามารถนี้ขึ้นสู่ browser API: รองรับหลาย stream, unidirectional stream, datagram แบบ unreliable และ out-of-order delivery — ทั้งหมดบน security model ของเว็บสมัยใหม่

แต่ในโรงงานจริง: MQTT over WebSocket ยังเป็นแชมป์ปัจจุบัน

ท่ามกลางกระแสใหม่ สถาปัตยกรรมที่พิสูจน์แล้วและยังคงเป็นหัวใจของ dashboard โรงงานส่วนใหญ่คือ MQTT over WebSocket: edge gateway publish ข้อมูลเซ็นเซอร์เข้า broker ที่เปิด WebSocket listener บนพอร์ต 443 พร้อม TLS ทำให้ทะลุ corporate firewall/proxy ได้โดยไม่ต้องขอเปิดพอร์ต 1883/8883 — browser ทุกเครื่องจากผู้จัดการถึง tablet ช่างเทคนิค subscribe topic ที่ต้องการแบบ real-time

ทีมงาน Honey Corporation ใช้รูปแบบนี้เป็นฐานของระบบ monitoring หลายโครงการ เช่น งานติดตั้งระบบ IoT ตู้แช่ Freezer ที่ dashboard แสดงอุณหภูมิ real-time ผ่าน browser โดยตรง ประสบการณ์จริงบ่อยครั้งชี้ว่าปัญหาที่ใหญ่กว่าการเลือก protocol คือ การออกแบบ topic structure และ data volume — กราฟ trend ที่ push ทุก 100 ms พร้อม payload ที่อ้วนเกินจำเป็น คือสาเหตุที่พบบ่อยกว่า head-of-line blocking หลายเท่า ดังนั้นก่อนเปลี่ยน technology ให้ตรวจสอบก่อนว่า Andon ที่เลื่อนเป็นครั้งคราวนั้น ติดที่ transport จริง หรือติดที่ข้อมูลที่ส่งเกินความจำเป็น

ลำดับความสำคัญของการเปลี่ยนผ่าน

Key Takeaways

• WebSocket ไม่ได้แก่ — แต่ TCP คือคอขวด: head-of-line blocking เป็นข้อจำกัดเชิงโครงสร้างของ transport ไม่ใช่ตัวโปรโตคอล
• WebTransport (W3C WD มี.ค. 2026) ตอบโจทย์ dashboard หนัก: หลาย stream + datagram ทำให้ alarm ไม่ติดรอกราฟ
• MQTT over WebSocket บน 443 ยังเป็น best practice: ทะลุ firewall องค์กรและเข้ากันได้กับ browser ทุกตัว
• วินิจฉัยก่อนเปลี่ยน: latency ที่แย่มักมาจาก payload อ้วนและ topic design มากกว่า protocol
• กลยุทธ์ 2026: hybrid: คง MQTT/WS เป็นฐาน ทดลอง WebTransport เฉพาะจุดที่ packet loss กระทบ alarm จริง