செயல்பாட்டில் உள்ள QUIC நெறிமுறை: செயல்திறனை மேம்படுத்த Uber அதை எவ்வாறு செயல்படுத்தியது

QUIC நெறிமுறை பார்ப்பதற்கு மிகவும் சுவாரஸ்யமாக இருக்கிறது, அதனால்தான் அதைப் பற்றி எழுத விரும்புகிறோம். ஆனால் QUIC பற்றிய முந்தைய வெளியீடுகள் வரலாற்று (உள்ளூர் வரலாறு, நீங்கள் விரும்பினால்) இயல்பு மற்றும் வன்பொருளாக இருந்தால், இன்று வேறு வகையான மொழிபெயர்ப்பை வெளியிடுவதில் நாங்கள் மகிழ்ச்சியடைகிறோம் - 2019 இல் நெறிமுறையின் உண்மையான பயன்பாட்டைப் பற்றி பேசுவோம். மேலும், நாங்கள் கேரேஜ் என்று அழைக்கப்படும் சிறிய உள்கட்டமைப்பைப் பற்றி பேசவில்லை, ஆனால் உலகம் முழுவதும் இயங்கும் Uber பற்றி. உற்பத்தியில் QUIC ஐப் பயன்படுத்துவதற்கான முடிவுக்கு நிறுவனத்தின் பொறியாளர்கள் எவ்வாறு வந்தனர், அவர்கள் எவ்வாறு சோதனைகளை மேற்கொண்டனர் மற்றும் உற்பத்தியில் அதை வெளியிட்ட பிறகு அவர்கள் பார்த்தது - வெட்டுக்கு கீழே.

படங்கள் கிளிக் செய்யக்கூடியவை. படித்து மகிழுங்கள்!

Uber உலகளாவிய அளவில் உள்ளது, அதாவது 600 நகரங்கள் உள்ளன, ஒவ்வொன்றிலும் பயன்பாடு 4500 க்கும் மேற்பட்ட செல்லுலார் ஆபரேட்டர்களின் வயர்லெஸ் இணையத்தை முழுமையாக நம்பியுள்ளது. ஆப்ஸ் வேகமானது மட்டுமல்ல, நிகழ்நேரத்திலும் இருக்கும் என்று பயனர்கள் எதிர்பார்க்கிறார்கள் - இதை அடைய, Uber பயன்பாட்டிற்கு குறைந்த தாமதமும் மிகவும் நம்பகமான இணைப்பும் தேவை. ஐயோ, ஆனால் அடுக்கு , HTTP / 2 டைனமிக் மற்றும் நஷ்டம் ஏற்படக்கூடிய வயர்லெஸ் நெட்வொர்க்குகளில் சிறப்பாக செயல்படாது. இந்த விஷயத்தில், குறைந்த செயல்திறன் இயக்க முறைமை கர்னல்களில் TCP செயலாக்கங்களுடன் நேரடியாக தொடர்புடையது என்பதை நாங்கள் உணர்ந்தோம்.

பிரச்னையை தீர்க்க, விண்ணப்பித்தோம் இது QUIC, ஒரு நவீன சேனல் மல்டிபிளெக்சிங் நெறிமுறை, இது போக்குவரத்து நெறிமுறையின் செயல்திறனில் கூடுதல் கட்டுப்பாட்டை வழங்குகிறது. தற்போது பணிக்குழு ஐஇடிஎஃப் என QUIC தரப்படுத்துகிறது , HTTP / 3.

விரிவான சோதனைக்குப் பிறகு, எங்கள் பயன்பாட்டில் QUICஐ செயல்படுத்துவது TCP உடன் ஒப்பிடும்போது குறைவான டெயில் லேட்டன்சிகளை ஏற்படுத்தும் என்று முடிவு செய்தோம். ஓட்டுநர் மற்றும் பயணிகள் பயன்பாடுகளில் HTTPS ட்ராஃபிக்கிற்கான வரம்பில் 10-30% குறைவதைக் கண்டோம். QUIC பயனர் தொகுப்புகளின் மீது இறுதி முதல் இறுதி வரை கட்டுப்பாட்டையும் எங்களுக்கு வழங்கியது.

இந்தக் கட்டுரையில், QUICஐ ஆதரிக்கும் அடுக்கைப் பயன்படுத்தி Uber பயன்பாடுகளுக்கு TCP ஐ மேம்படுத்துவதில் எங்கள் அனுபவத்தைப் பகிர்ந்து கொள்கிறோம்.

சமீபத்திய தொழில்நுட்பம்: TCP

