कृतीमध्ये QUIC प्रोटोकॉल: कार्यप्रदर्शन ऑप्टिमाइझ करण्यासाठी Uberने ते कसे लागू केले

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

चित्रे क्लिक करण्यायोग्य आहेत. वाचनाचा आनंद घ्या!

Uber चे जागतिक स्तरावर, म्हणजे उपस्थिती असलेली 600 शहरे आहेत, ज्यापैकी प्रत्येक अनुप्रयोग 4500 पेक्षा जास्त सेल्युलर ऑपरेटर्सच्या वायरलेस इंटरनेटवर पूर्णपणे अवलंबून आहे. वापरकर्ते अॅप फक्त वेगवान नसून रिअल टाइममध्ये असण्याची अपेक्षा करतात - हे साध्य करण्यासाठी, Uber अॅपला कमी विलंब आणि अतिशय विश्वासार्ह कनेक्शन आवश्यक आहे. अरेरे, पण स्टॅक HTTP / 2 डायनॅमिक आणि तोटा-प्रवण वायरलेस नेटवर्कमध्ये चांगले काम करत नाही. आमच्या लक्षात आले की या प्रकरणात, कमी कार्यक्षमता ऑपरेटिंग सिस्टम कर्नलमधील TCP अंमलबजावणीशी थेट संबंधित आहे.

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

विस्तृत चाचणीनंतर, आम्ही निष्कर्ष काढला की आमच्या अनुप्रयोगामध्ये QUIC लागू केल्याने TCP च्या तुलनेत कमी टेल लेटन्सी होतील. आम्ही ड्रायव्हर आणि पॅसेंजर ऍप्लिकेशन्समध्ये HTTPS रहदारीसाठी 10-30% च्या श्रेणीत घट पाहिली. QUIC ने आम्हाला वापरकर्ता पॅकेजेसवर एंड-टू-एंड नियंत्रण देखील दिले.

या लेखात, आम्ही QUIC ला समर्थन देणारा स्टॅक वापरून Uber ऍप्लिकेशनसाठी TCP ऑप्टिमाइझ करण्याचा आमचा अनुभव शेअर करतो.

नवीनतम तंत्रज्ञान: TCP

आज, इंटरनेटवर HTTPS रहदारी वितरीत करण्यासाठी TCP हा सर्वाधिक वापरला जाणारा ट्रान्सपोर्ट प्रोटोकॉल आहे. TCP बाइट्सचा एक विश्वासार्ह प्रवाह प्रदान करते, ज्यामुळे नेटवर्क कंजेशन आणि लिंक लेयर तोटा यांचा सामना केला जातो. HTTPS ट्रॅफिकसाठी TCP चा व्यापक वापर पूर्वीच्या सर्वव्यापीतेमुळे होतो (जवळजवळ प्रत्येक OS मध्ये TCP असते), बहुतेक पायाभूत सुविधांवरील उपलब्धता (जसे की लोड बॅलन्सर्स, HTTPS प्रॉक्सी आणि CDN) आणि उपलब्ध असलेल्या आउट-ऑफ-द-बॉक्स कार्यक्षमतेमुळे. बहुतेक प्लॅटफॉर्म आणि नेटवर्कवर.

बहुतेक वापरकर्ते जाता जाता आमचे अॅप वापरतात आणि आमच्या रिअल-टाइम HTTPS ट्रॅफिकच्या मागणीच्या जवळपासही TCP टेल लेटन्सीज नव्हते. सोप्या भाषेत सांगायचे तर, जगभरातील वापरकर्त्यांनी याचा अनुभव घेतला आहे - आकृती 1 प्रमुख शहरांमध्ये विलंब दर्शविते:

आकृती 1: Uber च्या मुख्य शहरांमध्ये टेल लेटन्सी बदलते.

भारतीय आणि ब्राझिलियन नेटवर्कमधील विलंबता यूएस आणि यूकेच्या तुलनेत जास्त असली तरी, टेल लेटन्सी सरासरी लेटन्सीपेक्षा लक्षणीयरीत्या जास्त आहे. आणि हे अगदी यूएस आणि यूकेसाठी खरे आहे.

हवाई कामगिरीवर TCP

