टीसीपी बनाम यूडीपी या नेटवर्क प्रोटोकॉल का भविष्य

प्रत्येक सेवा से कम से कम 1 एमबी / सेकेंड का इंटरनेट ट्रैफ़िक उत्पन्न करने से पहले, सवाल उठता है: “कैसे? टीसीपी पर या यूडीपी पर? " डिलीवरी क्षेत्रों में, डिलीवरी प्लेटफॉर्म सहित, इस तरह के निर्णय लेने की प्राथमिकताएं और परंपराएं पहले ही विकसित हो चुकी हैं।

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

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

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


सावधानी, कट के तहत 99 चित्र और चित्र और सभी महत्वपूर्ण।

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

टीसीपी बनाम यूडीपी। न्यूनतम सिद्धांत

तुलना करने के लिए, हमें थोड़ा बुनियादी सिद्धांत चाहिए।



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



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



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

बहुत मोटे तौर पर बोलते हुए, टीसीपी एक विश्वसनीय वितरण प्रोटोकॉल है, और यूडीपी एक अविश्वसनीय है।

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

• टीसीपी की तुलना क्यों करें या इसके साथ क्या गलत है;
• टीसीपी की तुलना किससे और किस आधार पर की जानी चाहिए;
• Google ने क्या किया और उसने क्या निर्णय लिया;
• नेटवर्क प्रोटोकॉल का भविष्य हमें इंतजार कर रहा है।

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

टीसीपी की तुलना क्यों करें या इसमें क्या गलत है

टीसीपी का आविष्कार 1974 में किया गया था, और 20 साल बाद, जब मैं स्कूल गया, मैंने इंटरनेट कार्ड खरीदे, कोड मिटा दिया, और कहीं बुलाया। इसके अलावा, यदि आप 2 रातों से सुबह 7 बजे तक कॉल करते हैं, तो इंटरनेट मुफ्त था, लेकिन इसके माध्यम से प्राप्त करना मुश्किल था।

एक और 20 साल बीत गए, और मोबाइल वायरलेस नेटवर्क पर उपयोगकर्ता "वायर्ड" उपयोगकर्ताओं पर हावी होने लगे, जबकि टीसीपी ने वैचारिक रूप से परिवर्तन नहीं किया।

मोबाइल की दुनिया जीत गई, वायरलेस प्रोटोकॉल दिखाई दिए, और टीसीपी अभी भी अपरिवर्तित था।

आज, 80% उपयोगकर्ता वाई-फाई या 3 जी -4 जी वायरलेस नेटवर्क का उपयोग करते हैं।



वायरलेस नेटवर्क में, निम्न हैं:

• पैकेट का नुकसान - जो पैकेट हम भेजते हैं उसका लगभग 0.6% रास्ते से खो जाता है;
• पुन: व्यवस्थित करना - वास्तविक जीवन में स्थानों में पैकेजों की पुनर्व्यवस्था एक दुर्लभ घटना है, लेकिन यह 0.2% मामलों में होता है;
• घबराना - जब पैकेट समान रूप से भेजे जाते हैं और लगभग 50 एमएस की देरी से कतारों में पहुंचते हैं।

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

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



यही है, औसतन, हमारे उपयोगकर्ताओं के लिए (रूस के पश्चिमी भाग को छोड़कर): थ्रूपुट 1.1 एमबीपीएस, 0.6% पैकेट हानि, आरटीटी (गोल-यात्रा समय) लगभग 200 एमएस।

RTT की गणना कैसे करें

जब मैंने 200ms का औसत देखा, तो मुझे लगा कि आंकड़ों में त्रुटि है, और RIPE एटलस का उपयोग करके वैकल्पिक रूप से MSC में हमारे सर्वरों को RTT को मापने का फैसला किया। यह इंटरनेट की स्थिति के बारे में डेटा एकत्र करने के लिए एक प्रणाली है। RIPE Atlas जांच मुफ्त में उपलब्ध है।



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



अजीब तरह से पर्याप्त, यादृच्छिक बिंदुओं के बीच कई ऐसे हैं जिनमें 200 से 300 एमएस तक पिंग है।

कुल मिलाकर, वायरलेस नेटवर्क लोकप्रिय और अस्थिर हैं (हालांकि बाद को आमतौर पर अनदेखा किया जाता है, क्योंकि यह माना जाता है कि टीसीपी इसे संभाल सकता है):

• 80% से अधिक उपयोगकर्ता वायरलेस इंटरनेट का उपयोग करते हैं;
• वायरलेस नेटवर्क के पैरामीटर गतिशील रूप से निर्भर करते हैं, उदाहरण के लिए, इस तथ्य पर कि उपयोगकर्ता ने कोने को बदल दिया है;
• वायरलेस नेटवर्क में पैकेट हानि, घबराना, पुन: व्यवस्थित होने की उच्च दर होती है;
• निश्चित असममित चैनल, आईपी पते का परिवर्तन।

सामग्री की खपत इंटरनेट की गति पर निर्भर करती है

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



इन आंकड़ों के अनुसार, रूस के पास काफी तेज़ इंटरनेट है, लेकिन हमारे आंतरिक डेटा के अनुसार, औसत गति थोड़ी कम है।

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

कैसे लोडिंग को गति दें

वीडियो प्लेटफॉर्म को विकसित करने की प्रक्रिया में, हमने महसूस किया कि वायरलेस नेटवर्क में टीसीपी बहुत प्रभावी नहीं है। आप इस निष्कर्ष पर कैसे आए?

हमने डाउनलोड को गति देने का फैसला किया और अगली चाल चली।



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

चार टीसीपी कनेक्शन वास्तव में सर्वर पर 3 गुना तेजी से डेटा अपलोड कर सकते हैं।

इसलिए हमने वीडियो डाउनलोड गति बढ़ा दी और निष्कर्ष निकाला कि डाउनलोड को समानांतर करने की आवश्यकता है।

