TCP เทียบกับ UDP บนสตรีมวิดีโอ

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

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

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

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

ข้อเสียของการใช้ TCP สำหรับวิดีโอสด:

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

FYI โปรดอย่าใช้คำว่า "แพ็กเกจ" เมื่ออธิบายเครือข่าย เครือข่ายส่ง "แพ็กเก็ต"

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

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

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

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

หากสตรีมแบบสดของคุณใช้ TCP / IP ระบบจะบังคับให้รอให้แพ็กเกจหลุดเหล่านั้นก่อนจึงจะประมวลผลข้อมูลใหม่ได้ต่อไป

แย่เป็นสองเท่า:

• ข้อมูลเก่าจะถูกส่งซ้ำ (อาจเป็นสำหรับเฟรมที่แสดงแล้วจึงไร้ค่า) และ
• ข้อมูลใหม่ไม่สามารถประสบความสำเร็จจนกระทั่งหลังจากที่ข้อมูลเก่า ๆ ได้ถูกส่งอีกครั้ง

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

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

มีบางกรณีการใช้งานที่เหมาะสมกับการขนส่ง UDP และอื่น ๆ ที่เหมาะสมกับการขนส่ง TCP

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

เมื่อใช้มัลติคาสต์เพื่อส่งวิดีโอไปยังลูกค้าของคุณระบบจะใช้ UDP

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

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

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

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

ไม่ได้เปิดใช้งานมัลติคาสต์ผ่านอินเทอร์เน็ต

สำหรับการส่งวิดีโอผ่านอินเทอร์เน็ตต้องใช้ TCP เมื่อนักพัฒนาใช้ UDP จบลงด้วยการนำการส่งแพ็กเก็ตซ้ำเช่น โปรโตคอลสด Bittorrent p2p

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

บัฟเฟอร์นี้ต้องมีอยู่ในบางรูปแบบ เช่นเดียวกับบัฟเฟอร์กระวนกระวายใจที่ฝั่งผู้เล่น เรียกว่า "ซ็อกเก็ตบัฟเฟอร์" และซอฟต์แวร์เซิร์ฟเวอร์สามารถทราบได้ว่าเมื่อใดที่บัฟเฟอร์เต็มและทิ้งเฟรมวิดีโอที่เหมาะสมสำหรับสตรีมแบบสด ควรใช้วิธี unicast / TCP เนื่องจากซอฟต์แวร์เซิร์ฟเวอร์สามารถใช้ตรรกะการวางเฟรมที่เหมาะสมได้ แพ็กเก็ตที่หายไปแบบสุ่มในกรณี UDP จะสร้างประสบการณ์การใช้งานที่ไม่ดี เช่นในวิดีโอนี้: http://tinypic.com/r/2qn89xz/9

"IP multicast ช่วยลดความต้องการแบนด์วิดท์วิดีโอสำหรับผู้ชมจำนวนมาก"

นี่เป็นเรื่องจริงสำหรับเครือข่ายส่วนตัว Multicast ไม่ได้เปิดใช้งานผ่านอินเทอร์เน็ต

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

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

"โดยปกติแล้วสตรีมวิดีโอค่อนข้างทนต่อความผิดพลาด"

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

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

ไม่ว่าในกรณีใด ๆ แพ็กเก็ตที่สูญหายจะไม่สามารถยอมรับได้ เฟรมที่ลดลงจะใช้ได้ในกรณีพิเศษเมื่อแบนด์วิดท์ถูกขัดขวาง

ผลลัพธ์ของแพ็กเก็ตที่หายไปคือสิ่งประดิษฐ์เช่นนี้:

ตัวถอดรหัสบางตัวสามารถทำลายสตรีมแพ็กเก็ตที่ขาดหายไปในสถานที่สำคัญได้

ผมแนะนำให้คุณดูที่ใหม่ P2P โปรโตคอลสดBittorent สด

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

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

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

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

มีสาเหตุหลักสองประการที่ทำให้ TCP ปรับขนาดได้ไม่ดี:

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

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

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

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

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

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

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

UDP FTW เมื่อทำการสตรีม

หากแบนด์วิดท์สูงกว่าบิตเรตมากฉันขอแนะนำ TCP สำหรับการสตรีมวิดีโอแบบสดแบบยูนิคาสต์

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

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

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

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

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

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

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

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