TCP साठी तयार केले होते वायर्ड नेटवर्क्स, म्हणजे, उच्च अंदाज लावता येण्याजोग्या लिंक्सवर जोर देऊन. तथापि, वायरलेस नेटवर्कची स्वतःची वैशिष्ट्ये आणि अडचणी आहेत. प्रथम, वायरलेस नेटवर्क हस्तक्षेप आणि सिग्नल क्षीणतेमुळे नुकसानास संवेदनाक्षम असतात. उदाहरणार्थ, वाय-फाय नेटवर्क मायक्रोवेव्ह, ब्लूटूथ आणि इतर रेडिओ लहरींसाठी संवेदनशील असतात. सेल्युलर नेटवर्क सिग्नल गमावण्याने ग्रस्त आहेत (हरवलेला मार्ग) वस्तू आणि इमारतींद्वारे सिग्नलचे प्रतिबिंब/शोषण केल्यामुळे, तसेच पासून हस्तक्षेप शेजारी पासून सेल टॉवर्स. हे अधिक लक्षणीय (4-10 वेळा) आणि अधिक वैविध्यपूर्ण ठरते राउंड ट्रिप वेळ (RTT) आणि वायर्ड कनेक्शनच्या तुलनेत पॅकेटचे नुकसान.

बँडविड्थ चढउतार आणि तोटा सोडवण्यासाठी, सेल्युलर नेटवर्क्स सामान्यत: ट्रॅफिक स्फोटांसाठी मोठ्या बफरचा वापर करतात. यामुळे जास्त रांग लागू शकते, याचा अर्थ जास्त विलंब होऊ शकतो. बरेचदा टीसीपी या रांगेला विस्तारित कालबाह्यतेमुळे कचरा मानते, त्यामुळे टीसीपी रिले करतो आणि त्याद्वारे बफर भरतो. ही समस्या म्हणून ओळखली जाते बफरब्लोट (अत्यधिक नेटवर्क बफरिंग, बफर ब्लोट), आणि हे खूप आहे गंभीर समस्या आधुनिक इंटरनेट.

शेवटी, सेल्युलर नेटवर्क कार्यप्रदर्शन कॅरियर, प्रदेश आणि वेळेनुसार बदलते. आकृती 2 मध्ये, आम्ही 2-किलोमीटर रेंजमधील सेलमधील HTTPS ट्रॅफिकचा मध्य विलंब गोळा केला. दिल्ली, भारतातील दोन प्रमुख सेल्युलर ऑपरेटरसाठी डेटा गोळा केला. जसे आपण पाहू शकता, कार्यप्रदर्शन सेल ते सेल बदलते. तसेच, एका ऑपरेटरची उत्पादकता दुसऱ्याच्या उत्पादकतेपेक्षा वेगळी असते. हे खाते वेळ आणि स्थान, वापरकर्त्याची गतिशीलता, तसेच टॉवर घनता आणि नेटवर्क प्रकारांचे प्रमाण (LTE, 3G, इ.) लक्षात घेऊन नेटवर्क इन्फ्रास्ट्रक्चर यासारख्या घटकांद्वारे प्रभावित होते.

आकृती 2. उदाहरण म्हणून 2 किमी त्रिज्या वापरून विलंब. दिल्ली, भारत.

तसेच, सेल्युलर नेटवर्कचे कार्यप्रदर्शन कालांतराने बदलते. आकृती 3 आठवड्याच्या दिवसानुसार मध्य विलंब दर्शवते. आम्ही एका दिवसात आणि तासाच्या आत, लहान प्रमाणात फरक देखील पाहिले.

आकृती 3. टेल विलंब दिवसांमध्ये लक्षणीयरीत्या बदलू शकतात, परंतु त्याच ऑपरेटरसाठी.

वरील सर्व गोष्टींमुळे वायरलेस नेटवर्क्समध्ये TCP कार्यप्रदर्शन कुचकामी ठरते. तथापि, TCP साठी पर्याय शोधण्यापूर्वी, आम्हाला खालील मुद्द्यांवर अचूक समज विकसित करायची होती:

• आमच्या ऍप्लिकेशन्समधील टेल लेटेन्सीमागे TCP मुख्य दोषी आहे का?
• आधुनिक नेटवर्कमध्ये लक्षणीय आणि विविध राउंड-ट्रिप विलंब (RTT) आहेत का?
• RTT चा काय परिणाम होतो आणि TCP कार्यक्षमतेवर तोटा होतो?

TCP कामगिरी विश्लेषण

