कार्रवाई में QUIC प्रोटोकॉल: उबर ने प्रदर्शन को अनुकूलित करने के लिए इसे कैसे लागू किया

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

तस्वीरें क्लिक करने योग्य हैं. मन लगाकर पढ़ाई करो!

उबर का वैश्विक स्तर है, अर्थात् 600 शहरों में उपस्थिति, जिनमें से प्रत्येक में एप्लिकेशन पूरी तरह से 4500 से अधिक सेलुलर ऑपरेटरों के वायरलेस इंटरनेट पर निर्भर करता है। उपयोगकर्ताओं को उम्मीद है कि ऐप न केवल तेज़ होगा, बल्कि वास्तविक समय में भी होगा - इसे प्राप्त करने के लिए, उबर ऐप को कम विलंबता और एक बहुत विश्वसनीय कनेक्शन की आवश्यकता है। अफ़सोस, लेकिन ढेर HTTP / 2 गतिशील और हानि-प्रवण वायरलेस नेटवर्क में अच्छा प्रदर्शन नहीं करता है। हमने महसूस किया कि इस मामले में, कम प्रदर्शन सीधे ऑपरेटिंग सिस्टम कर्नेल में टीसीपी कार्यान्वयन से संबंधित है।

समस्या के समाधान के लिए हमने आवेदन किया QUIC, एक आधुनिक चैनल मल्टीप्लेक्सिंग प्रोटोकॉल जो हमें ट्रांसपोर्ट प्रोटोकॉल के प्रदर्शन पर अधिक नियंत्रण देता है। वर्तमान में कार्य समूह IETF QUIC को मानकीकृत करता है HTTP / 3.

व्यापक परीक्षण के बाद, हमने निष्कर्ष निकाला कि हमारे एप्लिकेशन में QUIC को लागू करने से टीसीपी की तुलना में कम विलंबता होगी। हमने ड्राइवर और यात्री अनुप्रयोगों में HTTPS ट्रैफ़िक के लिए 10-30% की कमी देखी। QUIC ने हमें उपयोगकर्ता पैकेजों पर संपूर्ण नियंत्रण भी दिया।

इस लेख में, हम QUIC का समर्थन करने वाले स्टैक का उपयोग करके उबर अनुप्रयोगों के लिए टीसीपी को अनुकूलित करने में अपना अनुभव साझा करते हैं।

नवीनतम तकनीक: टीसीपी

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

अधिकांश उपयोगकर्ता चलते-फिरते हमारे ऐप का उपयोग करते हैं, और टीसीपी टेल विलंबताएं हमारे वास्तविक समय HTTPS ट्रैफ़िक की मांगों के आसपास भी नहीं थीं। सीधे शब्दों में कहें तो दुनिया भर के उपयोगकर्ताओं ने इसका अनुभव किया है - चित्र 1 प्रमुख शहरों में देरी दिखाता है:

चित्र 1: उबर के मुख्य शहरों में टेल विलंबता अलग-अलग है।

हालाँकि भारतीय और ब्राज़ीलियाई नेटवर्क में विलंबता अमेरिका और ब्रिटेन की तुलना में अधिक थी, लेकिन टेल विलंबता औसत विलंबता से काफी अधिक है। और यह बात अमेरिका और ब्रिटेन के लिए भी सच है।

टीसीपी ओवर द एयर प्रदर्शन

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

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

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

चित्र 2. उदाहरण के तौर पर 2 किमी के दायरे का उपयोग करते हुए विलंब। दिल्ली, भारत.

साथ ही, सेल्युलर नेटवर्क का प्रदर्शन समय के साथ बदलता रहता है। चित्र 3 सप्ताह के दिन के अनुसार औसत विलंबता दर्शाता है। हमने एक ही दिन और घंटे के भीतर छोटे पैमाने पर भी अंतर देखा।

चित्र 3. टेल विलंब दिनों के बीच काफी भिन्न हो सकता है, लेकिन एक ही ऑपरेटर के लिए।

