क्या यूडीपी अभी भी डेटा-हैवी रियलटाइम गेम्स के लिए टीसीपी से बेहतर है?

71

मुझे पता है कि UDP आमतौर पर उच्च डेटा उपयोग के साथ वास्तविक समय मल्टीप्लेयर गेम के लिए अनुशंसित है।

अधिकांश लेख सर्वल वर्ष पुराने हैं, और चूंकि ~ इंटरनेट पर प्रसारित सभी डेटा का 80% टीसीपी है, टीसीपी के लिए बहुत अधिक अनुकूलन किया जाना चाहिए।

यह मुझे आश्चर्यचकित करता है: क्या यूडीपी अभी भी गति और विलंबता के मामले में बेहतर है? क्या हाल ही में टीसीपी अनुकूलन ने टीसीपी को यूडीपी से बेहतर प्रदर्शन किया है?

— KaareZ
स्रोत

25

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

— नाथन

4

@KareZ क्या आप को लागू करने के लिए तेजी से मतलब है?

— नाथन

2

@nathan यह UDP की तुलना में टीसीपी के साथ अपने आवेदन को विकसित करना आसान है। मैं जानना चाहता हूं कि सभी टीसीपी अनुकूलन ने प्रदर्शन के मामले में टीसीपी को बेहतर विकल्प बना दिया है।

— केआरजेड

3

@KaareZ मैं एक विशेषज्ञ नहीं हूं, लेकिन इसके बारे में सोचते हैं। प्रदर्शन की अवधि में टीसीपी बेहतर कैसे हो सकता है और अभी भी एक विश्वसनीय प्रोटोकॉल हो सकता है? आपके पास सब कुछ नहीं हो सकता। टीसीपी विश्वसनीयता के लिए बनाई गई है। असली सवाल यह है कि आप अपने खेल में टीसीपी का उपयोग क्यों करना चाहेंगे?

— नाथन

7

यूडीपी टीसीपी से बेहतर है अगर और केवल अगर आप (= अनुभवी निम्न-स्तरीय नेटवर्किंग प्रोग्रामर) करने में सक्षम हैं, तो केवल टीसीपी सुविधाओं को प्रभावी ढंग से आपके अंदर की जरूरत है। प्रदर्शन के लिए अनावश्यक टीसीपी सुविधाओं को छोड़ना।

— वंद्रा

119

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

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

पहले अद्यतन के नुकसान का पता चला है।
पहले अद्यतन का पुन: प्रसारण का अनुरोध किया जाता है।
रिट्रांसमिशन आ गया है और संसाधित हो गया है।

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

इसके लिए आपको सही प्रकार का डेटा भेजना होगा, और अपने संचार को इस तरह से डिज़ाइन करना होगा कि डेटा खोना स्वीकार्य हो।

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

EDIT - कुछ टिप्पणियों को शामिल / संबोधित करने के लिए कुछ अतिरिक्त जानकारी जोड़ना:

आम तौर पर, ईथरनेट पर पैकेट हानि दर बहुत कम है, लेकिन वाईफाई शामिल होने या उपयोगकर्ता के अपलोड / डाउनलोड प्रगति पर होने पर यह बहुत अधिक हो जाता है। मान लेते हैं कि हमारे पास 0.01% (एक तरह से, गोल-यात्रा नहीं) का बिल्कुल समान पैकेट नुकसान है। पहले व्यक्ति शूटर पर, ग्राहकों को जब भी कुछ होता है, तो अपडेट भेजना चाहिए, जैसे कि जब माउस कर्सर खिलाड़ी को बदलता है, जो प्रति सेकंड लगभग 20 बार होता है। वे प्रति फ्रेम या एक निश्चित अंतराल पर अपडेट भी भेज सकते थे, जो प्रति सेकंड 60-120 अपडेट होगा। चूंकि ये अपडेट अलग-अलग समय पर भेजे जाते हैं, इसलिए उन्हें प्रति अपडेट एक पैकेट में भेजा जाना चाहिए। 16 खिलाड़ी के खेल पर, सभी 16 खिलाड़ी सर्वर पर प्रति सेकंड इन 20-120 पैकेटों को भेजते हैं, जिसके परिणामस्वरूप कुल 320-1920 पैकेट प्रति सेकंड होता है। 0.01% की हमारी पैकेट हानि दर के साथ, हम हर 5.2-31.25 सेकंड में एक पैकेट खोने की उम्मीद करते हैं।

