เมื่อใดจึงเหมาะสมที่จะใช้ UDP แทน TCP [ปิด]

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

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

นี่เป็นหนึ่งในคำถามที่ฉันชอบ UDP เข้าใจผิดมาก

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

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

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

อีกกรณีหนึ่งสำหรับการรับส่งข้อมูลแบบหลายผู้รับ UDP สามารถ multicast ไปยังหลาย ๆ โฮสต์ในขณะที่ TCP ไม่สามารถทำได้

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

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

"ความไม่น่าเชื่อถือ" ของ UDP เป็นพิธีการ การส่งไม่รับประกันอย่างแน่นอน เป็นเรื่องจริงพวกเขามักจะผ่าน พวกเขาไม่ได้รับการตอบกลับและลองใหม่หลังจากหมดเวลา

ค่าใช้จ่ายในการเจรจาซ็อกเก็ต TCP และการจับแพ็คเก็ต TCP มีขนาดใหญ่มาก ใหญ่มากจริงๆ ไม่มีค่าใช้จ่าย UDP ที่ประเมินค่าได้

สิ่งสำคัญที่สุดคือคุณสามารถเสริม UDP ได้อย่างง่ายดายด้วยการส่งมอบด้วยมือที่เชื่อถือได้ซึ่งค่าใช้จ่ายน้อยกว่า TCP อ่านสิ่งนี้: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDP มีประโยชน์สำหรับการเผยแพร่ข้อมูลในแอปพลิเคชั่นที่ประกาศรับสมัคร IIRC, TIBCO ใช้ UDP อย่างหนักเพื่อแจ้งการเปลี่ยนแปลงสถานะ

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

ข้อความระบบ "heartbeat" หรือ "I'm alive" เป็นตัวเลือกที่ดีเช่นกัน สิ่งที่ขาดหายไปไม่ใช่วิกฤต ไม่มีครึ่งโหล (เป็นแถว) คือ

ฉันทำงานกับผลิตภัณฑ์ที่รองรับการสื่อสาร UDP (IP) และ TCP / IP ระหว่างไคลเอนต์และเซิร์ฟเวอร์ มันเริ่มต้นด้วย IPX เมื่อ 15 ปีที่แล้วด้วยการสนับสนุน IP เพิ่มเมื่อ 13 ปีที่แล้ว เราเพิ่มการสนับสนุน TCP / IP 3 หรือ 4 ปีที่แล้ว คาดเดาอย่างรวดเร็ว: อัตราส่วนโค้ด UDP ถึง TCP น่าจะอยู่ที่ประมาณ 80/20 ผลิตภัณฑ์เป็นเซิร์ฟเวอร์ฐานข้อมูลดังนั้นความน่าเชื่อถือจึงเป็นสิ่งสำคัญ เราต้องจัดการกับปัญหาทั้งหมดที่กำหนดโดย UDP (การสูญเสียตแพ็กเก็ต, การแพ็คเก็ตสองเท่า, การสั่งซื้อแพ็คเก็ต, ฯลฯ ) ที่กล่าวถึงแล้วในคำตอบอื่น ๆ ไม่ค่อยมีปัญหาใด ๆ แต่บางครั้งก็เกิดขึ้นและต้องจัดการ ประโยชน์ที่จะได้รับจากการสนับสนุน UDP คือเราสามารถปรับแต่งให้เหมาะกับการใช้งานของเราเองและปรับแต่งประสิทธิภาพให้เพิ่มขึ้นอีกเล็กน้อย

ทุกเครือข่ายจะแตกต่างกัน แต่โปรโตคอลการสื่อสาร UDP โดยทั่วไปแล้วจะเร็วขึ้นเล็กน้อยสำหรับเรา ผู้อ่านที่สงสัยจะถามคำถามว่าเราใช้ทุกอย่างถูกต้องหรือไม่ นอกจากนี้สิ่งที่คุณคาดหวังจากคนที่มีตัวแทน 2 หลัก? อย่างไรก็ตามตอนนี้ฉันเพิ่งจะทดสอบความอยากรู้อยากเห็น การทดสอบอ่าน 1 ล้านบันทึก (เลือก * จากบางครั้ง) ฉันตั้งค่าจำนวนของเรกคอร์ดที่จะกลับมาพร้อมกับคำขอของลูกค้าแต่ละรายให้เป็น 1, 10 และจากนั้น 100 (ทดสอบสามรันกับแต่ละโปรโตคอล) เซิร์ฟเวอร์เพียงสองฮ็อปออกจาก LAN 100Mbit ตัวเลขดูเหมือนจะเห็นด้วยกับสิ่งที่คนอื่นเคยพบในอดีต (UDP เร็วขึ้นประมาณ 5% ในสถานการณ์ส่วนใหญ่) เวลารวมเป็นมิลลิวินาทีสำหรับการทดสอบเฉพาะนี้:

