UDP: คืออะไร โปรโตคอลแบบไม่มีการเชื่อมต่อและทำงานอย่างไร

UDP คืออะไร?

UDP (User Datagram Protocol) เป็นหนึ่งในโปรโตคอลหลักของเลเยอร์ขนส่งในแบบจำลอง TCP/IP ออกแบบโดย David Reed ในปี 1980 โดยมีกลไกการส่งข้อมูลที่น้อยที่สุด: แอปพลิเคชันส่งดาต้าแกรม และโปรโตคอลไม่ติดตามว่ามันถึงผู้รับหรือไม่

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

โปรโตคอลไม่รองรับการแยกส่วนในระดับของตัวเอง — หากดาต้าแกรมเกิน MTU (Maximum Transmission Unit) มันจะถูกแยกส่วนที่ระดับ IP หากส่วนใดสูญหาย ดาต้าแกรมทั้งหมดจะถูกทิ้ง เนื่องจาก UDP ไม่สามารถขอให้ส่งซ้ำแต่ละส่วนได้ นักพัฒนาต้องควบคุมขนาดของดาต้าแกรม — สำหรับเครือข่ายมือถือ MTU มักอยู่ที่ 1400 ไบต์ ดังนั้นขนาดสูงสุดไม่ควรเกินค่านี้

UDP ทำงานอย่างไร

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

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

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(b'Hello, UDP!', ('192.168.1.100', 8888))
sock.close()

ในตัวอย่างนี้ มีการสร้างซ็อกเก็ต SOCK_DGRAM สำหรับ UDP เมธอด sendto ส่งดาต้าแกรมโดยไม่ต้องสร้างการเชื่อมต่อ — เพียงรู้ IP และพอร์ตของผู้รับก็พอ เมธอด recvfrom ฝั่งเซิร์ฟเวอร์จะส่งคืนทั้งข้อมูลและที่อยู่ของผู้ส่งสำหรับการตอบกลับ ซ็อกเก็ต UDP บนแพลตฟอร์มมือถือถูกกำหนดค่าในลักษณะเดียวกัน แต่ต้องได้รับอนุญาตเพิ่มเติม: บน iOS ต้องเพิ่ม NSAppTransportSecurity สำหรับการเชื่อมต่อ UDP ที่ไม่เข้ารหัส และบน Android ต้องได้รับอนุญาต INTERNET ใน Manifest

ข้อดีและข้อเสียของ UDP

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

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

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

UDP ใช้ที่ไหนบ้าง

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

สตรีมมิ่งเสียงและวิดีโอ

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

เกมออนไลน์

เกมยิงมุมมองบุคคลที่หนึ่งแบบหลายผู้เล่นและ MOBA ต้องการความหน่วงต่ำกว่า 50 ms เพื่อการซิงโครไนซ์ที่เหมาะสม UDP ส่งตำแหน่งผู้เล่น การยิง และเหตุการณ์ได้เร็วกว่า TCP และการสูญเสียแพ็กเก็ตจะถูกมองข้าม — การอัปเดตครั้งต่อไปจะมาใน 16–33 ms เอนจินเกมยอดนิยม รวมถึง Unity และ Unreal Engine ใช้ UDP ผ่านเลเยอร์การขนส่งของตัวเอง โดยเพิ่มความน่าเชื่อถือสำหรับเหตุการณ์สำคัญผ่านการยืนยันในระดับแอปพลิเคชัน

DNS และ DHCP

การค้นหา DNS ใช้ UDP บนพอร์ต 53 เนื่องจากการค้นหาแต่ละครั้งเป็นดาต้าแกรมขนาดเล็กเดี่ยว (ปกติสูงสุด 512 ไบต์) หากไม่ได้รับการตอบกลับ ไคลเอ็นต์จะลองค้นหาอีกครั้งหลังจากหมดเวลา ซึ่งเร็วกว่าการสร้างการเชื่อมต่อ TCP ด้วยการจับมือสามทาง DHCP ก็ทำงานบน UDP เช่นกัน เนื่องจากไคลเอ็นต์ยังไม่มีที่อยู่ IP และไม่สามารถสร้างการเชื่อมต่อ TCP ได้ ในขณะที่แพ็กเก็ต UDP แบบบรอดคาสต์ช่วยให้ค้นหาเซิร์ฟเวอร์ DHCP ในเครือข่ายท้องถิ่น

การเปรียบเทียบ UDP และ TCP

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

โปรเจกต์มือถือมักใช้แนวทางแบบผสม: TCP สำหรับคำขอที่เชื่อถือได้ (การยืนยันตัวตน การโหลดข้อมูล) และ UDP สำหรับสตรีมสื่อ QUIC — โปรโตคอลสมัยใหม่ของ Google ที่ทำงานบน UDP — ผสานความเร็วของ UDP เข้ากับความน่าเชื่อถือของ TCP และถูกใช้ใน HTTP/3 แล้ว

ตัวอย่างโค้ด UDP

มาดูเซิร์ฟเวอร์ UDP ง่ายๆ ใน Python ที่รับข้อความจากไคลเอ็นต์และส่งการตอบกลับ เซิร์ฟเวอร์ฟังพอร์ต 8888 และประมวลผลดาต้าแกรมที่เข้ามาในลูปไม่สิ้นสุด

import socket

server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
server.bind(('0.0.0.0', 8888))
print('เซิร์ฟเวอร์ UDP เริ่มทำงานบนพอร์ต 8888')

while True:
    data, addr = server.recvfrom(1024)
    print(f'ได้รับจาก {addr}: {data.decode()}')
    server.sendto(b'OK', addr)

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

ในการพัฒนามือถือ UDP มักถูกใช้ผ่านไลบรารีระดับสูง ตัวอย่างเช่น CocoaAsyncSocket สำหรับ iOS ให้ซ็อกเก็ต UDP พร้อมตัวแทนและ GCD สำหรับการจัดการเหตุการณ์แบบอะซิงโครนัส บน Android คลาส DatagramSocket เป็นส่วนหนึ่งของไลบรารีมาตรฐาน java.net และไม่ต้องการการพึ่งพาเพิ่มเติม สำหรับ Flutter มีแพ็คเกจ udp ที่ให้อินเทอร์เฟซง่ายๆ สำหรับการส่งและรับดาต้าแกรมโดยไม่ต้องกำหนดค่าซ็อกเก็ตพื้นเมือง

สิ่งสำคัญที่ควรทราบคือเครือข่ายมือถือและไฟร์วอลล์ขององค์กรหลายแห่งบล็อกการรับส่ง UDP โดยเฉพาะบนพอร์ตที่สูงกว่า 1024 หากแอปพลิเคชันของคุณใช้ UDP คุณต้องเตรียมการสำรองไปยัง TCP หรือตรวจสอบความพร้อมใช้งานของโปรโตคอลผ่านเซิร์ฟเวอร์ STUN เช่นที่ WebRTC ทำ บน iOS เฟรมเวิร์กระบบ Network.framework กับ NWConnection รองรับทั้ง TCP และ UDP โดยเลือกโปรโตคอลที่เหมาะสมที่สุดโดยอัตโนมัติตามความพร้อมใช้งาน สำหรับแอปพลิเคชันเรียลไทม์ ควรใช้อัตราบิตแบบปรับได้ ซึ่งลดคุณภาพสตรีมเมื่อสูญเสียแพ็กเก็ต เพื่อให้แน่ใจว่าการเล่นต่อเนื่องแม้ในช่องสัญญาณที่ไม่เสถียรซึ่งมีอัตราข้อผิดพลาดสูง