खोए हुए पैकेट के बाद हमें मिलने वाले प्रत्येक पैकेट पर, हम एक डुपैक भेजेंगे, और 3 डुपैक के बाद प्रेषक खोए हुए पैकेट को फिर से भेज देगा । तो उस समय टीसीपी को फिर से शुरू करने की आवश्यकता होती है 3 पैकेट, इसके अलावा अंतिम डुपैक के प्रेषक पर पहुंचने में लगने वाला समय। फिर हमें रिट्रांसमिशन के आने का इंतजार करना होगा, इसलिए कुल मिलाकर हम 3 पैकेट + 1 राउंडट्रैपी लेटेंसी का इंतजार करते हैं। राउंडट्रिप लेटेंसी आमतौर पर एक स्थानीय नेटवर्क पर 0-1 एमएस और इंटरनेट पर 50-200 एमएस है। अगर हम प्रति पैकेट 20 पैकेट भेजते हैं तो 3 पैकेट आम तौर पर 25 एमएस में पहुंचेंगे और अगर हम 20 पैकेट प्रति सेकंड भेजते हैं तो 150 मी।

इसके विपरीत, UDP के साथ हम अगला पैकेट प्राप्त करते ही एक खोए हुए पैकेट से उबर जाते हैं, इसलिए यदि हम प्रति पैकेट 120 पैकेट भेजते हैं, और 50 ms प्रति सेकंड 20 पैकेट भेजते हैं, तो हम 8.3 ms खो देते हैं।

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

— पीटर
स्रोत

नोट: UDP स्थानीय नेटवर्क (संभावित लाभ) को प्रसारित कर सकता है, और चूंकि Vista को UDP (नुकसान) पर सर्वर / प्रसारण चलाने के लिए व्यवस्थापक की आवश्यकता होती है (UAC / फ़ायरवॉल उपयोगकर्ता कार्रवाई की आवश्यकता है, यह सूचित करने में विफल रहता है)।

— पीटीओआर

7

"यदि आप टीसीपी पर 2 अपडेट भेजते हैं, और पहले अपडेट का एक पैकेट खो जाता है" सही है, लेकिन इसके होने की संभावना क्या है? पिंगमैन के अनुसार : "समय की अवधि में 2% पैकेट नुकसान से अधिक कुछ भी समस्याओं का एक मजबूत संकेतक है।"

— मुचहो

30

@Peter आप भूल रहे हैं कि TCP में हर गिरा हुआ पैकेट हर बाद के पैकेट को स्टॉल करता है । 100ms पिंग के साथ यह आसानी से 300-500ms हो सकता है इससे पहले कि पैकेट को फिर से जमा और प्राप्त किया जाता है, ताकि 6-10 पैकेट हो जो हर 33 सेकंड में ठप हो जाए। यह निश्चित रूप से एक भूकंप की तरह एफपीएस में ध्यान देने योग्य होगा ।

— ब्लूराजा - डैनी पफ्लुगुएफ्ट

12

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

— सुपरकैट

23

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

— 21

19

हम IP के ऊपर निर्मित TCP और UDP प्रोटोकॉल पर सहमत हैं , क्या हम नहीं? IP निर्दिष्ट करता है कि संदेशों को इंटरनेट पर कैसे वितरित किया जाता है, लेकिन संदेश संरचना, प्रारूप के बारे में कुछ भी नहीं है। यहां टीसीपी और यूडीपी प्रोटोकॉल आते हैं। वे आईपी गुणों का उपयोग करते हैं, लेकिन प्रोग्रामर को नेट संचार की निचली परतों के बारे में चिंता किए बिना संदेश विनिमय पर ध्यान केंद्रित करने दें। और यह बहुत अच्छा है, क्योंकि सीधे तारों में एनालॉग संकेतों से निपटना एक तरह से दर्दनाक होगा।

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

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

लेकिन , परे देखो। यूडीपी हमें केवल एक ही फायदा देता है, वह है इसकी गति, और यह सही है कि हम वास्तव में चाहते हैं। एक यूडीपी पैकेट को बिना किसी विशेष नियंत्रण के केवल तैयार किया गया, समेटा गया और भेजा गया, क्योंकि यही यूडीपी प्रोटोकॉल काम करता है। एक टीसीपी पैकेट को तैयार किया जाना चाहिए, लेबल किया जाना चाहिए, संक्षिप्त किया जाना चाहिए, और जब यह आता है तो एक एसीके को वापस भेजा जाता है ताकि प्रेषक को "पैकेट एक्स यहां है, चलते रहें" , और जब यह संकेत नहीं भेजा जाता है, तो इसका मतलब है कि ऐसे पैकेट एक्स को भेजा जाना चाहिए फिर।

मुझे पता है कि UDP आमतौर पर उच्च डेटा उपयोग के साथ वास्तविक समय मल्टीप्लेयर गेम के लिए अनुशंसित है।

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

