UDP ยังดีกว่า TCP สำหรับเกมเรียลไทม์ที่มีข้อมูลมากหรือไม่?

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

บทความส่วนใหญ่มีอายุปีเป็น serval และเนื่องจาก ~ 80% ของข้อมูลทั้งหมดที่ส่งบนอินเทอร์เน็ตคือ TCP จึงต้องมีการปรับแต่งให้เหมาะสมสำหรับ TCP

นี่ทำให้ฉันสงสัย: UDP ยังเหนือกว่าในแง่ของความเร็วและความล่าช้าหรือไม่? การเพิ่มประสิทธิภาพ TCP ล่าสุดทำให้ TCP ทำงานได้ดีกว่า UDP หรือไม่

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

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

1. ตรวจพบการสูญหายของการอัพเดทครั้งแรก
2. ขอให้มีการส่งสัญญาณซ้ำของการอัพเดตครั้งแรก
3. การส่งสัญญาณใหม่มาถึงแล้วและได้รับการดำเนินการแล้ว

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

สิ่งนี้ต้องการให้คุณส่งข้อมูลประเภทที่ถูกต้องและออกแบบการสื่อสารของคุณในลักษณะที่การสูญเสียข้อมูลเป็นที่ยอมรับ

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

แก้ไข - การเพิ่มข้อมูลเพิ่มเติมเพื่อรวม / ที่อยู่ความคิดเห็นบางส่วน:

โดยทั่วไปอัตราการสูญเสียแพ็คเก็ตบนอีเธอร์เน็ตต่ำมาก แต่จะสูงขึ้นมากเมื่อมีการเชื่อมต่อ WiFi หรือหากผู้ใช้มีการอัพโหลด / ดาวน์โหลดอยู่ สมมติว่าเรามีแพ็กเก็ตที่สูญหายอย่างสมบูรณ์แบบ 0.01% (เที่ยวเดียวไม่ใช่ไป - กลับ) สำหรับนักกีฬาคนแรกลูกค้าควรส่งการอัปเดตทุกครั้งที่มีอะไรบางอย่างเกิดขึ้นเช่นเมื่อเคอร์เซอร์เปลี่ยนผู้เล่นซึ่งจะเกิดขึ้นประมาณ 20 ครั้งต่อวินาที พวกเขายังสามารถส่งอัปเดตต่อเฟรมหรือในช่วงเวลาคงที่ซึ่งจะเป็นการอัปเดต 60-120 ต่อวินาที เนื่องจากการอัปเดตเหล่านี้ได้รับการส่งในเวลาที่ต่างกันการอัปเดตเหล่านี้จะ / ควรถูกส่งในหนึ่งแพ็กเก็ตต่อการอัปเดต ในเกมที่มีผู้เล่น 16 คนผู้เล่นทั้ง 16 คนจะส่งแพ็คเก็ต 20-120 ต่อวินาทีเหล่านี้ไปยังเซิร์ฟเวอร์ส่งผลให้มีแพ็คเก็ต 320-1920 ต่อวินาที ด้วยอัตราการสูญเสียแพ็กเก็ต 0.01% เราคาดว่าจะสูญเสียแพ็คเก็ตทุก ๆ 5.2-31.25 วินาที

ในทุกแพ็คเก็ตที่เราได้รับหลังจากแพ็คเก็ตที่หายไปเราจะส่ง DupAck และหลังจาก DupAck ที่ 3 ผู้ส่งจะทำการส่งแพ็กเก็ตที่หายไปอีกครั้ง ดังนั้นเวลาที่ TCP ต้องการเริ่มต้นการส่งใหม่คือ 3 แพ็คเก็ตรวมถึงเวลาที่ DupAck สุดท้ายจะมาถึงผู้ส่ง จากนั้นเราต้องรอให้การส่งใหม่มาถึงดังนั้นโดยรวมแล้วเรารอ 3 แพ็คเก็ต + 1 เวลาในการตอบสนองล่าช้า เวลาแฝงแบบไปกลับมักจะมี 0-1 ms บนเครือข่ายท้องถิ่นและ 50-200 ms บนอินเทอร์เน็ต โดยทั่วไป 3 แพ็คเก็ตจะมาถึงใน 25 มิลลิวินาทีถ้าเราส่ง 120 แพ็กเก็ตต่อวินาทีและใน 150 มิลลิวินาทีถ้าเราส่ง 20 แพ็กเก็ตต่อวินาที

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

