वीडियो स्ट्रीम पर टीसीपी बनाम यूडीपी


96

मैं नेटवर्क-प्रोग्रामिंग में अपनी परीक्षा से घर आया था, और उनमें से एक सवाल उन्होंने हमसे पूछा था "यदि आप वीडियो स्ट्रीम करने जा रहे हैं, तो क्या आप टीसीपी या यूडीपी का उपयोग करेंगे? संग्रहीत वीडियो और लाइव वीडियो-स्ट्रीम दोनों के लिए एक स्पष्टीकरण दें?" । इस सवाल के लिए उन्होंने लाइव वीडियो के लिए संग्रहीत वीडियो और यूडीपी के लिए बस टीसीपी के एक संक्षिप्त जवाब की उम्मीद की, लेकिन मैंने अपने घर के रास्ते पर इस बारे में सोचा, और क्या लाइव वीडियो स्ट्रीमिंग के लिए यूडीपी का उपयोग करना बेहतर है? मेरा मतलब है, अगर आपके पास इसके लिए बैंडविड्थ है, और कहते हैं कि आप एक फुटबॉल मैच स्ट्रीमिंग कर रहे हैं, या उस मामले के लिए कॉन्सर्ट कर रहे हैं, तो क्या आपको वास्तव में यूडीपी का उपयोग करने की आवश्यकता है?

यह कहते हुए कि आप इस कॉन्सर्ट को स्ट्रीम कर रहे हैं या टीसीपी का उपयोग करके आप पैकेट खोना शुरू कर देते हैं (आपके और प्रेषक के बीच कुछ नेटवर्क में कुछ बुरा हुआ है), और पूरे एक मिनट के लिए आपको कोई पैकेट नहीं मिलता है। वीडियो-स्ट्रीम विराम देगा, और मिनट बीत जाने के बाद पैकेट फिर से मिलना शुरू हो जाएगा (आईपी ने आपके लिए एक नया मार्ग ढूंढ लिया)। फिर क्या होगा कि टीसीपी आपके द्वारा खोए गए मिनट को फिर से भेज देगा और आपको लाइव स्ट्रीम भेजना जारी रखेगा। एक धारणा के रूप में बैंडविड्थ धारा पर बिट-दर से अधिक है, और पिंग बहुत अधिक नहीं है, इसलिए कम समय में, आपके द्वारा खो दिया गया एक मिनट आपके लिए धारा के लिए एक बफर के रूप में कार्य करेगा, इस तरह से , अगर पैकेट-नुकसान फिर से होता है, तो आप नोटिस नहीं करेंगे।

अब, मैं कुछ उपकरणों जहां यह एक अच्छा विचार नहीं हो सकता है, उदाहरण के वीडियो सम्मेलनों, जहां के लिए की तरह के बारे में सोच सकते हैं की जरूरत है , हमेशा धारा के अंत में हो सकता है क्योंकि एक वीडियो चैट के दौरान देरी सिर्फ भयानक है, लेकिन फ़ुटबॉल-मैच के दौरान, या एक कॉन्सर्ट से क्या फ़र्क पड़ता है अगर आप स्ट्रीम से एक मिनट पीछे हों? साथ ही, आपको गारंटी दी जाती है कि आपको सभी डेटा मिलते हैं और बाद में देखने के लिए बचत करना बेहतर होगा जब यह बिना किसी त्रुटि के आ रहा हो।

तो यह मुझे मेरे सवाल पर लाता है। क्या ऐसी कोई कमियां हैं जिनके बारे में मुझे लाइव-स्ट्रीमिंग के लिए टीसीपी का उपयोग करने की जानकारी नहीं है? या यह वास्तव में होना चाहिए, कि यदि आपके पास इसके लिए बैंडविड्थ है तो आपको टीसीपी के लिए जाना चाहिए जो कि यह नेटवर्क (प्रवाह-नियंत्रण) के लिए "अच्छा" है?


आप टीसीपी डब्ल्यू / ओ का उपयोग किसी भी निर्मित लैग में नहीं कर सकते हैं (जो हर किसी पर सहमत है) लेकिन सत्र रिकॉर्ड होने पर आप अच्छी गुणवत्ता प्रदान करने के लिए टीसीपी + यूडीपी का उपयोग कर सकते हैं।
bestsss

जवाबों:


87