1. 1 บันทึก
   • IP: 390,760 ms
   • TCP: 416,903 ms
2. 10 บันทึก
   • IP: 91,707 ms
   • TCP: 95,662 ms
3. 100 บันทึก
   • IP: 29,664 ms
   • TCP: 30,968 ms

จำนวนข้อมูลทั้งหมดที่ส่งเป็นเรื่องเดียวกันสำหรับทั้ง IP และ TCP เรามีค่าใช้จ่ายเพิ่มเติมด้วยการสื่อสาร UDP เพราะเรามีสิ่งเดียวกันกับที่คุณได้รับ "ฟรี" ด้วย TCP / IP (checksums หมายเลขลำดับเป็นต้น) ตัวอย่างเช่น Wireshark แสดงให้เห็นว่าคำขอสำหรับชุดระเบียนถัดไปคือ 80 ไบต์ด้วย UDP และ 84 ไบต์ด้วย TCP

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

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

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

ผลลัพธ์คือ UDP สามารถ:

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

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

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

UDP เป็นโปรโตคอลที่ไม่มีการเชื่อมต่อและใช้ในโปรโตคอลเช่นSNMPและDNSซึ่งแพ็กเก็ตข้อมูลที่มาจากคำสั่งซื้อนั้นเป็นที่ยอมรับและมีการส่งข้อมูลแพคเก็ตข้อมูลทันที

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

มันถูกใช้ใน DNS เนื่องจากไม่เกี่ยวข้องกับการสร้างการเชื่อมต่อจึงหลีกเลี่ยงความล่าช้าในการสร้างการเชื่อมต่อ

ไชโย

หนึ่งในคำตอบที่ดีที่สุดที่ฉันรู้สำหรับคำถามนี้มาจากผู้ใช้ที่ zAy0LfpBZLC8mAC ข่าว คำตอบนี้ดีมากฉันแค่จะพูดตามที่เป็น

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

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

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

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

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

การสตรีมวิดีโอเป็นตัวอย่างที่สมบูรณ์แบบของการใช้ UDP

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

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

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

UDP นั้นง่ายกว่าในการเขียนโค้ดสำหรับทั้งสองด้านเนื่องจากคุณไม่จำเป็นต้องสร้างและบำรุงรักษาการเชื่อมต่อแบบจุดต่อจุด คำถามของฉันคือสถานการณ์ที่คุณต้องการใช้โอเวอร์เฮดของ TCP อยู่ที่ไหน และถ้าคุณใช้ทางลัดเช่นสมมติว่าได้รับ "แพ็คเก็ต" TCP เป็นแพ็กเก็ตที่สมบูรณ์ที่ถูกส่งคุณจะดีกว่าไหม? (คุณมีแนวโน้มที่จะทิ้งสองแพ็คเก็ตถ้าคุณรำคาญที่จะตรวจสอบความยาว / เนื้อหา)

การสื่อสารผ่านเครือข่ายสำหรับวิดีโอเกมนั้นทำผ่าน UDP เกือบทุกครั้ง

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

คำถามสำคัญเกี่ยวข้องกับ "สถานการณ์แบบไหนที่ UDP จะเป็นตัวเลือกที่ดีกว่า [over tcp]"

มีคำตอบที่ดีมากมายด้านบน แต่สิ่งที่ขาดคือการประเมินผลกระทบของความไม่แน่นอนของการขนส่งที่มีต่อประสิทธิภาพ TCP

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

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

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

กรณีเฉพาะหนึ่งกรณีที่คุณต้องการใช้ UDP แทน TCP คือที่ที่คุณกำลังขุดอุโมงค์ TCP ผ่านโปรโตคอลอื่น (เช่นอุโมงค์เครือข่ายเสมือน ฯลฯ ) หากคุณขุดอุโมงค์ TCP ผ่าน TCP การควบคุมความแออัดของแต่ละคนจะรบกวนซึ่งกันและกัน ดังนั้นโดยทั่วไปแล้วหนึ่งคนชอบที่จะทันเนล TCP ผ่าน UDP (หรือโปรโตคอลไร้สัญชาติอื่น ๆ ) ดูบทความ TechRepublic: เข้าใจ TCP ผ่าน TCP: ผลกระทบจาก TCP Tunneling บน End-to-End ทางเข้าและแฝง

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

UDP เมื่อจำเป็นต้องใช้ความเร็วและความแม่นยำหากแพ็กเก็ตไม่ใช่และ TCP เมื่อคุณต้องการความแม่นยำ

