โปรโตคอลสื่อสาร — ภาษาที่เครื่องคุยกัน
HTTP/HTTPS · TCP vs UDP · WebSockets · Polling · SSE · ▶ ในคลิป 0:46:06 – 1:03:11
ทุกครั้งที่เลือกวิธีสื่อสาร เรากำลังตอบคำถามสองข้อ: "ยอมเสียข้อมูลบ้างไหม" (transport layer: TCP vs UDP) และ "ใครเป็นฝ่ายเริ่มพูด" (request-response vs real-time) บทนี้ไล่จากชั้นล่างขึ้นบน
5.1 ชั้นของการสื่อสาร
โปรโตคอลซ้อนกันเป็นชั้น แต่ละชั้นทำหน้าที่เดียวแล้วส่งต่อ: HTTP (ความหมายของข้อความ) วิ่งอยู่บน TCP หรือ UDP (วิธีขนส่ง) ซึ่งวิ่งบน IP (ที่อยู่ปลายทาง) — เวลาพูดว่า "เว็บช้า" ปัญหาอาจอยู่ชั้นไหนก็ได้ การรู้ชั้นช่วยให้ debug ถูกที่
5.2 TCP — ส่งถึงชัวร์ เรียงลำดับครบ
TCP (Transmission Control Protocol) เป็นโปรโตคอลแบบ connection-oriented: ก่อนส่งข้อมูลจริงต้อง "จับมือ 3 จังหวะ" (3-way handshake) เพื่อสถาปนาการเชื่อมต่อก่อน จากนั้นทุก packet ที่ส่งจะมีการตอบรับ (ACK) — หายก็ส่งซ้ำ มาสลับลำดับก็เรียงคืนให้
5.3 UDP — เร็วก่อน ครบไม่สัญญา
UDP (User Datagram Protocol) ตรงข้ามทุกอย่าง: ไม่มี handshake ไม่มี ACK ไม่มีการเรียงลำดับ — แค่ยิง packet ออกไปแล้วหวังว่าถึง ฟังดูแย่ แต่สำหรับงานบางประเภท "ข้อมูลเก่า" แย่กว่า "ข้อมูลหาย": วิดีโอคอลที่เฟรมหายไปเฟรมหนึ่งดีกว่าภาพค้างรอส่งซ้ำ เกมออนไลน์ที่ตำแหน่งล่าสุดสำคัญกว่าตำแหน่งเมื่อ 200ms ก่อน
| มิติ | TCP | UDP |
|---|---|---|
| การเชื่อมต่อ | ต้อง handshake ก่อน | ยิงได้ทันที |
| ความครบถ้วน | รับประกัน (ส่งซ้ำเมื่อหาย) | ไม่รับประกัน |
| ลำดับ | เรียงให้ถูกเสมอ | มาก่อนได้ก่อน |
| ความเร็ว | ช้ากว่า (overhead + รอ ACK) | เร็วและ overhead ต่ำ |
| ใช้กับ | เว็บ, API, อีเมล, โอนไฟล์ | วิดีโอคอล, เกม, สตรีมมิง, DNS |
🧭 จุดบรรจบของสองโลก: QUIC / HTTP-3 — HTTP/1.1 และ HTTP/2 วิ่งบน TCP ส่วน HTTP/3 วิ่งบน QUIC ซึ่งสร้างบน UDP — เอาความเร็วของ UDP มาแล้วเขียนกลไกความน่าเชื่อถือขึ้นใหม่ในชั้นบน ตัด handshake ให้สั้นลงและแก้ปัญหา head-of-line blocking ของ TCP ได้ นี่คือเหตุผลที่เว็บใหญ่ ๆ (Google, Cloudflare) ดัน HTTP/3
5.4 HTTP และ HTTPS
HTTP เป็นโปรโตคอลแบบ request–response และ stateless — แต่ละ request จบในตัว เซิร์ฟเวอร์ไม่จำอะไรระหว่าง request (เหตุผลที่ต้องมี cookie/token ในบทที่ 7) ส่วน HTTPS คือ HTTP ที่ห่อด้วย TLS: เข้ารหัสข้อมูลทั้งหมดระหว่างทาง + พิสูจน์ว่าเซิร์ฟเวอร์เป็นตัวจริงผ่าน certificate — ยุคนี้ ทุกอย่างต้องเป็น HTTPS ไม่มีข้อยกเว้น แม้แต่ระบบภายใน
วิวัฒนาการที่ควรรู้: HTTP/1.1 ใช้ 1 connection ต่อ 1 request ขณะหนึ่ง (เปลือง) → HTTP/2 multiplex หลาย request บน connection เดียว → HTTP/3 ย้ายไป QUIC ตามที่เล่าข้างบน
5.5 Real-time — เมื่อเซิร์ฟเวอร์อยากพูดก่อน
HTTP ปกติ client ถามก่อนเสมอ แต่แอปแชต ราคาหุ้น หรือแจ้งเตือน ต้องการให้ เซิร์ฟเวอร์ push ข้อมูลมาเอง — มี 4 เทคนิคไล่ระดับ:
- Short Polling — client ถามซ้ำทุก X วินาที ("มีอะไรใหม่ไหม") ง่ายสุดแต่เปลือง: ส่วนใหญ่ได้คำตอบว่า "ไม่มี" และข้อมูลดีเลย์ได้ถึง X วินาที
- Long Polling — client ถามแล้วเซิร์ฟเวอร์ แขวนคำตอบไว้ จนกว่าจะมีข้อมูลจริงค่อยตอบ แล้ว client ถามใหม่ทันที — ดีเลย์ต่ำลงมาก แต่ยังมี overhead ของการตั้ง request ใหม่เรื่อย ๆ
- SSE (Server-Sent Events) — เปิด HTTP connection เดียวค้างไว้ ให้เซิร์ฟเวอร์สตรีมข้อความมาได้เรื่อย ๆ ทางเดียว — เบาและง่าย เหมาะ feed/แจ้งเตือน/ราคาหุ้น
- WebSocket — อัปเกรดจาก HTTP เป็นท่อ สองทางถาวร (full-duplex) ทั้งสองฝั่งส่งหากันได้ทุกเมื่อ — มาตรฐานของแชต, เกม, collaborative editing
✅ สรุปบทที่ 5 — TCP = ครบชัวร์แต่จ่ายค่า handshake · UDP = เร็วแต่หายได้ เหมาะงานที่ข้อมูลเก่าไร้ค่า · HTTPS คือภาคบังคับ · งาน real-time ไล่จากถูกไปแพง: short polling → long polling → SSE (ทางเดียว) → WebSocket (สองทาง) — เลือกตัวที่ "พอ" ไม่ใช่ตัวที่เก่งสุด