लाइव वीडियो के लिए टीसीपी का उपयोग करने की कमियां:

  1. आमतौर पर लाइव वीडियो-स्ट्रीमिंग उपकरणों को टीसीपी स्ट्रीमिंग को ध्यान में रखकर नहीं बनाया गया है। यदि आप टीसीपी का उपयोग करते हैं, तो ओएस को हर क्लाइंट के लिए अनजाने खंडों को बफर करना चाहिए। यह अवांछनीय है, विशेष रूप से लाइव घटनाओं के मामले में; संभवतः एक साथ ग्राहकों की आपकी सूची घटना की विलक्षणता के कारण लंबी है। पहले से रिकॉर्ड किए गए वीडियो-कास्ट में आम तौर पर इसके साथ कोई समस्या नहीं होती है क्योंकि दर्शक अपनी पुनरावृत्ति गतिविधि को रोकते हैं; इसलिए वीडियो-ऑन-डिमांड को दोहराने के लिए टीसीपी अधिक उपयुक्त है।
  2. आईपी ​​मल्टीकास्ट बड़े दर्शकों के लिए वीडियो बैंडविड्थ आवश्यकताओं को काफी कम करता है; टीसीपी आईपी मल्टीकास्ट के उपयोग को रोकता है, लेकिन यूडीपी आईपी मल्टीकास्ट के लिए अच्छी तरह से अनुकूल है।
  3. लाइव वीडियो आम तौर पर एक निरंतर-बैंडविड्थ धारा है जिसे एक कैमरे से रिकॉर्ड किया जाता है; प्री-रिकॉर्डेड वीडियो स्ट्रीम एक डिस्क से आती हैं। टीसीपी के नुकसान-बैकऑफ़ डायनेमिक्स लाइव वीडियो की सेवा करना कठिन बनाते हैं जब स्रोत धारा एक निरंतर बैंडविड्थ पर होती है (जैसा कि लाइव-इवेंट के लिए होता है)। यदि आप कैमरा बंद करने के लिए बफर करते हैं, तो सुनिश्चित करें कि आपके पास अप्रत्याशित नेटवर्क घटनाओं और चर टीसीपी भेजने / बैकऑफ़ दरों के लिए पर्याप्त बफर है। UDP इस एप्लिकेशन के लिए आपको अधिक नियंत्रण देता है क्योंकि UDP नेटवर्क ट्रांसपोर्ट लेयर ड्रॉप्स की परवाह नहीं करता है।

FYI करें, कृपया नेटवर्क का वर्णन करते समय "संकुल" शब्द का प्रयोग न करें। नेटवर्क "पैकेट" भेजते हैं।


इसके बारे में क्षमा करें, मैं इसे बदल दूंगा। एक सवाल हालांकि, IPv6 (मुझे नहीं पता, यह अच्छी तरह से अभी तक समर्थित नहीं हो सकता है) इसमें मल्टीकास्ट का समर्थन है, तो फिर IPv6 पर भी टीसीपी नहीं होना चाहिए?
एलेक्जेंडर

1
ओह, और भी, एक लाइव इवेंट से रिकॉर्ड किए गए वीडियो को शायद वैसे भी डिस्क पर सहेजा जाता है, उस के एक छोटे से हिस्से को फिर से ग्रहण करने के लिए, क्या यह वास्तव में उस बुरे को चोट पहुंचाएगा?
एलेक्जेंडर

1
@Alxandr, मैं IPv6 में ऐसी किसी भी चीज़ से परिचित नहीं हूँ जो TCP मल्टीकास्ट को आसान बनाती है। आपके मन में IPv6 की क्या विशेषता है?
माइक पेनिंगटन

2
@ एलेक्ज़ेंडर, भले ही आप एनीकास्ट पतों का उपयोग करते हैं, यह टीसीपी पर मल्टीकास्ट की सेवा के साथ मूलभूत मुद्दे को हल नहीं करता है ... टीसीपी सॉकेट की पहचान एक क्वाड-टपल (src ip, src port, dst ip, dst port) के रूप में करता है। यदि सभी क्लाइंट एक ही src आईपी का उपयोग करते हैं, तो आपको किसी तरह IPv6 पैकेट को src पोर्ट के आधार पर रूट करना होगा और सभी क्लाइंट के बीच लॉस स्टेट को बनाए रखना होगा। यह मल्टीकास्ट के उद्देश्य को पराजित करता है, जिसे हर रिसीवर को पैकेट की एक प्रति भेजनी थी
माइक पेनिंगटन