उपरोक्त सभी के कारण वायरलेस नेटवर्क में टीसीपी प्रदर्शन अप्रभावी हो जाता है। हालाँकि, टीसीपी के विकल्पों की तलाश करने से पहले, हम निम्नलिखित बिंदुओं पर एक सटीक समझ विकसित करना चाहते थे:

• क्या टीसीपी हमारे अनुप्रयोगों में विलंबता के पीछे मुख्य दोषी है?
• क्या आधुनिक नेटवर्क में महत्वपूर्ण और विविध राउंड-ट्रिप विलंब (आरटीटी) हैं?
• आरटीटी और हानि का टीसीपी प्रदर्शन पर क्या प्रभाव पड़ता है?

टीसीपी प्रदर्शन विश्लेषण

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

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

चित्र 4. टीसीपी/टीएलएस पर पैकेट एक्सचेंज में एक पुन:संचरण तंत्र शामिल है।

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

दोनों प्रयोगों के परिणाम एक दूसरे के अनुरूप थे। हमने उच्च आरटीटी विलंबताएं देखीं; पूँछ का मान औसत मान से लगभग 6 गुना अधिक था; विलंब का अंकगणितीय औसत 1 सेकंड से अधिक है। कई कनेक्शन हानिपूर्ण थे, जिसके कारण टीसीपी को सभी पैकेटों का 3,5% पुनः प्रेषित करना पड़ा। हवाई अड्डों और ट्रेन स्टेशनों जैसे भीड़भाड़ वाले इलाकों में, हमने 7% नुकसान देखा। ये परिणाम सेलुलर नेटवर्क में उपयोग किए जाने वाले पारंपरिक ज्ञान पर संदेह पैदा करते हैं उन्नत रीट्रांसमिशन सर्किट परिवहन स्तर पर घाटे को काफी हद तक कम किया जा सकता है। नीचे "सिम्युलेटर" एप्लिकेशन से परीक्षण परिणाम दिए गए हैं:

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

आरटीटी, मिलीसेकंड [50%,75%, 95%,99%]
[०, २, १, ०]

आरटीटी विचलन, सेकंड
औसतन ~1,2 सेकेंड

अस्थिर कनेक्शन पर पैकेट हानि
औसत ~3.5% (अतिभारित क्षेत्रों में 7%)

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

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

जबकि मापी गई आरटीटी का 75वां प्रतिशतक लगभग 425 एमएस था, टीसीपी के लिए 75वां प्रतिशतक लगभग 3 सेकंड था। यह संकेत देता है कि नुकसान के कारण टीसीपी को सफलतापूर्वक डेटा संचारित करने में 7-10 पास लेने पड़े। यह अकुशल आरटीओ गणना, टीसीपी की हानि पर त्वरित प्रतिक्रिया देने में असमर्थता का परिणाम हो सकता है नवीनतम पैकेज विंडो में और कंजेशन कंट्रोल एल्गोरिदम की अक्षमता, जो वायरलेस नुकसान और नेटवर्क कंजेशन के कारण होने वाले नुकसान के बीच अंतर नहीं करती है। टीसीपी हानि परीक्षण के परिणाम नीचे दिए गए हैं:

टीसीपी पैकेट हानि आँकड़े
मूल्य

कम से कम 1 पैकेट हानि वाले कनेक्शन का प्रतिशत
45% तक

कनेक्शन सेटअप के दौरान नुकसान वाले कनेक्शन का प्रतिशत
30% तक

डेटा एक्सचेंज के दौरान नुकसान वाले कनेक्शन का प्रतिशत
76% तक

पुन:संचरण में देरी का वितरण, सेकंड [50%, 75%, 95%,99%] [1, 2.8, 15, 28]

एक पैकेट या टीसीपी खंड के लिए पुनः प्रसारण की संख्या का वितरण
[1,3,6,7]

QUIC का अनुप्रयोग

