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

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

तस्वीरें क्लिक करने योग्य हैं। अच्छा पढ़ लो!

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

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

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

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

प्रौद्योगिकी का अंतिम शब्द: टीसीपी

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

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


चित्र 1. "पूंछ" देरी का परिमाण उन मुख्य शहरों में भिन्न होता है जहां उबर संचालित होता है।

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

हवा पर टीसीपी प्रदर्शन

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

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

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


चित्रा 2. 2 किमी के दायरे के उदाहरण के लिए देरी। दिल्ली, भारत।

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


चित्रा 3. पूंछ में देरी अलग-अलग दिनों में काफी भिन्न हो सकती है, लेकिन एक ही ऑपरेटर के साथ।

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

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

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

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

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


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

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

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

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

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

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

QUIC आवेदन

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


चित्र 5: QUIC HTTP / 3 के तहत काम करता है, TLS को प्रतिस्थापित करता है, जो HTTP / 2 के तहत काम करता था।

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

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

QUIC के विकल्प

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

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

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

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

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

मंच में QUIC एकीकरण

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

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

Android उपकरणों के दृष्टिकोण के समान, हमने iOS के लिए Uber अनुप्रयोगों में Cronet को कार्यान्वित किया, NSURLProtocol का उपयोग करके नेटवर्क API से HTTP ट्रैफ़िक को रोकना। IOS फाउंडेशन द्वारा प्रदान की गई यह अमूर्तता, प्रोटोकॉल-विशिष्ट URL डेटा को संसाधित करती है और यह सुनिश्चित करती है कि हम महत्वपूर्ण प्रवासन लागत के बिना Cronet को अपने iOS ऐप में एकीकृत कर सकते हैं।

Google क्लाउड Balancers पर पूरा हुआ

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

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

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

प्रयोग १

प्रयोग के लिए सूची:

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

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

प्रयोग २

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


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

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

• PoP समाप्ति टीसीपी प्रदर्शन में सुधार हुआ। चूंकि बैलेंसर टीसीपी कनेक्शन को उपयोगकर्ताओं के करीब पूरा करते हैं और पूरी तरह से अनुकूलित होते हैं, इससे आरटीटी कम होता है, जो टीसीपी प्रदर्शन को बेहतर बनाता है। QUIC , TCP ( 10-30 ).
• (hops) . QUIC- ( 50 ), , – 15%- 20%- 99 TCP. , – (bottleneck) .

8. , QUIC TCP.

, QUIC Android iOS-. A/B , QUIC Uber. , , .

(95 99 ) – LTE, 3G, 2G.

9. QUIC TCP .

, – QUIC , , :

, , 80% QUIC , 15% QUIC TCP. , - , Cronet TCP , UDP- . , QUIC.

QUIC

, . . , , TCP QUIC . QUIC- .

, .