अस्थिर नेटवर्क में टीसीपी

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



तालिका RTT और नुकसान को दर्शाती है। यह देखा जा सकता है कि 0% हानि के मामले में, नेटवर्क 100% उपयोग किया जाता है।

अगले पुनरावृत्ति से, हम पैकेट नुकसान को 5% तक बढ़ा देते हैं, और हम देखते हैं कि नेटवर्क केवल 74% द्वारा उपयोग किया जाता है। यह ठीक लगता है - 5% के पैकेट नुकसान के साथ, 26% नेटवर्क खो जाता है। लेकिन अगर आप पिंग भी बढ़ाते हैं, तो आधे से भी कम चैनल बने रहेंगे।

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

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



समानांतर टीसीपी कनेक्शनों की संख्या में वृद्धि के साथ, नेटवर्क का उपयोग लगभग थ्रूपुट के बराबर हो जाता है, नुकसान का प्रतिशत घटा देता है।

इस प्रकार, यह निकला:

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

जाहिर है, आपको कहीं और स्थानांतरित करने और टीसीपी के विकल्पों पर विचार करने की आवश्यकता है।

टीसीपी बनाम टीसीपी नहीं

गर्म की तुलना कैसे करें? दो विकल्प हैं।

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

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

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



नेटवर्क कैसे काम करता है, इसका अध्ययन करते हुए हम इसे विकसित करेंगे।

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

खैर, और क्या तुलना करने के लिए?

नेटवर्क अलग हैं:

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

आप हमेशा नेटवर्क प्रोफाइल को खुद छू सकते हैं: अपने फोन पर एक या दूसरे प्रोफाइल का चयन करें और स्पीड टेस्ट चलाएं।



नेटवर्क प्रोफाइल के अलावा, आपको ट्रैफ़िक खपत का प्रोफ़ाइल भी निर्धारित करना होगा। यहाँ हम इस्तेमाल कर रहे हैं:



चूंकि मैं वीडियो और स्ट्रीम के लिए जिम्मेदार हूं, इसलिए प्रोफाइल उपयुक्त हैं:

• प्रोफ़ाइल वीडियो, जब आप इस या उस सामग्री को कनेक्ट और स्ट्रीम करते हैं। ऊपरी ग्राफ़ के रूप में कनेक्शन की गति बढ़ जाती है। इस प्रोटोकॉल के लिए आवश्यकताएँ: कम विलंबता और बिटरेट अनुकूलन।
• टेप दृश्य विकल्प: आवेग डेटा लोडिंग, पृष्ठभूमि क्वेरी, डाउनटाइम। इस प्रोटोकॉल के लिए आवश्यकताएँ: प्राप्त डेटा को बहुसंकेतन और प्राथमिकता दी जाती है, उपयोगकर्ता सामग्री की प्राथमिकता पृष्ठभूमि प्रक्रियाओं की तुलना में अधिक है, डाउनलोड को रद्द करना है।

बेशक, आपको सबसे लोकप्रिय HTTP पर प्रोटोकॉल की तुलना करने की आवश्यकता है।

HTTP 1.1 और HTTP 2.0

SSL के शीर्ष पर 2000 मानक स्टैक HTTP 1.1 जैसा दिखता था। आधुनिक स्टैक HTTP 2.0, TLS 1.3 और सभी TCP के शीर्ष पर है।



मुख्य अंतर यह है कि HTTP 1.1 ब्राउज़र में एक डोमेन के लिए सीमित पूल का उपयोग करता है, इसलिए वे चित्रों के लिए एक अलग डोमेन बनाते हैं, डेटा के लिए, और इसी तरह। HTTP 2.0 एक बहुसंकेतित कनेक्शन प्रदान करता है जिसमें यह सारा डेटा संचारित होता है।



HTTP 1.1 इस तरह काम करता है: एक अनुरोध करें, डेटा प्राप्त करें, एक अनुरोध करें, डेटा प्राप्त करें।



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



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

HTTP 1.1 के साथ, आपको अभी भी वही मिलता है जो आपने अनुरोध किया था, डाउनलोड को रद्द करना मुश्किल है।

कनेक्शन बंद करने का एकमात्र मौका सॉकेट सॉकेट है। फिर हम देखेंगे कि यह क्यों खराब है।

HTTP 2.0 में अंतर

HTTP 2.0 इन समस्याओं को हल करती है:

• बाइनरी, हेडर संपीड़न;
• डेटा मल्टीप्लेक्सिंग;
• प्राथमिकता;
• डाउनलोड रद्द करना;
• सर्वर धक्का

आइए हमारे लिए और अधिक महत्वपूर्ण बिंदुओं पर विचार करें।



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



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

एक रीसेट स्ट्रीम कमांड भी है जो ब्राउज़र को पृष्ठों, आदि के बीच जाने पर खुद को निष्पादित करता है। मोबाइल क्लाइंट के लिए, इसकी मदद से, आप कनेक्शन खोए बिना डेटा प्राप्त करने से इनकार कर सकते हैं।

इस प्रकार, हम अलग-अलग पर टीसीपी की तुलना करेंगे:

• नेटवर्क प्रोफाइल: वाई-फाई, 3 जी, एलटीई।
• उपभोग प्रोफ़ाइल: टेप की सामग्री प्राप्त करने के लिए डाउनलोड (HTTP / 2) को रद्द करने के साथ स्ट्रीमिंग (वीडियो), बहुसंकेतन और प्राथमिकता।

दोषरहित मॉडल

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

आरटीटी पिंग है, पैकेट का टर्न-अराउंड समय, पावती की रसीद या प्रतिक्रिया प्रतिध्वनि समय।

बैंडविड्थ को मापने के लिए - नेटवर्क बैंडविड्थ - हम पैकेट का एक पैकेट भेजते हैं और एक निश्चित समय अंतराल पर प्रेषित पैकेटों की संख्या की गिनती करते हैं।