இன்று, இணையத்தில் HTTPS ட்ராஃபிக்கை வழங்குவதற்கு TCP மிகவும் பயன்படுத்தப்படும் போக்குவரத்து நெறிமுறையாகும். TCP ஆனது நம்பகமான பைட்டுகளை வழங்குகிறது, இதன் மூலம் பிணைய நெரிசல் மற்றும் இணைப்பு அடுக்கு இழப்புகளை சமாளிக்கிறது. HTTPS ட்ராஃபிக்கிற்கு TCP இன் பரவலான பயன்பாடு, முந்தையது எங்கும் பரவுவது (கிட்டத்தட்ட ஒவ்வொரு OS லும் TCP உள்ளது), பெரும்பாலான உள்கட்டமைப்புகளில் கிடைக்கும் தன்மை (லோட் பேலன்சர்கள், HTTPS ப்ராக்ஸிகள் மற்றும் CDNகள் போன்றவை) மற்றும் கிடைக்கக்கூடிய அவுட்-ஆஃப்-தி-பாக்ஸ் செயல்பாடு காரணமாகும். கிட்டத்தட்ட பெரும்பாலான தளங்கள் மற்றும் நெட்வொர்க்குகளில்.

பெரும்பாலான பயனர்கள் பயணத்தின்போது எங்கள் பயன்பாட்டைப் பயன்படுத்துகின்றனர், மேலும் TCP டெயில் தாமதங்கள் எங்களின் நிகழ்நேர HTTPS ட்ராஃபிக்கின் தேவைகளுக்கு அருகில் இல்லை. எளிமையாகச் சொன்னால், உலகம் முழுவதும் உள்ள பயனர்கள் இதை அனுபவித்திருக்கிறார்கள் - படம் 1 முக்கிய நகரங்களில் தாமதங்களைக் காட்டுகிறது:

படம் 1: Uber இன் முக்கிய நகரங்களில் டெயில் தாமதம் மாறுபடும்.

அமெரிக்கா மற்றும் இங்கிலாந்தை விட இந்திய மற்றும் பிரேசிலிய நெட்வொர்க்குகளில் தாமதம் அதிகமாக இருந்தாலும், வால் தாமதமானது சராசரி தாமதத்தை விட கணிசமாக அதிகமாக உள்ளது. இது அமெரிக்கா மற்றும் இங்கிலாந்துக்கு கூட உண்மை.

காற்று செயல்திறன் மீது TCP

TCP உருவாக்கப்பட்டது கம்பி நெட்வொர்க்குகள், அதாவது, மிகவும் கணிக்கக்கூடிய இணைப்புகளுக்கு முக்கியத்துவம் அளிக்கிறது. எனினும், வயர்லெஸ் நெட்வொர்க்குகள் அவற்றின் சொந்த பண்புகள் மற்றும் சிரமங்களைக் கொண்டுள்ளன. முதலாவதாக, வயர்லெஸ் நெட்வொர்க்குகள் குறுக்கீடு மற்றும் சமிக்ஞை குறைப்பு காரணமாக இழப்புகளுக்கு ஆளாகின்றன. எடுத்துக்காட்டாக, வைஃபை நெட்வொர்க்குகள் மைக்ரோவேவ், புளூடூத் மற்றும் பிற ரேடியோ அலைகளுக்கு உணர்திறன் கொண்டவை. செல்லுலார் நெட்வொர்க்குகள் சமிக்ஞை இழப்பால் பாதிக்கப்படுகின்றன (பாதையை இழந்தது) பொருள்கள் மற்றும் கட்டிடங்கள் மூலம் சமிக்ஞையின் பிரதிபலிப்பு / உறிஞ்சுதல் காரணமாக, அத்துடன் குறுக்கீடு அண்டையிலிருந்து செல் கோபுரங்கள். இது மிகவும் குறிப்பிடத்தக்க (4-10 மடங்கு) மற்றும் மிகவும் மாறுபட்டது சுற்று பயண தாமதம் (RTT) மற்றும் கம்பி இணைப்புடன் ஒப்பிடும்போது பாக்கெட் இழப்பு.

அலைவரிசை ஏற்ற இறக்கங்கள் மற்றும் இழப்புகளை எதிர்த்துப் போராட, செல்லுலார் நெட்வொர்க்குகள் பொதுவாக போக்குவரத்து வெடிப்புகளுக்கு பெரிய இடையகங்களைப் பயன்படுத்துகின்றன. இது அதிக வரிசைக்கு வழிவகுக்கும், அதாவது நீண்ட தாமதங்கள். பெரும்பாலும் TCP இந்த வரிசையை நீட்டிக்கப்பட்ட காலக்கெடுவின் காரணமாக வீணாகக் கருதுகிறது, எனவே TCP ரிலே மற்றும் அதன் மூலம் இடையகத்தை நிரப்ப முனைகிறது. இந்த பிரச்சனை அறியப்படுகிறது தாங்கல் (அதிகப்படியான பிணைய இடையகப்படுத்தல், இடையக வீக்கம்), மற்றும் இது மிகவும் தீவிர பிரச்சனை நவீன இணையம்.