आम्ही TCP कार्यप्रदर्शनाचे विश्लेषण कसे केले हे समजून घेण्यासाठी, TCP पाठवणार्‍याकडून प्राप्तकर्त्याकडे डेटा कसा हस्तांतरित करतो ते पाहूया. प्रथम, प्रेषक एक TCP कनेक्शन स्थापित करतो, तीन-मार्गी कामगिरी करतो हस्तांदोलन: प्रेषक एक SYN पॅकेट पाठवतो, प्राप्तकर्त्याकडून SYN-ACK पॅकेटची वाट पाहतो, त्यानंतर ACK पॅकेट पाठवतो. TCP कनेक्शन स्थापित करण्यासाठी अतिरिक्त दुसरा आणि तिसरा पास खर्च केला जातो. विश्वसनीय वितरण सुनिश्चित करण्यासाठी प्राप्तकर्ता प्रत्येक पॅकेटची पावती (ACK) स्वीकारतो.

पॅकेट किंवा ACK हरवल्यास, प्रेषक कालबाह्य झाल्यानंतर पुन्हा पाठवतो (RTO, रीट्रांसमिशन कालबाह्य). RTO ची गणना विविध घटकांवर आधारित आहे, जसे की प्रेषक आणि प्राप्तकर्ता यांच्यातील अपेक्षित RTT विलंब.

आकृती 4. TCP/TLS वरील पॅकेट एक्सचेंजमध्ये रीट्रांसमिशन यंत्रणा समाविष्ट आहे.

आमच्या ऍप्लिकेशन्समध्ये TCP कसे कार्य करते हे निर्धारित करण्यासाठी, आम्ही वापरून TCP पॅकेटचे परीक्षण केले tcpdump भारतीय एज सर्व्हरवरून येणार्‍या लढाऊ रहदारीवर एका आठवड्यासाठी. त्यानंतर आम्ही वापरून TCP कनेक्शनचे विश्लेषण केले tcptrace. याव्यतिरिक्त, आम्ही एक Android अनुप्रयोग तयार केला जो शक्य तितक्या वास्तविक रहदारीचे अनुकरण करून चाचणी सर्व्हरवर अनुकरणित रहदारी पाठवतो. या अॅप्लिकेशनसह स्मार्टफोन अनेक कर्मचाऱ्यांना वितरीत करण्यात आले, ज्यांनी अनेक दिवस नोंदी गोळा केल्या.

दोन्ही प्रयोगांचे परिणाम एकमेकांशी सुसंगत होते. आम्ही उच्च आरटीटी विलंब पाहिले; शेपटीची मूल्ये सरासरी मूल्यापेक्षा जवळजवळ 6 पट जास्त होती; विलंबाची अंकगणितीय सरासरी 1 सेकंदापेक्षा जास्त आहे. अनेक जोडण्या तोट्यात होत्या, ज्यामुळे TCP ने सर्व पॅकेटपैकी 3,5% पुन्हा प्रसारित केले. विमानतळ आणि रेल्वे स्थानकांसारख्या गजबजलेल्या भागात, आम्ही ७% नुकसान पाहिले. हे परिणाम सेल्युलर नेटवर्कमध्ये वापरल्या जाणार्‍या पारंपारिक शहाणपणावर शंका निर्माण करतात प्रगत रीट्रांसमिशन सर्किट्स वाहतूक स्तरावरील तोटा लक्षणीयरीत्या कमी करा. खाली “सिम्युलेटर” ऍप्लिकेशनचे चाचणी परिणाम आहेत:

नेटवर्क मेट्रिक्स
मूल्ये

RTT, मिलिसेकंद [५०%,७५%, ९५%,९९%]
[,, २, १,]]

RTT विचलन, सेकंद
सरासरी ~1,2 से

अस्थिर कनेक्शनवर पॅकेट नुकसान
सरासरी ~3.5% (ओव्हरलोड केलेल्या भागात 7%)

यापैकी जवळपास अर्ध्या कनेक्शनमध्ये किमान एक पॅकेट तोटा होता, त्यापैकी बहुतेक SYN आणि SYN-ACK पॅकेट होते. बहुतेक TCP अंमलबजावणी SYN पॅकेटसाठी 1 सेकंदाचे RTO मूल्य वापरते, जे नंतरच्या नुकसानासाठी वेगाने वाढते. कनेक्शन स्थापित करण्यासाठी TCP ला जास्त वेळ लागल्याने अनुप्रयोग लोड होण्याच्या वेळा वाढू शकतात.

