कार्यमा रहेको 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

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

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

चित्र १: Uber को मुख्य शहरहरूमा पुच्छर विलम्बता फरक हुन्छ।

यद्यपि भारतीय र ब्राजिलियन नेटवर्कहरूमा विलम्बता US र UK को तुलनामा उच्च थियो, टेल विलम्बता औसत विलम्बता भन्दा उल्लेखनीय रूपमा उच्च छ। र यो अमेरिका र बेलायतको लागि पनि सत्य हो।

हावा प्रदर्शन मा TCP

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

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

अन्तमा, सेलुलर नेटवर्क प्रदर्शन क्यारियर, क्षेत्र, र समय अनुसार फरक हुन्छ। चित्र २ मा, हामीले २-किलोमिटर दायरा भित्रका कक्षहरूमा HTTPS ट्राफिकको औसत ढिलाइ सङ्कलन गर्यौं। दिल्ली, भारतमा दुई प्रमुख सेलुलर अपरेटरहरूको लागि डेटा सङ्कलन। तपाईले देख्न सक्नुहुने रूपमा, कार्यसम्पादन सेल देखि सेल फरक हुन्छ। साथै, एक अपरेटरको उत्पादकता दोस्रोको उत्पादकता भन्दा फरक छ। यो खाता समय र स्थान, प्रयोगकर्ता गतिशीलता, साथै नेटवर्क पूर्वाधार खाता टावर घनत्व र नेटवर्क प्रकारहरूको अनुपात (LTE, 2G, आदि) लाई ध्यानमा राखेर नेटवर्क प्रविष्टि ढाँचा जस्ता कारकहरूद्वारा प्रभावित हुन्छ।

चित्र 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। थप रूपमा, हामीले एक एन्ड्रोइड अनुप्रयोग सिर्जना गर्‍यौं जसले वास्तविक ट्राफिकलाई सकेसम्म धेरै नक्कल गर्दै परीक्षण सर्भरमा इमुलेट गरिएको ट्राफिक पठाउँदछ। यस अनुप्रयोगको साथ स्मार्टफोनहरू धेरै कर्मचारीहरूलाई वितरण गरिएको थियो, जसले धेरै दिनहरूमा लगहरू सङ्कलन गरे।

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

नेटवर्क मेट्रिक्स
मानहरू

RTT, मिलिसेकेन्ड [५०%,७५%, ९५%,९९%]
[०, २, १, ०]

RTT विचलन, सेकेन्ड
औसतमा ~1,2 सेकेन्ड

अस्थिर जडानहरूमा प्याकेट हानि
औसत ~3.5% (7% ओभरलोड क्षेत्रहरूमा)

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

डाटा प्याकेटको मामलामा, उच्च RTO मानहरूले वायरलेस नेटवर्कहरूमा क्षणिक हानिहरूको उपस्थितिमा नेटवर्कको उपयोगी उपयोगलाई ठूलो मात्रामा कम गर्छ। हामीले फेला पारेका छौं कि औसत पुन: प्रसारण समय लगभग 1 सेकेन्डको पुच्छर ढिलाइको साथ लगभग 30 सेकेन्ड हो। TCP स्तरमा यी उच्च विलम्बताहरूले HTTPS टाइमआउट र पुन: अनुरोधहरू निम्त्यायो, थप नेटवर्क विलम्बता र अक्षमता बढ्यो।

मापन गरिएको RTT को 75 औं पर्सेन्टाइल लगभग 425 ms थियो, TCP को 75 औं पर्सेन्टाइल लगभग 3 सेकेन्ड थियो। यसले सङ्केत गर्छ कि हानिको कारणले TCP ले डाटा सफलतापूर्वक प्रसारण गर्न 7-10 पासहरू लियो। यो अकुशल RTO गणनाको परिणाम हुन सक्छ, TCP को हानिको तुरुन्तै प्रतिक्रिया दिन असक्षमता नवीनतम प्याकेजहरू सञ्झ्यालमा र भीड नियन्त्रण एल्गोरिथ्मको असक्षमता, जसले वायरलेस हानि र नेटवर्क भीडको कारणले हुने नोक्सान बीचको भिन्नता देखाउँदैन। तल TCP हानि परीक्षणको नतिजाहरू छन्:

TCP प्याकेट हानि तथ्याङ्क
मूल्य