இறுதியாக, செல்லுலார் நெட்வொர்க் செயல்திறன் கேரியர், பிராந்தியம் மற்றும் நேரத்தைப் பொறுத்து மாறுபடும். படம் 2 இல், 2-கிலோமீட்டர் வரம்பில் உள்ள செல்கள் முழுவதும் HTTPS போக்குவரத்தின் சராசரி தாமதங்களை நாங்கள் சேகரித்தோம். இந்தியாவின் டெல்லியில் உள்ள இரண்டு பெரிய செல்லுலார் ஆபரேட்டர்களுக்கான தரவு சேகரிக்கப்பட்டது. நீங்கள் பார்க்க முடியும் என, செயல்திறன் செல் இருந்து செல் வேறுபடுகிறது. மேலும், ஒரு ஆபரேட்டரின் உற்பத்தித்திறன் இரண்டாவது உற்பத்தித்திறனிலிருந்து வேறுபடுகிறது. நெட்வொர்க் நுழைவு முறைகள், நேரம் மற்றும் இருப்பிடம், பயனர் இயக்கம், அத்துடன் நெட்வொர்க் உள்கட்டமைப்பு ஆகியவை கோபுர அடர்த்தி மற்றும் நெட்வொர்க் வகைகளின் விகிதத்தை (LTE, 3G, முதலியன) கணக்கில் எடுத்துக்கொள்வது போன்ற காரணிகளால் இது பாதிக்கப்படுகிறது.

படம் 2. 2 கிமீ ஆரத்தை உதாரணமாகப் பயன்படுத்துவதில் தாமதம். டெல்லி, இந்தியா.

மேலும், செல்லுலார் நெட்வொர்க்குகளின் செயல்திறன் காலப்போக்கில் மாறுபடும். படம் 3 வாரத்தின் நாளின் சராசரி தாமதத்தைக் காட்டுகிறது. ஒரே நாள் மற்றும் ஒரு மணி நேரத்திற்குள் சிறிய அளவில் வேறுபாடுகளைக் கண்டோம்.

படம் 3. வால் தாமதங்கள் நாட்களுக்கு இடையே கணிசமாக மாறுபடும், ஆனால் அதே ஆபரேட்டருக்கு.

மேலே உள்ள அனைத்தும் வயர்லெஸ் நெட்வொர்க்குகளில் TCP செயல்திறன் பயனற்றதாக இருக்கும். இருப்பினும், TCPக்கு மாற்றுகளைத் தேடும் முன், பின்வரும் புள்ளிகளில் துல்லியமான புரிதலை உருவாக்க விரும்பினோம்:

• எங்கள் பயன்பாடுகளில் உள்ள தாமதங்களுக்குப் பின்னால் TCP முக்கிய குற்றவாளியா?
• நவீன நெட்வொர்க்குகள் குறிப்பிடத்தக்க மற்றும் மாறுபட்ட சுற்று பயண தாமதங்கள் (RTT) உள்ளதா?
• TCP செயல்திறனில் RTT மற்றும் இழப்பின் தாக்கம் என்ன?

TCP செயல்திறன் பகுப்பாய்வு

TCP செயல்திறனை எவ்வாறு பகுப்பாய்வு செய்தோம் என்பதைப் புரிந்து கொள்ள, அனுப்புநரிடமிருந்து பெறுநருக்கு TCP எவ்வாறு தரவை மாற்றுகிறது என்பதை விரைவாகப் பார்ப்போம். முதலில், அனுப்புநர் ஒரு TCP இணைப்பை நிறுவி, மூன்று வழிகளைச் செய்கிறார் கைகுலுக்கல்: அனுப்புபவர் ஒரு SYN பாக்கெட்டை அனுப்புகிறார், பெறுநரிடமிருந்து SYN-ACK பாக்கெட்டுக்காகக் காத்திருக்கிறார், பின்னர் ACK பாக்கெட்டை அனுப்புகிறார். TCP இணைப்பை நிறுவ கூடுதல் இரண்டாவது மற்றும் மூன்றாவது பாஸ் செலவிடப்படுகிறது. நம்பகமான டெலிவரியை உறுதிசெய்ய, பெறுநர் ஒவ்வொரு பாக்கெட்டின் (ACK) ரசீதை ஒப்புக்கொள்கிறார்.