डेटा पॅकेट्सच्या बाबतीत, उच्च आरटीओ मूल्ये वायरलेस नेटवर्क्समध्ये क्षणिक नुकसानीच्या उपस्थितीत नेटवर्कचा उपयुक्त वापर मोठ्या प्रमाणात कमी करतात. आम्हाला आढळले की सरासरी रीट्रांसमिशन वेळ अंदाजे 1 सेकंदांच्या शेपटीच्या विलंबासह अंदाजे 30 सेकंद आहे. TCP स्तरावरील या उच्च विलंबांमुळे HTTPS कालबाह्यता आणि पुन्हा विनंत्या झाल्या, पुढे नेटवर्क विलंबता आणि अकार्यक्षमता वाढली.

मोजलेले RTT चे 75 वे पर्सेंटाइल सुमारे 425 ms होते, तर TCP साठी 75 वे पर्सेंटाइल जवळपास 3 सेकंद होते. हे सूचित करते की नुकसानीमुळे TCP मुळे डेटा यशस्वीरित्या प्रसारित करण्यासाठी 7-10 पास घ्यावे लागले. हे अकार्यक्षम आरटीओ गणना, नुकसानास त्वरित प्रतिसाद देण्यास TCP च्या अक्षमतेचा परिणाम असू शकतो नवीनतम पॅकेजेस विंडोमध्ये आणि कंजेशन कंट्रोल अल्गोरिदमची अकार्यक्षमता, जे वायरलेस नुकसान आणि नेटवर्कच्या गर्दीमुळे होणारे नुकसान यांच्यात फरक करत नाही. खाली TCP नुकसान चाचण्यांचे परिणाम आहेत:

TCP पॅकेट नुकसान आकडेवारी
मूल्य

किमान 1 पॅकेट गमावलेल्या कनेक्शनची टक्केवारी
45%

कनेक्शन सेटअप दरम्यान नुकसान झालेल्या कनेक्शनची टक्केवारी
30%

डेटा एक्सचेंज दरम्यान नुकसानासह कनेक्शनची टक्केवारी
76%

रीट्रांसमिशनमध्ये विलंबाचे वितरण, सेकंद [50%, 75%, 95%,99%] [1, 2.8, 15, 28]

एका पॅकेट किंवा TCP विभागासाठी रीट्रांसमिशनच्या संख्येचे वितरण
[1,3,6,7]

QUIC चा अर्ज

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

आकृती 5: QUIC HTTP/3 अंतर्गत चालते, TLS च्या जागी, जे पूर्वी HTTP/2 अंतर्गत चालत होते.

खाली कारणे आहेत जी आम्हाला TCP प्रवर्धनासाठी QUIC वापरण्यास पटवून देतात:

