UDP และการขนส่งแบบ Connectionless

User Datagram Protocol (UDP) คือการขนส่งแบบ connectionless ที่มีน้ำหนักเบาของอินเทอร์เน็ต โดยเพิ่มการมัลติเพล็กซ์กระบวนการและการตรวจสอบผลรวม (checksum) ที่เป็นทางเลือกเล็กน้อยให้กับบริการแบบ best-effort ของ IP ดังนั้นแอปพลิเคชันจึงได้รับค่าใช้จ่ายและเวลาแฝงที่น้อยที่สุด โดยแลกกับการรับประกันความน่าเชื่อถือ

Definition

User Datagram Protocol (UDP) คือโปรโตคอลชั้นการขนส่งแบบ connectionless ที่ให้บริการแบบ best-effort, เน้นข้อความ (message-oriented) ระหว่างกระบวนการ โดยเพิ่มการมัลติเพล็กซ์ตามพอร์ตและการตรวจสอบผลรวมที่เป็นทางเลือกให้กับชั้นเครือข่าย แต่ไม่มีการรับประกันความน่าเชื่อถือ, ลำดับ, การควบคุมการไหล หรือการควบคุมการแออัด

Scope

หัวข้อนี้ครอบคลุมการขนส่งแบบ connectionless: รูปแบบเซ็กเมนต์ UDP, การมัลติเพล็กซ์และการดีมัลติเพล็กซ์ผ่านหมายเลขพอร์ต, การตรวจสอบผลรวมที่เป็นทางเลือก, และเหตุผลที่แอปพลิเคชันจะเลือกใช้ UDP แทน TCP — ไม่มีเวลาหน่วงในการตั้งค่าการเชื่อมต่อ, ไม่มีการควบคุมการแออัด, การควบคุมที่ละเอียดขึ้นว่าจะส่งอะไรและเมื่อใด, และค่าใช้จ่ายต่อแพ็กเก็ตที่น้อย หัวข้อนี้สำรวจแอปพลิเคชันที่ใช้ UDP ทั่วไปและความรับผิดชอบ (เช่น ความน่าเชื่อถือหรือการควบคุมอัตรา) ที่เปลี่ยนไปอยู่กับแอปพลิเคชัน หัวข้อนี้ไม่รวมกลไกความน่าเชื่อถือและการแออัดของ TCP

Core questions

• UDP เพิ่มบริการขั้นต่ำอะไรบ้างบน IP?
• UDP ทำการมัลติเพล็กซ์และดีมัลติเพล็กซ์ข้อมูลโดยใช้หมายเลขพอร์ตได้อย่างไร?
• เหตุใดแอปพลิเคชันจึงควรเลือกใช้ UDP แทน TCP?
• ความรับผิดชอบใดบ้าง เช่น ความน่าเชื่อถือและการควบคุมอัตรา ที่เปลี่ยนไปอยู่กับแอปพลิเคชันเมื่อใช้ UDP?
• แอปพลิเคชันประเภทใดบ้างที่มักจะใช้ UDP?

Key concepts

• บริการแบบ connectionless
• การวางแนวแบบดาต้าแกรม (ข้อความ)
• รูปแบบเซ็กเมนต์ UDP
• การมัลติเพล็กซ์/ดีมัลติเพล็กซ์ตามพอร์ต
• การตรวจสอบผลรวมที่เป็นทางเลือก
• ค่าใช้จ่ายและเวลาแฝงต่ำ
• ไม่มีการควบคุมการแออัด
• ความน่าเชื่อถือระดับแอปพลิเคชัน

Key theories

บริการแบบ connectionless ขั้นต่ำ

UDP เปิดเผยบริการดาต้าแกรมแบบ best-effort ของ IP ให้กับแอปพลิเคชันโดยแทบไม่เปลี่ยนแปลง โดยเพิ่มเพียงการมัลติเพล็กซ์ตามพอร์ตและการตรวจสอบผลรวมที่เป็นทางเลือกเท่านั้น ดังนั้นจึงไม่มีการตั้งค่า, ไม่มีสถานะ, และไม่มีการกู้คืนอัตโนมัติ — แลกเปลี่ยนการรับประกันด้วยความเรียบง่ายและเวลาแฝงต่ำ

การขนส่งที่ควบคุมโดยแอปพลิเคชัน

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

Clinical relevance

UDP เป็นรากฐานของบริการที่เวลาแฝงต่ำหรือการควบคุมที่ละเอียดมีความสำคัญมากกว่าการรับประกันการส่งมอบ: การค้นหา DNS, เสียงและวิดีโอแบบเรียลไทม์, เกมออนไลน์ และการจัดการเครือข่าย การขนส่งใหม่ๆ เช่น QUIC ถูกสร้างขึ้นบน UDP เพื่อให้สามารถควบคุมการขนส่งได้ในขณะที่หลีกเลี่ยงข้อจำกัดของ TCP ทำให้การขนส่งแบบ connectionless เป็นหัวใจสำคัญของเครือข่ายที่มีเวลาแฝงต่ำในปัจจุบัน

History

UDP ถูกระบุไว้ใน RFC 768 (1980) ในฐานะการขนส่งขั้นต่ำสำหรับแอปพลิเคชันที่ไม่ต้องการกลไกของ TCP เมื่อ TCP และ IP ถูกแยกออกเป็นโปรโตคอลที่แตกต่างกัน UDP ยังคงไม่เปลี่ยนแปลงโดยพื้นฐาน และบทบาทของมันได้เติบโตขึ้นเมื่อแอปพลิเคชันที่อ่อนไหวต่อเวลาแฝงมีจำนวนมากขึ้น และเมื่อนักพัฒนาสร้างคุณสมบัติการขนส่งใหม่ๆ รวมถึงโปรโตคอล QUIC บน UDP

Key figures

• Jon Postel
• James F. Kurose
• Keith W. Ross

Seminal works

• rfc768
• kurose2021

Frequently asked questions

ถ้า UDP ไม่น่าเชื่อถือ แล้วทำไมถึงยังใช้?

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

UDP ทำอะไรได้มากกว่า IP หรือไม่?

ได้ แต่เพียงเล็กน้อย UDP เพิ่มหมายเลขพอร์ตเพื่อให้ข้อมูลไปถึงกระบวนการแอปพลิเคชันที่ถูกต้องบนโฮสต์ (การมัลติเพล็กซ์และการดีมัลติเพล็กซ์) และการตรวจสอบผลรวมที่เป็นทางเลือกเพื่อตรวจจับความเสียหาย นอกเหนือจากนั้น UDP ยังคงการส่งมอบแบบ best-effort, connectionless ของ IP ไว้ไม่เปลี่ยนแปลง