เมื่อไรที่คุณจะใช้ WebSockets, SSE หรือ long-polling แทน HTTP ธรรมดา?

Question

IT Interview Practice · Accepted Answer

HTTP ธรรมดาเป็นแบบ **request/response**: client ถาม, server ตอบ, จบ นั่นไม่เหมาะกับฟีเจอร์ **real-time** (แชท, dashboard สด, การแจ้งเตือน, การแก้ไขร่วมกัน) ที่ *server* ต้องผลักข้อมูลออกไปเมื่อใดก็ตามที่มีของใหม่ ตัวเลือกต่าง ๆ เป็นวิธีอ้อมโมเดล client-เริ่มก่อนของ HTTP บนสเปกตรัมของความซับซ้อน:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling** เป็นทางเลือกสำรองที่ทำงานได้ทุกที่: client ยิง request ปกติที่ server ค้างไว้จนกว่าจะมีข้อมูล แล้ว client ยิงขอใหม่ทันที มันเลียนแบบ push บน HTTP ธรรมดาแต่สิ้นเปลืองรอบ request หนึ่งรอบต่อข้อความและเพิ่ม latency

**SSE (Server-Sent Events)** เป็น stream **ทางเดียว** (server → client) ที่เบา, เป็นมาตรฐาน บน HTTP response เดียวที่อยู่ได้นาน มันเหมาะเมื่อมีเพียง server ที่ผลัก — feed สด, การแจ้งเตือน, ความคืบหน้า, การ stream token ของ LLM มันเรียบง่าย, ทำงานบน HTTP/2 ปกติ (ไม่ต้องมี infrastructure พิเศษ) และ reconnect อัตโนมัติ ข้อจำกัด: มันเป็นทางเดียวและเป็น text เท่านั้น

**WebSockets** อัปเกรดการเชื่อมต่อ HTTP เดียวให้เป็นช่องทาง TCP **full-duplex** ที่คงอยู่ ซึ่งทั้งสองฝ่ายส่งได้ทุกเมื่อด้วย overhead ต่อข้อความน้อยที่สุด ใช้มันสำหรับการโต้ตอบสองทิศทางจริง ๆ ที่ latency ต่ำ: แชท, เกมหลายผู้เล่น, editor ร่วมกัน, การเทรด ต้นทุนคือด้านการดำเนินงาน — มันเป็นการเชื่อมต่อที่มี state ซึ่ง proxy, load balancer และ autoscaler ต้องถูกตั้งค่าให้รองรับ และคุณต้องสร้าง reconnect, heartbeat และ backpressure เอง

**หลักเกณฑ์คร่าว ๆ:** ใช้ HTTP ธรรมดาเป็นค่าเริ่มต้น; ใช้ **SSE** สำหรับการ stream server→client; คว้า **WebSockets** เฉพาะเมื่อคุณต้องการ real-time สองทิศทางจริง ๆ; เก็บ **long-polling** ไว้เป็นทางเลือกสำรองสากล

## ทำไมจึงสำคัญ

การเลือก transport แบบ real-time เป็นการตัดสินใจออกแบบระดับ senior แบบคลาสสิกที่คำตอบไร้เดียงสา ("ก็ใช้ WebSockets กับทุกอย่างสิ") มักผิด ผู้สัมภาษณ์อยากเห็นว่าคุณจับคู่เครื่องมือกับ *รูปแบบการสื่อสาร* — ทางเดียวเทียบกับสองทิศทาง, ความต้องการ latency, ปริมาณข้อความ — และว่าคุณชั่งน้ำหนัก **ต้นทุนการดำเนินงาน** ของการเชื่อมต่อที่มี state และอยู่นาน: sticky session, การ scale, proxy timeout และตรรกะ reconnect การตระหนักว่า SSE มักครอบคลุม "server ผลักการอัปเดต" ได้เรียบง่ายกว่า WebSockets และว่า long-polling ยังเป็นทางเลือกสำรองที่ทนทาน บ่งบอกประสบการณ์ production จริงแทนที่จะคว้าตัวเลือกที่หวือหวาที่สุด

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง