การทำ Timeliness(ความทันท่วงที) ด้วย QUIC โดยไม่ใช้ Datagram

อย่าใช้ datagram เด็ดขาด

TCP vs UDP

• เมื่อพัฒนาแอปพลิเคชันอินเทอร์เน็ต จำเป็นต้องเลือกระหว่าง TCP กับ UDP
• TCP: รับประกันการส่งข้อมูลที่เชื่อถือได้
• UDP: ให้การส่งข้อมูลแบบไม่เชื่อถือได้
• กรณีที่ต้องการการส่งข้อมูลแบบไม่เชื่อถือได้นั้นแทบไม่มีเลย

คุณสมบัติ

• วิศวกรรมซอฟต์แวร์ตั้งอยู่บนชั้นของนามธรรมหลายระดับ
• แต่ละชั้นมอบคุณสมบัติเฉพาะ เพื่อให้นักพัฒนาไม่ต้องสร้างทุกอย่างขึ้นมาใหม่ตั้งแต่ต้น
• นักพัฒนาจึงต้องเลือกว่าจะใช้ชั้นใด

"ไม่เชื่อถือได้"

• ในการประชุมออกแบบโปรโตคอลวิดีโอแบบเรียลไทม์ มีความเห็นว่า SUBSCRIBE ควรเป็นแบบไม่เชื่อถือได้
• แต่สิ่งที่ต้องการจริง ๆ คือ ความทันท่วงที
• สำหรับวิดีโอเรียลไทม์ สิ่งสำคัญคือการส่งข้อมูลล่าสุดให้ถึงก่อน

Datagram

• datagram (แพ็กเก็ต IP) คือหน่วยของข้อมูลที่ส่งจากที่อยู่ต้นทางไปยังที่อยู่ปลายทาง
• datagram อาจสูญหายหรือสลับลำดับได้
• เหตุผลที่ใช้ datagram คือเมื่อเครือข่ายหนาแน่น การทิ้งแพ็กเก็ตอาจเป็นทางเลือกที่ดีกว่า

คิวบนอินเทอร์เน็ต

• เมื่อเครือข่ายหนาแน่น การทิ้งแพ็กเก็ตเป็นเรื่องปกติ
• การนำแพ็กเก็ตไปเข้าคิวแล้วส่งภายหลังอาจก่อให้เกิดปัญหา bufferbloat
• bufferbloat ทำให้แพ็กเก็ตทั้งหมดกองสะสมอยู่ในคิวและทำลายความทันท่วงที

คุณ, นักพัฒนาแอปพลิเคชัน

• หากใช้ UDP โดยตรง คุณอาจต้องเผชิญกับปัญหาหลายอย่าง
• หากจะสร้างโปรโตคอลขนส่งของตนเองบน UDP ก็ต้องทำเรื่อง retransmission, congestion control ฯลฯ เอง
• การใช้ไลบรารี QUIC เป็นทางเลือกที่ดีกว่า

ความทันท่วงที

• สามารถใช้ QUIC เพื่อให้บรรลุ ความทันท่วงที ได้
  1. ระบายบัฟเฟอร์: ตรวจจับคิวผ่าน congestion control และลดอัตราการส่ง
  2. แยกข้อมูลเป็นสตรีม: แต่ละสตรีมจะถูกส่งอย่างเป็นอิสระ
  3. กำหนดลำดับความสำคัญของสตรีม: ส่งสตรีมที่สำคัญก่อน

การปกป้อง datagram

• QUIC และ MoQ รองรับ datagram
• การรองรับ datagram มีความสำคัญเพื่อเปิดทางให้มีการทดลอง
• อย่างไรก็ตาม การใช้ datagram อาจเป็นกับดักได้

บทสรุป

• ไม่ควรออกแบบแอปพลิเคชันบนพื้นฐานของ datagram
• แทนที่จะสร้างโปรโตคอลวิดีโออีกตัวบน UDP การเข้าร่วมกับ Media over QUIC น่าจะเป็นทางเลือกที่ดีกว่า

ความเห็นของ GN⁺

1. ความสำคัญของความทันท่วงที: ในแอปพลิเคชันแบบเรียลไทม์ ความทันท่วงทีของข้อมูลสำคัญมาก UDP อาจเหมาะกว่า TCP แต่ก็ต้องคำนึงถึงเรื่องเพิ่มเติม เช่น congestion control
2. ข้อดีของ QUIC: QUIC ช่วยชดเชยข้อเสียของ UDP พร้อมมอบประสิทธิภาพสูง โดยเฉพาะเหมาะกับการสตรีมวิดีโอแบบเรียลไทม์
3. ปัญหา bufferbloat: เมื่อเครือข่ายหนาแน่น การปล่อยให้แพ็กเก็ตกองในคิวอาจทำลายความทันท่วงที จึงจำเป็นต้องมี congestion control เพื่อหลีกเลี่ยงปัญหานี้
4. ข้อจำกัดของ datagram: datagram เหมาะกับการส่งแบบเรียลไทม์ แต่เมื่อจำเป็นต้องมีความน่าเชื่อถือและการรับประกันลำดับ โปรโตคอลอย่าง QUIC เป็นตัวเลือกที่ดีกว่า
5. ความสำคัญของการเลือกเทคโนโลยี: การเลือกโปรโตคอลขนส่งที่เหมาะกับความต้องการของแอปพลิเคชันเป็นเรื่องสำคัญ การเลือกผิดอาจทำให้ประสิทธิภาพลดลงและประสบการณ์ผู้ใช้แย่ลง

[GN⁺]

ความเห็นจาก Hacker News

• ปัญหาของ TCP: TCP มีปัญหามากในสภาพแวดล้อมที่ต้องการแบนด์วิดท์สูงและ latency ต่ำ และยังไม่มีประสิทธิภาพในเครือข่ายแบนด์วิดท์ต่ำแต่ latency สูงด้วย
• กรณีใช้งานของ UDP: มีการใช้ UDP สำหรับสตรีมข้อมูลเซนเซอร์ความถี่สูง และยังมีกรณีที่แก้ปัญหาผ่าน QUIC ได้เช่นกัน
• คำเรียกของ UDP: การอธิบาย UDP ว่าเป็น "best-effort" อาจเหมาะสมกว่าการบอกว่า "ไม่น่าเชื่อถือ"
• ปัญหาของ stream abstraction: stream abstraction ทำให้โปรแกรมเปราะบาง และการกู้คืนเมื่อการเชื่อมต่อหลุดทำได้ช้า แนวทางแบบ datagram อาจมีประสิทธิภาพมากกว่า
• การดรอปแพ็กเก็ต UDP: เมื่อเครือข่ายแออัด แพ็กเก็ต UDP จะถูกดรอปก่อน และมีการกล่าวถึงปัญหาการส่งซ้ำของ QUIC
• พาดหัวแบบคลิกเบต: เป็นความพยายามที่จะปฏิบัติตามแนวทางของ Hacker News ที่ให้ใช้พาดหัวตามต้นฉบับของบทความ
• ความแตกต่างระหว่าง TCP กับ UDP: TCP ให้ความน่าเชื่อถือ ส่วน UDP ให้ความเร็วและประสิทธิภาพ จึงควรเข้าใจคุณลักษณะของแต่ละโปรโตคอลแล้วเลือกใช้ให้เหมาะสม
• กรณีใช้งานที่เหมาะกับ datagram: การค้นหาอุปกรณ์ในเครือข่ายภายใน, การ broadcast, การห่อหุ้มแพ็กเก็ต เป็นต้น เป็นงานที่เหมาะกับการใช้ datagram
• คำแนะนำในการใช้ datagram: แม้การเชื่อมต่อแบบอิงเซสชันจะเป็นเรื่องทั่วไป แต่การใช้ datagram ก็มีประโยชน์ และเป็นโอกาสที่ดีในการเรียนรู้แง่มุมระดับล่างของระบบเครือข่าย