मूल रूप से Google द्वारा विकसित, QUIC एक बहु-थ्रेडेड आधुनिक परिवहन प्रोटोकॉल है जो UDP के शीर्ष पर चलता है। वर्तमान में QUIC चालू है मानकीकरण प्रक्रिया (हमने पहले ही लिखा है कि QUIC के दो संस्करण हैं, जिज्ञासु लिंक का अनुसरण कर सकते हैं - लगभग। अनुवादक)। जैसा कि चित्र 5 में दिखाया गया है, QUIC को HTTP/3 के अंतर्गत रखा गया है (वास्तव में, QUIC के शीर्ष पर HTTP/2 HTTP/3 है, जिसे अब गहन रूप से मानकीकृत किया जा रहा है)। यह पैकेट बनाने के लिए यूडीपी का उपयोग करके एचटीटीपीएस और टीसीपी परतों को आंशिक रूप से बदल देता है। QUIC केवल सुरक्षित डेटा ट्रांसफर का समर्थन करता है क्योंकि TLS पूरी तरह से QUIC में निर्मित है।

चित्र 5: QUIC HTTP/3 के अंतर्गत चलता है, TLS की जगह लेता है, जो पहले HTTP/2 के अंतर्गत चलता था।

नीचे वे कारण दिए गए हैं जिन्होंने हमें टीसीपी प्रवर्धन के लिए QUIC का उपयोग करने के लिए राजी किया:

• 0-आरटीटी कनेक्शन स्थापना। QUIC पिछले कनेक्शनों से प्राधिकरणों के पुन: उपयोग की अनुमति देता है, जिससे सुरक्षा हैंडशेक की संख्या कम हो जाती है। भविष्य में TLS1.3 0-आरटीटी का समर्थन करेगा, लेकिन तीन-तरफा टीसीपी हैंडशेक की अभी भी आवश्यकता होगी।
• HoL अवरोधन पर काबू पाना। प्रदर्शन को बेहतर बनाने के लिए HTTP/2 प्रति क्लाइंट एक टीसीपी कनेक्शन का उपयोग करता है, लेकिन इससे HoL (हेड-ऑफ़-लाइन) ब्लॉक हो सकता है। QUIC मल्टीप्लेक्सिंग को सरल बनाता है और एप्लिकेशन को स्वतंत्र रूप से अनुरोध वितरित करता है।
• भीड़ नियंत्रण। QUIC एप्लिकेशन परत पर रहता है, जिससे मुख्य परिवहन एल्गोरिदम को अपडेट करना आसान हो जाता है जो नेटवर्क पैरामीटर (नुकसान की संख्या या आरटीटी) के आधार पर भेजने को नियंत्रित करता है। अधिकांश टीसीपी कार्यान्वयन एल्गोरिदम का उपयोग करते हैं घन, जो विलंबता-संवेदनशील ट्रैफ़िक के लिए इष्टतम नहीं है। हाल ही में विकसित एल्गोरिदम जैसे BBR, नेटवर्क को अधिक सटीक रूप से मॉडल करें और विलंबता को अनुकूलित करें। QUIC आपको BBR का उपयोग करने और इस एल्गोरिथम को उपयोग के अनुसार अपडेट करने की अनुमति देता है। में सुधार.
• घाटे की भरपाई. QUIC दो टीएलपी कॉल करता है (पूंछ हानि जांच) आरटीओ चालू होने से पहले - तब भी जब नुकसान बहुत ध्यान देने योग्य हो। यह टीसीपी कार्यान्वयन से अलग है। टीएलपी तेजी से पुनःपूर्ति को ट्रिगर करने के लिए मुख्य रूप से अंतिम पैकेट (या नया, यदि कोई हो) को पुनः प्रेषित करता है। उबेर जिस तरह से अपने नेटवर्क को संचालित करता है, उसके लिए पूंछ विलंब को संभालना विशेष रूप से उपयोगी है, अर्थात् लघु, छिटपुट और विलंबता-संवेदनशील डेटा स्थानांतरण के लिए।
• अनुकूलित ACK. चूँकि प्रत्येक पैकेट में एक अद्वितीय अनुक्रम संख्या होती है, इसलिए कोई समस्या नहीं है भेद पैकेट जब पुनः प्रेषित होते हैं। ACK पैकेट में पैकेट को संसाधित करने और क्लाइंट साइड पर ACK उत्पन्न करने का समय भी होता है। ये सुविधाएँ सुनिश्चित करती हैं कि QUIC RTT की अधिक सटीक गणना करता है। QUIC में ACK 256 बैंड तक सपोर्ट करता है नैक, जिससे प्रेषक को पैकेट फेरबदल के प्रति अधिक लचीला होने और प्रक्रिया में कम बाइट्स का उपयोग करने में मदद मिलती है। चयनात्मक एसीके (थैला) टीसीपी में सभी मामलों में इस समस्या का समाधान नहीं होता है।
• कनेक्शन माइग्रेशन. QUIC कनेक्शन की पहचान 64-बिट आईडी द्वारा की जाती है, इसलिए यदि कोई क्लाइंट आईपी पते बदलता है, तो पुराने कनेक्शन आईडी का उपयोग बिना किसी रुकावट के नए आईपी पते पर किया जा सकता है। यह मोबाइल एप्लिकेशन के लिए एक बहुत ही सामान्य अभ्यास है जहां उपयोगकर्ता वाई-फाई और सेलुलर कनेक्शन के बीच स्विच करता है।