ஒரு பாக்கெட் அல்லது ACK தொலைந்துவிட்டால், அனுப்பியவர் நேரம் முடிந்த பிறகு மீண்டும் அனுப்புகிறார் (RTO, மறு பரிமாற்ற நேரம் முடிந்தது) அனுப்புநருக்கும் பெறுநருக்கும் இடையே எதிர்பார்க்கப்படும் RTT தாமதம் போன்ற பல்வேறு காரணிகளின் அடிப்படையில் RTO மாறும் வகையில் கணக்கிடப்படுகிறது.

படம் 4. TCP/TLS மூலம் பாக்கெட் பரிமாற்றம் ஒரு மறுபரிமாற்ற பொறிமுறையை உள்ளடக்கியது.

எங்கள் பயன்பாடுகளில் TCP எவ்வாறு செயல்படுகிறது என்பதைத் தீர்மானிக்க, TCP பாக்கெட்டுகளைப் பயன்படுத்தி கண்காணித்தோம் tcpdump இந்திய எட்ஜ் சர்வர்களில் இருந்து வரும் போர் டிராஃபிக்கில் ஒரு வாரத்திற்கு. TCP இணைப்புகளைப் பயன்படுத்தி பகுப்பாய்வு செய்தோம் tcptrace. கூடுதலாக, ஒரு ஆண்ட்ராய்டு செயலியை உருவாக்கியுள்ளோம், இது ஒரு சோதனை சேவையகத்திற்கு எமுலேட்டட் டிராஃபிக்கை அனுப்புகிறது, முடிந்தவரை உண்மையான டிராஃபிக்கைப் பின்பற்றுகிறது. இந்த பயன்பாட்டுடன் கூடிய ஸ்மார்ட்போன்கள் பல ஊழியர்களுக்கு விநியோகிக்கப்பட்டன, அவர்கள் பல நாட்களில் பதிவுகளை சேகரித்தனர்.

இரண்டு சோதனைகளின் முடிவுகளும் ஒன்றோடொன்று ஒத்துப்போனது. உயர் RTT தாமதங்களைக் கண்டோம்; வால் மதிப்புகள் சராசரி மதிப்பை விட கிட்டத்தட்ட 6 மடங்கு அதிகமாக இருந்தன; தாமதங்களின் எண்கணித சராசரி 1 வினாடிக்கும் அதிகமாக உள்ளது. பல இணைப்புகள் இழந்தன, இதனால் TCP அனைத்து பாக்கெட்டுகளிலும் 3,5% மீண்டும் அனுப்பப்பட்டது. விமான நிலையங்கள் மற்றும் ரயில் நிலையங்கள் போன்ற நெரிசலான பகுதிகளில், 7% இழப்புகளைக் கண்டோம். இந்த முடிவுகள் செல்லுலார் நெட்வொர்க்குகளில் பயன்படுத்தப்படும் வழக்கமான ஞானத்தின் மீது சந்தேகத்தை ஏற்படுத்துகின்றன மேம்பட்ட மறுபரிமாற்ற சுற்றுகள் போக்குவரத்து மட்டத்தில் இழப்புகளை கணிசமாகக் குறைக்கிறது. "சிமுலேட்டர்" பயன்பாட்டிலிருந்து சோதனை முடிவுகள் கீழே உள்ளன:

நெட்வொர்க் அளவீடுகள்
அதாவது

RTT, மில்லி விநாடிகள் [50%,75%, 95%,99%]
[350, 425, 725, 2300]

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 பாக்கெட் இழப்பு புள்ளிவிவரங்கள்
மதிப்பு