หาก TCP มีเรื่องยุ่งมากเราต้องพิจารณาNagle ด้วย (หากผู้พัฒนาลืมที่จะส่ง send coalescing หรือไม่สามารถปิดการทำงาน ACK ล่าช้า ) การหลีกเลี่ยงความแออัดของเครือข่ายหรือถ้าแพ็กเก็ตสูญหายนั้นแย่มาก การสูญเสียแพ็กเก็ต (รวมถึง Ack Ack และ DupAck ที่สูญหาย) ด้วย UDP เราสามารถเขียนรหัสได้เร็วขึ้นเพราะเราค่อนข้างไม่สนใจว่าจะเป็นเครือข่ายที่ดีเช่น TCP

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

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

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

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

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

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

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

TCP ทำให้เกิดการกระตุกเมื่อเวลาแฝงสูงพอ UDP ไม่ได้:

<video style="min-width: 100% height: auto" autoplay="" preload="auto" loop="true"><source src="https://gafferongames.com/videos/deterministic_lockstep_tcp_250ms_5pc.mp4" type="video/mp4"><source src="http://173.255.195.190/cubes_deterministic_lockstep_tcp_250ms_5pc.webm" type="video/webm">Your browser does not support the video tag.</video>

นี่ทำให้ฉันสงสัยว่า UDP นั้นยังเหนือกว่าในแง่ของความเร็วและความหน่วง

ใช่มันเป็นและมันจะเป็นเวลานาน คุณสามารถอ่านเพิ่มเติมเกี่ยวกับ TCP UDP เทียบกับที่นี่

TCP <- โปรโตคอลควบคุมการส่ง มันทำเพื่อควบคุมการส่ง

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

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

นอกจากนี้

• อัลกอริทึมของ Nagle อาจเก็บข้อมูลของผู้ส่งไว้จนกว่าจะมีการส่งอีกมาก (เพื่อใช้ประโยชน์จาก data frames อย่างมีประสิทธิภาพมากขึ้น) ข้อมูลเวลาที่สำคัญได้รับล่าช้า
• ฉันเชื่อว่าบ้านเราเตอร์ธรรมดาที่มี wlan อาจทำสิ่งที่ชาญฉลาด (ช้าลง) เพื่อทำให้ปริมาณงาน TCP ระหว่างไคลเอนต์หลาย ๆ อย่างราบรื่น (อินเทอร์เฟซ wlan เป็นคอขวดแม้ว่าเกมจะไม่ใช้ก็ตาม) เกี่ยวข้องกับการกระจายเสียง / การทำมัลติคาสต์เช่น ข้อมูล "อื่น ๆ " อาจลดปริมาณงาน TCP ของคุณ
• TCP ACKnowledgesทุกอย่างซึ่งไม่จำเป็นสำหรับสภาพแวดล้อมการเล่นเกม ไม่มีจุดใดใน ACKing ทุกการอัพเดททางฟิสิกส์ พอที่จะรับรู้เช่นหนึ่งครั้งต่อวินาทีหรือในทำนองเดียวกัน หากไคลเอนต์ (หรือเซิร์ฟเวอร์) ไม่ทำงานเป็นเวลานานแสดงว่าถึงเวลาตอบสนองแล้ว

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

UDP ไม่ทำสิ่งเหล่านี้ มันยิงตามความต้องการของคุณเพียงแค่ไม่สามารถคาดหวังว่าจะถูกโจมตีในแต่ละครั้ง - Insead เป้าหมายต้องประกาศว่า "คุณไม่ได้ยิงมานานแล้วทำไม" หนึ่งยังคงสามารถสร้างแพ็คเก็ต ACK ที่กำหนดเองของคุณใส่หลายระเบียนในแพ็คเก็ตเดียว ฯลฯ และที่สำคัญควบคุม NAT traversal UDP นั้นเหมาะสมที่สุดสำหรับเกมที่มีความต้องการเวลาแฝงต่ำ

