9.9. UDP -- ส่งแพ็กเก็ตแล้วหวังว่าจะดีที่สุด¶
UDP หรือ User Datagram Protocol คือบริการที่ง่ายกว่าในสองบริการที่เลเยอร์การส่งเสนอ การส่ง UDP แต่ละครั้งคือ datagram หนึ่งรายการ ซึ่งเป็นกลุ่มไบต์ที่บรรจุในตัวเองที่มีที่อยู่ IP และ port โยนเข้าไปในเครือข่ายด้วยตัวเอง โปรโตคอลจะส่งถ้าทำได้ ถ้าไม่ได้ก็ไม่ลองใหม่ ไม่แจ้งผู้ส่ง และไม่รักษาการเรียงลำดับระหว่าง datagram
9.9.1. สิ่งที่ UDP เพิ่มเติมจาก IP¶
UDP เป็นเลเยอร์บาง ๆ บน IP โดยเพิ่มสามสิ่งให้กับการส่งผ่าน IP ดิบ:
หมายเลข port ที่ทั้งสองปลาย เพื่อให้ datagram สามารถส่งถึง โปรแกรม ที่ถูกต้องบนโฮสต์ปลายทาง ไม่ใช่แค่โฮสต์ (ดู Ports)
ฟิลด์ความยาว เพื่อให้ผู้รับรู้แน่ชัดว่าต้องอ่านไบต์ payload กี่ไบต์
checksum ขนาดเล็ก บน header และ payload เพื่อให้ผู้รับตรวจจับ datagram ที่เสียหายและทิ้งมันได้
เท่านั้น ทุกอย่างอื่นที่ IP ทำหรือไม่ทำ UDP คงไว้ datagram จะไม่ถูกลองใหม่ อาจมาถึงไม่เป็นลำดับ อาจถูกทำซ้ำโดยข้อบกพร่องของเครือข่ายพื้นฐาน อาจถูกทิ้งอย่างเงียบ ๆ ถ้าเครือข่ายแออัด บัฟเฟอร์ที่ปลายทางเต็ม หรือหนึ่งในเราเตอร์กลางตัดสินใจเช่นนั้น
UDP datagram แต่ละรายการถูกส่งอย่างอิสระ ถ้ารายการใดสูญหายระหว่างทาง ไม่มีอะไรบอกผู้ส่งหรือผู้รับ -- ช่องว่างนั้นเงียบ¶
9.9.2. เหตุใดจึงมีคนใช้มัน¶
ถ้า UDP ไม่น่าเชื่อถือเช่นนั้น ทำไมต้องมีมันอยู่เลย? สามเหตุผล
ความเร็วและ overhead การส่ง UDP คือแพ็กเก็ตเดียวที่ออกไป ไม่มีการจับมือกัน ไม่มีการยืนยัน ไม่มีสถานะการเชื่อมต่อต้องรักษา เวลาแฝงและต้นทุนแบนด์วิดท์น้อยที่สุด
ข้อความอิสระ การสื่อสารบางประเภทเป็นสตรีมของ การอัปเดตสถานะ ที่ทุกข้อความเป็นสแนปช็อตใหม่และข้อเก่าไม่มีคุณค่า กล้องที่เผยแพร่ "ฉันยังมีชีวิตอยู่ นี่คือการอ่านปัจจุบัน" ทุกวินาทีสนใจในการส่งการอ่าน ใหม่ แต่ละครั้ง ไม่ใช่การเล่นซ้ำการอ่านที่หายไป
Multicast UDP datagram เดียวสามารถส่งไปยังผู้รับหลายคนพร้อมกัน (TCP ไม่สามารถทำได้ ทุกการเชื่อมต่อ TCP อยู่ระหว่างสองจุดปลายทางพอดี) มีประโยชน์สำหรับการค้นพบบริการ telemetry ไปยังผู้ฟังหลายคน การสตรีมวิดีโอ
ที่ที่เครือข่ายดีและความทนทานของผู้ส่งต่อการสูญหายสูง UDP คือคำตอบที่ถูกต้อง ที่ที่ต้องรับประกันการส่งและการเรียงลำดับ UDP ต้องการเลเยอร์ความน่าเชื่อถืออีกชั้นบน หรือแอปพลิเคชันควรใช้ TCP แทน
9.9.3. เมื่อ ไม่ ควรใช้มัน¶
ตรงกันข้ามก็ควรระบุให้ชัดเจนเช่นกัน UDP เป็นตัวเลือกที่ผิดเมื่อ:
ทุกไบต์มีความสำคัญ ข้อมูลการกำหนดค่า การอัปเดตโค้ด ธุรกรรมที่ลงนาม -- กรณีใดก็ตามที่ไบต์ที่หายไปทำให้ผลลัพธ์ผิดพลาด
ลำดับมีความสำคัญ UDP datagram 2 อาจมาถึงก่อน datagram 1
ข้อความมีขนาดใหญ่ payload ขนาดใหญ่ต้องถูกแบ่งเป็น datagram ขนาดเล็กโดยแอปพลิเคชัน เลเยอร์การส่งจะไม่ทำให้ ถ้าชิ้นใดหายไปข้อความทั้งหมดไม่สมบูรณ์
ถ้าข้อใดข้อหนึ่งเหล่านั้นใช้ได้ ให้เลือก TCP แทน
9.9.4. ตัวอย่างที่เป็นรูปธรรมบนกล้อง¶
ตัวอย่าง UDP traffic ฝั่งกล้องในสภาพแวดล้อมจริง:
การค้นพบ กล้องกระจาย datagram "ใครอยู่ที่นี่" ไปยังเครือข่ายท้องถิ่นเมื่อเริ่มต้น อุปกรณ์อื่นตอบกลับ
Telemetry ทุกวินาที กล้องส่ง datagram ขนาดเล็กพร้อมการอ่านค่า sensor ปัจจุบันไปยังตัวรวบรวม การสูญเสียตัวอย่างบางครั้งไม่สำคัญเพราะตัวต่อไปจะมาถึงในอีกวินาที
การซิงโครไนซ์เวลา NTP โปรโตคอลเวลาของเครือข่าย ทำงานบน UDP client ส่งคำขอขนาดเล็ก server ตอบด้วยเวลาปัจจุบัน ถ้าการตอบกลับสูญหาย client จะถามอีกครั้งในภายหลัง
การค้นหา DNS การถามเครือข่ายว่า "IP ใดที่ชื่อนี้แมปไปยัง?" ทำงานบน UDP (ครอบคลุมใน ชื่อและ DNS)
Python API สำหรับการส่งและรับ datagram อยู่ที่ UDP sockets หลังจากเรื่องราวที่เหลือของเลเยอร์การส่งอยู่ในที่แล้ว