குறைந்தபட்சம் 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 ஆகும், இது இப்போது தீவிரமாக தரப்படுத்தப்படுகிறது). இது HTTPS மற்றும் TCP அடுக்குகளை பாதியாக மாற்றியமைக்கிறது, UDP ஐப் பயன்படுத்தி பாக்கெட்டுகளை உருவாக்குகிறது. TLS முழுமையாக QUIC இல் கட்டமைக்கப்பட்டுள்ளதால் 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 செயலாக்கங்கள் அல்காரிதத்தைப் பயன்படுத்துகின்றன கியூபிக், இது தாமதம் உணர்திறன் போக்குவரத்திற்கு உகந்ததல்ல. போன்ற சமீபத்தில் உருவாக்கப்பட்ட அல்காரிதம்கள் BBR, மிகவும் துல்லியமாக நெட்வொர்க்கை மாதிரியாக்கி, தாமதத்தை மேம்படுத்தவும். QUIC ஆனது BBR ஐப் பயன்படுத்தவும், இந்த அல்காரிதத்தைப் பயன்படுத்தும்போது புதுப்பிக்கவும் அனுமதிக்கிறது. முன்னேற்றம்.
• இழப்புகளை நிரப்புதல். QUIC இரண்டு TLPகளை அழைக்கிறது (வால் இழப்பு ஆய்வு) RTO தூண்டப்படுவதற்கு முன் - இழப்புகள் மிகவும் கவனிக்கத்தக்கதாக இருந்தாலும் கூட. இது TCP செயலாக்கங்களிலிருந்து வேறுபட்டது. TLP முக்கியமாக கடைசி பாக்கெட்டை (அல்லது புதியது, இருந்தால்) வேகமாக நிரப்புவதைத் தூண்டும். வால் தாமதங்களைக் கையாள்வது, Uber அதன் நெட்வொர்க்கைச் செயல்படுத்தும் விதத்திற்கு, அதாவது குறுகிய, அவ்வப்போது மற்றும் தாமதம்-உணர்திறன் தரவு பரிமாற்றங்களுக்கு மிகவும் பயனுள்ளதாக இருக்கும்.
• உகந்த ACK. ஒவ்வொரு பாக்கெட்டிற்கும் தனித்தனி வரிசை எண் இருப்பதால், எந்த பிரச்சனையும் இல்லை வேறுபாடுகள் பாக்கெட்டுகள் மீண்டும் அனுப்பப்படும் போது. ACK பாக்கெட்டுகள் பாக்கெட்டைச் செயலாக்குவதற்கும் கிளையன்ட் பக்கத்தில் ACK ஐ உருவாக்குவதற்கும் நேரத்தைக் கொண்டிருக்கும். இந்த அம்சங்கள் QUIC RTT ஐ மிகவும் துல்லியமாக கணக்கிடுவதை உறுதி செய்கிறது. QUIC இல் ACK 256 பேண்டுகள் வரை ஆதரிக்கிறது நாக், அனுப்புநருக்கு பாக்கெட் ஷஃபிளிங்கில் அதிக மீள்தன்மையுடன் இருக்க உதவுகிறது மற்றும் செயல்பாட்டில் குறைவான பைட்டுகளைப் பயன்படுத்துகிறது. தேர்ந்தெடுக்கப்பட்ட ACK (கோணி) TCP இல் உள்ள அனைத்து நிகழ்வுகளிலும் இந்த சிக்கலை தீர்க்க முடியாது.
• இணைப்பு இடம்பெயர்வு. QUIC இணைப்புகள் 64-பிட் ஐடி மூலம் அடையாளம் காணப்படுகின்றன, எனவே கிளையன்ட் ஐபி முகவரிகளை மாற்றினால், பழைய இணைப்பு ஐடி புதிய ஐபி முகவரியில் தடையின்றி தொடர்ந்து பயன்படுத்தப்படலாம். பயனர் Wi-Fi மற்றும் செல்லுலார் இணைப்புகளுக்கு இடையில் மாறும்போது மொபைல் பயன்பாடுகளுக்கு இது மிகவும் பொதுவான நடைமுறையாகும்.

QUICக்கான மாற்றுகள்

QUIC ஐத் தேர்ந்தெடுப்பதற்கு முன், சிக்கலைத் தீர்ப்பதற்கான மாற்று அணுகுமுறைகளைக் கருத்தில் கொண்டோம்.

பயனர்களுக்கு நெருக்கமான TCP இணைப்புகளை நிறுத்துவதற்கு TPC PoPs (Points of Presence) வரிசைப்படுத்த முயற்சித்தோம். முக்கியமாக, செல்லுலார் நெட்வொர்க்கிற்கு நெருக்கமான மொபைல் சாதனத்துடன் TCP இணைப்பை PoP கள் நிறுத்துகின்றன மற்றும் ட்ராஃபிக்கை அசல் உள்கட்டமைப்புக்குத் திரும்பப் பெறுகின்றன. TCP ஐ நெருக்கமாக நிறுத்துவதன் மூலம், RTT ஐக் குறைக்கலாம் மற்றும் TCP ஆனது டைனமிக் வயர்லெஸ் சூழலுக்கு மிகவும் பதிலளிக்கக்கூடியதாக இருப்பதை உறுதிசெய்யலாம். எவ்வாறாயினும், பெரும்பாலான RTT மற்றும் இழப்பு செல்லுலார் நெட்வொர்க்குகளிலிருந்து வருகிறது என்பதையும் PoP களின் பயன்பாடு குறிப்பிடத்தக்க செயல்திறன் மேம்பாட்டை வழங்கவில்லை என்பதையும் எங்கள் சோதனைகள் காட்டுகின்றன.