समझा। जवाब के लिए धन्यवाद :)। मैं बस इस बारे में उत्सुक था, इसलिए मैंने सोचा कि मैं देखूंगा कि लोगों ने इस बारे में क्या सोचा था। और ऐसा लगता है कि दुनिया फ़ुटबॉल-प्रशंसकों और इंटरनेट खुद मेरे खिलाफ है, इसलिए मुझे लगता है कि यह मेरा नुकसान है ^ _ ^
Alxandr

26

लेकिन एक फुटबॉल मैच के दौरान, या एक संगीत कार्यक्रम से क्या फर्क पड़ता है अगर आप धारा से एक मिनट पीछे हैं?

कुछ फुटबॉल प्रशंसकों के लिए, थोड़ा सा। यह टिप्पणी की गई है कि एन्कोडिंग (या जो भी) के कारण डिजिटल वीडियो धाराओं में मौजूद कुछ सेकंड की देरी हो सकती है, जब विश्व कप के मैचों जैसे हाई-प्रोफाइल इवेंट के दौरान, आप लोगों से चीयर्स और कराह सुन सकते हैं। अगले दरवाजे (जो एक अप्रभावित एनालॉग प्रोग्राम देख रहे हैं) इससे पहले कि आप गेम चालें देखें जो उन्हें कारण बना।

मुझे लगता है कि किसी को खेल के बारे में बहुत परवाह है (और वे डिजिटल टीवी के लिए ग्राहकों को भुगतान करने का सबसे बड़ा समूह हैं, कम से कम जर्मनी में), लाइव वीडियो स्ट्रीम में एक मिनट पीछे होना पूरी तरह से अस्वीकार्य होगा (जैसा कि, वे ') d अपने प्रतियोगी पर स्विच करें जहां ऐसा नहीं होता है)।


मुझे याद है कि स्विट्जरलैंड में भी लोग इस बारे में शिकायत करते थे।
तारा

21

आमतौर पर एक वीडियो स्ट्रीम कुछ हद तक सहिष्णु है। इसलिए यदि कुछ पैकेज खो जाते हैं (उदाहरण के लिए, ओवरलोड होने के तरीके के साथ कुछ राउटर के कारण), तो यह अभी भी सामग्री को प्रदर्शित करने में सक्षम होगा, लेकिन कम गुणवत्ता के साथ।

यदि आपकी लाइव स्ट्रीम टीसीपी / आईपी का उपयोग कर रही थी, तो नए डेटा को संसाधित करना जारी रखने से पहले उन ड्रॉप किए गए पैकेजों की प्रतीक्षा करने के लिए मजबूर होना पड़ेगा ।

यह दोगुना बुरा है:

  • पुराने डेटा को फिर से प्रसारित किया जा सकता है (यह संभवतः एक फ्रेम के लिए है जो पहले से प्रदर्शित था और इसलिए बेकार है) और
  • नए डेटा तक नहीं आ सकते बाद पुराने डेटा फिर से प्रेषित किया गया

यदि आपका लक्ष्य संभव के रूप में अप-टू-डेट जानकारी प्रदर्शित करना है (और एक लाइव-स्ट्रीम के लिए आप आमतौर पर अप-टू-डेट होना चाहते हैं, भले ही आपके फ्रेम थोड़ा खराब दिखें), तो टीसीपी आपके खिलाफ काम करेगा।

एक रिकॉर्ड की गई धारा के लिए स्थिति थोड़ी अलग है: आप शायद बहुत अधिक (संभवतः कई मिनट!) बफरिंग करेंगे और खोए हुए पैकेजों के कारण कुछ कलाकृतियों की तुलना में डेटा फिर से प्रसारित होगा। इस मामले में टीसीपी एक अच्छा मैच है (इसे अभी भी यूडीपी में लागू किया जा सकता है, लेकिन टीसीपी में लाइव स्ट्रीम केस के लिए उतनी कमियां नहीं हैं)।


1
लेकिन जैसा कि मैंने समझाया, "लाइव" स्ट्रीम का उपयोग हम आज करते हैं, शायद आधे मिनट की देरी होने के साथ कोई समस्या नहीं होगी, और इस तरह आपको स्वचालित रूप से एक बफर मिलेगा, ताकि आप खोए हुए पैकेजों को न देख सकें। सब। यदि आप डेटा को सहेजना चाहते हैं तो क्या यह बेहतर नहीं होगा?
एलेक्जेंडर

2
@ अलेक्जेंडर: उस मामले में आप "लाइव" स्ट्रीम की परिभाषा को नरम कर रहे हैं, क्या आप ;-)
जोकिम सॉयर