QUIC के विकल्प

हमने QUIC को चुनने से पहले समस्या को हल करने के लिए वैकल्पिक तरीकों पर विचार किया।

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

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

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

हमारे शोध से पता चला है कि QUIC शायद एकमात्र प्रोटोकॉल है जो सुरक्षा और प्रदर्शन दोनों को ध्यान में रखते हुए इंटरनेट ट्रैफ़िक की समस्या से निपटने में मदद कर सकता है।

प्लेटफ़ॉर्म में QUIC का एकीकरण

QUIC को सफलतापूर्वक एम्बेड करने और खराब कनेक्टिविटी वातावरण में एप्लिकेशन प्रदर्शन को बेहतर बनाने के लिए, हमने पुराने स्टैक (HTTP/2 ओवर TLS/TCP) को QUIC प्रोटोकॉल से बदल दिया। हमने नेटवर्क लाइब्रेरी का उपयोग किया क्रोनेट से क्रोमियम परियोजनाएँ, जिसमें प्रोटोकॉल का मूल, Google संस्करण शामिल है - gQUIC। नवीनतम IETF विनिर्देश का पालन करने के लिए इस कार्यान्वयन में भी लगातार सुधार किया जा रहा है।

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

एंड्रॉइड डिवाइसों के लिए दृष्टिकोण के समान, हमने नेटवर्क से HTTP ट्रैफ़िक को रोकते हुए, iOS पर Uber ऐप्स में क्रोनेट लागू किया APIका उपयोग करते हुए NSURLप्रोटोकॉल. आईओएस फाउंडेशन द्वारा प्रदान किया गया यह अमूर्त प्रोटोकॉल-विशिष्ट यूआरएल डेटा को संभालता है और यह सुनिश्चित करता है कि हम महत्वपूर्ण माइग्रेशन लागत के बिना क्रोनेट को अपने आईओएस अनुप्रयोगों में एकीकृत कर सकते हैं।

Google क्लाउड बैलेंसर्स पर QUIC पूरा करना

बैकएंड की ओर, QUIC पूर्णता Google क्लाउड लोड बैलेंसिंग इंफ्रास्ट्रक्चर द्वारा प्रदान की जाती है, जिसका उपयोग किया जाता है alt-svc QUIC का समर्थन करने के लिए प्रत्युत्तरों में हेडर। सामान्य तौर पर, बैलेंसर प्रत्येक HTTP अनुरोध में एक alt-svc हेडर जोड़ता है, और यह पहले से ही डोमेन के लिए QUIC समर्थन को मान्य करता है। जब एक क्रोनेट क्लाइंट को इस हेडर के साथ HTTP प्रतिक्रिया प्राप्त होती है, तो वह उस डोमेन के बाद के HTTP अनुरोधों के लिए QUIC का उपयोग करता है। एक बार जब बैलेंसर QUIC पूरा कर लेता है, तो हमारा बुनियादी ढांचा स्पष्ट रूप से इस कार्रवाई को HTTP2/TCP पर हमारे डेटा केंद्रों पर भेजता है।