TCP அளவுருக்களை சரிசெய்வதையும் பார்த்தோம். எங்கள் பன்முகத்தன்மை வாய்ந்த எட்ஜ் சர்வர்களில் TCP அடுக்கை அமைப்பது கடினமாக இருந்தது, ஏனெனில் TCP ஆனது வெவ்வேறு OS பதிப்புகளில் வேறுபட்ட செயலாக்கங்களைக் கொண்டுள்ளது. இதை செயல்படுத்துவது மற்றும் வெவ்வேறு நெட்வொர்க் உள்ளமைவுகளை சோதிப்பது கடினமாக இருந்தது. அனுமதிகள் இல்லாததால் மொபைல் சாதனங்களில் TCP ஐ நேரடியாக உள்ளமைக்க முடியவில்லை. மிக முக்கியமாக, 0-RTT இணைப்புகள் மற்றும் மேம்படுத்தப்பட்ட RTT கணிப்பு போன்ற அம்சங்கள் நெறிமுறையின் கட்டமைப்பிற்கு முக்கியமானவை, எனவே TCP ஐ மட்டும் டியூன் செய்வதன் மூலம் குறிப்பிடத்தக்க பலன்களை அடைய முடியாது.

இறுதியாக, வீடியோ ஸ்ட்ரீமிங்கைச் சரிசெய்யும் பல UDP-அடிப்படையிலான நெறிமுறைகளை மதிப்பீடு செய்தோம்—இந்த நெறிமுறைகள் எங்கள் விஷயத்தில் உதவுமா என்பதைப் பார்க்க விரும்பினோம். துரதிர்ஷ்டவசமாக, பல பாதுகாப்பு அமைப்புகளில் அவை கடுமையாகக் குறைவாக இருந்தன, மேலும் மெட்டாடேட்டா மற்றும் கட்டுப்பாட்டுத் தகவலுக்கு கூடுதல் TCP இணைப்பு தேவைப்பட்டது.

பாதுகாப்பு மற்றும் செயல்திறன் ஆகிய இரண்டையும் கணக்கில் எடுத்துக்கொண்டு, இணையப் போக்குவரத்தின் சிக்கலுக்கு உதவக்கூடிய ஒரே நெறிமுறை QUIC மட்டுமே என்பதை எங்கள் ஆராய்ச்சி காட்டுகிறது.

மேடையில் QUIC இன் ஒருங்கிணைப்பு

QUIC ஐ வெற்றிகரமாக உட்பொதிக்கவும், மோசமான இணைப்பு சூழல்களில் பயன்பாட்டின் செயல்திறனை மேம்படுத்தவும், பழைய அடுக்கை (HTTP/2 over TLS/TCP) QUIC நெறிமுறையுடன் மாற்றியுள்ளோம். பிணைய நூலகத்தைப் பயன்படுத்தினோம் குரோனெட் из குரோமியம் திட்டங்கள், இது நெறிமுறையின் அசல், Google பதிப்பைக் கொண்டுள்ளது - gQUIC. சமீபத்திய IETF விவரக்குறிப்புகளைப் பின்பற்றுவதற்காக இந்தச் செயலாக்கமும் தொடர்ந்து மேம்படுத்தப்பட்டு வருகிறது.

QUICக்கான ஆதரவைச் சேர்க்க, முதலில் எங்கள் Android பயன்பாடுகளில் Cronet ஐ ஒருங்கிணைத்தோம். இடப்பெயர்வு செலவுகளை முடிந்தவரை குறைக்கும் வகையில் ஒருங்கிணைப்பு மேற்கொள்ளப்பட்டது. நூலகத்தைப் பயன்படுத்திய பழைய நெட்வொர்க்கிங் அடுக்கை முழுமையாக மாற்றுவதற்குப் பதிலாக OkHttp, OkHttp API கட்டமைப்பின் கீழ் க்ரோனெட்டை ஒருங்கிணைத்துள்ளோம். இந்த வழியில் ஒருங்கிணைப்பை செய்வதன் மூலம், எங்கள் நெட்வொர்க் அழைப்புகளில் மாற்றங்களைத் தவிர்த்துவிட்டோம் (அவை பயன்படுத்தப்படுகின்றன தாங்கவல்ல) API அளவில்.