คุณอาจจะเปรียบเทียบแผนภาพแรกของRFC 768 (UDP)แผนภาพแรกของRFCP 793 (TCP) หน้า 15

ทั้งสองแสดง 16 บิตสำหรับ "พอร์ตต้นทาง" ตามด้วย 16 บิตสำหรับ "พอร์ตปลายทาง" ทั้งสองแสดง 16 บิตสำหรับ“ เช็คซัม” ตาม RFC 768“ กระบวนการตรวจสอบของ UDP เหมือนกับที่ใช้ใน TCP”

ในขณะที่ความยาวของ UDP ครอบคลุมรายละเอียดของแผนภาพ UDP ความยาวของ TCP เป็นส่วนหนึ่งของ "ส่วนหัวหลอก 96 บิต" ที่อธิบายไว้ในหน้า 15 และ 16

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

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

พิจารณาสิ่งที่เกิดขึ้นครู่หนึ่ง เพื่อให้สถานการณ์ง่ายขึ้นคุณมีสองทางเลือกเมื่อพยายามส่งการเปลี่ยนแปลงสถานะ (เช่นผู้เล่นของคุณเพิ่งเปลี่ยนทิศทางหรือยิงปืนหรือผู้เล่นคนอื่น ๆ เพิ่งวางระเบิด):

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

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

นานแค่ไหนนานเกินไป เมื่อการพัฒนานักกีฬาคนแรกด้วยการยิงหลายคนมันก็ก้าวย้อนกลับไปในช่วงปลายยุค 90 และต้นยุค 2000 การเชื่อมต่อเวลาแฝงที่ต่ำไม่ใช่เรื่องธรรมดา โมเด็มการเรียกผ่านสายโทรศัพท์จะมีเวลาแฝงแบบทางเดียวปกติ 180ms การรอรอบก่อนที่จะส่งการอัปเดตอีกครั้งอย่างมีประสิทธิภาพสองเท่าถึง 360 มิลลิวินาทีก็เจ็บปวด แม้แต่ผู้ใช้มือใหม่ก็สามารถรู้สึกถึงความแตกต่างอย่างแน่นอน เมื่อการเชื่อมต่อบรอดแบนด์ติดพวกเขาทำให้เวลาหน่วงน้อยลง แต่ก็ยังคงมีอยู่เมื่อแบนด์วิดท์ขาดตลาด (บ่อยครั้งในบางพื้นที่) ดังนั้นความพึงพอใจต่อความหน่วงแฝงต่ำที่สุดจึงยังคงอยู่

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

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

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

พวกเขาไม่แตกต่างกันในแง่ของปริมาณ ("การใช้ข้อมูลสูง") หรือปริมาณงาน TCP จะส่งผ่านข้อมูลมากเท่ากับ UDP มันจะทำให้สายเคเบิลทางกายภาพอิ่มตัว

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

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

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

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

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

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

ใน MPG ที่มีแบนด์วิดธ์สูงคุณไม่สนใจว่าคุณจะพลาดแพ็คเก็ตหรือเปล่าที่บอกตำแหน่งและสุขภาพของ monster # 425 เพราะคุณจะได้รับการอัปเดตอีกครั้งในเสี้ยววินาที นี่คือตัวอย่างที่ UDP ทำให้ TCP ดูงี่เง่าที่ทำให้คุณรอข้อมูลที่ล้าสมัยทันที

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

นี่คือคำอธิบายง่ายๆของสิ่งที่เกิดขึ้น

UDP - แยกก้อน O'data
ทำแพ็กเก็ต
ห่อหุ้มใน IP
จัดส่ง

TCP - แยกกระแสข้อมูล
ทำแพ็กเก็ตจากด้านหน้าของสตรีม
ห่อหุ้มใน IP
รอพื้นที่ในหน้าต่าง TCP
จัดส่ง
เก็บ reshipping ไว้จนกว่าจะได้รับหรือหมดเวลา
อยู่ในหน้าต่าง TCP จนกว่าจะได้รับใบเสร็จหรือหมดเวลา

การจัดส่งหมายถึงมันทำให้ผ่าน NIC ท้องถิ่นไม่มาก

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

การส่งซ้ำ (เล็กน้อย) จะเพิ่มโอกาสในการรับในที่สุด