• 0-RTT कनेक्शन स्थापना. सुरक्षा हँडशेकची संख्या कमी करून, QUIC मागील कनेक्शनमधील अधिकृतता पुन्हा वापरण्याची परवानगी देते. भविष्यात TLS1.3 0-RTT चे समर्थन करेल, परंतु तरीही तीन-मार्गी TCP हँडशेक आवश्यक असेल.
• HoL ब्लॉकिंगवर मात करणे. HTTP/2 कार्यप्रदर्शन सुधारण्यासाठी प्रति क्लायंट एक TCP कनेक्शन वापरते, परंतु यामुळे HoL (हेड-ऑफ-लाइन) ब्लॉकिंग होऊ शकते. QUIC मल्टिप्लेक्सिंग सुलभ करते आणि अनुप्रयोगास स्वतंत्रपणे विनंत्या वितरीत करते.
• गर्दी नियंत्रण. QUIC अनुप्रयोग स्तरावर राहतो, ज्यामुळे नेटवर्क पॅरामीटर्स (नुकसानांची संख्या किंवा RTT) वर आधारित पाठवणे नियंत्रित करणारे मुख्य वाहतूक अल्गोरिदम अपडेट करणे सोपे होते. बहुतेक TCP अंमलबजावणी अल्गोरिदम वापरतात क्यूबिक, जे विलंब-संवेदनशील रहदारीसाठी इष्टतम नाही. अलीकडे विकसित अल्गोरिदम जसे बीबीआर, अधिक अचूकपणे नेटवर्क मॉडेल करा आणि लेटन्सी ऑप्टिमाइझ करा. QUIC तुम्हाला BBR वापरण्याची आणि हे अल्गोरिदम वापरल्याप्रमाणे अपडेट करण्याची परवानगी देते. सुधारणा.
• नुकसानाची भरपाई. QUIC दोन TLP ला कॉल करते (शेपूट नुकसान चौकशी) आरटीओ सुरू होण्याआधी - नुकसान अगदी लक्षात येण्यासारखे असतानाही. हे TCP अंमलबजावणीपेक्षा वेगळे आहे. जलद भरपाई ट्रिगर करण्यासाठी TLP मुख्यतः शेवटचे पॅकेट (किंवा नवीन असल्यास) पुन्हा पाठवते. टेल विलंब हाताळणे विशेषतः Uber चे नेटवर्क ज्या प्रकारे चालवते त्यासाठी उपयुक्त आहे, म्हणजे लहान, तुरळक आणि विलंब-संवेदनशील डेटा ट्रान्सफरसाठी.
• अनुकूलित ACK. प्रत्येक पॅकेटला एक अद्वितीय अनुक्रम क्रमांक असल्याने कोणतीही अडचण नाही भेद पॅकेट जेव्हा ते पुन्हा प्रसारित केले जातात. ACK पॅकेटमध्ये पॅकेटवर प्रक्रिया करण्यासाठी आणि क्लायंटच्या बाजूने ACK तयार करण्यासाठी वेळ देखील असतो. ही वैशिष्ट्ये QUIC अधिक अचूकपणे RTT गणना करते याची खात्री करतात. QUIC मध्‍ये ACK 256 बँडपर्यंत सपोर्ट करते NACK, प्रेषकाला पॅकेट शफल करण्यासाठी अधिक लवचिक होण्यास मदत करणे आणि प्रक्रियेत कमी बाइट्स वापरणे. निवडक ACK (सॅक) TCP मध्ये सर्व प्रकरणांमध्ये ही समस्या सोडवत नाही.
• कनेक्शन स्थलांतर. QUIC कनेक्शन्स 64-बिट ID द्वारे ओळखले जातात, म्हणून जर एखाद्या क्लायंटने IP पत्ते बदलले, तर जुना कनेक्शन ID नवीन IP पत्त्यावर व्यत्ययाशिवाय वापरला जाऊ शकतो. मोबाईल ऍप्लिकेशन्ससाठी ही एक सामान्य पद्धत आहे जिथे वापरकर्ता Wi-Fi आणि सेल्युलर कनेक्शन दरम्यान स्विच करतो.

QUIC साठी पर्याय

आम्ही QUIC निवडण्यापूर्वी समस्येचे निराकरण करण्यासाठी पर्यायी पध्दतींचा विचार केला.

वापरकर्त्यांच्या जवळचे TCP कनेक्शन बंद करण्यासाठी TPC PoPs (पॉइंट्स ऑफ प्रेझेन्स) तैनात करण्याचा आम्ही प्रयत्न केला. मूलत:, PoPs सेल्युलर नेटवर्कच्या जवळ असलेल्या मोबाइल डिव्हाइससह TCP कनेक्शन समाप्त करतात आणि ट्रॅफिकला मूळ पायाभूत सुविधांकडे प्रॉक्सी करतात. TCP जवळ बंद करून, आम्ही संभाव्यपणे RTT कमी करू शकतो आणि TCP डायनॅमिक वायरलेस वातावरणास अधिक प्रतिसाद देणारी आहे याची खात्री करू शकतो. तथापि, आमच्या प्रयोगांनी दर्शविले आहे की बहुतेक RTT आणि तोटा सेल्युलर नेटवर्कमधून होतो आणि PoPs चा वापर लक्षणीय कार्यप्रदर्शन सुधारणा प्रदान करत नाही.

आम्ही TCP पॅरामीटर्स ट्यूनिंग देखील पाहिले. आमच्या विषम एज सर्व्हरवर TCP स्टॅक सेट करणे कठीण होते कारण TCP ची विविध OS आवृत्त्यांमध्ये भिन्न अंमलबजावणी आहे. याची अंमलबजावणी करणे आणि वेगवेगळ्या नेटवर्क कॉन्फिगरेशनची चाचणी घेणे कठीण होते. परवानग्या नसल्यामुळे थेट मोबाइल डिव्हाइसवर TCP कॉन्फिगर करणे शक्य झाले नाही. अधिक महत्त्वाचे म्हणजे, 0-RTT कनेक्शन आणि सुधारित RTT अंदाज यासारखी वैशिष्ट्ये प्रोटोकॉलच्या आर्किटेक्चरसाठी महत्त्वपूर्ण आहेत, आणि म्हणूनच केवळ TCP ट्यून करून महत्त्वपूर्ण फायदे प्राप्त करणे अशक्य आहे.