Android சாதனங்களுக்கான அணுகுமுறையைப் போலவே, IOS இல் Uber பயன்பாடுகளில் Cronet ஐ செயல்படுத்தினோம், நெட்வொர்க்கில் இருந்து HTTP டிராஃபிக்கை இடைமறித்தோம் ஏபிஐபயன்படுத்தி NSURLProtocol. iOS அறக்கட்டளை வழங்கிய இந்த சுருக்கமானது, நெறிமுறை சார்ந்த URL தரவைக் கையாளுகிறது மற்றும் குறிப்பிடத்தக்க இடம்பெயர்வு செலவுகள் இல்லாமல் எங்கள் iOS பயன்பாடுகளில் Cronet ஐ ஒருங்கிணைக்க முடியும் என்பதை உறுதி செய்கிறது.

கூகுள் கிளவுட் பேலன்சர்களில் QUICஐ நிறைவு செய்கிறது

பின்தளத்தில், கூகுள் கிளவுட் லோட் பேலன்சிங் இன்ஃப்ராஸ்ட்ரக்சர் மூலம் QUIC நிறைவு வழங்கப்படுகிறது. alt-svc QUIC ஐ ஆதரிக்கும் பதில்களில் தலைப்புகள். பொதுவாக, பேலன்சர் ஒவ்வொரு HTTP கோரிக்கைக்கும் alt-svc தலைப்பைச் சேர்க்கிறது, மேலும் இது ஏற்கனவே டொமைனுக்கான QUIC ஆதரவைச் சரிபார்க்கிறது. ஒரு க்ரோனெட் கிளையண்ட் இந்த தலைப்புடன் HTTP பதிலைப் பெறும்போது, ​​அந்த டொமைனுக்கான HTTP கோரிக்கைகளுக்கு QUICஐப் பயன்படுத்துகிறது. பேலன்சர் QUICஐ முடித்தவுடன், எங்கள் உள்கட்டமைப்பு HTTP2/TCP மூலம் இந்தச் செயலை எங்கள் தரவு மையங்களுக்கு வெளிப்படையாக அனுப்புகிறது.

செயல்திறன்: முடிவுகள்

சிறந்த நெறிமுறைக்கான எங்கள் தேடலுக்கு வெளியீட்டு செயல்திறன் முக்கிய காரணம். தொடங்குவதற்கு, நாங்கள் ஒரு நிலைப்பாட்டை உருவாக்கினோம் பிணைய முன்மாதிரிவெவ்வேறு நெட்வொர்க் சுயவிவரங்களின் கீழ் QUIC எவ்வாறு செயல்படும் என்பதைக் கண்டறிய. நிஜ-உலக நெட்வொர்க்குகளில் QUIC இன் செயல்திறனைச் சோதிக்க, பயணிகள் பயன்பாட்டில் உள்ள HTTP அழைப்புகளைப் போலவே எமுலேட்டட் நெட்வொர்க் ட்ராஃபிக்கைப் பயன்படுத்தி புது டெல்லியைச் சுற்றி ஓட்டும்போது சோதனைகளை நடத்தினோம்.

பரிசோதனை 1

பரிசோதனைக்கான உபகரணங்கள்:

• OkHttp மற்றும் Cronet அடுக்குகளுடன் கூடிய Android சாதனங்களைச் சோதித்து, முறையே TCP மற்றும் QUIC வழியாக HTTPS போக்குவரத்தை அனுமதிக்கிறோம் என்பதை உறுதிப்படுத்தவும்;
• ஜாவா அடிப்படையிலான எமுலேஷன் சர்வர், அதே வகையான HTTPS தலைப்புகளை பதில்களில் அனுப்புகிறது மற்றும் வாடிக்கையாளர் சாதனங்களில் இருந்து கோரிக்கைகளைப் பெற ஏற்றுகிறது;
• TCP மற்றும் QUIC இணைப்புகளை நிறுத்துவதற்கு, இந்தியாவிற்கு அருகில் அமைந்துள்ள கிளவுட் ப்ராக்ஸிகள். TCP முடிவிற்கு நாங்கள் ரிவர்ஸ் ப்ராக்ஸியைப் பயன்படுத்தினோம் Nginx, QUICக்கான ஓப்பன் சோர்ஸ் ரிவர்ஸ் ப்ராக்ஸியைக் கண்டறிவது கடினமாக இருந்தது. Chromium மற்றும் அடிப்படை QUIC ஸ்டேக்கைப் பயன்படுத்தி, QUICக்கான ரிவர்ஸ் ப்ராக்ஸியை நாமே உருவாக்கினோம் வெளியிடப்பட்ட திறந்த மூலமாக குரோமியத்தில்.

படம்.

பரிசோதனை 2

கூகிள் 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 எம்எஸ் அதிக தாமதம்) இருந்தபோதிலும், இது இதேபோன்ற செயல்திறனை வழங்கியது - TCPக்கான 15வது சதவிகிதத்தில் 20% குறைப்பு மற்றும் தாமதத்தில் 99% குறைப்பு. கடைசி மைல் மாற்றம் நெட்வொர்க்கில் ஒரு இடையூறு என்று இது அறிவுறுத்துகிறது.