แพ็กเก็ต TCP จะประกอบขึ้นอีกด้านหนึ่งเป็นสตรีมข้อมูลที่สั่งซื้อ รับแพ็คเก็ต UPD เป็นแพ็กเก็ตที่แตกต่างกัน โปรโตคอลไม่รักษาลำดับ

TCP เหมาะสำหรับการพุชข้อมูลที่จำเป็นและการสั่งข้อมูลจำนวนมาก TCP จัดให้มีการแจ้งเตือนของความล้มเหลวถาวร TCP self-throttles ผ่านไปป์ที่ผ่านการสำลัก (หน้าต่างอ้างอิง:) TCP มี handshakes เพื่อชะลอการเริ่มต้น TCP ต้องการ "การเชื่อมต่อ" ก่อนส่ง

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

ฉันออกแบบและเขียน UDP Multicast File Transport Utility ที่ใช้ในเชิงพาณิชย์ ฉันทำงานกับ IP สแต็คแล้ว สิ่งเหล่านี้เป็นแค่ข้อมูลพื้นฐานเท่านั้น การอธิบาย "ซ็อกเก็ต MTU และของเล่นสนุก ๆ " นั้นเล็กน้อยเกินกว่าจะเป็นประโยชน์สำหรับคำถามนี้

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

เราเตอร์ที่ได้รับการเพิ่มประสิทธิภาพ TCP ทั้งหมดทำให้ TCP ทำงานได้ดีกว่า UDP หรือไม่

คำถามอีกข้อหนึ่งคือ: "data heavy" หมายความว่าคุณจะโหลดฉากบ่อยไหม?

ถ้าใช่คุณอาจต้องส่งข้อมูลขนาดใหญ่ (> 1k) อย่างเข้มข้นซึ่ง TCP อาจมีประสิทธิภาพมากกว่าเพราะโดยเฉพาะอย่างยิ่งในฝั่งเซิร์ฟเวอร์ NIC จะให้การถ่ายโอนข้อมูลที่หลากหลายซึ่งรอบเดียวกัน แอปพลิเคชันพื้นที่ผู้ใช้อาจออกการเขียนขนาดใหญ่ด้วย TCP ในขณะที่อยู่ใน UDP ความพยายามในการส่งมากกว่าไบต์ขนาดส่วนหัว MTU จะทำให้การกระจายตัวของ IP และค่าโสหุ้ยอื่น ๆ ซึ่งจะฆ่าประสิทธิภาพ

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

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

โดยทั่วไปแล้ว UDP (User Datagram Protocol) เสนอคุณสมบัติจำนวนน้อยที่สุด มันง่ายในการที่คุณส่งข้อมูลโดยไม่มีการรับ / ตอบรับใด ๆ

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

ตัวอย่าง: Skype Conference Call

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

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

ตัวเลือกการนำไปใช้

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

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

ฉันสังเกตเห็นความคิดเห็นมากมายที่ผู้คนเชื่อว่าแพ็กเก็ต TCP มีขนาดใหญ่กว่าแพ็คเก็ต UDP อย่าเพิ่งเชื่อใจฉันอ่านเอกสาร โพรโทคอลมีดังนี้: ไม่กี่ไบต์สำหรับส่วนหัวของอีเธอร์เน็ต (ชนิดข้อความ 2 ไบต์, 48 บิต MAC, 6 ไบต์) (สำหรับ Wifi ส่วนหัวอาจแตกต่างกัน) 20 ไบต์สำหรับ IP 20 ไบต์สำหรับ TCP หรือ UDP x ไบต์สำหรับข้อมูล x จาก 0 ถึงประมาณ 1500 (ดู MTU) สุดท้ายการตรวจสอบเพื่อให้แน่ใจว่าไม่มีความเสียหายเกิดขึ้นในแพ็กเก็ตอีเธอร์เน็ตนั้น

TCP อนุญาตให้ส่งแพ็คเก็ต "สตรีม" ขนาดใหญ่ขึ้นประมาณ 64K บล็อก "ใหญ่" นี้ถูกสับจริง ๆ ในหลาย ๆ แพ็คเก็ตอีเทอร์เน็ต