विलंबता अधिक होने पर टीसीपी घबराने लगता है, 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>

स्निपेट का विस्तार करें

यह मुझे आश्चर्य है कि अगर गति और विलंबता के मामले में यूडीपी अभी भी बेहतर है।

खैर, हां, यह है और यह लंबे समय तक रहेगा। आप यहां टीसीपी बनाम यूडीपी के बारे में अधिक पढ़ सकते हैं ।

— liggiorgio
स्रोत

8

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

— सुपरकैट

@supercat दुर्भाग्य से, TCP के पास प्रेषक को यह बताने का कोई तरीका नहीं है कि उसने कौन से पैकेट किए और प्राप्त नहीं किए। इसका केवल एक तंत्र है "मैंने सभी बाइट्स को x अनुक्रम संख्या के माध्यम से प्राप्त किया है।" यदि प्रेषक पैकेट को प्राप्त करता है जो रिसीवर पहले से ही प्राप्त करता है, तो यह सिर्फ प्रतियों की अनदेखी करेगा।

— 21

@reirab: मैंने सोचा था कि कुछ आधुनिक एक्सटेंशन थे, जिसमें वह फीचर भी शामिल था, हालांकि इसके बिना भी मुझे लगता है कि एक कार्यान्वयन जिसने बाइट # 1,050,000 तक का डेटा भेजा था, लेकिन केवल 1,000,000 के लिए डेटा प्राप्त करने के लिए एक सेकंड में, बिना सुनवाई के एक सेकंड के बाद प्राप्त होता है। 1,000,000 में से किसी भी चीज़ के लिए कोई भी बीक, १००,००० से १,५००,००० तक का डेटा ब्लॉक करके शुरू करता है और फिर प्रतिक्रिया की प्रतीक्षा करता है। यदि इसे 1,000,500 तक के डेटा के लिए एक ऐक मिल जाता है तो यह अधिक डेटा को फिर से दर्ज कर सकता है; अगर यह 1,050,000 तक के डेटा के लिए एक ऐक हो जाता है तो यह रिट्रांसमिशन को छोड़ सकता है।

— सुपरकैट

1

@Giorgio IP अनुरूप संकेतों के बारे में कुछ भी निर्दिष्ट नहीं करता है। यह भौतिक परत पर किया जाता है। IP नेटवर्क परत पर ऊपर दो परतों को संचालित करता है। आईपी कम परवाह नहीं कर सकता है कि बिट्स फाइबर पर जा रहे हैं, एक उपग्रह लिंक, या एक 14.4 kbps डायल-अप मॉडेम। UDP और TCP ट्रांसपोर्ट लेयर पर IP से लेयर होती है। इसके अलावा, जैसे सुपरकैट कहता है, टीसीपी आवेदन के लिए एक स्ट्रीम इंटरफ़ेस प्रस्तुत करता है, न कि यूडीपी जैसे डेटाग्राम इंटरफ़ेस।

— पुनर्वसु

@supercat हम्म ... आप आधुनिक एक्सटेंशन के बारे में सही हो सकते हैं, हालांकि यह निश्चित रूप से मूल टीसीपी मानक का हिस्सा नहीं है। एक ACK में केवल एक अनुक्रम संख्या होती है। मुझे लगता है कि यदि कोई पैकेट प्रत्येक पैकेट के लिए संपूर्ण RTT के आसपास प्रतीक्षा करने के बजाय गिरा दिया जाता है, तो TCP कार्यान्वयन आम तौर पर संपूर्ण भेजें विंडो को फिर से शुरू करना शुरू कर देता है। यदि बहुत कम लाभ के लिए कई लगातार पैकेट खो जाते हैं, तो यह विलंबता की एक बड़ी राशि जोड़ देगा।

— 21

9

टीसीपी <- ट्रांसमिशन कंट्रोल प्रोटोकॉल। यह ट्रांसमिशन को नियंत्रित करने के लिए बनाया गया है ।

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

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

इसके अतिरिक्त

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

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

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

— Stormwind
स्रोत

1

नोट: नागल के एल्गोरिथ्म को अक्षम किया जा सकता है, उदाहरण के लिए लिनक्स ।

— मुशाहो

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

— जेफ मेडन

4

यह ट्रांसमिशन कंट्रोल प्रोटोकॉल है।

— ysdx

1

इन शब्दों को एक लाख बार लिखें ... thx - निश्चित।

— स्टॉर्मविंड

3

आप के पहले चित्र की तुलना कर सकते हैं आरएफसी 768 (यूडीपी) के पहले चित्र को RFCP 793 (टीसीपी) पेज 15 ।