UDP มักจะยากกว่าที่คุณจะต้องเขียนโปรแกรมของคุณในลักษณะที่ไม่ได้ขึ้นอยู่กับความถูกต้องของแพ็กเก็ต

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

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

นอกจากนี้ยังเหมาะสมเมื่อคุณต้องการออกอากาศข้อมูลเดียวกันกับผู้ใช้หลายคน

ในบางครั้งก็เหมาะสมเมื่อคุณส่งข้อมูลตามลำดับ แต่หากบางส่วนหายไปคุณจะไม่กังวลเกินไป (เช่นแอปพลิเคชัน VOIP)

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

ตัวอย่างของการใช้ / สามารถใช้ 1) เซิร์ฟเวอร์เวลาออกอากาศเวลาที่ถูกต้องไปยังเครือข่ายของเครื่องบน LAN 2) โปรโตคอล VOIP 3) การค้นหา DNS 4) การร้องขอบริการ LAN เช่นคุณอยู่ที่ไหน 5) วิทยุอินเทอร์เน็ต 6) และอื่น ๆ อีกมากมาย ...

บนยูนิกซ์คุณสามารถพิมพ์ grep udp / etc / services เพื่อรับรายการโพรโทคอล UDP ที่นำมาใช้ในวันนี้ ... มีหลายร้อยรายการ

ดูหัวข้อ 22.4 ของการเขียนโปรแกรม Unix Networkของ Steven "เมื่อใดควรใช้ UDP แทน TCP"

ดูคำตอบอื่น ๆ ของ SO เกี่ยวกับความเข้าใจผิดที่ UDP เร็วกว่า TCPTCP

สิ่งที่สตีเว่นกล่าวสามารถสรุปได้ดังต่อไปนี้:

• ใช้ UDP สำหรับการออกอากาศและมัลติคาสต์เนื่องจากเป็นตัวเลือกเดียวของคุณ (ใช้มัลติคาสต์สำหรับแอพใหม่ใด ๆ )
• คุณสามารถใช้ UDP สำหรับแอปคำขอ / ตอบง่ายๆ แต่คุณต้องสร้างในเวลาตอบรับของคุณเองหมดเวลาและการส่งสัญญาณใหม่
• อย่าใช้ UDP สำหรับการถ่ายโอนข้อมูลจำนวนมาก

เรารู้ว่า UDP เป็นโปรโตคอลที่ไม่มีการเชื่อมต่อดังนั้นมันจึงเป็น

1. เหมาะสำหรับกระบวนการที่ต้องการการสื่อสารตอบสนองคำขอที่เรียบง่าย
2. เหมาะสำหรับกระบวนการที่มีการไหลภายในการควบคุมข้อผิดพลาด
3. เหมาะสำหรับการหล่อแบบกว้างและมัลติคาสต์

ตัวอย่างเฉพาะ:

• ใช้ใน SNMP
• ใช้สำหรับการอัพเดตโปรโตคอลบางเส้นทางเช่น RIP

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

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

เรามีบริการบนเว็บที่มีไคลเอนต์ winforms หลายพันเครื่องในพีซีหลายเครื่อง พีซีไม่มีการเชื่อมต่อกับแบ็กเอนด์ DB การเข้าถึงทั้งหมดผ่านทางบริการเว็บ ดังนั้นเราจึงตัดสินใจที่จะพัฒนาเซิร์ฟเวอร์การบันทึกกลางที่ฟังพอร์ต UDP และไคลเอนต์ทั้งหมดส่งแพ็คเก็ตบันทึกข้อผิดพลาด xml (โดยใช้ app4 log4net UDP) ที่ได้รับการทิ้งลงในตารางฐานข้อมูลเมื่อได้รับ เนื่องจากเราไม่สนใจจริงๆหากพลาดบันทึกข้อผิดพลาดเล็กน้อยและมีลูกค้านับพันรายจึงรวดเร็วด้วยบริการบันทึกเฉพาะที่ไม่โหลดบริการเว็บหลัก

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

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

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

TCP ควรได้รับการคาดหวังว่าจะได้เร็วขึ้นมากกับการ์ดเชื่อมต่อเครือข่ายที่ทันสมัยเนื่องจากสิ่งที่เรียกว่าการตรวจสอบของสำนักพิมพ์ น่าแปลกใจที่ความเร็วการเชื่อมต่อที่รวดเร็ว (เช่น 1Gbps) การตรวจสอบการประมวลผลจะเป็นภาระที่ยิ่งใหญ่สำหรับ CPU ดังนั้นจึงถูกถ่ายโอนไปยังฮาร์ดแวร์ NICที่รับรู้แพ็คเก็ต TCP สำหรับสำนักพิมพ์และจะไม่ให้บริการเดียวกันกับคุณ

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