कम्तिमा १ प्याकेट हराएको जडानको प्रतिशत
45%

जडान सेटअप गर्दा हानि भएको जडानको प्रतिशत
30%

डाटा आदानप्रदानको क्रममा हानि भएको जडानको प्रतिशत
76%

पुन: प्रसारणमा ढिलाइको वितरण, सेकेन्ड [५०%, ७५%, ९५%,९९%] [१, २.८, १५, २८]

एक प्याकेट वा TCP खण्डको लागि पुन: प्रसारण संख्याको वितरण
[1,3,6,7]

QUIC को आवेदन

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

चित्र 5: QUIC HTTP/3 अन्तर्गत चल्छ, TLS प्रतिस्थापन गर्दै, जुन पहिले HTTP/2 अन्तर्गत चलेको थियो।

TCP प्रवर्धनको लागि QUIC प्रयोग गर्न हामीलाई विश्वस्त पार्ने कारणहरू तल छन्:

• ०-RTT जडान स्थापना। QUIC ले सुरक्षा ह्यान्डशेकहरूको संख्या घटाउँदै अघिल्लो जडानहरूबाट प्राधिकरणहरूको पुन: प्रयोग गर्न अनुमति दिन्छ। भविष्यमा TLS1.3 0-RTT लाई समर्थन गर्नेछ, तर तीन-तर्फी TCP ह्यान्डशेक अझै आवश्यक हुनेछ।
• HoL अवरुद्ध पार गर्दै। HTTP/2 ले प्रदर्शन सुधार गर्न प्रति क्लाइन्ट एक TCP जडान प्रयोग गर्दछ, तर यसले HoL (हेड-अफ-लाइन) अवरुद्ध हुन सक्छ। QUIC ले मल्टिप्लेक्सिङलाई सरल बनाउँछ र स्वतन्त्र रूपमा अनुप्रयोगमा अनुरोधहरू प्रदान गर्दछ।
• भीड नियन्त्रण। QUIC अनुप्रयोग तहमा रहन्छ, नेटवर्क प्यारामिटरहरू (हानि वा RTT संख्या) को आधारमा पठाउने नियन्त्रण गर्ने मुख्य यातायात एल्गोरिदम अद्यावधिक गर्न सजिलो बनाउँछ। धेरै जसो TCP कार्यान्वयनहरूले एल्गोरिदम प्रयोग गर्छन् घन, जुन विलम्बता-संवेदनशील ट्राफिकको लागि इष्टतम छैन। हालै विकसित एल्गोरिदम जस्तै BBR, अधिक सटीक रूपमा नेटवर्क मोडेल र विलम्बता अनुकूलन। QUIC ले तपाईंलाई BBR प्रयोग गर्न र यो एल्गोरिदमलाई प्रयोग गरिए अनुसार अद्यावधिक गर्न अनुमति दिन्छ। सुधार.
• घाटाको पुन:पूर्ति। QUIC दुई TLP कल गर्दछ (पुच्छर हानि जाँच) आरटीओ ट्रिगर हुनु अघि - हानि धेरै उल्लेखनीय हुँदा पनि। यो TCP कार्यान्वयन भन्दा फरक छ। TLP ले छिटो पुनःपूर्ति ट्रिगर गर्न मुख्यतया अन्तिम प्याकेट (वा नयाँ, यदि त्यहाँ छ भने) पुन: प्रसारण गर्दछ। टेल ढिलाइहरू ह्यान्डलिङ विशेष गरी Uber ले आफ्नो नेटवर्क सञ्चालन गर्ने तरिकाको लागि उपयोगी छ, अर्थात् छोटो, छिटपुट, र विलम्ब-संवेदनशील डेटा स्थानान्तरणका लागि।
• अनुकूलित ACK। प्रत्येक प्याकेटको एक अद्वितीय अनुक्रम संख्या भएकोले, त्यहाँ कुनै समस्या छैन भेदहरू प्याकेटहरू पुन: प्रसारण गर्दा। ACK प्याकेटहरूले प्याकेट प्रशोधन गर्न र ग्राहक पक्षमा ACK उत्पन्न गर्न समय समावेश गर्दछ। यी सुविधाहरूले QUIC ले RTT थप सटीक रूपमा गणना गर्छ भनी सुनिश्चित गर्दछ। ACK मा QUIC ले २५६ ब्यान्ड सम्म समर्थन गर्दछ NACK, प्रेषकलाई प्याकेट फेरबदल गर्न र प्रक्रियामा कम बाइटहरू प्रयोग गर्न थप लचिलो हुन मद्दत गर्दै। चयनात्मक ACK (बोराTCP मा सबै अवस्थामा यो समस्या समाधान गर्दैन।
• जडान माइग्रेसन। QUIC जडानहरू 64-बिट ID द्वारा पहिचान गरिन्छ, त्यसैले यदि ग्राहकले IP ठेगानाहरू परिवर्तन गर्दछ भने, पुरानो जडान ID कुनै अवरोध बिना नयाँ IP ठेगानामा प्रयोग गर्न जारी राख्न सक्छ। यो मोबाइल अनुप्रयोगहरूको लागि एक धेरै सामान्य अभ्यास हो जहाँ प्रयोगकर्ताले Wi-Fi र सेलुलर जडानहरू बीच स्विच गर्दछ।

QUIC को विकल्प

हामीले QUIC छनौट गर्नु अघि समस्या समाधान गर्न वैकल्पिक दृष्टिकोणहरू विचार गर्यौं।

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

हामीले TCP प्यारामिटरहरू ट्युनिङमा पनि हेर्यौं। हाम्रो विषम किनारा सर्भरहरूमा TCP स्ट्याक सेट अप गर्न गाह्रो थियो किनभने TCP को विभिन्न OS संस्करणहरूमा फरक कार्यान्वयनहरू छन्। यसलाई कार्यान्वयन गर्न र विभिन्न नेटवर्क कन्फिगरेसनहरू परीक्षण गर्न गाह्रो थियो। अनुमतिको कमीको कारणले मोबाइल उपकरणहरूमा सीधा TCP कन्फिगर गर्न सम्भव थिएन। अझ महत्त्वपूर्ण कुरा, ०-RTT जडानहरू र सुधारिएको RTT भविष्यवाणी जस्ता सुविधाहरू प्रोटोकलको संरचनाको लागि महत्त्वपूर्ण छन्, र त्यसैले TCP एक्लै ट्युनिङ गरेर महत्त्वपूर्ण फाइदाहरू प्राप्त गर्न असम्भव छ।

अन्तमा, हामीले भिडियो स्ट्रिमिङ समस्या निवारण गर्ने धेरै UDP-आधारित प्रोटोकलहरूको मूल्याङ्कन गर्‍यौं—हामी हेर्न चाहन्थ्यौं कि यी प्रोटोकलहरूले हाम्रो मामलामा मद्दत गर्नेछन्। दुर्भाग्यवश, तिनीहरूसँग धेरै सुरक्षा सेटिङहरूमा गम्भीर रूपमा अभाव थियो, र मेटाडेटा र नियन्त्रण जानकारीको लागि थप TCP जडान आवश्यक थियो।

हाम्रो अनुसन्धानले देखाएको छ कि QUIC सायद एक मात्र प्रोटोकल हो जसले सुरक्षा र कार्यसम्पादन दुवैलाई ध्यानमा राख्दै इन्टरनेट ट्राफिकको समस्यामा मद्दत गर्न सक्छ।

प्लेटफर्ममा QUIC को एकीकरण

QUIC लाई सफलतापूर्वक इम्बेड गर्न र खराब जडान वातावरणमा अनुप्रयोग प्रदर्शन सुधार गर्न, हामीले पुरानो स्ट्याक (HTTP/2 over TLS/TCP) लाई QUIC प्रोटोकलसँग बदल्यौं। हामीले नेटवर्क लाइब्रेरी प्रयोग गर्यौं क्रोनेट बाट क्रोमियम परियोजनाहरू, जसमा प्रोटोकलको मूल, गुगल संस्करण - gQUIC समावेश छ। नवीनतम IETF विनिर्देशहरू पालना गर्न यो कार्यान्वयन पनि निरन्तर सुधार भइरहेको छ।

हामीले QUIC को लागि समर्थन थप्नको लागि पहिले हाम्रो Android एपहरूमा Cronet एकीकृत गर्यौं। एकीकरण सम्भव भएसम्म बसाइँसर लागत घटाउने तरिकामा गरिएको थियो। पुरानो नेटवर्किङ स्ट्याक पूर्ण रूपमा प्रतिस्थापन गर्नुको सट्टा जुन पुस्तकालय प्रयोग गर्यो OkHttp, हामीले OkHttp API फ्रेमवर्क अन्तर्गत Cronet लाई एकीकृत गरेका छौं। यसरी एकीकरण गरेर, हामीले हाम्रो नेटवर्क कलहरूमा परिवर्तनहरू बेवास्ता गर्यौं (जुन द्वारा प्रयोग गरिन्छ रेट्रोफिट) API स्तरमा।

एन्ड्रोइड उपकरणहरूको लागि दृष्टिकोण जस्तै, हामीले आईओएसमा उबर एपहरूमा क्रोनेट लागू गर्यौं, नेटवर्कबाट HTTP ट्राफिकलाई रोक्दै। एपीआईप्रयोग गर्दै NSURL प्रोटोकल। iOS फाउन्डेसनद्वारा प्रदान गरिएको यो अमूर्तताले प्रोटोकल-विशिष्ट URL डेटा ह्यान्डल गर्छ र हामीले महत्त्वपूर्ण माइग्रेसन लागतहरू बिना नै हाम्रा iOS अनुप्रयोगहरूमा Cronet एकीकृत गर्न सक्छौं भन्ने सुनिश्चित गर्छ।

गुगल क्लाउड ब्यालेन्सरहरूमा QUIC पूरा गर्दै

ब्याकएन्ड साइडमा, गुगल क्लाउड लोड ब्यालेन्सिङ पूर्वाधारद्वारा QUIC पूर्णता प्रदान गरिएको छ, जसले प्रयोग गर्दछ alt-svc QUIC समर्थन गर्न प्रतिक्रियाहरूमा हेडरहरू। सामान्यतया, ब्यालेन्सरले प्रत्येक HTTP अनुरोधमा alt-svc हेडर थप्छ, र यसले डोमेनको लागि QUIC समर्थनलाई पहिले नै प्रमाणित गर्छ। जब Cronet क्लाइन्टले यो हेडरको साथ HTTP प्रतिक्रिया प्राप्त गर्दछ, यसले त्यस डोमेनमा पछिल्ला HTTP अनुरोधहरूको लागि QUIC प्रयोग गर्दछ। ब्यालेन्सरले QUIC पूरा गरेपछि, हाम्रो पूर्वाधारले स्पष्ट रूपमा HTTP2/TCP मार्फत हाम्रो डेटा केन्द्रहरूमा यो कार्य पठाउँछ।

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

आउटपुट प्रदर्शन राम्रो प्रोटोकल को लागी हाम्रो खोज को लागी मुख्य कारण हो। सुरुमा, हामीले एउटा स्ट्यान्ड सिर्जना गर्यौं नेटवर्क अनुकरणविभिन्न नेटवर्क प्रोफाइलहरू अन्तर्गत QUIC ले कसरी व्यवहार गर्नेछ भनेर पत्ता लगाउन। वास्तविक-विश्व नेटवर्कहरूमा QUIC को कार्यसम्पादन परीक्षण गर्न, हामीले नयाँ दिल्लीको वरिपरि ड्राइभिङ गर्दा यात्रु एपमा HTTP कलहरू जस्तै नक्कल गरिएको नेटवर्क ट्राफिक प्रयोग गरेर प्रयोगहरू चलायौं।

प्रयोग १

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

• हामीले क्रमशः TCP र QUIC मा HTTPS ट्राफिकलाई अनुमति दिन्छौं भन्ने कुरा सुनिश्चित गर्न OkHttp र Cronet स्ट्याकहरूका साथ एन्ड्रोइड उपकरणहरूको परीक्षण गर्नुहोस्;
• जाभा-आधारित इमुलेशन सर्भर जसले प्रतिक्रियाहरूमा समान प्रकारको HTTPS हेडरहरू पठाउँदछ र तिनीहरूबाट अनुरोधहरू प्राप्त गर्न ग्राहक उपकरणहरू लोड गर्दछ;
• क्लाउड प्रोक्सीहरू जुन भौतिक रूपमा TCP र QUIC जडानहरू समाप्त गर्न भारतको नजिक अवस्थित छन्। TCP समाप्तिको लागि हामीले रिभर्स प्रोक्सी अन प्रयोग गर्यौं NGINX, QUIC को लागि खुला स्रोत रिभर्स प्रोक्सी फेला पार्न गाह्रो थियो। हामीले क्रोमियम र प्रकाशित भयो यसलाई क्रोमियममा खुला स्रोतको रूपमा।

चित्र 6. TCP बनाम QUIC सडक परीक्षण सुइटमा OkHttp र Cronet, जडानहरू समाप्त गर्न क्लाउड प्रोक्सीहरू, र एक इमुलेशन सर्भरको साथ एन्ड्रोइड उपकरणहरू समावेश थिए।

प्रयोग १

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

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

नतिजाको रूपमा, धेरै खुलासाहरू हामीलाई पर्खिरहेका थिए:

• PoP मार्फत समाप्तिले TCP प्रदर्शन सुधार गर्यो। ब्यालेन्सरहरूले TCP जडानहरू प्रयोगकर्ताहरूका नजिकै समाप्त गर्ने र अत्यधिक अप्टिमाइज गरिएको हुनाले, यसले कम RTT हरूमा परिणाम दिन्छ, जसले TCP कार्यसम्पादनमा सुधार गर्छ। र यद्यपि क्विक कम प्रभावित भएको थियो, यसले अझै पनि टेल विलम्बता (१०-३० प्रतिशतले) घटाउने सन्दर्भमा TCP भन्दा राम्रो प्रदर्शन गर्यो।
• पुच्छर प्रभावित छन् नेटवर्क हप्स. यद्यपि हाम्रो QUIC प्रोक्सी गुगलको लोड ब्यालेन्सरहरू भन्दा यन्त्रहरूबाट (लगभग 50 ms उच्च विलम्बता) थियो, यसले समान कार्यसम्पादन प्रदान गर्‍यो - TCP को लागि 15th प्रतिशतमा 20% कमी बनाम विलम्बतामा 99% कमी। यसले सुझाव दिन्छ कि अन्तिम माइल संक्रमण नेटवर्कमा एक बाधा हो।

चित्र 8: दुईवटा प्रयोगका नतिजाहरूले देखाउँछन् कि QUIC ले TCP लाई उल्लेखनीय रूपमा अगाडि बढाउँछ।

लडाई ट्राफिक

प्रयोगबाट प्रेरित भएर हामीले हाम्रा एन्ड्रोइड र आईओएस अनुप्रयोगहरूमा QUIC समर्थन लागू गरेका छौं। हामीले Uber सञ्चालन गर्ने सहरहरूमा QUIC को प्रभाव निर्धारण गर्न A/B परीक्षण सञ्चालन गर्यौं। सामान्यतया, हामीले दुबै क्षेत्रहरू, टेलिकम अपरेटरहरू र नेटवर्क प्रकारहरूमा टेल ढिलाइमा उल्लेखनीय कमी देख्यौं।

तलका ग्राफहरूले म्याक्रो-क्षेत्र र विभिन्न नेटवर्क प्रकारहरू - LTE, 95G, 99G द्वारा पुच्छर (3 र 2 प्रतिशतक) मा प्रतिशत सुधारहरू देखाउँछन्।

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

केवल अगाडि

सायद यो केवल शुरुवात हो - उत्पादनमा QUIC को रिलीजले स्थिर र अस्थिर दुवै नेटवर्कहरूमा अनुप्रयोग प्रदर्शन सुधार गर्न अद्भुत अवसरहरू प्रदान गरेको छ, अर्थात्:

कभरेज बढ्यो

वास्तविक ट्राफिकमा प्रोटोकलको कार्यसम्पादनको विश्लेषण गरेर, हामीले देख्यौं कि लगभग 80% सत्रहरूले सफलतापूर्वक QUIC को लागि प्रयोग गर्यो। всех अनुरोधहरू, जबकि 15% सत्रहरूले QUIC र TCP को संयोजन प्रयोग गरे। हामी मान्दछौं कि संयोजन Cronet पुस्तकालय TCP मा फिर्ता टाइमआउटको कारण हो, किनकि यसले वास्तविक UDP विफलता र कमजोर नेटवर्क अवस्थाहरू बीच भेद गर्न सक्दैन। हामी हाल यस समस्याको समाधान खोजिरहेका छौं किनकि हामी QUIC को पछिल्ला कार्यान्वयनमा काम गर्छौं।

QUIC अनुकूलन

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

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

स्रोत: www.habr.com