दोनों एक "स्रोत पोर्ट" के लिए 16 बिट्स दिखाते हैं और उसके बाद "गंतव्य पोर्ट" के लिए 16 बिट्स। दोनों एक "चेकसम" के लिए 16 बिट्स दिखाते हैं। RFC 768 के अनुसार, UDP की "चेकसम प्रक्रिया वही है जो टीसीपी में उपयोग की जाती है।"

जबकि UDP की लंबाई UDP के आरेख के विवरण को लपेटती है, TCP की लंबाई 15 और 16 पृष्ठ पर वर्णित "96 बिट छद्म शीर्षलेखक" का हिस्सा है।

UDP से बेहतर प्रदर्शन के लिए TCP की अपेक्षा न करें। यह कई कारणों से होने की संभावना नहीं है। एक यह है कि टीसीपी में बस अधिक बिट्स हैं। इसलिए यदि उपकरण प्रति सेकंड एक निश्चित संख्या में बिट्स को प्रभावी ढंग से संसाधित कर सकते हैं, तो यह टीसीपी पैकेटों की तुलना में अधिक यूडीपी पैकेटों को अनुमति देगा।

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

— TOOGAM
स्रोत

हालाँकि अंग्रेजी सारांश (जैसा कि कुछ अन्य उत्तरों में देखा गया है) अच्छे हैं, बस कुछ सटीक और सटीक विवरण होने से यह सरल हो सकता है।

— TOOGAM

आपका मतलब है 16 बिट्स, बाइट्स नहीं!

— जैकर्न

ओह, मुझे मूर्ख। तकनीकी रूप से सटीक उत्तर अच्छे क्यों हैं, इसका एक उदाहरण देखें; वे त्रुटियों को पहचानना और सही जानकारी देखना आसान है। मैंने जवाब तय किया। शुक्रिया @jcaron

— TOOGAM

2

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

एक टीसीपी सत्र खुला रखें, और जब बम को बंद करना है तो सभी खिलाड़ियों को एक टीसीपी संदेश भेजें (यदि संभव हो तो नीचे देखें)
यूडीपी पोर्ट को सुनते रहें, और जब बम को छोड़ना है तो सभी खिलाड़ियों को यूडीपी संदेश भेजें, चाहे उनकी कनेक्शन स्थिति कोई भी हो

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

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

आधुनिक घर कनेक्शन और इंटरकनेक्ट ने इसे बदल दिया है, उस बिंदु पर जहां क्षेत्रीय विलंबता, यहां तक कि दिन के भीड़भाड़ वाले समय के दौरान, 15ms या उससे नीचे की सीमा में हैं। यूडीपी के बजाय टीसीपी चुनना ज्यादातर मामलों में अदृश्य होगा, क्योंकि विलंबता "कम पर्याप्त" है। हालाँकि, अभी भी UDP की प्रवृत्ति है कि कम विलंबता प्रोटोकॉल के रूप में टीसीपी को अपना इतिहास दिया गया है। इसलिए, अब (और शायद भविष्य में कुछ समय) यूडीपी को वास्तविक समय के संचार के लिए पसंद किया जाएगा।

— जेफ मेडन
स्रोत

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

— लुआन

1

@ Luaan Enter: TCP PSH ध्वज। जब कोई एप्लिकेशन इसे बंद करता है तो स्टैक पैकेट को अधिक डेटा की प्रतीक्षा किए बिना तुरंत भेजा जाता है। बहुत सारे अनुप्रयोग इसका सफलतापूर्वक उपयोग करते हैं (उदाहरण के लिए टेलनेट और ssh)।

— जेफ मेडन

2

मुझे पता है कि UDP आमतौर पर उच्च डेटा उपयोग
के साथ वास्तविक समय मल्टीप्लेयर गेम के लिए अनुशंसित है क्या UDP अभी भी गति और विलंबता के मामले में बेहतर है? क्या हाल ही में टीसीपी अनुकूलन ने टीसीपी को यूडीपी से बेहतर प्रदर्शन किया है?

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

वे मात्रा ("उच्च डेटा उपयोग") या थ्रूपुट के संबंध में भिन्न नहीं हैं। टीसीपी केवल यूडीपी के रूप में अधिक डेटा के माध्यम से धक्का देगा, यह आसानी से भौतिक केबल को संतृप्त करेगा।

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

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

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

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

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

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

— डैमन
स्रोत

2

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

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

यहाँ एक सरल वर्णन है कि क्या हो रहा है।