चूंकि हम विश्वसनीय प्रोटोकॉल के साथ काम करते हैं, ज़ाहिर है, एक पावती है - हम पैकेट भेजते हैं और रसीद की पुष्टि प्राप्त करते हैं।

धीमे इंटरनेट की समस्या

2013 में हमारी वीडियो सेवा के विकास के भोर में, मेरा दोस्त कैलिफोर्निया गया और उसने ओडनोकलास्निक पर अपनी पसंदीदा श्रृंखला की एक नई श्रृंखला देखने का फैसला किया। उनके पास 250 एमएम आरटीटी था, जो गूगल कैंपस में वाई-फाई 400 एमबीपीएस परफेक्ट था, वह फुलएचडी में नई सीरीज देखना चाहते थे।

क्या आपको लगता है कि वह वीडियो देखने में सक्षम था? उत्तर हमारे सर्वर पर सेंड / रिकव बफर के कॉन्फ़िगरेशन पर निर्भर करता है।



चूंकि हमारे पास पावती के साथ एक प्रोटोकॉल है, इसलिए डिलीवरी का पुष्टिकरण प्राप्त नहीं करने वाले सभी डेटा को एक बफर में संग्रहीत किया जाता है। यदि भेजने वाले बफर 128 Kb तक सीमित है, तो ये 128 Kb RTT के लिए कम हैं, हम नहीं भेज सकते हैं। इस प्रकार, 400 Mbit / s के हमारे नेटवर्क से, 4 Mbit / s रहता है। यह फुलएचडी में ऑनलाइन वीडियो देखने के लिए पर्याप्त नहीं है।

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

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

सब कुछ ठीक लगने लगा है। आप fast.com सेवा पर जा सकते हैं, जो आपके इंटरनेट की गति को नेटफ्लिक्स सर्वर पर मापती है। ऑफिस से मुझे 210 एमबीपीएस की स्पीड मिली। और फिर नेट शेपर के माध्यम से मैंने कार्य की शर्तों को निर्धारित किया और फिर से इस साइट पर गया। जादू - मुझे 4 एमबीपीएस बिल्कुल मिला।



कोई फर्क नहीं पड़ता कि मैं इसे कैसे मोड़ता हूं, नेटफ्लिक्स ने 128 केबी से बड़ा बफर प्राप्त करने का प्रबंधन नहीं किया।

बफर का आकार

इष्टतम बफर आकार का पता लगाने के लिए, आपको यह समझने की आवश्यकता है कि ऑन-द-फ्लाई पैकेट क्या हैं।



एक नेटवर्क स्थिति है:

• पैकेट 1 और 2 पहले ही भेजे जा चुके हैं, उनके लिए एक पुष्टि प्राप्त हुई है;
• पैकेट 3, 4, 5, 6 भेजे गए थे, लेकिन वितरण परिणाम अज्ञात है (ऑन-द-फ्लाई पैकेट);
• अन्य पैकेट कतार में हैं।

यदि ऑन-द-फ्लाई में पैकेट की संख्या बफर के आकार के बराबर है, तो यह पर्याप्त बड़ा नहीं है। इस मामले में, नेटवर्क भूख से मर रहा है, पूरी तरह से उपयोग नहीं किया गया है।

रिवर्स स्थिति संभव है - बफर बहुत बड़ा है। इस मामले में, बफर सूज जाता है। यह बुरा क्यों है?



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

एक सरल समाधान स्वचालित रूप से बफर आकार को समायोजित करना है। अब यह कई क्लाइंट्स पर उपलब्ध है और कुछ इस तरह से काम करता है।



यदि बहुत सारे पैकेट अब भेजे जा सकते हैं, तो बफर बढ़ रहा है, डेटा ट्रांसफर तेज हो रहा है, बफर का आकार बढ़ रहा है, सब कुछ बहुत अच्छा लग रहा है।

लेकिन एक समस्या है। यदि बफर बढ़ गया है, तो इसे इतनी आसानी से कम नहीं किया जा सकता है। यह अधिक कठिन कार्य है। यदि गति कम हो जाती है, तो वही बफर सूजन होती है। बफर काफी बड़ा और भरा हुआ है, हमें तब तक इंतजार करने की जरूरत है जब तक कि सभी डेटा क्लाइंट को नहीं भेजे जाते।

यदि हम अपना यूडीपी प्रोटोकॉल लिखते हैं, तो सब कुछ बहुत सरल है - हमारे पास बफर तक पहुंच है।



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

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

यह कैसे किया जाता है? यह ज्ञात है कि पैकेटों को बहाल करने, वितरण का प्रबंधन करने, स्वीकृति प्राप्त करने के लिए आपको पैकेट के कुछ क्रम_ की आवश्यकता है। Sequence_id हमें केवल-ऑन-द-फ़्लाई पैकेट के लिए लिखा जाता है, यानी हम इसे तभी जारी करते हैं जब हम पैकेट भेजते हैं। बफ़र में अन्य सभी चीज़ों को तब तक ले जाया जा सकता है जब तक हम चाहते हैं कि पैकेट चले नहीं जाते।

निष्कर्ष: टीसीपी बफर को सही ढंग से कॉन्फ़िगर किया जाना चाहिए, शेष को पकड़ना चाहिए ताकि नेटवर्क को समाप्त न करें और बफर को न फुलाएं। अपने स्वयं के यूडीपी प्रोटोकॉल के लिए, सब कुछ सरल है - इसे नियंत्रित किया जा सकता है।

हानिपूर्ण नेटवर्क मॉडल

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



पैकेट भेजता है, प्रत्येक पैकेट के लिए पावती प्राप्त करता है। Retransmit timeout (RTO) RTT , .

TCP, 5% , 50%.



retransmit, , . , , Congestion control.

Congestion control

flow control, .