शेवटी, आम्ही अनेक UDP-आधारित प्रोटोकॉलचे मूल्यांकन केले जे व्हिडिओ स्ट्रीमिंगचे समस्यानिवारण करतात—आम्हाला हे प्रोटोकॉल आमच्या बाबतीत मदत करतील की नाही हे पाहायचे होते. दुर्दैवाने, त्यांच्याकडे बर्‍याच सुरक्षितता सेटिंग्जचा अभाव होता आणि मेटाडेटा आणि नियंत्रण माहितीसाठी अतिरिक्त TCP कनेक्शन देखील आवश्यक होते.

आमच्या संशोधनात असे दिसून आले आहे की QUIC हा कदाचित एकमेव प्रोटोकॉल आहे जो सुरक्षितता आणि कार्यप्रदर्शन या दोन्ही गोष्टी लक्षात घेऊन इंटरनेट रहदारीच्या समस्येस मदत करू शकतो.

प्लॅटफॉर्ममध्ये QUIC चे एकत्रीकरण

QUIC यशस्वीरित्या एम्बेड करण्यासाठी आणि खराब कनेक्टिव्हिटी वातावरणात अनुप्रयोग कार्यप्रदर्शन सुधारण्यासाठी, आम्ही जुना स्टॅक (HTTP/2 ओव्हर TLS/TCP) QUIC प्रोटोकॉलने बदलला. आम्ही नेटवर्क लायब्ररी वापरली क्रोनेट पासून Chromium प्रकल्प, ज्यामध्ये प्रोटोकॉलची मूळ, Google आवृत्ती आहे - gQUIC. नवीनतम IETF तपशीलांचे पालन करण्यासाठी ही अंमलबजावणी देखील सतत सुधारली जात आहे.

QUIC साठी समर्थन जोडण्यासाठी आम्ही प्रथम आमच्या Android अॅप्समध्ये Cronet समाकलित केले. स्थलांतर खर्च शक्य तितक्या कमी करण्यासाठी एकत्रीकरण केले गेले. लायब्ररी वापरलेल्या जुन्या नेटवर्किंग स्टॅकला पूर्णपणे बदलण्याऐवजी OkHttp, आम्ही OkHttp API फ्रेमवर्क अंतर्गत Cronet समाकलित केले आहे. अशा प्रकारे एकत्रीकरण करून, आम्ही आमच्या नेटवर्क कॉलमधील बदल टाळले (जे वापरतात रिट्रोफिट) API स्तरावर.

अँड्रॉइड उपकरणांसाठीच्या दृष्टिकोनाप्रमाणेच, आम्ही iOS वरील Uber अॅप्समध्ये Cronet लागू केले, नेटवर्कवरून HTTP ट्रॅफिक रोखून APIवापरत आहे NSURLप्रोटोकॉल. iOS फाउंडेशनद्वारे प्रदान केलेले हे अ‍ॅब्स्ट्रॅक्शन, प्रोटोकॉल-विशिष्ट URL डेटा हाताळते आणि हे सुनिश्चित करते की आम्ही महत्त्वपूर्ण स्थलांतर खर्चाशिवाय आमच्या iOS अनुप्रयोगांमध्ये Cronet समाकलित करू शकतो.

Google Cloud Balancers वर QUIC पूर्ण करत आहे

बॅकएंड बाजूला, Google क्लाउड लोड बॅलन्सिंग इन्फ्रास्ट्रक्चरद्वारे QUIC पूर्णत्व प्रदान केले जाते, जे वापरते alt-svc QUIC चे समर्थन करण्यासाठी प्रतिसादांमध्ये शीर्षलेख. सर्वसाधारणपणे, बॅलन्सर प्रत्येक HTTP विनंतीवर alt-svc शीर्षलेख जोडतो आणि हे डोमेनसाठी आधीच QUIC समर्थन प्रमाणित करते. जेव्हा क्रॉनेट क्लायंटला या शीर्षलेखासह HTTP प्रतिसाद प्राप्त होतो, तेव्हा तो त्या डोमेनच्या पुढील HTTP विनंत्यांसाठी QUIC वापरतो. एकदा बॅलन्सरने QUIC पूर्ण केल्यावर, आमची इन्फ्रास्ट्रक्चर ही क्रिया HTTP2/TCP वर आमच्या डेटा केंद्रांना स्पष्टपणे पाठवते.