यूडीपी - आइसोलेट चंक O'data।
एक पैकेट बनाओ।
आईपी में इनकैप्सुलेट।
इसे भेज दो।

टीसीपी - एक स्ट्रीम O'data अलग।
धारा के सामने से एक पैकेट बनाओ।
आईपी में इनकैप्सुलेट।
टीसीपी विंडो में जगह के लिए प्रतीक्षा करें।
इसे भेज दो।
रसीद प्राप्त होने या समय समाप्त होने तक फिर से चालू रखें।
रसीद प्राप्त होने या समय समाप्त होने तक टीसीपी विंडो में रहें।

शिपिंग का मतलब है कि यह स्थानीय एनआईसी के माध्यम से बना, अब और नहीं।

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

लंबित (थोड़ा) होने पर अंततः प्राप्ति की संभावना बढ़ जाती है।

टीसीपी पैकेट को दूसरी ओर डेटा के एक आदेशित स्ट्रीम के रूप में पुन: प्राप्त किया जाता है। UPD पैकेट को अलग पैकेट के रूप में प्राप्त किया जाता है। प्रोटोकॉल आदेश को संरक्षित नहीं करता है।

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

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

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

Ps (मैं टिप्पणियों में जवाब देने के लिए टिप्पणियां नहीं जोड़ सकता) UDP डेटा के लिए भी अच्छा है जो वांछनीय है लेकिन आवश्यक नहीं है। फॉरवर्ड एरर करेक्शन इसका एक उदाहरण है, बहुत सारे अनावश्यक लेकिन वांछनीय पैकेट।

— dusc2don
स्रोत

3

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

— सुपरकैट

1

क्या सभी टीसीपी अनुकूलित रूटर्स ने टीसीपी को यूडीपी से बेहतर प्रदर्शन किया है?

एक और सवाल है: "डेटा भारी" का मतलब है कि आप अक्सर दृश्यों को लोड करेंगे?

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

— वदिम सुरव
स्रोत

यह "वॉक्सेल" गेम है, इसलिए हां, इसमें बहुत सारे दृश्य डेटा भेजने की आवश्यकता होगी।

— केआरजेड

@ KareareZ खैर, आप शायद उस मामले में व्यक्तिगत स्वतंत्र संदेशों के रूप में उन लोगों को भेजना चाहते हैं, वैसे भी अपने स्वयं के पुनर्प्रकाशन तंत्र के साथ। Minecraft टीसीपी पर शुरू हुआ, और इंटरनेट पर बहुत अधिक अप्राप्य था; UDP के लिए स्विच अधिकांश लोगों के लिए एक खुशी का अवसर था। मुख्य विचार यह है कि जब आप वॉक्सेल डेटा के 20 चंक्स भेजते हैं, और पहला "खो गया" है, तो आपको डेटा मिलते ही अन्य 19 विखंडू को दिखाने से ब्लॉक नहीं करना चाहिए; जब आपको पता चलता है कि पहले वाला गायब है, तो आप पुनः प्रयास करते हैं। टीसीपी पर, उन सभी 19 को बहुत कम से कम रोक दिया जाता है, और सबसे खराब स्थिति में पीछे कर दिया जाता है।

— लुआन

2

@ Luaan Minecraft ने वास्तविक गेमप्ले के लिए UDP पर स्विच नहीं किया है। यहां तक कि नवीनतम संस्करण अभी भी टीसीपी का उपयोग करते हैं। कोई ख़ुशी का मौक़ा नहीं ... :( Minecraft का एकमात्र हिस्सा जो यूडीपी का उपयोग करता है, व्यक्तिगत सर्वर को पिंग करने और यह निर्धारित करने के लिए सर्वर सूची है कि क्या वे ऑनलाइन हैं?

— camerondm9

1

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

प्रोटोकॉल की तुलना

सामान्यतया, यूडीपी (उपयोगकर्ता डेटाग्राम प्रोटोकॉल) कम से कम सुविधाओं की पेशकश करता है। यह सरल है कि आप बिना किसी रसीद / पावती के डेटा भेजते हैं।

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

उदाहरण: Skype कॉन्फ़्रेंस कॉल

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

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

कार्यान्वयन विकल्प

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

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

— निकोलस मिलर
स्रोत

1

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

टीसीपी 64K के बड़े "स्ट्रीम" पैकेट को भेजने की अनुमति देता है। यह "बड़ा" ब्लॉक वास्तव में कई छोटे ईथरनेट पैकेट में कटा हुआ है।

— Joust6809
स्रोत

क्या आप यह सुझाव देने की कोशिश कर रहे हैं कि यूडीपी और टीसीपी हेडर एक ही आकार के हैं?

— कैमरन 12