• Flow control — . , , . flow control recv window, . flow control — back pressure , - .
• congestion control . , — .

, : , , , . , congestion control.

TCP window.



flow control congestion control, .

:

• TCP window = 1, : acknowledgement, ..
• TCP window = 4, , acknowledgement .

, . initial window TCP = 10.



, , .

?

• , . , .
• : , acknowledgements .
• - , acknowledgements ( ).

.



, , . : , .. , . congestion control, TCP window, , .



congestion control, , — . packet loss — , . , , — , .

, TCP , , congestion control loss-. congestion control loss delay, , .



:

• Cubic — Congestion Control Linux 2.6. : — .
• BBR — Congestion Control, Google 2016 . .

BBR Congestion Control

Cubic BBR feedback.



, — acknowledgement . :

• BBR , , , .
• Cubic .

नीचे विलंब बनाम कनेक्शन समय का एक ग्राफ है, जो दिखाता है कि अलग-अलग भीड़ नियंत्रण पर क्या होता है।



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

क्यूबिक आक्रामक रूप से काम करता है - यह पूरे बफर को ओवरफ्लो करता है, और जब बफर ओवरफ्लो और पैकेट का नुकसान होता है, तो क्यूबिक विंडो को कम कर देता है।

ऐसा लगता है कि बीबीआर की मदद से सभी समस्याओं को हल करना संभव होगा, लेकिन नेटवर्क में घबराहट होती है - पैकेट में कभी-कभी देरी होती है, कभी-कभी बंडलों में समूहीकृत होते हैं। आप उन्हें एक निश्चित आवृत्ति के साथ भेजते हैं, और वे समूहों में आते हैं। इससे भी बदतर, जब आप इन पैकेजों को वापस पावती प्राप्त करते हैं, और वे किसी तरह "घबराना" भी करते हैं।

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



यह देखा जा सकता है कि पैकेट असमान रूप से आते हैं, औसत घबराना लगभग 50 एमएस है। स्वाभाविक रूप से, बीबीआर गलत हो सकता है।

BBR अच्छा है क्योंकि यह बीच में अंतर करता है: डिवाइस की ओवरफ्लो के कारण वास्तविक जमाव की हानि, पैकेट की हानि और खराब वायरलेस नेटवर्क के कारण यादृच्छिक हानि। लेकिन उच्च जर्क के मामले में यह अच्छी तरह से काम नहीं करता है। मैं उसकी मदद कैसे कर सकता हूं?

कंजेशन कंट्रोल को बेहतर कैसे बनाएं

वास्तव में, टीसीपी के पास पावती में पर्याप्त जानकारी नहीं है, इसमें केवल वही पैकेट है जो उसने देखा था। चयनात्मक पावती भी है, जो कहता है कि कौन से पैकेट की पुष्टि की जाती है, जो अभी तक नहीं आए हैं। लेकिन यह जानकारी पर्याप्त नहीं है।



यदि आपके पास पावती को बढ़ाने का अवसर है, तो आप अभी भी हर समय बचा सकते हैं - न केवल इन पैकेटों को भेज रहे हैं, बल्कि क्लाइंट पर भी पहुंच सकते हैं। यह वास्तव में, सर्वर पर घबराना क्लाइंट को इकट्ठा करने के लिए है।

आम तौर पर पावती को बढ़ाने के लिए यह प्रभावी क्यों है? क्योंकि मोबाइल नेटवर्क असममित हैं। उदाहरण के लिए, आमतौर पर 3 जी या एलटीई के साथ, 70% बैंडविड्थ को डेटा डाउनलोड करने के लिए और अपलोड के लिए 30% आवंटित किया जाता है। ट्रांसमीटर स्विच: अपलोड - डाउनलोड, अपलोड - डाउनलोड, और आप इसे किसी भी तरह से प्रभावित नहीं करते हैं। यदि आप कुछ भी नहीं उतारते हैं, तो यह केवल बेकार है। इसलिए, यदि आपके पास कोई दिलचस्प विचार है, तो पावती बढ़ाएं, शर्मीली न हों - यह कोई समस्या नहीं है।



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

कौन सा चयन चुनने के लिए नियंत्रण

सहपाठियों का एक बड़ा नेटवर्क है जिसमें बहुत सारे ट्रैफ़िक हैं: वीडियो, एपीआई, चित्र। और ऐसे आँकड़े हैं जिनके लिए भीड़ नियंत्रण नियंत्रण के लिए बेहतर है।

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



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

उदाहरण के लिए, यह एक वीडियो पर बीबीआर शुरू करने का प्रभाव है।



हम देखने की गहराई को गंभीरता से बढ़ाने में कामयाब रहे। Google का कहना है कि उनके पास BBR का उपयोग करते समय खिलाड़ी में लगभग 10% कम बफरिंग है।

महान, लेकिन हमारे ग्राहकों के बारे में क्या?



ग्राहक थोड़े धीमे होते हैं, उन सभी में घन होता है, और आप इसे प्रभावित नहीं कर सकते। लेकिन यह ठीक है, कभी-कभी आप डेटा को समानांतर कर सकते हैं, और यह अच्छा होगा।

भीड़ नियंत्रण के बारे में निष्कर्ष:

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

यदि आप अपना यूडीपी प्रोटोकॉल बनाते हैं, तो आपको भीड़ नियंत्रण के मामले में बहुत अधिक स्वतंत्रता है।

मल्टीप्लेक्सिंग और प्राथमिकता

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



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

यह पता चलता है कि यदि आप HTTP 2.0 का उपयोग करते हैं, तो यह टीसीपी पर मल्टीप्लेक्सिंग हमेशा खराब नेटवर्क पर प्रभावी नहीं होता है।

अगली समस्या बफर सूजन है।