कामगिरी: परिणाम

आउटपुट कामगिरी हे आमच्या चांगल्या प्रोटोकॉलच्या शोधाचे मुख्य कारण आहे. सुरुवातीला, आम्ही एक स्टँड तयार केला नेटवर्क अनुकरणभिन्न नेटवर्क प्रोफाइल अंतर्गत QUIC कसे वागेल हे शोधण्यासाठी. रिअल-वर्ल्ड नेटवर्क्सवर QUIC च्या कार्यप्रदर्शनाची चाचणी घेण्यासाठी, आम्ही प्रवासी अॅपमधील HTTP कॉल प्रमाणेच अनुकरणीय नेटवर्क ट्रॅफिक वापरून नवी दिल्लीभोवती गाडी चालवताना प्रयोग केले.

प्रयोग १

प्रयोगासाठी उपकरणे:

• आम्ही अनुक्रमे TCP आणि QUIC वर HTTPS रहदारीला परवानगी देतो याची खात्री करण्यासाठी OkHttp आणि Cronet स्टॅकसह Android डिव्हाइसेसची चाचणी घ्या;
• Java-आधारित इम्युलेशन सर्व्हर जो प्रतिसादांमध्ये समान प्रकारचे HTTPS शीर्षलेख पाठवतो आणि त्यांच्याकडून विनंत्या प्राप्त करण्यासाठी क्लायंट डिव्हाइस लोड करतो;
• TCP आणि QUIC कनेक्शन संपुष्टात आणण्यासाठी भौतिकरित्या भारताजवळ असलेल्या क्लाउड प्रॉक्सी. TCP टर्मिनेशनसाठी आम्ही रिव्हर्स प्रॉक्सी ऑन वापरली एनजीएनएक्स, QUIC साठी ओपन सोर्स रिव्हर्स प्रॉक्सी शोधणे कठीण होते. आम्ही क्रोमियम आणि प्रकाशित मुक्त स्रोत म्हणून क्रोमियममध्ये.

आकृती 6. TCP vs QUIC रोड चाचणी संचमध्ये OkHttp आणि Cronet सह Android डिव्हाइसेस, कनेक्शन समाप्त करण्यासाठी क्लाउड प्रॉक्सी आणि एक इम्युलेशन सर्व्हर यांचा समावेश आहे.

प्रयोग १

जेव्हा Google ने QUIC उपलब्ध करून दिले Google क्लाउड लोड बॅलन्सिंग, आम्ही समान इन्व्हेंटरी वापरली, परंतु एका बदलासह: NGINX ऐवजी, आम्ही डिव्हाइसेसवरून TCP आणि QUIC कनेक्शन समाप्त करण्यासाठी तसेच इम्युलेशन सर्व्हरवर HTTPS ट्रॅफिक रूट करण्यासाठी Google लोड बॅलन्सर्स घेतले. बॅलन्सर जगभरात वितरीत केले जातात, परंतु डिव्हाइसच्या सर्वात जवळचा PoP सर्व्हर वापरा (जिओलोकेशनबद्दल धन्यवाद).

आकृती 7. दुसऱ्या प्रयोगात, आम्हाला TCP आणि QUIC च्या पूर्ण होण्याच्या विलंबाची तुलना करायची होती: Google Cloud वापरून आणि आमच्या क्लाउड प्रॉक्सीचा वापर करून.

परिणामी, अनेक खुलासे आम्हाला वाट पाहत होते:

