2008-12-12 16 views
26

मैं जानना चाहता था कि क्यों टीडीपी के बजाय आरटीपी में यूडीपी का उपयोग किया जाता है? प्रमुख वीओआईपी उपकरण केवल यूडीपी का इस्तेमाल करते थे क्योंकि मैंने कुछ वीओआईपी ओएसएस को हैक किया था।आरटीपी टीसीपी के बजाय यूडीपी का उपयोग क्यों करता है?

+0

आरटीपी में यूडीपी का उपयोग क्यों किया जाता है लेकिन टीसीपी में नहीं? गलत तरीके से पूछे जाने वाले प्रश्न की तरह लगता है। -> आरटीपी ने टीसीपी के बजाय यूडीपी का उपयोग क्यों किया? –

+0

धन्यवाद अब ठीक किया गया :) – mahesh

+0

"मैं जानना चाहता हूं कि आरटीपी में यूडीपी का उपयोग क्यों किया जाता है लेकिन टीसीपी क्यों नहीं है?" यह आपके मतलब के करीब हो सकता है? –

उत्तर

50

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

यूडीपी संचार की विश्वसनीयता की परवाह नहीं करता है, और डेटा धीमा या फिर से संचारित नहीं करेगा।

यदि आपके एप्लिकेशन को एक विश्वसनीय डेटा स्ट्रीम की आवश्यकता है, उदाहरण के लिए, वेबसर्वर से फ़ाइल पुनर्प्राप्त करने के लिए, आप टीसीपी चुनते हैं।

यदि आपके एप्लिकेशन को दूषित या खोए गए पैकेट की परवाह नहीं है, और आपको अतिरिक्त विश्वसनीयता प्रदान करने के लिए अतिरिक्त ओवरहेड लेने की आवश्यकता नहीं है, तो आप इसके बजाय यूडीपी चुन सकते हैं।

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

+5

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

+1

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

3

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

2

आरटीपी पैकेट नुकसान के लिए काफी असंवेदनशील है, इसलिए इसे टीसीपी की विश्वसनीयता की आवश्यकता नहीं है।

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

यूडीपी तेजी से डेटा ट्रांसमिशन भी प्रदान करता है।

तो यूडीपी इस तरह के मामलों में स्पष्ट पसंद है।

0

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

टीसीपी का उपयोग तब किया जाता है जब डेटा को बिल्कुल प्राप्त किया जाना चाहिए, थोड़ा सा बिट, बिट्स का कोई नुकसान नहीं।

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

19

अच्छा जवाब का एक बहुत दिया गया है, लेकिन मैं एक बात स्पष्ट रूप से बाहर बात करने के लिए करना चाहते हैं:

मूल रूप से एक पूरा डाटा प्रवाह वास्तविक समय ऑडियो/वीडियो के लिए करने के लिए एक अच्छी बात है, लेकिन इसकी कड़ाई से जरूरी नहीं है (जैसा कि अन्य ने इंगित किया है):

महत्वपूर्ण तथ्य यह है कि कुछ डेटा जो बहुत देर से आता है वह बेकार है। एक फ्रेम के लिए गायब डेटा कितना अच्छा है जो एक दूसरे पहले प्रदर्शित किया जाना चाहिए था?

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

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

(*) वास्तव में मैं आरटीपी की बारीकियों पता नहीं है। हो सकता है कि यह पुनः प्रेषण करने का प्रयास करता है, लेकिन यदि ऐसा होता है तो यह टीसीपी के रूप में आक्रामक नहीं होगा (जो कभी भी खोए गए डेटा को स्वीकार नहीं करेगा)।

+1

को अपना तीसरा पैरा पसंद आया "यदि आप टीसीपी का उपयोग करना चाहते हैं ....."। :) – mahesh

+0

टीसीपी कभी भी खोए गए डेटा को स्वीकार नहीं करेगा? ... क्या आपने कभी एक टीसीपी पैकेट खराब किया है या खराब कवरेज के साथ वाईफाई का उपयोग किया है? – Jay

+0

@Jay: मेरा मतलब यह है कि यदि पैकेट 1 कहीं गिरा दिया गया है और पैकेट 2 तब आता है तो उपयोगकर्ता एप्लिकेशन कभी भी पैकेट 2 से डेटा नहीं देखेगा जब तक कि पैकेट 1 सफलतापूर्वक पुनः प्रेषित न हो जाए। और यह वास्तव में हिस्सा है कि क्यों खराब कनेक्शन पर टीसीपी इतना दर्दनाक है। –

1

सभी दूसरों अच्छा और सही उत्तरों इसके अलावा this article TCP और UDP के बीच मतभेदों के बारे में एक अच्छी समझ देता है।

+0

धन्यवाद mlarsen। लिंक पसंद आया। :) – mahesh

+0

लिंक मृत। अब यह जवाब बिल्कुल उपयोगी नहीं है। –

+0

आलेख अब यहां पाया जा सकता है: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/ – mbelow

11

दूसरों सही हैं, लेकिन वास्तव में आप असली कारण है कि पता नहीं चलता। सॉआ इस तरह के संकेत, लेकिन यहां एक और पूरा जवाब है।

ऑडियो और वीडियो वास्तविक समय है। यदि आप रेडियो सुन रहे हैं, या टीवी देख रहे हैं, और सिग्नल बाधित है, तो यह उस स्थान को नहीं लेता है जहां आपने छोड़ा था .. आप सिग्नल के रूप में सिग्नल को "देख रहे हैं", और यदि आप देख नहीं सकते यह किसी भी समय पर, आप इसे खो देते हैं।

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

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

पुनर्संचरण से

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

आरटीपी कनेक्शन उन्मुख हो सकता है, लेकिन फिर इसे जारी रखने के लिए डेटा छोड़ना या छोड़ना होगा वैसे भी पुन: ट्रांसमिशन त्रुटियों, तो अतिरिक्त ओवरहेड से परेशान क्यों?

+0

उत्तर को पसंद किया Mystere :) – mahesh

0

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

0

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

rtpchecksums=yes ; or no if you prefer 

चीयर्स!

5

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

आरएफसी 4588 वर्णन करता है कि कोई आरटीपी डेटा के साथ पुन: ट्रांसमिशन का उपयोग कैसे कर सकता है। अधिकांश क्लाइंट जो आरटीपी धाराएं प्राप्त करते हैं, वे नेटवर्क में जिटर के लिए एक बफर को नियोजित करते हैं जो आम तौर पर 1-5 सेकंड लंबा होता है और जिसका मतलब है कि वांछित डेटा प्राप्त करने के लिए रीट्रांसमिट के लिए समय उपलब्ध है।

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

+0

+1 आरटीपी के लिए टीसीपी पर चलाने में सक्षम है। इसके अलावा, टीसीपी पर आरटीपी फ़्रेमिंग मुद्दों को पेश कर सकता है। उदाहरण के लिए, आरएफसी 4103, अपने स्वयं के फ़्रेमिंग को परिभाषित नहीं करता है, इसलिए यदि आप इसे टीसीपी पर चलाने का प्रयास करते हैं तो आपको अपने _own_ फ़्रेमिंग प्रोटोकॉल को परिभाषित करने की आवश्यकता होगी। –

संबंधित मुद्दे