जब कोई चित्र क्लाइंट को भेजा जाता है, तो बफर बढ़ जाता है। हम इसे लंबे समय तक भेजते हैं, और फिर एक एपीआई अनुरोध प्रकट होता है, और इसे किसी भी तरह से प्राथमिकता नहीं दी जा सकती है। ऐसे मामलों में, टीसीपी प्राथमिकता काम नहीं करती है।

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

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



यह मुश्किल नहीं है, बस बफर के साथ संख्याओं के साथ पैकेट जोड़ें। ऑन-द-फ्लाई - जो पहले से ही भेजा गया है उसे स्पर्श न करें, लेकिन जो अभी तक नहीं भेजा गया है उसे फिर से व्यवस्थित किया जा सकता है। ऐसा दिखता है।



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

एक कनेक्शन स्थापित करें

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



इससे निपटने के लिए, आइए देखें कि कनेक्शन कैसे स्थापित किया गया है।



पहला DNS हल है - हम इसके साथ कुछ नहीं कर सकते। अगला, एक टीसीपी कनेक्शन स्थापित करें, एक सुरक्षित कनेक्शन स्थापित करें, फिर अनुरोध निष्पादित करें और प्रतिक्रिया प्राप्त करें। सबसे दिलचस्प बात यह है कि काम का वह हिस्सा जो सर्वर किसी अनुरोध का जवाब देते समय आमतौर पर कनेक्शन स्थापित करने में कम समय लेता है।

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



और यह सेकंड हो सकता है! यहां तक ​​कि 700 एमएस पर 4 जी भी महत्वपूर्ण है। लेकिन टीसीपी इस समय इतनी आसानी से नहीं रह सकती थी।

कनेक्शन मूल टीसीपी 3-वे हैंडशेक एल्गोरिदम पर आधारित है। सिंक, सिंक + ack करो, फिर बाद में अनुरोध को सही करें (चित्र में बाईं तरफ)।



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



Nginx यह सब कर सकता है - बस इसे चालू करें, सब कुछ काम करेगा (या इसे कर्नेल में चालू करें)।

टीएलएस

आइए देखें कि टीएलएस खराब है।

मैंने 200 ms में फिर से net shaper सेट किया, google.com को पिंग किया और देखा कि RTT = 220 मेरा RTT + RTT शेपर है। फिर मैंने HTTP और HTTPS के माध्यम से एक अनुरोध किया। मुझे पता चला कि HTTP पर RTT के दौरान प्रतिक्रिया प्राप्त करना संभव है, अर्थात्, TFO मेरे कंप्यूटर से Google के लिए काम करता है। HTTPS के लिए, इसमें अधिक समय लगा।



यह एक ऐसा सामान्य टीएलएस ओवरहेड है जिसे सुरक्षित कनेक्शन स्थापित करने के लिए संदेश की आवश्यकता होती है।



ऐसा करने के लिए, उन्होंने हमारे लिए सोचा, टीएलएस 1.3 जोड़ा। नगनेक्स में शामिल करना भी आसान है।



सब कुछ काम करने लगता है। लेकिन आइए देखें कि हमारे मोबाइल ग्राहकों में ऐसा क्या है जो इस सब का फायदा उठाता है।

ग्राहकों के साथ क्या हो रहा है

टीसीपी फास्ट ओपन एक अच्छी बात है। आंकड़ों के अनुसार।



ऐसे कई लेख हैं जो कहते हैं कि कनेक्शन स्थापित करना 10% तेजी से पारित करने की गारंटी है। लेकिन एंड्रॉइड 8.1.0 पर (मैंने विभिन्न उपकरणों को देखा) किसी के पास टीएफओ नहीं है। एंड्रॉइड 9 पर, मैंने एमुलेटर पर टीएफओ देखा, लेकिन वास्तविक उपकरणों पर नहीं। IOS थोड़ा बेहतर है। यहाँ आप इसे देख सकते हैं:

sysctl -a | grep fast net.ipv4.tcp_fastopen = 0 

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

टीएलएस 1.3 के साथ, जो हमें शून्य-आरटीटी कनेक्शन सेटअप का वादा करता है, और भी बेहतर है। मुझे ऐसा कोई भी Android डिवाइस नहीं मिला, जिस पर यह काम करे। इसलिए, फेसबुक ने फ़िज़ लाइब्रेरी बनाई। कुछ महीने पहले, यह खुले स्रोत में उपलब्ध हो गया, आप इसे अपने साथ खींच सकते हैं और टीएलएस 1.3 का उपयोग कर सकते हैं। यह पता चला है कि यहां तक ​​कि सुरक्षा को भी घसीटने की जरूरत है, इसके मूल में कुछ भी नहीं दिखता है।



आरेख हमारे मोबाइल ग्राहकों द्वारा एंड्रॉइड के विभिन्न संस्करणों के उपयोग को दर्शाता है। वी 9.x काफी थोड़ा है - जहां टीएफओ दिखाई दे सकता है, और टीएलएस 1.3 कहीं और नहीं पाया जाता है।

कनेक्शन स्थापित करने के बारे में निष्कर्ष:

• टीएफओ 95% उपकरणों के लिए उपलब्ध नहीं है।
• TLS1.3 को अपने साथ लाना होगा।
• यदि आपको इसे यूडीपी में दोहराने की आवश्यकता है, तो यह सब यूडीपी में स्थानांतरित करें और दोहराएं।

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

टीसीपी इसकी बड़ाई नहीं कर सकता। अधिकतम 5% मामलों में, यदि आप सब कुछ ठीक करते हैं, तो आप वास्तविक शून्य-आरटीटी प्राप्त कर पाएंगे जो हर कोई अब तक बात कर रहा है।

आईपी ​​पते में परिवर्तन

अक्सर, जब आप घर से निकलते हैं, तो आपका फोन वाई-फाई से 4 जी में बदल जाता है।

टीसीपी इस तरह काम करता है: आईपी पता बदल गया है - कनेक्शन विफल हो गया है।

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



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

टीसीपी में, आईपी प्रवासन एक असंभव बात है।

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