प्रदर्शन: परिणाम

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

प्रयोग 1

प्रयोग के लिए उपकरण:

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

चित्र 6. टीसीपी बनाम क्विक रोड टेस्ट सूट में ओकेएचटीपी और क्रोनेट के साथ एंड्रॉइड डिवाइस, कनेक्शन समाप्त करने के लिए क्लाउड प्रॉक्सी और एक इम्यूलेशन सर्वर शामिल था।

प्रयोग 2

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

चित्र 7. दूसरे प्रयोग में, हम टीसीपी और क्विक की पूर्णता विलंबता की तुलना करना चाहते थे: Google क्लाउड का उपयोग करना और हमारे क्लाउड प्रॉक्सी का उपयोग करना।

परिणामस्वरूप, कई खुलासे हमारा इंतजार कर रहे थे:

• पीओपी के माध्यम से समाप्ति से टीसीपी प्रदर्शन में सुधार हुआ। चूंकि बैलेंसर्स टीसीपी कनेक्शन को उपयोगकर्ताओं के करीब समाप्त करते हैं और अत्यधिक अनुकूलित होते हैं, इसके परिणामस्वरूप कम आरटीटी होते हैं, जिससे टीसीपी प्रदर्शन में सुधार होता है। और यद्यपि QUIC पर कम प्रभाव पड़ा, फिर भी इसने टेल लेटेंसी (10-30 प्रतिशत) को कम करने के मामले में टीसीपी से बेहतर प्रदर्शन किया।
• पूँछें प्रभावित होती हैं नेटवर्क हॉप्स. हालाँकि हमारा QUIC प्रॉक्सी Google के लोड बैलेंसर्स की तुलना में डिवाइस (लगभग 50 एमएस अधिक विलंबता) से अधिक था, इसने समान प्रदर्शन दिया - टीसीपी के लिए 15 वें प्रतिशत में 20% की कमी के मुकाबले विलंबता में 99% की कमी। इससे पता चलता है कि अंतिम मील संक्रमण नेटवर्क में एक बाधा है।

चित्र 8: दो प्रयोगों के नतीजे बताते हैं कि QUIC टीसीपी से बेहतर प्रदर्शन करता है।

यातायात का मुकाबला करें

प्रयोग से प्रेरित होकर, हमने अपने Android और iOS अनुप्रयोगों में QUIC समर्थन लागू किया है। हमने उन शहरों में QUIC के प्रभाव को निर्धारित करने के लिए A/B परीक्षण किया जहां Uber संचालित होता है। सामान्य तौर पर, हमने दोनों क्षेत्रों, दूरसंचार ऑपरेटरों और नेटवर्क प्रकार में टेल देरी में उल्लेखनीय कमी देखी।

नीचे दिए गए ग्राफ़ मैक्रो-क्षेत्र और विभिन्न नेटवर्क प्रकारों - एलटीई, 95जी, 99जी द्वारा टेल्स (3 और 2 प्रतिशत) में प्रतिशत सुधार दिखाते हैं।

चित्र 9. युद्ध परीक्षणों में, विलंबता के मामले में QUIC ने TCP से बेहतर प्रदर्शन किया।

केवल आगे

शायद यह सिर्फ शुरुआत है - उत्पादन में QUIC की रिहाई ने स्थिर और अस्थिर दोनों नेटवर्क में एप्लिकेशन प्रदर्शन को बेहतर बनाने के अद्भुत अवसर प्रदान किए हैं, अर्थात्:

बढ़ा हुआ कवरेज

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

त्वरित अनुकूलन

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

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

स्रोत: www.habr.com