படம் 8: இரண்டு சோதனைகளின் முடிவுகள், QUIC கணிசமாக TCP ஐ விஞ்சுகிறது என்பதைக் காட்டுகிறது.

போக்குவரத்தை எதிர்த்துப் போராடுங்கள்

பரிசோதனையால் ஈர்க்கப்பட்டு, எங்கள் Android மற்றும் iOS பயன்பாடுகளில் QUIC ஆதரவைச் செயல்படுத்தியுள்ளோம். Uber செயல்படும் நகரங்களில் QUIC இன் தாக்கத்தை அறிய, A/B சோதனையை நடத்தினோம். பொதுவாக, டெலிகாம் ஆபரேட்டர்கள் மற்றும் நெட்வொர்க் வகை ஆகிய இரு பிராந்தியங்களிலும் டெயில் தாமதங்களில் குறிப்பிடத்தக்க குறைப்பைக் கண்டோம்.

கீழேயுள்ள வரைபடங்கள், மேக்ரோ-பிராந்தியத்தின்படி (95 மற்றும் 99 சதவிகிதங்கள்) சதவீத மேம்பாடுகளைக் காட்டுகின்றன மற்றும் வெவ்வேறு நெட்வொர்க் வகைகளான - LTE, 3G, 2G.

படம் 9. போர்ச் சோதனைகளில், தாமதத்தின் அடிப்படையில் QUIC TCP ஐ விஞ்சியது.

முன்னோக்கி மட்டுமே

ஒருவேளை இது ஆரம்பம் மட்டுமே - உற்பத்தியில் QUIC இன் வெளியீடு நிலையான மற்றும் நிலையற்ற நெட்வொர்க்குகளில் பயன்பாட்டு செயல்திறனை மேம்படுத்த அற்புதமான வாய்ப்புகளை வழங்கியுள்ளது, அதாவது:

அதிகரித்த கவரேஜ்

உண்மையான போக்குவரத்தில் நெறிமுறையின் செயல்திறனைப் பகுப்பாய்வு செய்த பிறகு, ஏறக்குறைய 80% அமர்வுகள் வெற்றிகரமாக QUIC ஐப் பயன்படுத்துவதைக் கண்டோம். всех கோரிக்கைகள், 15% அமர்வுகள் QUIC மற்றும் TCP ஆகியவற்றின் கலவையைப் பயன்படுத்துகின்றன. உண்மையான UDP தோல்விகள் மற்றும் மோசமான நெட்வொர்க் நிலைமைகளை வேறுபடுத்திப் பார்க்க முடியாததால், க்ரோனெட் லைப்ரரி TCP க்கு திரும்பியதால் இந்த சேர்க்கை ஏற்பட்டது என்று கருதுகிறோம். QUIC-ஐத் தொடர்ந்து செயல்படுத்துவதில் நாங்கள் வேலை செய்வதால், இந்தச் சிக்கலுக்கான தீர்வை நாங்கள் தற்போது பார்த்து வருகிறோம்.

QUIC தேர்வுமுறை

மொபைல் பயன்பாடுகளின் ட்ராஃபிக் தாமதத்தை உணரக்கூடியது, ஆனால் அலைவரிசை உணர்திறன் அல்ல. மேலும், எங்கள் பயன்பாடுகள் முதன்மையாக செல்லுலார் நெட்வொர்க்குகளில் பயன்படுத்தப்படுகின்றன. சோதனைகளின் அடிப்படையில், பயனர்களுக்கு நெருக்கமான TCP மற்றும் QUIC ஐ நிறுத்துவதற்கு ப்ராக்ஸியைப் பயன்படுத்தினாலும், வால் தாமதங்கள் இன்னும் அதிகமாகவே உள்ளன. நெரிசல் மேலாண்மை மற்றும் QUIC இழப்பு மீட்பு வழிமுறைகளின் செயல்திறனை மேம்படுத்துவதற்கான வழிகளை நாங்கள் தீவிரமாகத் தேடுகிறோம்.

இவை மற்றும் பல மேம்பாடுகள் மூலம், நெட்வொர்க் மற்றும் பிராந்தியத்தைப் பொருட்படுத்தாமல் பயனர் அனுபவத்தை மேம்படுத்த நாங்கள் திட்டமிட்டுள்ளோம், இதனால் உலகம் முழுவதும் வசதியான மற்றும் தடையற்ற பாக்கெட் போக்குவரத்தை அணுக முடியும்.

ஆதாரம்: www.habr.com