कनेक्शन का पुन: उपयोग

हर कोई कहता है कि आपको कनेक्शन का पुन: उपयोग करने की आवश्यकता है क्योंकि कनेक्शन बहुत महंगी चीज है।



लेकिन पुन: उपयोग करने वाले यौगिकों में नुकसान होते हैं।



सबसे अधिक संभावना है, बहुत से लोग याद करते हैं (यदि नहीं, तो यहां देखें) कि सभी के पास सार्वजनिक पते नहीं हैं, लेकिन एनएटी है, जो आमतौर पर होम राउटर पर कुछ समय के लिए मैपिंग स्टोर करता है। टीसीपी के लिए, यह स्पष्ट है कि कितना स्टोर करना है, लेकिन यूडीपी के लिए यह स्पष्ट नहीं है। NAT एक टाइमआउट पर चल रहा है, अगर आप सावधानीपूर्वक इस टाइमआउट को मापते हैं, तो हम पाते हैं कि लगभग 15-30 सेकंड में 50% से अधिक कनेक्शन विफल होने लगेंगे।

यह ठीक है - हम 15 के लिए एक पिंग-पोंग पैकेज बनायेंगे। ऐसे मामलों के लिए जब कनेक्शन अभी भी टूट गया है, तो आईपी माइग्रेशन है, जो आपको राउटर पर पोर्ट को बदलने की सस्ते में अनुमति देता है।

पैकेट पेसिंग

यह बहुत महत्वपूर्ण बात है अगर आप अपना यूडीपी प्रोटोकॉल कर रहे हैं।



यदि बहुत सरल है, तो आप लगातार पैकेट को नेटवर्क पर भेजते हैं, पैकेट के नुकसान की संभावना अधिक होती है। यदि आप पैकेट को फ़िल्टर करते हैं, तो पैकेट का नुकसान कम होगा।

यह कैसे काम करता है, इसके कई अलग-अलग सिद्धांत हैं, लेकिन मुझे यह पसंद है।



एक समय में 3 कनेक्शन बनाए जाते हैं। आपके पास तथाकथित प्रारंभिक विंडो है - एक ही समय में बनाए गए 10 पैकेज। बेशक, इस बिंदु पर बैंडविड्थ पर्याप्त नहीं हो सकता है। लेकिन अगर आप ध्यान से उन्हें वितरित करते हैं, तो उन्हें अलग करें, तो सब कुछ ठीक हो जाएगा, जैसा कि सही आंकड़े में है।

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



जब आपको पैकेट के माध्यम से कटौती करने की आवश्यकता होती है (पेसिंग करें):

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

MTU

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



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



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



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

मोबाइल ग्राहकों के बीच MTU के वितरण को देखने के लिए एक पेचीदा विकल्प है।



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

1. 1350 बाइट्स - 98% के बजाय हमें तुरंत 95% डिलीवरी मिलती है।
2. 1500 बाइट्स - एमटीयू, जिसके बाद पहले से ही 80% ग्राहकों को ऐसे पैकेट प्राप्त नहीं होंगे।

वास्तव में, हम यह कह सकते हैं: हम अपने ग्राहकों के 1-2% की उपेक्षा करते हैं, उन्हें खंडित पैकेजों पर रहने देते हैं। लेकिन हम तुरंत वही शुरू करेंगे जो हमें चाहिए - यह 1350 से है।

त्रुटि सुधार (SACK, NACK, FEC)

यदि आप अपना प्रोटोकॉल बना रहे हैं, तो आपको त्रुटियों को ठीक करने की आवश्यकता है। यदि पैकेट गायब है (यह वायरलेस नेटवर्क के लिए सामान्य है), इसे पुनर्स्थापित करने की आवश्यकता है।

सबसे सरल मामले में ( यहां अधिक विवरण), रिट्रेन्सिट टाइम आउट (आरटीओ) के माध्यम से एक रिले है। यदि पैकेट गायब है, तो रिट्रांसमीटर समय की प्रतीक्षा करें और इसे फिर से भेजें।

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



जब पैकेट चला जाता है, तो हम भेजना जारी रखते हैं - अन्य पैकेटों का प्रसारण होता है। इस समय, सर्वर कहता है कि उसे अगला पैकेट प्राप्त हुआ, लेकिन कोई पिछला नहीं था। ऐसा करने के लिए, वह एक पेचीदा पावती बनाता है, जो पैकेज नंबर + 1 के बराबर होता है, और डुप्लिकेट ack फ्लैग को सेट करता है। वह इन डुबकी को भेजता है, और तीसरे पर हम आमतौर पर समझते हैं कि पैकेट गायब हो गया है और इसे फिर से भेजना है।

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



ऐसा लगता है कि अगर हमें पता है कि पैकेज खो सकते हैं, तो हम पैकेज का एक सेट ले सकते हैं, इसमें एक XOR पैकेज जोड़ सकते हैं और डेटा प्राप्त करते समय क्लाइंट पर अतिरिक्त रिट्रांसमिशन के बिना समस्या को ठीक कर सकते हैं। लेकिन कई पैकेज गायब होने पर समस्या होती है। ऐसा लगता है कि इसे समता संरक्षण, रीड-सोलोमन, आदि के माध्यम से हल किया जा सकता है।

हमने इसे इस तरह आज़माया, यह पता चला कि वास्तव में पैकेट बंडल में गायब हो जाते हैं।



औसत पैकेट अंतर 6. निकला। यह एक बहुत ही असुविधाजनक पैकेट अंतराल है - आपको त्रुटि सुधार कोड की बहुत आवश्यकता है। इसी समय, 11 पर किसी तरह का शिखर है - मुझे नहीं पता कि क्यों, लेकिन पैकेट कभी-कभी 11 के पैक में गायब हो जाते हैं। इस पैकेट अंतराल के कारण, यह काम नहीं करता है।

