"तेज क्या है" की बात करते समय - कम से कम दो बहुत अलग पहलू होते हैं: थ्रूपुट और विलंबता।
यदि थ्रूपुट के बारे में कहा जाए - टीसीपी का प्रवाह नियंत्रण (जैसा कि अन्य उत्तरों में बताया गया है), अत्यंत महत्वपूर्ण है और यूडीपी पर तुलनीय कुछ भी कर सकता है, जबकि निश्चित रूप से संभव है, एक बड़ा सिरदर्द (टीएम) होगा। परिणामस्वरूप - जब आपको थ्रूपुट की आवश्यकता होती है तो यूडीपी का उपयोग करना , , शायद ही कभी एक अच्छे विचार के रूप में योग्य होता है (जब तक कि आप टीसीपी पर अनुचित लाभ प्राप्त नहीं करना चाहते हैं)।
हालांकि, अगर विलंबता के बारे में बात कर रहे हैं - पूरी बात पूरी तरह से अलग है। जबकि पैकेट नुकसान की अनुपस्थिति में टीसीपी और यूडीपी एक समान व्यवहार करते हैं (कोई अंतर, यदि कोई हो, सीमांत होना) - पैकेट खो जाने के बाद, पूरे पैटर्न में भारी बदलाव होता है।
किसी भी पैकेट के नुकसान के बाद, टीसीपी कम से कम 200ms (RFC6298 के प्रति पैरा 2.4 वर्ग प्रति 1sec) के लिए प्रतीक्षा करेगा, लेकिन व्यावहारिक आधुनिक कार्यान्वयन इसे 200ms तक कम करते हैं)। इसके अलावा, टीसीपी के साथ, यहां तक कि वे पैकेट जो गंतव्य होस्ट तक पहुंच गए थे - जब तक कि लापता पैकेट प्राप्त नहीं हो जाता है, तब तक आपके ऐप पर वितरित नहीं किया जाएगा (यानी, पूरे संचार में ~ 200ms देरी हो रही है) - BTW, यह प्रभाव, हेड-ऑफ के रूप में जाना जाता है -लीन ब्लॉकिंग, सभी विश्वसनीय ऑर्डर किए गए स्ट्रीमों के लिए अंतर्निहित है, चाहे टीसीपी या विश्वसनीय + यूडीपी का आदेश दिया गया हो। चीजों को और भी बदतर बनाने के लिए - यदि रिट्रांस्ड पैकेट भी खो गया है, तो हम ~ 600ms की देरी के बारे में बात करेंगे (तथाकथित घातीय बैकऑफ़ के कारण, 1 रिट्रांसमिट 200ms है, और दूसरा 200 * 2 = 400ms है)। यदि हमारे चैनल में 1% पैकेट का नुकसान है (जो कि आज के मानकों से बुरा नहीं है), और हमारे पास प्रति सेकंड 20 अपडेट के साथ एक गेम है - ऐसे 600ms देरी औसतन हर 8 मिनट में होगी। और जैसा कि आप तेजी से खेल में मारे जाने के लिए 600ms से अधिक पर्याप्त है - ठीक है, यह गेमप्ले के लिए बहुत बुरा है। ये प्रभाव ठीक उसी कारण हैं कि gamedevs अक्सर TCP पर UDP को प्राथमिकता देते हैं।
हालांकि, यूडीपी को विलंबता को कम करने के लिए उपयोग करते समय - यह महसूस करना महत्वपूर्ण है कि केवल "यूडीपी का उपयोग करना" पर्याप्त विलंबता सुधार प्राप्त करने के लिए पर्याप्त नहीं है, यह सब है कि आप यूडीपी का उपयोग कैसे कर रहे हैं। विशेष रूप से, जबकि RUDP पुस्तकालय आमतौर पर "एक्सपोनेंशियल बैकऑफ़" से बचते हैं और छोटे रिट्रांसमीटर समय का उपयोग करते हैं - यदि उन्हें "विश्वसनीय आदेश" स्ट्रीम के रूप में उपयोग किया जाता है, तो उन्हें अभी भी हेड-ऑफ-लाइन ब्लॉकिंग से पीड़ित होना पड़ता है (इसलिए दोहरे के मामले में) पैकेट की हानि, 600ms के बजाय हम लगभग 1.5 * 2 * RTT - या एक बहुत अच्छा 80ms RTT के लिए प्राप्त करेंगे, यह एक ~ 250ms देरी है, जो एक सुधार है, लेकिन यह अभी भी बेहतर करना संभव है)। दूसरी ओर, यदि http://gafferongames.com/networked-physics/snapshot-compression/ और / या http: // ithare में चर्चा की गई तकनीकों का उपयोग किया जाता है। , यह पूरी तरह से हेड-ऑफ-लाइन ब्लॉकिंग को खत्म करने के लिए संभव है (इसलिए 20 अपडेट / सेकंड के साथ गेम के लिए डबल-पैकेट नुकसान के लिए, आरटीटी की परवाह किए बिना देरी 100ms होगी)।
और एक साइड नोट के रूप में - यदि आप केवल टीसीपी तक पहुँच प्राप्त करते हैं, लेकिन कोई यूडीपी नहीं है (जैसे कि ब्राउज़र में, या यदि आपका क्लाइंट यूडीपी को अवरुद्ध करने वाले 6-9% बदसूरत फ़ायरवॉल में से एक के पीछे है) - तो ऐसा लगता है यूडीपी-ओवर-टीसीपी को बहुत अधिक विलंब के बिना लागू करें, यहां देखें : http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (टिप्पणियों को पढ़ने के लिए सुनिश्चित करें! (!)।