ธรรมชาติที่แท้จริงของ UDP ก่อให้เกิดการถกเถียงร้อนระอุในหมู่ผู้พัฒนา

ในโลกของเครือข่าย มีหัวข้อไม่กี่เรื่องที่ก่อให้เกิดการอภิปรายอย่างเร่าร้อนได้เท่ากับธรรมชาติพื้นฐานของ UDP บทความล่าสุดที่เปรียบเทียบ UDP กับรถเปิดประทุนได้จุดประกายการถกเถียงอย่างดุเดือดในหมู่ผู้พัฒนา วิศวกร และผู้เชี่ยวชาญด้านเครือข่ายเกี่ยวกับว่า UDP คืออะไรกันแน่ และเราควรคิดเกี่ยวกับมันอย่างไร

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

ความขัดแย้งหลัก: โปรโตคอลการขนส่งหรือส่วนประกอบพื้นฐาน?

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

มุมมองนี้มองว่า UDP เป็นพื้นฐานหลัก—การ multiplexing และ checksums—ที่ผู้พัฒนาสามารถใช้สร้างความหมายของการขนส่งใดๆ ก็ได้ตามที่ต้องการ จากมุมมองนี้ การเปรียบเทียบ UDP กับ TCP ก็เหมือนกับการบอกว่า TCP แย่กว่าการจัดการ URL เมื่อเทียบกับ HTTP—มันเป็นการเข้าใจผิดประเภท

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

ผู้คิดค้น UDP อาจตั้งใจอย่างหนึ่งเมื่อ 45 ปีที่แล้ว แต่ไม่ได้หมายความว่านั่นเป็นวิธีเดียวที่มันเกิดขึ้นจริง

ความเป็นจริงในทางปฏิบัติ: เมื่อความไม่น่าเชื่อถือกลายเป็นคุณสมบัติ

นอกเหนือจากการอภิปรายทางทฤษฎีแล้ว ผู้พัฒนากำลังพูดถึงผลกระทบในทางปฏิบัติของการออกแบบ UDP หลายคนตั้งข้อสังเกตว่าการที่ UDP ไม่มีคุณสมบัติความน่าเชื่อถือในตัวไม่ใช่ข้อบกพร่อง—มันเป็นคุณสมบัติสำหรับกรณีใช้เฉพาะ

แอปพลิเคชันเช่นเกมแบบผู้เล่นหลายคน การสตรีมวิดีโอสด และระบบ telemetry มักให้ความสำคัญกับความทันเวลามากกว่าความสมบูรณ์ ในสถานการณ์เหล่านี้ การรับข้อมูลล่าสุดอย่างรวดเร็วมีค่ามากกว่าการรับประกันการส่งทุกรายการ packet ดังที่ผู้แสดงความคิดเห็นหนึ่งระบุ UDP เหมาะอย่างยิ่งสำหรับสถานการณ์ที่คุณกำลังส่งค่า 100,000 ค่าล่าสุดภายในวินาทีที่ผ่านมา มากกว่าคำสั่งที่สำคัญซึ่งการสูญเสีย packet เดียวอาจเป็นหายนะ

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

โปรโตคอลที่ใช้ UDP ทั่วไป

DNS (Domain Name System) NTP (Network Time Protocol) DHCP (Dynamic Host Configuration Protocol) RTP (Real-time Transport Protocol) QUIC (Quick UDP Internet Connections) โปรโตคอลเกมออนไลน์แบบผู้เล่นหลายคนแบบดั้งเดิม

ปัญหา Middlebox และวิวัฒนาการของโปรโตคอล

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

การแพร่หลายของ middleboxes—ไฟร์วอลล์, NAT และอุปกรณ์เครือข่ายอื่นๆ ที่ตรวจสอบและกรอง traffic—ทำให้การปรับใช้โปรโตคอล Layer 4 ใหม่แทบจะเป็นไปไม่ได้เลย ความจริงนี้ได้ผลักดันนวัตกรรมไปสู่การสร้างบน UDP ดังที่แสดงให้เห็นโดยความสำเร็จของ QUIC ในการพัฒนาการขนส่งเว็บในขณะที่ยังคงความเข้ากันได้กับโครงสร้างพื้นฐานที่มีอยู่

ผู้พัฒนาบางคนแสดงความไม่พอใจกับสถานการณ์นี้ โดยหวังให้มีกฎไฟร์วอลล์ที่ยืดหยุ่นมากขึ้นซึ่งสามารถอนุญาตการกำหนดประเภท stream/443 และ dgram/53 ได้ แทนที่จะถูกล็อกไว้กับ TCP และ UDP โดยเฉพาะ

ความน่าเชื่อถือ: การรับประกันเทียบกับผลลัพธ์ในทางปฏิบัติ

การสนทนายังเจาะลึกถึงว่าความน่าเชื่อถือหมายถึงอะไรในทางปฏิบัติ ในขณะที่ TCP ให้การรับประกันเฉพาะเกี่ยวกับการส่งตามลำดับและการยืนยัน receipt ผู้แสดงความคิดเห็นหลายคนตั้งข้อสังเกตว่าการรับประกันเหล่านี้ไม่จำเป็นต้องแปลเป็นพฤติกรรมแอปพลิเคชันที่เชื่อถือได้

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

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

การเปรียบเทียบโปรโตคอลหลัก

อนาคตของ UDP ในโลก QUIC

เมื่อมองไปข้างหน้า ผู้พัฒนากำลังพิจารณาบทบาทของ UDP ในขณะที่ QUIC กำลังแพร่หลายมากขึ้น ในขณะที่ QUIC สร้างบน UDP เพื่อให้ความน่าเชื่อถือแบบ TCP พร้อมกับการปรับปรุงที่ทันสมัย บางคนกังวลว่ามันแสดงถึงการแก้ปัญหาแบบ one size fits all อีกอย่างหนึ่งที่ไม่ยอมให้มีความยืดหยุ่นที่ทำให้ UDP มีค่า

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

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

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

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

อ้างอิง: UDP Isn't Unreliable, It's a Convertible