คุณใช้อะไรเมื่อคุณต้องการ UDP ที่เชื่อถือได้?

หากคุณมีสถานการณ์ที่การเชื่อมต่อ TCP อาจช้าเกินไปและ 'การเชื่อมต่อ' UDP อาจไม่น่าเชื่อถือเกินไปคุณใช้อะไร? มีโปรโตคอล UDP มาตรฐานที่เชื่อถือได้หลายแบบคุณมีประสบการณ์อะไรบ้าง?

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

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

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

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

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

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

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

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

สิ่งที่เกี่ยวกับSCTP เป็นโปรโตคอลมาตรฐานของ IETF (RFC 4960)

มีความสามารถในการแยกชิ้นส่วนซึ่งสามารถช่วยในเรื่องความเร็วได้

อัปเดต: การเปรียบเทียบระหว่าง TCP และ SCTPแสดงให้เห็นว่าการแสดงสามารถเทียบเคียงกันได้เว้นแต่จะสามารถใช้สองอินเทอร์เฟซ

การปรับปรุงที่: บทความแนะนำที่ดี

ENET - http://enet.bespin.org/

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

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

เรามีลูกค้าในอุตสาหกรรมป้องกันประเทศบางรายที่ใช้ UDT (UDP-based Data Transfer) (ดูhttp://udt.sourceforge.net/ ) และพอใจกับมันมาก ฉันเห็นว่ามีใบอนุญาต BSD ที่เป็นมิตรเช่นกัน

RUDP - โปรโตคอลดาต้าแกรมผู้ใช้ที่เชื่อถือได้

สิ่งนี้ให้:

• การรับแพ็คเก็ตที่ได้รับ
• การควบคุมหน้าต่างและความแออัด
• การส่งแพ็กเก็ตที่สูญหายอีกครั้ง
• Overbuffering (เร็วกว่าการสตรีมแบบเรียลไทม์)

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

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

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

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

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

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");

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

จุดเริ่มต้นที่ดีสำหรับ QUIC อยู่ที่นี่แล้วที่ Chromium Blog

ปัจจุบันเอกสารการออกแบบ QUIC สามารถพบได้ที่นี่

หากคุณมีสถานการณ์ที่การเชื่อมต่อ TCP อาจช้าเกินไปและ 'การเชื่อมต่อ' UDP อาจไม่น่าเชื่อถือเกินไปคุณใช้อะไร? มีโปรโตคอล UDP มาตรฐานที่เชื่อถือได้หลายแบบคุณมีประสบการณ์อะไรบ้าง?

คำสำคัญในประโยคของคุณคือ "อาจจะ" ฉันคิดว่าคุณต้องพิสูจน์ตัวเองจริงๆว่า TCP นั้นช้าเกินไปสำหรับความต้องการของคุณหากคุณต้องการความน่าเชื่อถือในโปรโตคอลของคุณ

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

โปรโตคอล DCCP ซึ่งเป็นมาตรฐานในRFC 4340 "Datagram Congestion Control Protocol" อาจเป็นสิ่งที่คุณกำลังมองหา

ดูเหมือนว่าการดำเนินการในลินุกซ์

อาจเป็นRFC 5405 "แนวทางการใช้งาน Unicast UDP สำหรับนักออกแบบแอปพลิเคชัน" จะเป็นประโยชน์สำหรับคุณ

คุณพิจารณาบีบอัดข้อมูลของคุณหรือไม่

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

RUDP เซิร์ฟเวอร์ซ็อกเก็ตหลายเกมใช้สิ่งที่คล้ายกัน

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