Google ने भी यह कोशिश की, हर कोई FEC के सपने देखता है, लेकिन अभी तक किसी ने काम नहीं किया है।

एक और विकल्प है जब एफईसी मदद कर सकता है।



Retransmit Time Out, Fast Retransmit के माध्यम से Retransmit के अलावा, टेल लॉस जांच भी होती है । यह एक ऐसी चीज है जब आप डेटा भेजते हैं, और पूंछ चली जाती है। यही है, आपने डेटा का हिस्सा भेजा है, पांचवां पैकेट भेजा है - यह आ गया है। फिर पैकेट गायब होने लगे, उदाहरण के लिए, क्योंकि नेटवर्क विफल हो गया। पैकेट गायब हो जाते हैं, गायब हो जाते हैं, और आपको केवल पांचवे पैकेट के लिए पावती मिलती है।

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

आप एफईसी को टीएलपी में जोड़ सकते हैं। आप उन सभी पैकेटों को देख सकते हैं जो नहीं पहुंचे, उन पर समता की गिनती करें और कुछ समानता पैकेट के साथ टीएलपी भेजें।

यह सब शांत है, यह काम करने लगता है। लेकिन ऐसी समस्या है।



हमने आंकड़े एकत्र किए, और यह पता चला कि 98% त्रुटियों की मरम्मत फास्ट रिट्रांसमिट के माध्यम से की जाती है। बाकी की मरम्मत रिट्रांसमिट टाइम आउट के माध्यम से की जाती है, और टीएलपी के माध्यम से 1% से भी कम। यदि आप कुछ और एफईसी तय करते हैं, तो यह 0.5% से कम होगा।

टीसीपी FEC का समर्थन नहीं करता है। यूडीपी में ऐसा करना मुश्किल नहीं है, लेकिन सामान्य मामले में, मानक टीसीपी रिकवरी एल्गोरिदम पर्याप्त हैं।

प्रदर्शन

यूडीपी के साथ टीसीपी की तुलना करके प्रदर्शन को नुकसान नहीं पहुंचाना संभव होगा।

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

ज़ेरोस्कोपी और एलएसओ के लिए अनुकूलन का समर्थन करने वाली मुख्य समस्या पेसिंग खो गई है।

बाजार या टीसीपी को मारने का समय

हाल ही में, जब मोबाइल वायरलेस नेटवर्क लोकप्रिय हो गए, तो कई अलग-अलग टीसीपी मानक दिखाई दिए: टीएलपी, टीएफओ, नया कंजेशन कंट्रोल, रैक, बीबीआर और बहुत कुछ।

लेकिन मुख्य समस्या यह है कि उनमें से कई को लागू नहीं किया जा रहा है, क्योंकि टीसीपी को ossified कहा जाता है। कई मामलों में, ऑपरेटर टीसीपी पैकेट को देखते हैं और यह देखने की उम्मीद करते हैं कि वे क्या उम्मीद करते हैं। इसलिए, इसे बदलना बहुत मुश्किल है।

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



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



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

टीसीपी बनाम स्व-निर्मित यूडीपी। अंतिम लड़ाई

• भेजें / पुनः बफर करें: आपके प्रोटोकॉल के लिए म्यूटेबल बफर किया जा सकता है, टीसीपी के साथ बफर ब्लोट के साथ समस्याएं होंगी।
• भीड़ नियंत्रण आप मौजूदा का उपयोग कर सकते हैं। यूडीपी में वे किसी भी हैं।
• नए Congestion नियंत्रण को टीसीपी में जोड़ना मुश्किल है, क्योंकि आपको पावती को संशोधित करने की आवश्यकता है, आप क्लाइंट पर ऐसा नहीं कर सकते।
• मल्टीप्लेक्सिंग एक महत्वपूर्ण मुद्दा है। हेड-ऑफ-लाइन ब्लॉकिंग होती है, जब आप एक पैकेट खो देते हैं, तो आप टीसीपी को मल्टीप्लेक्स नहीं कर सकते। इसलिए, टीसीपी पर HTTP2.0 को गंभीर वृद्धि नहीं देनी चाहिए।
• जब आप टीसीपी में 0-आरटीटी के लिए कनेक्शन सेटअप प्राप्त कर सकते हैं, तो 5% के ऑर्डर और स्व-निर्मित यूडीपी के लिए 97% के ऑर्डर बेहद दुर्लभ हैं।

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

यदि आप सभी सबसे महत्वपूर्ण एकत्र करते हैं, तो यूडीपी, अधिक संभावना है, विपक्ष की तुलना में अधिक पेशेवरों के पास है।



UDP चुनें!

उपयोगकर्ताओं पर स्व-निर्मित यूडीपी का परीक्षण करना

हमने एक साथ एक टेस्ट बेंच रखी है।



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



पोर्टल पर औसत को मापने पर, हमने देखा कि हम एपीआई को कॉल करने के समय को 10%, चित्रों को 7% तक कम करने में सक्षम थे। उपयोगकर्ता गतिविधि केवल 1% बढ़ी, लेकिन हमने हार नहीं मानी, हमें लगता है कि यह बेहतर होगा।



भार के संदर्भ में, अब हमारे पास स्व-निर्मित यूडीपी पर लगभग 10 मिलियन उपयोगकर्ता हैं, 80 जीबी / सेकेंड तक ट्रैफ़िक, प्रति सेकंड 6 मिलियन पैकेट और 20 सर्वर यह सब सेवा करते हैं।

यूडीपी चेकलिस्ट

यदि आप अपना प्रोटोकॉल लिखेंगे, तो आपको एक चेकलिस्ट चाहिए:

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

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

QUIC

यह कहना बेईमानी होगी कि Google ने नहीं किया।



एक क्विक प्रोटोकॉल है जिसे Google ने HTTP 2.0 के तहत लागू किया है, जो एक ही चीज का समर्थन करता है।