हाँ, मुझे पता है, लेकिन मैंने उस प्रश्न में भी समझाने की कोशिश की। यद्यपि यह ऐसा लगता है कि बड़ी समस्या पुराने डेटा (
रिट्रांसमिटिंग के

किसी भी मामले में आप गिराए गए पैकेट नहीं चाहते हैं यह दृश्य कलाकृतियों का कारण होगा जो कई फ़्रेमों में प्रचारित करता है। उचित समाधान पूरे फ्रेम को गिराने के लिए है और वीडियो प्लेबैक में नेटवर्क की भीड़ के लिए यूडीपी निश्चित रूप से समाधान नहीं है।
एलेक्स

डिफ़ॉल्ट रूप से एक वीडियो स्ट्रीम गलती सहिष्णु नहीं है
एलेक्स

9

यूडीपी परिवहन के लिए उपयुक्त कुछ उपयोग मामले हैं और टीसीपी परिवहन के लिए उपयुक्त अन्य हैं।

उपयोग का मामला वीडियो के लिए एन्कोडिंग सेटिंग्स को भी निर्धारित करता है। जब फुटबॉल मैच का प्रसारण गुणवत्ता पर होता है और वीडियो कॉन्फ्रेंस के लिए फोकस विलंबता पर होता है।

अपने ग्राहकों को वीडियो देने के लिए मल्टीकास्ट का उपयोग करते समय तो यूडीपी का उपयोग किया जाता है।

ब्रॉडकास्टिंग सर्वर और ग्राहक के बीच मल्टीकास्ट की आवश्यकता महंगी नेटवर्किंग हार्डवेयर है। व्यवहार में इसका मतलब है कि यदि आपकी कंपनी नेटवर्क के बुनियादी ढांचे का मालिक है तो आप लाइव वीडियो स्ट्रीमिंग के लिए यूडीपी और मल्टीकास्ट का उपयोग कर सकते हैं। फिर भी वीडियो पैकेटों को चिह्नित करने और उन्हें प्राथमिकता देने के लिए गुणवत्ता-की-सेवा भी लागू की जाती है ताकि कोई पैकेट नुकसान न हो।

मल्टिकास्ट ब्रॉडकास्टिंग सॉफ्टवेयर को सरल बनाएगा क्योंकि नेटवर्क हार्डवेयर ग्राहकों को पैकेट बांटने का काम करेगा। ग्राहक मल्टीकास्ट चैनल की सदस्यता लेते हैं और नेटवर्क नए ग्राहकों के लिए रूट पैकेट को फिर से कॉन्फ़िगर करेगा। डिफ़ॉल्ट रूप से सभी चैनल सभी ग्राहकों के लिए उपलब्ध होते हैं और इन्हें बेहतर तरीके से रूट किया जा सकता है।

यह वर्कफ़्लो प्राधिकरण प्रक्रिया पर भिन्नता रखता है। नेटवर्क हार्डवेयर उपयोगकर्ताओं को अन्य उपयोगकर्ताओं से सदस्यता अलग नहीं करता है। प्राधिकरण का समाधान वीडियो सामग्री को एन्क्रिप्ट करने और सदस्यता वैध होने पर खिलाड़ी सॉफ्टवेयर में डिक्रिप्शन को सक्षम करने में है।

यूनिकास्ट (टीसीपी) वर्कफ़्लो सर्वर को क्लाइंट के क्रेडेंशियल्स की जांच करने और केवल वैध सदस्यता की अनुमति देता है। यहां तक ​​कि केवल निश्चित संख्या में एक साथ कनेक्शन की अनुमति दें।

इंटरनेट पर मल्टीकास्ट सक्षम नहीं है।

इंटरनेट पर वीडियो देने के लिए टीसीपी का उपयोग किया जाना चाहिए। जब यूडीपी का उपयोग किया जाता है, तो उदाहरण के लिए, डेवलपर्स री-इम्प्लीमेंटिंग पैकेट री-ट्रांसमिशन को समाप्त करते हैं। बिटटोरेंट पी 2 पी लाइव प्रोटोकॉल।

"यदि आप टीसीपी का उपयोग करते हैं, तो ओएस को हर क्लाइंट के लिए अनजाने खंडों को बफर करना चाहिए। यह अवांछनीय है, खासकर लाइव इवेंट के मामले में"।

यह बफर किसी न किसी रूप में मौजूद होना चाहिए। खिलाड़ी पक्ष पर घबराना बफर के लिए भी यही सच है। इसे "सॉकेट बफर" कहा जाता है और सर्वर सॉफ्टवेयर यह जान सकता है कि यह बफर कब भरा हुआ है और लाइव स्ट्रीम के लिए उचित वीडियो फ्रेम को त्याग देगा। यूनिकस्ट / टीसीपी विधि का उपयोग करना बेहतर है क्योंकि सर्वर सॉफ़्टवेयर उचित फ़्रेम ड्रॉपिंग तर्क को लागू कर सकता है। यूडीपी के मामले में रैंडम गुम पैकेट केवल खराब उपयोगकर्ता अनुभव पैदा करेगा। इस वीडियो की तरह: http://tinypic.com/r/2qn89xz/9

"आईपी मल्टीकास्ट बड़े दर्शकों के लिए वीडियो बैंडविड्थ आवश्यकताओं को काफी कम करता है"

यह निजी नेटवर्क के लिए सही है, मल्टीकास्ट इंटरनेट पर सक्षम नहीं है।

"ध्यान दें कि अगर टीसीपी बहुत सारे पैकेट खो देता है, तो कनेक्शन मर जाता है; इस प्रकार, यूडीपी आपको इस एप्लिकेशन के लिए बहुत अधिक नियंत्रण देता है क्योंकि यूडीपी नेटवर्क ट्रांसपोर्ट लेयर ड्रॉप्स की परवाह नहीं करता है।"

यूडीपी पूरे फ्रेम या ग्रुप-ऑफ-फ्रेम्स को छोड़ने के बारे में परवाह नहीं करता है, इसलिए यह उपयोगकर्ता के अनुभव पर कोई अधिक नियंत्रण नहीं देता है।

"आमतौर पर एक वीडियो स्ट्रीम कुछ हद तक सहिष्णु है"

एन्कोडेड वीडियो दोषपूर्ण सहिष्णु नहीं है। जब अविश्वसनीय परिवहन पर संचारित किया जाता है तो वीडियो कंटेनर में फ़ॉरवर्ड त्रुटि सुधार जोड़ा जाता है। अच्छा उदाहरण एमपीईजी-टीएस कंटेनर है जिसका उपयोग उपग्रह वीडियो प्रसारण में किया जाता है जो कई ऑडियो, वीडियो, ईपीजी, इत्यादि धाराओं को ले जाता है। यह आवश्यक है क्योंकि उपग्रह लिंक द्वैध संचार नहीं है, जिसका अर्थ है कि रिसीवर खोए हुए पैकेटों के पुन: प्रसारण का अनुरोध नहीं कर सकता है।

जब आपके पास द्वैध संचार उपलब्ध होता है, तो केवल पैकेट हानि वाले ग्राहकों के लिए डेटा को फिर से प्रसारित करना बेहतर होता है, फिर सभी क्लाइंट को भेजे गए स्ट्रीम में फॉरवर्ड-एरर-करेक्शन के ओवरहेड को शामिल करना।

किसी भी मामले में खोए हुए पैकेट अस्वीकार्य हैं। जब बैंडविड्थ में बाधा होती है तो असाधारण मामलों में तख्ते ठीक हो जाते हैं।

गायब पैकेट का परिणाम इस तरह की कलाकृतियां हैं: कलाकृतियों

कुछ डिकोडर गंभीर स्थानों पर लापता पैकेटों को तोड़ सकते हैं।


मल्टीकास्ट के लिए -1 इंटरनेट पर सक्षम नहीं है। यह हर जगह नहीं है लेकिन कुछ सहकर्मी मल्टीकास्ट सेवा प्रदान करते हैं। एक उदाहरण सिएटलिक्स है जिसने 2009 में मल्टीकास्ट को सक्रिय किया
माइक पेनिंगटन

2
@ माइक पेनिंगटन: कुछ प्रदाता "इंटरनेट" नहीं हैं, इसलिए मेरा कथन सत्य है। आप बुनियादी ढांचे के बहुत छोटे हिस्से की ओर इशारा कर रहे हैं और उम्मीद करते हैं कि अन्य लोग इस अभ्यास में शामिल होंगे। कृपया तथ्यों से चिपके रहें।
एलेक्स

1
जब आपको यह बहस करने का एक बिंदु मिल जाता है कि इंटरनेट पर कितना मल्टीकास्ट चलता है, तो कृपया मुझे बताएं
माइक पेनिंगटन

4

मैं आपको नए पी 2 पी लाइव प्रोटोकॉल बिटोरेंट लाइव को देखने की सलाह देता हूं ।

स्ट्रीमिंग के लिए यूडीपी का उपयोग करना बेहतर है, क्योंकि यह सर्वर पर लोड को कम करता है, लेकिन ज्यादातर इसलिए कि आप मल्टीकास्ट के साथ पैकेट भेज सकते हैं, यह प्रत्येक कनेक्टेड क्लाइंट को भेजने की तुलना में सरल है।


3

निर्भर करता है। आपके द्वारा स्ट्रीम की जा रही सामग्री कितनी महत्वपूर्ण है? यदि महत्वपूर्ण टीसीपी का उपयोग करें। यह बैंडविड्थ, वीडियो गुणवत्ता (आपको विलंबता से निपटने के लिए कम गुणवत्ता का उपयोग करना पड़ सकता है), और विलंबता का कारण हो सकता है। लेकिन अगर आपको वहां पहुंचने के लिए आवश्यक सामग्री चाहिए, तो इसका उपयोग करें।

अन्यथा यूडीपी ठीक होना चाहिए यदि धारा महत्वपूर्ण नहीं है और इसे प्राथमिकता दी जाएगी क्योंकि यूडीपी कम ओवरहेड होता है।


3

इंटरनेट पर लाइव इवेंट देने के साथ सबसे बड़ी समस्याओं में से एक 'स्केल' है, और टीसीपी अच्छी तरह से स्केल नहीं करता है। उदाहरण के लिए जब आप एक लाइव फुटबॉल मैच-ऑन ऑन डिमांड मूवी प्लेबैक का विरोध कर रहे हैं- तो देखने वालों की संख्या आसानी से 1000 गुना अधिक हो सकती है। ऐसे परिदृश्य में टीसीपी का उपयोग सीडीएन (सामग्री वितरण नेटवर्क) के लिए एक मौत की सजा है।

मुख्य कारणों में से कुछ कारण हैं कि टीसीपी अच्छा नहीं है:

  1. टीसीपी के सबसे बड़े ट्रेडऑफ्स में से एक प्रेषक और रिसीवर के बीच थ्रूपुट प्राप्य की परिवर्तनशीलता है। इंटरनेट पर वीडियो स्ट्रीमिंग करते समय वीडियो पैकेट को इंटरनेट पर कई राउटरों को पार करना होगा, इनमें से प्रत्येक राउटर विभिन्न गति कनेक्शनों के साथ जुड़ा हुआ है। टीसीपी एल्गोरिथ्म टीसीपी विंडो के साथ छोटे से शुरू होता है, फिर तब तक बढ़ता है जब तक पैकेट नुकसान का पता नहीं चल जाता है, पैकेट नुकसान को भीड़ का संकेत माना जाता है और टीसीपी भीड़ से बचने के लिए खिड़की के आकार को काफी कम करके इसका जवाब देता है। इस प्रकार, प्रभावी थ्रूपुट को तुरंत कम करने में। अब ग्राहक के लिए 6-7 राउटर हॉप्स का उपयोग करके टीसीपी ट्रांसमिशन के साथ एक नेटवर्क की कल्पना करें (एक बहुत ही सामान्य परिदृश्य), यदि कोई मध्यवर्ती राउटर किसी भी पैकेट को खो देता है, तो उस लिंक के लिए टीसीपी ट्रांसमिशन दर को कम कर देगा। वास्तव में, राउटर के बीच ट्रैफ़िक का प्रवाह एक घंटे के आकार का एक प्रकार का पालन करता है; हमेशा मध्यवर्ती राउटर में से एक के बीच में और ऊपर-नीचे गोंग। सबसे अच्छा प्रयास UDP की तुलना में बहुत कम डाल के माध्यम से प्रभावी प्रतिपादन।

  2. जैसा कि आप पहले से ही जानते होंगे कि टीसीपी एक पावती आधारित प्रोटोकॉल है। उदाहरण के लिए चलो एक प्रेषक 50ms दूर है (यानी विलंबता btw दो अंक)। इसका मतलब होगा कि एक पैकेट को रिसीवर और रिसीवर को भेजे जाने के लिए समय लगता है और पावती भेजने के लिए 100ms होगा; यूडीपी आधारित ट्रांसमिशन की तुलना में इस प्रकार अधिकतम थ्रूपुट संभव है जो पहले से ही आधा है।

  3. टीसीपी मल्टीकास्टिंग या मल्टीटास्टिंग एएमटी के नए उभरते मानक का समर्थन नहीं करता है। जिसका अर्थ है कि CDNs के पास पैकेटों की प्रतिकृति बनाकर नेटवर्क ट्रैफ़िक को कम करने का अवसर नहीं है, जब कई ग्राहक समान सामग्री देख रहे हैं। यह स्वयं CDN के लिए एक बड़ा कारण है (जैसे अकामाई या लेवल 3) लाइव स्ट्रीम के लिए टीसीपी के साथ नहीं जाने के लिए।


2

टीसीपी यूडीपी बहस पढ़ते समय मैंने एक तार्किक दोष देखा। एक टीसीपी पैकेट हानि के कारण एक मिनट की देरी होती है जो एक मिनट बफर कैंट में परिवर्तित हो जाती है और उसी नुकसान का अनुभव करते हुए यूडीपी को एक पूर्ण मिनट छोड़ने के लिए सहसंबद्ध किया जाता है। एक अधिक उचित तुलना इस प्रकार है।

टीसीपी एक पैकेट नुकसान का अनुभव करता है। वीडियो को रोक दिया जाता है जबकि TCP गणितीय रूप से परिपूर्ण पैकेट को स्ट्रीम करने के प्रयास में पैकेट को फिर से भेजती है। वीडियो में एक मिनट की देरी होती है और वह गायब हो जाता है जहां गायब पैकेट के बाद उसे छोड़ दिया जाता है। हम सभी प्रतीक्षा करते हैं लेकिन हम जानते हैं कि हम एक भी पिक्सेल को याद नहीं करेंगे।

यूडीपी एक पैकेट नुकसान का अनुभव करता है। वीडियो स्ट्रीम के दौरान एक सेकंड के लिए स्क्रीन के एक कोने में थोड़ी धुंधली हो जाती है। बिना खोए पैकेट की तलाश में कोई भी नोटिस और शो नहीं चलता है।

यूडीपी से जो भी धाराएँ प्राप्त होती हैं, वे सबसे अधिक लाभ देती हैं। टीसीपी को एक मिनट की देरी के कारण पैकेट नुकसान से यूडीपी को एक मिनट की देरी नहीं होगी। यह देखते हुए कि अधिकांश सिस्टम पैकेट के लिए भूखे रहने पर चीजों को अवरुद्ध करने वाले कई रिज़ॉल्यूशन स्ट्रीम का उपयोग करते हैं, यूडीपी का उपयोग करने के लिए और भी अधिक समझ में आता है।

स्ट्रीमिंग करते समय UDP FTW।


1
आप भूल रहे हैं कि अधिकांश वीडियो कोडेक्स में त्रुटि सुधार कोड के उपयोग के माध्यम से कम से कम थोड़ा अतिरेक है। एक एकल गिरा पैकेट वैसे भी नजरअंदाज किया जा सकता है क्योंकि डेटा पहले से ही उपलब्ध था, और डिकोडर भी नोटिस नहीं कर सकता है।
एंडी

2

यदि बैंडविड्थ बिटरेट से कहीं अधिक है, तो मैं यूनिकस्ट लाइव वीडियो स्ट्रीमिंग के लिए टीसीपी की सिफारिश करूंगा।

केस 1: लगातार पैकेट कई सेकंड की अवधि के लिए खो जाते हैं। => लाइव वीडियो क्लाइंट साइड पर जो भी ट्रांसपोर्ट लेयर है (टीसीपी या यूडीपी) बंद हो जाएगी। जब नेटवर्क ठीक हो जाता है: - यदि टीसीपी का उपयोग किया जाता है, तो क्लाइंट वीडियो प्लेयर पहले पैकेट खोए (टाइमशिफ्ट) या फिर सभी देर के पैकेट को छोड़ने के लिए और बिना टाइमशिफ्ट के वीडियो स्ट्रीम को फिर से शुरू करने के लिए स्ट्रीम को फिर से शुरू करना चुन सकता है। - यदि यूडीपी का उपयोग किया जाता है, तो क्लाइंट पक्ष पर कोई विकल्प नहीं है, वीडियो पुनरारंभ किसी भी समय के बिना रहते हैं। => टीसीपी बराबर या बेहतर।

केस 2: कुछ पैकेट बेतरतीब ढंग से और अक्सर नेटवर्क पर खो जाते हैं। - यदि टीसीपी का उपयोग किया जाता है, तो इन पैकेटों को तुरंत वापस ले लिया जाएगा और एक सही घबराना बफर के साथ, वीडियो स्ट्रीम गुणवत्ता / विलंबता पर कोई प्रभाव नहीं पड़ेगा। - अगर यूडीपी का उपयोग किया जाता है, तो वीडियो की गुणवत्ता खराब होगी। => टीसीपी ज्यादा बेहतर


1

वीडियो स्ट्रीमिंग बैंडविड्थ के लिए सिस्टम पर बाधा की संभावना है। मल्टीकास्ट का उपयोग करके आप उपयोग किए गए अपस्ट्रीम बैंडविड्थ की मात्रा को काफी कम कर सकते हैं। यूडीपी के साथ आप आसानी से अपने पैकेट को सभी कनेक्टेड टर्मिनलों पर मल्टिकास्ट कर सकते हैं। आप एक विश्वसनीय मल्टीकास्ट प्रोटोकॉल का भी उपयोग कर सकते हैं, एक को प्रैग्मेटिक जनरल मल्टीकास्ट (पीजीएम) कहा जाता है, मुझे इसके बारे में कुछ नहीं पता है और मुझे लगता है कि यह इसके उपयोग में व्यापक नहीं है।


1

अन्य सभी कारणों के अलावा, यूडीपी मल्टीकास्ट का उपयोग कर सकता है। सभी टीसीपी उपयोगकर्ताओं को एक ही डेटा कचरे के बैंडविड्थ को संचारित करने में सहायता करना। हालांकि, टीसीपी का उपयोग करने का एक और महत्वपूर्ण कारण है।

टीसीपी बहुत अधिक आसानी से फायरवॉल और NAT से गुजर सकता है। आपके NAT और ऑपरेटर के आधार पर, आप UDP छेद छिद्रण की समस्याओं के कारण UDP स्ट्रीम प्राप्त करने में भी सक्षम नहीं हो सकते हैं।


0

सभी 'यूडीपी का उपयोग करें' उत्तर एक खुले नेटवर्क का अनुमान लगाते हैं और इसे 'उतने ही सामान करते हैं जितना आप कर सकते हैं।' पुरानी शैली के बंद-बगीचे के लिए अच्छा है समर्पित ऑडियो / वीडियो नेटवर्क, जो एक लुप्त हो रहे हैं।

वास्तविक दुनिया में, आपका प्रसारण फायरवॉल (जो कभी-कभी मल्टिकास्ट और कभी-कभी udp छोड़ देगा) के माध्यम से जाएगा, नेटवर्क दूसरों के साथ साझा किया जाता है अधिक महत्वपूर्ण ($ $ $), इसलिए आप विंडो स्केलिंग के साथ नशेड़ी को दंडित करना चाहते हैं।


0

यह बात है, यह समय की समस्या की तुलना में अधिक सामग्री का मामला है। टीसीपी प्रोटोकॉल के लिए आवश्यक है कि जिस पैकेट को डिलीवर नहीं किया गया था, उसकी जाँच, सत्यापन और पुनर्वितरण होना चाहिए। यूडीपी इस आवश्यकता का उपयोग नहीं करता है। इसलिए यदि आपने एक फाइल भेजी है जिसमें एक वीडियो की तरह यूडीपी का उपयोग करने वाले लाखों पैकेट हैं, अगर डिलीवरी के समय कुछ पैकेट गायब हैं, तो वे सबसे अधिक संभावनाहीन हो जाएंगे।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.