• PoP द्वारे समाप्ती TCP कामगिरी सुधारली. बॅलन्सर्स वापरकर्त्यांच्या जवळ TCP कनेक्शन्स संपुष्टात आणतात आणि उच्च ऑप्टिमाइझ केलेले असल्याने, यामुळे RTT कमी होतात, ज्यामुळे TCP कार्यप्रदर्शन सुधारते. आणि जरी QUIC चा कमी परिणाम झाला, तरीही टेल लेटन्सी (10-30 टक्क्यांनी) कमी करण्याच्या बाबतीत ते TCP पेक्षा जास्त कामगिरी करते.
• शेपटी प्रभावित आहेत नेटवर्क हॉप्स. जरी आमची QUIC प्रॉक्सी Google च्या लोड बॅलन्सर्सच्या तुलनेत (सुमारे 50 ms जास्त लेटन्सी) डिव्हाइसेसवरून होती, तरीही त्याने समान कार्यप्रदर्शन दिले - लेटन्सीमध्ये 15% घट विरुद्ध TCP साठी 20 व्या पर्सेंटाइलमध्ये 99% घट. हे सूचित करते की शेवटच्या मैलाचे संक्रमण नेटवर्कमधील अडथळे आहे.

आकृती 8: दोन प्रयोगांचे परिणाम दर्शवतात की QUIC लक्षणीयरित्या TCP ला मागे टाकते.

वाहतूक वाहतूक

प्रयोगाने प्रेरित होऊन, आम्ही आमच्या Android आणि iOS अनुप्रयोगांमध्ये QUIC समर्थन लागू केले आहे. ज्या शहरांमध्ये Uber कार्यरत आहे तेथे QUIC चा प्रभाव निश्चित करण्यासाठी आम्ही A/B चाचणी केली. सर्वसाधारणपणे, आम्ही दोन्ही क्षेत्रांमध्ये, दूरसंचार ऑपरेटर आणि नेटवर्क प्रकारात टेल विलंबामध्ये लक्षणीय घट पाहिली.

खालील आलेख मॅक्रो-रिजन आणि विविध नेटवर्क प्रकारांनुसार पुच्छांमध्ये (95 आणि 99 टक्केवारी) टक्केवारी सुधारणा दर्शवतात - LTE, 3G, 2G.

आकृती 9. युद्धाच्या चाचण्यांमध्ये, QUIC ने विलंबतेच्या बाबतीत टीसीपीला मागे टाकले.

फक्त पुढे

कदाचित ही फक्त सुरुवात आहे - उत्पादनामध्ये QUIC च्या प्रकाशनाने स्थिर आणि अस्थिर दोन्ही नेटवर्कमध्ये अनुप्रयोग कार्यप्रदर्शन सुधारण्यासाठी आश्चर्यकारक संधी प्रदान केल्या आहेत, म्हणजे:

व्याप्ती वाढवली

वास्तविक रहदारीवरील प्रोटोकॉलच्या कार्यप्रदर्शनाचे विश्लेषण केल्यावर, आम्ही पाहिले की अंदाजे 80% सत्रांनी यशस्वीरित्या QUIC चा वापर केला всех विनंत्या, तर 15% सत्रांनी QUIC आणि TCP चे संयोजन वापरले. आम्ही असे गृहीत धरतो की हे संयोजन क्रोनेट लायब्ररी TCP कडे परत जाण्याच्या कालबाह्यतेमुळे आहे, कारण ते वास्तविक UDP अपयश आणि खराब नेटवर्क स्थिती यांच्यात फरक करू शकत नाही. आम्ही सध्या या समस्येवर उपाय शोधत आहोत कारण आम्ही QUIC च्या पुढील अंमलबजावणीच्या दिशेने काम करत आहोत.

QUIC ऑप्टिमायझेशन

मोबाइल अॅप्सवरील रहदारी विलंब संवेदनशील आहे, परंतु बँडविड्थ संवेदनशील नाही. तसेच, आमचे अनुप्रयोग प्रामुख्याने सेल्युलर नेटवर्कवर वापरले जातात. प्रयोगांवर आधारित, वापरकर्त्यांच्या जवळच्या TCP आणि QUIC बंद करण्यासाठी प्रॉक्सी वापरत असतानाही टेल लेटेंसी अजूनही जास्त आहेत. आम्ही गर्दीचे व्यवस्थापन सुधारण्यासाठी आणि QUIC नुकसान पुनर्प्राप्ती अल्गोरिदमची कार्यक्षमता सुधारण्यासाठी सक्रियपणे मार्ग शोधत आहोत.

या आणि इतर अनेक सुधारणांसह, आम्ही नेटवर्क आणि क्षेत्राचा विचार न करता वापरकर्त्याचा अनुभव सुधारण्याची योजना आखत आहोत, ज्यामुळे जगभरातील सोयीस्कर आणि अखंड पॅकेट वाहतूक अधिक सुलभ होईल.

स्त्रोत: www.habr.com