क्यों क्विक इतनी जल्दी नहीं है

जब क्विक बाहर आया, तो इस तथ्य के बारे में बहुत नफरत थी कि Google कहता है कि सब कुछ तेजी से काम करता है, और "मैंने इसे कंप्यूटर पर घर पर मापा - यह धीमी गति से काम करता है।"



इस लेख में चित्रों और मापों का एक समूह है।

खैर, यह पता चला है कि हमने यह सब व्यर्थ किया, क्या लोगों ने हमारे लिए माप किया? कोड उदाहरणों के साथ वास्तविक घर माप भी हैं।



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

लेकिन वहाँ एक सकारात्मक है, वे कहते हैं, QUIC न तो बेहतर है और न ही बदतर है। इस प्रकार, सही नेटवर्क में, QUIC अच्छा काम करता है।

भविष्य

Google ने हाल ही में HTTP 2.0 का नाम QUIC HTTP 3 के शीर्ष पर रखा है, भ्रमित न हों, क्योंकि HTTP 2.0 टीसीपी के ऊपर और QUIC के शीर्ष पर हो सकता है। अब यह HTTP 3 है।



Google QUIC भी था - यह QUIC है, जिसे क्रोम में लागू किया गया है, और iQUIC - एक मानकीकृत QUIC है। मानकीकृत QUIC को कहीं भी लागू नहीं किया गया था, मानक iQUIC सर्वर Google QUIC के साथ हाथ नहीं मिलाते थे। अब वे इस समस्या को हल करने का वादा करते हैं, और जल्द ही यह उपलब्ध होगा।

QUIC हर जगह है

यदि आप अभी भी विश्वास नहीं करते हैं कि टीसीपी मर चुका है, तो मैं आपको बताता हूं कि जब आप क्रोम, एंड्रॉइड, और जल्द ही आईओएस का उपयोग करते हैं, और Google, youtube और इसी तरह से जाते हैं, तो आप QUIC और UDP ( प्रूफलिंक ) का उपयोग करते हैं।

QUIC अब है:

• सभी वेबसाइटों का 1.9%;
• सभी ट्रैफ़िक का 12%;
• मोबाइल नेटवर्क पर 30% वीडियो ट्रैफ़िक।

यदि आप विश्वास नहीं करते हैं कि कैसे आप QUIC का उपयोग करते हैं? क्रोम तारों में खोलें। मैं iQUIC की तलाश में था, मुझे यह कहीं भी नहीं मिला, लेकिन GQUIC होता है।



आप अपने ब्राउज़र में ऑनलाइन भी जा सकते हैं और यह भी देख सकते हैं कि GQUIC क्या है।

कुछ और भविष्य

मल्टीपाथ जल्द ही हमारा इंतजार कर रहा है।



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



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

IPv6 में UDP के साथ मल्टीकास्ट है, जो कई सब्सक्राइब किए गए उपयोगकर्ताओं को एक साथ पैकेट वितरित करने की अनुमति देगा। इसलिए, मुझे लगता है कि अगर हम आईपीवी 6 के लिए मल्टीकास्ट का उपयोग करके सभी सामग्री वितरित करते हैं तो निकट भविष्य में सीडीएन और पी 2 पी प्रौद्योगिकियों की आवश्यकता नहीं होगी।

निष्कर्ष

मुझे आशा है कि आप समझ गए होंगे:

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

आप सब कुछ पढ़ते हैं और पता लगाते हैं कि आगे क्या होगा?

• स्थिति (नेटवर्क प्रोफ़ाइल + लोड प्रोफ़ाइल) के लिए प्रोटोकॉल (टीसीपी, यूडीपी - यह महत्वपूर्ण नहीं है) कॉन्फ़िगर करें।
• मैंने आपको बताई गई TCP रेसिपी का उपयोग करें: TFO, send / recv बफर, TLS1.3, CC ...
• यदि आपके पास संसाधन हैं तो अपना UDP प्रोटोकॉल बनाएं।
• यदि आपने अपना यूडीपी किया है, तो यूडीपी की जांच सूची की जांच करें जो आपने अपनी जरूरत के अनुसार किया है। पेसिंग जैसे किसी भी बकवास को भूलकर, यह काम नहीं करेगा।

यदि आपके पास संसाधन नहीं हैं, तो QUIC के लिए अपना बुनियादी ढांचा तैयार करें। जल्दी या बाद में वह आपके पास आएगा।

हम भविष्य का निर्धारण कर रहे हैं। हम तय करते हैं कि क्या प्रोटोकॉल का उपयोग करना है। यदि आप QUIC का उपयोग करना चाहते हैं - इसका उपयोग करें, यदि आप अपना UDP चाहते हैं या TCP पर बने रहते हैं - तो भविष्य का निर्णय स्वयं करें।

उपयोगी लिंक

• मिलियन वीडियो कॉल प्रति दिन या "कॉल माँ!" ।
• हम अपना प्रोटोकॉल UDP के शीर्ष पर लिख रहे हैं ।
• नेटवर्क अनुकूलन के बारे में पॉडकास्ट ।
• खराब नेटवर्क में डेटा ट्रांसफर की गति बढ़ाएं ।

7 सितंबर तक, आप अभी भी मॉस्को हाईलाड ++ के लिए एक आवेदन जमा कर सकते हैं और साझा कर सकते हैं कि आप अपनी सेवाओं को उच्च भार के लिए कैसे तैयार करते हैं। लेकिन कार्यक्रम पहले से ही धीरे-धीरे भरा जा रहा है, ओडनोक्लासनिकिकी रिपोर्ट से दोस्तों के ग्राफ के नए आर्किटेक्चर पर उच्च भार के लिए उपहार सेवा को अनुकूलित करने पर और क्या करना है अगर आपने सब कुछ अनुकूलित किया है और डेटा उपयोगकर्ता तक जल्दी से नहीं पहुंचता है।