QUIC പ്രോട്ടോക്കോൾ പ്രവർത്തനത്തിലാണ്: പ്രകടനം ഒപ്റ്റിമൈസ് ചെയ്യാൻ Uber എങ്ങനെയാണ് ഇത് നടപ്പിലാക്കിയത്

QUIC പ്രോട്ടോക്കോൾ കാണാൻ വളരെ രസകരമാണ്, അതിനാലാണ് ഞങ്ങൾ അതിനെ കുറിച്ച് എഴുതാൻ ഇഷ്ടപ്പെടുന്നത്. എന്നാൽ ക്യുഐസിയെക്കുറിച്ചുള്ള മുൻ പ്രസിദ്ധീകരണങ്ങൾ ചരിത്രപരമായ (പ്രാദേശിക ചരിത്രം, നിങ്ങൾ ഇഷ്ടപ്പെടുന്നെങ്കിൽ) സ്വഭാവവും ഹാർഡ്‌വെയറും ആയിരുന്നെങ്കിൽ, ഇന്ന് മറ്റൊരു തരത്തിലുള്ള വിവർത്തനം പ്രസിദ്ധീകരിക്കുന്നതിൽ ഞങ്ങൾക്ക് സന്തോഷമുണ്ട് - 2019 ൽ പ്രോട്ടോക്കോളിൻ്റെ യഥാർത്ഥ പ്രയോഗത്തെക്കുറിച്ച് ഞങ്ങൾ സംസാരിക്കും. മാത്രമല്ല, ഞങ്ങൾ സംസാരിക്കുന്നത് ഗാരേജ് എന്ന് വിളിക്കപ്പെടുന്ന ചെറിയ ഇൻഫ്രാസ്ട്രക്ചറിനെക്കുറിച്ചല്ല, മറിച്ച് ലോകമെമ്പാടും പ്രവർത്തിക്കുന്ന Uber നെക്കുറിച്ചാണ്. ഉൽപ്പാദനത്തിൽ ക്യുഐസി ഉപയോഗിക്കാനുള്ള തീരുമാനത്തിൽ കമ്പനിയുടെ എഞ്ചിനീയർമാർ എങ്ങനെയാണ് എത്തിയത്, അവർ എങ്ങനെയാണ് പരിശോധനകൾ നടത്തിയത്, ഉൽപ്പാദനത്തിൽ ഇറക്കിയ ശേഷം അവർ കണ്ടത് - കട്ടിന് താഴെ.

ചിത്രങ്ങൾ ക്ലിക്ക് ചെയ്യാവുന്നവയാണ്. വായന ആസ്വദിക്കൂ!

Uber-ന് ആഗോള തലത്തിൽ ഉണ്ട്, അതായത് 600 സാന്നിധ്യമുള്ള നഗരങ്ങൾ, അവയിൽ ഓരോന്നിലും 4500-ലധികം സെല്ലുലാർ ഓപ്പറേറ്റർമാരിൽ നിന്നുള്ള വയർലെസ് ഇൻ്റർനെറ്റിനെ പൂർണ്ണമായും ആശ്രയിക്കുന്നു. ഉപയോക്താക്കൾ ആപ്പ് വേഗമേറിയതായിരിക്കില്ല, തത്സമയം ആയിരിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു - ഇത് നേടുന്നതിന്, Uber ആപ്പിന് കുറഞ്ഞ ലേറ്റൻസിയും വളരെ വിശ്വസനീയമായ കണക്ഷനും ആവശ്യമാണ്. അയ്യോ, പക്ഷേ സ്റ്റാക്ക് HTTP / 2 ചലനാത്മകവും നഷ്ടസാധ്യതയുള്ളതുമായ വയർലെസ് നെറ്റ്‌വർക്കുകളിൽ നന്നായി പ്രവർത്തിക്കുന്നില്ല. ഈ സാഹചര്യത്തിൽ, കുറഞ്ഞ പ്രകടനം ഓപ്പറേറ്റിംഗ് സിസ്റ്റം കേർണലുകളിലെ ടിസിപി നടപ്പിലാക്കലുകളുമായി നേരിട്ട് ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി.

പ്രശ്നം പരിഹരിക്കാൻ, ഞങ്ങൾ അപേക്ഷിച്ചു QUIC, ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോളിൻ്റെ പ്രകടനത്തിൽ ഞങ്ങൾക്ക് കൂടുതൽ നിയന്ത്രണം നൽകുന്ന ഒരു ആധുനിക ചാനൽ മൾട്ടിപ്ലക്സിംഗ് പ്രോട്ടോക്കോൾ. നിലവിൽ വർക്കിംഗ് ഗ്രൂപ്പ് ഐഇടിഎഫ് QUIC ആയി സ്റ്റാൻഡേർഡ് ചെയ്യുന്നു HTTP / 3.

വിപുലമായ പരിശോധനയ്ക്ക് ശേഷം, ഞങ്ങളുടെ ആപ്ലിക്കേഷനിൽ QUIC നടപ്പിലാക്കുന്നത് TCP-യുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ കുറഞ്ഞ ടെയിൽ ലേറ്റൻസികൾക്ക് കാരണമാകുമെന്ന് ഞങ്ങൾ നിഗമനം ചെയ്തു. ഡ്രൈവർ, പാസഞ്ചർ ആപ്ലിക്കേഷനുകളിൽ HTTPS ട്രാഫിക്കിന് 10-30% പരിധിയിൽ കുറവ് ഞങ്ങൾ നിരീക്ഷിച്ചു. ഉപയോക്തൃ പാക്കേജുകളിൽ ക്യുഐസി ഞങ്ങൾക്ക് എൻഡ്-ടു-എൻഡ് നിയന്ത്രണവും നൽകി.

ഈ ലേഖനത്തിൽ, QUIC-യെ പിന്തുണയ്ക്കുന്ന ഒരു സ്റ്റാക്ക് ഉപയോഗിച്ച് Uber ആപ്ലിക്കേഷനുകൾക്കായി TCP ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിനുള്ള ഞങ്ങളുടെ അനുഭവം ഞങ്ങൾ പങ്കിടുന്നു.

ഏറ്റവും പുതിയ സാങ്കേതികവിദ്യ: ടിസിപി

ഇന്ന്, ഇൻ്റർനെറ്റിൽ HTTPS ട്രാഫിക് നൽകുന്നതിന് ഏറ്റവും കൂടുതൽ ഉപയോഗിക്കുന്ന ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ TCP ആണ്. TCP ബൈറ്റുകളുടെ ഒരു വിശ്വസനീയമായ സ്ട്രീം നൽകുന്നു, അതുവഴി നെറ്റ്‌വർക്ക് തിരക്കും ലിങ്ക് ലെയർ നഷ്ടവും നേരിടാൻ. എച്ച്‌ടിടിപിഎസ് ട്രാഫിക്കിനായി ടിസിപിയുടെ വ്യാപകമായ ഉപയോഗത്തിന് കാരണം മുൻകാലത്തിൻ്റെ സർവ്വവ്യാപിത്വം (ഏതാണ്ട് എല്ലാ ഒഎസിലും ടിസിപി അടങ്ങിയിരിക്കുന്നു), മിക്ക ഇൻഫ്രാസ്ട്രക്ചറുകളിലെയും ലഭ്യത (ലോഡ് ബാലൻസറുകൾ, എച്ച്ടിടിപിഎസ് പ്രോക്സികൾ, സിഡിഎൻ എന്നിവ പോലുള്ളവ), ഔട്ട്-ഓഫ്-ദി-ബോക്‌സ് പ്രവർത്തനക്ഷമത എന്നിവയാണ്. മിക്കവാറും മിക്ക പ്ലാറ്റ്‌ഫോമുകളിലും നെറ്റ്‌വർക്കുകളിലും.

മിക്ക ഉപയോക്താക്കളും എവിടെയായിരുന്നാലും ഞങ്ങളുടെ ആപ്പ് ഉപയോഗിക്കുന്നു, കൂടാതെ TCP ടെയിൽ ലേറ്റൻസികൾ ഞങ്ങളുടെ തത്സമയ HTTPS ട്രാഫിക്കിൻ്റെ ആവശ്യത്തിന് അടുത്തെങ്ങും ഉണ്ടായിരുന്നില്ല. ലളിതമായി പറഞ്ഞാൽ, ലോകമെമ്പാടുമുള്ള ഉപയോക്താക്കൾ ഇത് അനുഭവിച്ചിട്ടുണ്ട് - പ്രധാന നഗരങ്ങളിലെ കാലതാമസം ചിത്രം 1 കാണിക്കുന്നു:

ചിത്രം 1: Uber-ൻ്റെ പ്രധാന നഗരങ്ങളിൽ ഉടനീളം ടെയിൽ ലേറ്റൻസി വ്യത്യാസപ്പെടുന്നു.

ഇന്ത്യൻ, ബ്രസീലിയൻ നെറ്റ്‌വർക്കുകളിലെ ലേറ്റൻസി യുഎസിലും യുകെയിലും ഉള്ളതിനേക്കാൾ കൂടുതലാണെങ്കിലും, ടെയിൽ ലേറ്റൻസി ശരാശരി ലേറ്റൻസിയേക്കാൾ വളരെ കൂടുതലാണ്. യുഎസിലും യുകെയിലും പോലും ഇത് സത്യമാണ്.

എയർ പ്രകടനത്തെക്കുറിച്ചുള്ള ടി.സി.പി

ഇതിനായി ടിസിപി സൃഷ്ടിച്ചു വയർഡ് നെറ്റ്‌വർക്കുകൾ, അതായത്, വളരെ പ്രവചിക്കാവുന്ന ലിങ്കുകൾക്ക് ഊന്നൽ നൽകുന്നു. എന്നിരുന്നാലും, വയർലെസ് നെറ്റ്‌വർക്കുകൾക്ക് അതിൻ്റേതായ സവിശേഷതകളും ബുദ്ധിമുട്ടുകളും ഉണ്ട്. ഒന്നാമതായി, വയർലെസ് നെറ്റ്‌വർക്കുകൾ ഇടപെടലും സിഗ്നൽ അറ്റന്യൂവേഷനും കാരണം നഷ്ടത്തിന് വിധേയമാണ്. ഉദാഹരണത്തിന്, വൈഫൈ നെറ്റ്‌വർക്കുകൾ മൈക്രോവേവ്, ബ്ലൂടൂത്ത്, മറ്റ് റേഡിയോ തരംഗങ്ങൾ എന്നിവയോട് സെൻസിറ്റീവ് ആണ്. സെല്ലുലാർ നെറ്റ്‌വർക്കുകൾ സിഗ്നൽ നഷ്ടം നേരിടുന്നു (വഴി നഷ്ടപ്പെട്ടു) വസ്തുക്കളും കെട്ടിടങ്ങളും സിഗ്നലിൻ്റെ പ്രതിഫലനം / ആഗിരണം കാരണം, അതുപോലെ നിന്ന് ഇടപെടൽ അയൽക്കാരിൽ നിന്ന് സെൽ ടവറുകൾ. ഇത് കൂടുതൽ പ്രാധാന്യമർഹിക്കുന്നതിലേക്കും (4-10 തവണ) കൂടുതൽ വൈവിധ്യത്തിലേക്കും നയിക്കുന്നു മടക്കയാത്ര വൈകൽ (RTT) വയർഡ് കണക്ഷനുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ പാക്കറ്റ് നഷ്ടവും.

ബാൻഡ്‌വിഡ്ത്ത് ഏറ്റക്കുറച്ചിലുകളും നഷ്ടങ്ങളും നേരിടാൻ, സെല്ലുലാർ നെറ്റ്‌വർക്കുകൾ സാധാരണയായി ട്രാഫിക് പൊട്ടിത്തെറിക്ക് വലിയ ബഫറുകൾ ഉപയോഗിക്കുന്നു. ഇത് അമിതമായ ക്യൂവിന് കാരണമാകും, അതായത് കൂടുതൽ കാലതാമസം. മിക്കപ്പോഴും ടിസിപി ഈ ക്യൂയിംഗിനെ വിപുലീകൃതമായ സമയപരിധി കാരണം ഒരു പാഴായതായി കണക്കാക്കുന്നു, അതിനാൽ ടിസിപി റിലേ ചെയ്യാനും അതുവഴി ബഫർ നിറയ്ക്കാനും പ്രവണത കാണിക്കുന്നു. ഈ പ്രശ്നം അറിയപ്പെടുന്നത് ബഫർബ്ലോട്ട് (അമിതമായ നെറ്റ്‌വർക്ക് ബഫറിംഗ്, ബഫർ ബ്ലോട്ട്), ഇത് വളരെ ആണ് ഗുരുതരമായ പ്രശ്നം ആധുനിക ഇൻ്റർനെറ്റ്.

അവസാനമായി, സെല്ലുലാർ നെറ്റ്‌വർക്ക് പ്രകടനം കാരിയർ, പ്രദേശം, സമയം എന്നിവ അനുസരിച്ച് വ്യത്യാസപ്പെടുന്നു. ചിത്രം 2-ൽ, 2-കിലോമീറ്റർ പരിധിക്കുള്ളിലെ സെല്ലുകളിലുടനീളം HTTPS ട്രാഫിക്കിൻ്റെ ശരാശരി കാലതാമസം ഞങ്ങൾ ശേഖരിച്ചു. ഇന്ത്യയിലെ ഡൽഹിയിലെ രണ്ട് പ്രധാന സെല്ലുലാർ ഓപ്പറേറ്റർമാർക്കായി ശേഖരിച്ച ഡാറ്റ. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, പ്രകടനം സെല്ലിൽ നിന്ന് സെല്ലിലേക്ക് വ്യത്യാസപ്പെടുന്നു. കൂടാതെ, ഒരു ഓപ്പറേറ്ററുടെ ഉൽപ്പാദനക്ഷമത രണ്ടാമത്തേതിൻ്റെ ഉൽപ്പാദനക്ഷമതയിൽ നിന്ന് വ്യത്യസ്തമാണ്. നെറ്റ്‌വർക്ക് എൻട്രി പാറ്റേണുകൾ, സമയവും സ്ഥലവും, ഉപയോക്തൃ മൊബിലിറ്റി, ടവർ സാന്ദ്രത, നെറ്റ്‌വർക്ക് തരങ്ങളുടെ അനുപാതം (LTE, 3G, മുതലായവ) കണക്കിലെടുത്ത് നെറ്റ്‌വർക്ക് ഇൻഫ്രാസ്ട്രക്ചർ എന്നിവ പോലുള്ള ഘടകങ്ങളാൽ ഇത് സ്വാധീനിക്കപ്പെടുന്നു.

ചിത്രം 2. ഉദാഹരണമായി 2 കിലോമീറ്റർ ചുറ്റളവ് ഉപയോഗിക്കുന്ന കാലതാമസം. ഡൽഹി, ഇന്ത്യ.

കൂടാതെ, സെല്ലുലാർ നെറ്റ്‌വർക്കുകളുടെ പ്രകടനം കാലക്രമേണ വ്യത്യാസപ്പെടുന്നു. ചിത്രം 3 ആഴ്ചയിലെ ദിവസങ്ങളിലെ ശരാശരി ലേറ്റൻസി കാണിക്കുന്നു. ഒരു ദിവസത്തിലും മണിക്കൂറിലും ഞങ്ങൾ ചെറിയ തോതിലുള്ള വ്യത്യാസങ്ങളും നിരീക്ഷിച്ചു.

ചിത്രം 3. ടെയിൽ കാലതാമസം ദിവസങ്ങൾക്കിടയിൽ കാര്യമായി വ്യത്യാസപ്പെട്ടേക്കാം, എന്നാൽ അതേ ഓപ്പറേറ്റർക്ക്.

മുകളിൽ പറഞ്ഞവയെല്ലാം വയർലെസ് നെറ്റ്‌വർക്കുകളിൽ TCP പ്രകടനം ഫലപ്രദമല്ലാതാക്കുന്നു. എന്നിരുന്നാലും, ടിസിപിക്ക് ബദലുകൾ തിരയുന്നതിന് മുമ്പ്, ഇനിപ്പറയുന്ന പോയിൻ്റുകളിൽ കൃത്യമായ ധാരണ വികസിപ്പിക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു:

• ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകളിലെ ടെയിൽ ലാറ്റൻസിക്ക് പിന്നിലെ പ്രധാന കുറ്റവാളി TCP ആണോ?
• ആധുനിക നെറ്റ്‌വർക്കുകൾക്ക് കാര്യമായതും വ്യത്യസ്തവുമായ റൗണ്ട് ട്രിപ്പ് കാലതാമസം (RTT) ഉണ്ടോ?
• ടിസിപി പ്രകടനത്തിൽ ആർടിടിയുടെയും നഷ്ടത്തിൻ്റെയും സ്വാധീനം എന്താണ്?

TCP പ്രകടന വിശകലനം

TCP പ്രകടനം ഞങ്ങൾ എങ്ങനെയാണ് വിശകലനം ചെയ്തതെന്ന് മനസിലാക്കാൻ, TCP എങ്ങനെയാണ് ഒരു അയച്ചയാളിൽ നിന്ന് ഒരു റിസീവറിലേക്ക് ഡാറ്റ കൈമാറുന്നത് എന്ന് നമുക്ക് നോക്കാം. ആദ്യം, അയച്ചയാൾ ഒരു ടിസിപി കണക്ഷൻ സ്ഥാപിക്കുന്നു, ഒരു ത്രീ-വേ നടത്തുന്നു ഹസ്തദാനം: അയച്ചയാൾ ഒരു SYN പാക്കറ്റ് അയയ്ക്കുന്നു, റിസീവറിൽ നിന്ന് ഒരു SYN-ACK പാക്കറ്റിനായി കാത്തിരിക്കുന്നു, തുടർന്ന് ഒരു ACK പാക്കറ്റ് അയയ്ക്കുന്നു. TCP കണക്ഷൻ സ്ഥാപിക്കുന്നതിന് ഒരു അധിക രണ്ടാമത്തെയും മൂന്നാമത്തെയും പാസ് ചെലവഴിക്കുന്നു. വിശ്വസനീയമായ ഡെലിവറി ഉറപ്പാക്കാൻ ഓരോ പാക്കറ്റിൻ്റെയും (ACK) രസീത് സ്വീകർത്താവ് അംഗീകരിക്കുന്നു.

ഒരു പാക്കറ്റോ ACKയോ നഷ്‌ടപ്പെട്ടാൽ, ഒരു സമയപരിധിക്ക് ശേഷം അയച്ചയാൾ വീണ്ടും സംപ്രേക്ഷണം ചെയ്യുന്നു (RTO, പുനഃസംപ്രേക്ഷണം കാലഹരണപ്പെട്ടു). അയയ്ക്കുന്നയാളും സ്വീകർത്താവും തമ്മിലുള്ള പ്രതീക്ഷിക്കുന്ന RTT കാലതാമസം പോലുള്ള വിവിധ ഘടകങ്ങളെ അടിസ്ഥാനമാക്കി ചലനാത്മകമായി RTO കണക്കാക്കുന്നു.

ചിത്രം 4. TCP/TLS വഴിയുള്ള പാക്കറ്റ് എക്സ്ചേഞ്ചിൽ ഒരു റീട്രാൻസ്മിഷൻ മെക്കാനിസം ഉൾപ്പെടുന്നു.

ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകളിൽ TCP എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നിർണ്ണയിക്കാൻ, ഞങ്ങൾ TCP പാക്കറ്റുകൾ ഉപയോഗിച്ച് നിരീക്ഷിച്ചു tcpdump ഇന്ത്യൻ എഡ്ജ് സെർവറുകളിൽ നിന്ന് വരുന്ന കോംബാറ്റ് ട്രാഫിക്കിൽ ഒരാഴ്ചത്തേക്ക്. തുടർന്ന് ഞങ്ങൾ TCP കണക്ഷനുകൾ ഉപയോഗിച്ച് വിശകലനം ചെയ്തു tcptrace. കൂടാതെ, ഞങ്ങൾ ഒരു ആൻഡ്രോയിഡ് ആപ്ലിക്കേഷൻ സൃഷ്ടിച്ചു, അത് ഒരു ടെസ്റ്റ് സെർവറിലേക്ക് എമുലേറ്റഡ് ട്രാഫിക് അയയ്‌ക്കുന്നു, യഥാർത്ഥ ട്രാഫിക്കിനെ കഴിയുന്നത്ര അനുകരിക്കുന്നു. ഈ ആപ്ലിക്കേഷനുള്ള സ്മാർട്ട്‌ഫോണുകൾ നിരവധി ജീവനക്കാർക്ക് വിതരണം ചെയ്തു, അവർ നിരവധി ദിവസങ്ങളിൽ ലോഗുകൾ ശേഖരിച്ചു.

രണ്ട് പരീക്ഷണങ്ങളുടെയും ഫലങ്ങൾ പരസ്പരം പൊരുത്തപ്പെടുന്നവയായിരുന്നു. ഉയർന്ന RTT ലേറ്റൻസികൾ ഞങ്ങൾ കണ്ടു; വാൽ മൂല്യങ്ങൾ ശരാശരി മൂല്യത്തേക്കാൾ ഏകദേശം 6 മടങ്ങ് കൂടുതലാണ്; കാലതാമസത്തിൻ്റെ ഗണിത ശരാശരി 1 സെക്കൻഡിൽ കൂടുതലാണ്. പല കണക്ഷനുകളും നഷ്‌ടപ്പെട്ടു, ഇത് എല്ലാ പാക്കറ്റുകളുടെയും 3,5% വീണ്ടും സംപ്രേക്ഷണം ചെയ്യാൻ TCP കാരണമായി. വിമാനത്താവളങ്ങൾ, ട്രെയിൻ സ്റ്റേഷനുകൾ തുടങ്ങിയ തിരക്കേറിയ സ്ഥലങ്ങളിൽ 7% നഷ്ടം കണ്ടു. ഈ ഫലങ്ങൾ സെല്ലുലാർ നെറ്റ്‌വർക്കുകളിൽ ഉപയോഗിക്കുന്ന പരമ്പരാഗത ജ്ഞാനത്തെക്കുറിച്ച് സംശയം ജനിപ്പിക്കുന്നു വിപുലമായ റീട്രാൻസ്മിഷൻ സർക്യൂട്ടുകൾ ഗതാഗത തലത്തിൽ നഷ്ടം ഗണ്യമായി കുറയ്ക്കുക. "സിമുലേറ്റർ" ആപ്ലിക്കേഷനിൽ നിന്നുള്ള പരിശോധനാ ഫലങ്ങൾ ചുവടെയുണ്ട്:

നെറ്റ്‌വർക്ക് മെട്രിക്‌സ്
അർത്ഥങ്ങൾ

RTT, മില്ലിസെക്കൻഡ് [50%,75%, 95%,99%]
[350, 425, 725, 2300]

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 സെക്കൻഡ് ആയിരുന്നു. ഡാറ്റ വിജയകരമായി കൈമാറാൻ ടിസിപി 7-10 പാസുകൾ എടുക്കാൻ ഈ നഷ്ടം കാരണമായി എന്ന് ഇത് സൂചന നൽകുന്നു. ഇത് കാര്യക്ഷമമല്ലാത്ത RTO കണക്കുകൂട്ടലിൻ്റെ അനന്തരഫലമായിരിക്കാം, നഷ്ടത്തോട് പെട്ടെന്ന് പ്രതികരിക്കാനുള്ള TCP-യുടെ കഴിവില്ലായ്മ ഏറ്റവും പുതിയ പാക്കേജുകൾ വിൻഡോയിലും കൺജഷൻ കൺട്രോൾ അൽഗോരിതത്തിൻ്റെ കാര്യക്ഷമതയില്ലായ്മയും, വയർലെസ് നഷ്ടവും നെറ്റ്‌വർക്ക് തിരക്ക് മൂലമുള്ള നഷ്ടവും തമ്മിൽ വേർതിരിച്ചറിയുന്നില്ല. TCP ലോസ് ടെസ്റ്റുകളുടെ ഫലങ്ങൾ ചുവടെയുണ്ട്:

TCP പാക്കറ്റ് നഷ്ട സ്ഥിതിവിവരക്കണക്കുകൾ
വില

കുറഞ്ഞത് 1 പാക്കറ്റ് നഷ്ടമുള്ള കണക്ഷനുകളുടെ ശതമാനം
45%

കണക്ഷൻ സജ്ജീകരണ സമയത്ത് നഷ്ടപ്പെടുന്ന കണക്ഷനുകളുടെ ശതമാനം
30%

ഡാറ്റാ എക്സ്ചേഞ്ച് സമയത്ത് നഷ്ടപ്പെടുന്ന കണക്ഷനുകളുടെ ശതമാനം
76%

പുനഃസംപ്രേക്ഷണത്തിലെ കാലതാമസം, സെക്കൻഡുകൾ [50%, 75%, 95%,99%] [1, 2.8, 15, 28]

ഒരു പാക്കറ്റിനോ TCP വിഭാഗത്തിനോ വേണ്ടിയുള്ള റീട്രാൻസ്മിഷനുകളുടെ എണ്ണം വിതരണം
[1,3,6,7]

ക്യുഐസിയുടെ അപേക്ഷ

യഥാർത്ഥത്തിൽ Google വികസിപ്പിച്ചെടുത്തത്, UDP-യുടെ മുകളിൽ പ്രവർത്തിക്കുന്ന ഒരു മൾട്ടി-ത്രെഡഡ് ആധുനിക ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ ആണ് QUIC. നിലവിൽ QUIC പ്രവർത്തിക്കുന്നു സ്റ്റാൻഡേർഡൈസേഷൻ പ്രക്രിയ (QUIC യുടെ രണ്ട് പതിപ്പുകൾ ഉണ്ടെന്ന് ഞങ്ങൾ ഇതിനകം എഴുതിയിട്ടുണ്ട്, കൗതുകകരമാണ് ലിങ്ക് പിന്തുടരാനാകും - ഏകദേശം. വിവർത്തകൻ). ചിത്രം 5-ൽ കാണിച്ചിരിക്കുന്നതുപോലെ, QUIC എന്നത് HTTP/3-ന് കീഴിലാണ് സ്ഥാപിച്ചിരിക്കുന്നത് (വാസ്തവത്തിൽ, QUIC-ന് മുകളിലുള്ള HTTP/2 എന്നത് HTTP/3 ആണ്, അത് ഇപ്പോൾ തീവ്രമായി സ്റ്റാൻഡേർഡ് ചെയ്യുന്നു). പാക്കറ്റുകൾ രൂപപ്പെടുത്തുന്നതിന് UDP ഉപയോഗിച്ച് ഇത് HTTPS, TCP ലെയറുകളെ ഭാഗികമായി മാറ്റിസ്ഥാപിക്കുന്നു. TLS പൂർണ്ണമായും QUIC-ൽ നിർമ്മിച്ചിരിക്കുന്നതിനാൽ സുരക്ഷിതമായ ഡാറ്റാ കൈമാറ്റത്തെ മാത്രമേ QUIC പിന്തുണയ്ക്കൂ.

ചിത്രം 5: മുമ്പ് HTTP/3-ന് കീഴിൽ പ്രവർത്തിച്ചിരുന്ന TLS-ന് പകരമായി QUIC HTTP/2-ന് കീഴിൽ പ്രവർത്തിക്കുന്നു.

TCP ആംപ്ലിഫിക്കേഷനായി QUIC ഉപയോഗിക്കാൻ ഞങ്ങളെ ബോധ്യപ്പെടുത്തിയ കാരണങ്ങൾ ചുവടെയുണ്ട്:

• 0-RTT കണക്ഷൻ സ്ഥാപനം. മുൻ കണക്ഷനുകളിൽ നിന്നുള്ള അംഗീകാരങ്ങൾ പുനരുപയോഗിക്കാൻ QUIC അനുവദിക്കുന്നു, ഇത് സുരക്ഷാ ഹാൻഡ്‌ഷേക്കുകളുടെ എണ്ണം കുറയ്ക്കുന്നു. ഭാവിയിൽ TLS1.3 0-RTT പിന്തുണയ്‌ക്കും, പക്ഷേ ത്രീ-വേ TCP ഹാൻഡ്‌ഷേക്ക് ഇപ്പോഴും ആവശ്യമാണ്.
• HoL തടയൽ മറികടക്കുന്നു. പ്രകടനം മെച്ചപ്പെടുത്താൻ HTTP/2 ഓരോ ക്ലയൻ്റിനും ഒരു TCP കണക്ഷൻ ഉപയോഗിക്കുന്നു, എന്നാൽ ഇത് HoL (ഹെഡ്-ഓഫ്-ലൈൻ) തടയുന്നതിലേക്ക് നയിച്ചേക്കാം. QUIC മൾട്ടിപ്ലക്‌സിംഗ് ലളിതമാക്കുകയും സ്വതന്ത്രമായി ആപ്ലിക്കേഷനിലേക്ക് അഭ്യർത്ഥനകൾ നൽകുകയും ചെയ്യുന്നു.
• തിരക്ക് നിയന്ത്രണം. നെറ്റ്‌വർക്ക് പാരാമീറ്ററുകൾ (നഷ്ടങ്ങളുടെ എണ്ണം അല്ലെങ്കിൽ ആർടിടി) അടിസ്ഥാനമാക്കി അയയ്‌ക്കുന്നത് നിയന്ത്രിക്കുന്ന പ്രധാന ഗതാഗത അൽഗോരിതം അപ്‌ഡേറ്റ് ചെയ്യുന്നത് എളുപ്പമാക്കുന്ന, ആപ്ലിക്കേഷൻ ലെയറിൽ QUIC വസിക്കുന്നു. മിക്ക TCP നടപ്പിലാക്കലുകളും അൽഗോരിതം ഉപയോഗിക്കുന്നു ക്യുബിക്, ഇത് ലേറ്റൻസി സെൻസിറ്റീവ് ട്രാഫിക്കിന് അനുയോജ്യമല്ല. ഈയിടെ വികസിപ്പിച്ച അൽഗോരിതങ്ങൾ പോലുള്ളവ BBR, കൂടുതൽ കൃത്യമായി നെറ്റ്‌വർക്ക് മാതൃകയാക്കുകയും ലേറ്റൻസി ഒപ്റ്റിമൈസ് ചെയ്യുകയും ചെയ്യുക. BBR ഉപയോഗിക്കാനും ഈ അൽഗോരിതം ഉപയോഗിക്കുന്നതുപോലെ അപ്ഡേറ്റ് ചെയ്യാനും QUIC നിങ്ങളെ അനുവദിക്കുന്നു. മെച്ചപ്പെടുത്തൽ.
• നഷ്ടങ്ങളുടെ നികത്തൽ. QUIC രണ്ട് TLP-കളെ വിളിക്കുന്നു (വാൽ നഷ്ട അന്വേഷണം) ആർടിഒ പ്രവർത്തനക്ഷമമാകുന്നതിന് മുമ്പ് - നഷ്ടങ്ങൾ വളരെ ശ്രദ്ധേയമാണെങ്കിൽ പോലും. ഇത് TCP നടപ്പിലാക്കലുകളിൽ നിന്ന് വ്യത്യസ്തമാണ്. വേഗത്തിലുള്ള നികത്തൽ പ്രവർത്തനക്ഷമമാക്കാൻ TLP പ്രധാനമായും അവസാനത്തെ പാക്കറ്റ് (അല്ലെങ്കിൽ പുതിയത് ഉണ്ടെങ്കിൽ) വീണ്ടും സംപ്രേക്ഷണം ചെയ്യുന്നു. ടെയിൽ കാലതാമസം കൈകാര്യം ചെയ്യുന്നത് Uber അതിൻ്റെ നെറ്റ്‌വർക്ക് പ്രവർത്തിപ്പിക്കുന്ന രീതിക്ക് പ്രത്യേകിച്ചും ഉപയോഗപ്രദമാണ്, അതായത് ഹ്രസ്വവും ഇടയ്ക്കിടെയുള്ളതും ലേറ്റൻസി സെൻസിറ്റീവായതുമായ ഡാറ്റാ കൈമാറ്റങ്ങൾക്ക്.
• ഒപ്റ്റിമൈസ് ചെയ്ത ACK. ഓരോ പാക്കറ്റിനും തനതായ ഒരു സീക്വൻസ് നമ്പർ ഉള്ളതിനാൽ, ഒരു പ്രശ്നവുമില്ല വ്യത്യാസങ്ങൾ പാക്കറ്റുകൾ വീണ്ടും കൈമാറ്റം ചെയ്യുമ്പോൾ. ACK പാക്കറ്റുകളിൽ പാക്കറ്റ് പ്രോസസ്സ് ചെയ്യുന്നതിനും ക്ലയൻ്റ് വശത്ത് ഒരു ACK സൃഷ്ടിക്കുന്നതിനുമുള്ള സമയവും അടങ്ങിയിരിക്കുന്നു. ഈ സവിശേഷതകൾ QUIC കൂടുതൽ കൃത്യമായി RTT കണക്കാക്കുന്നുവെന്ന് ഉറപ്പാക്കുന്നു. QUIC-ലെ ACK 256 ബാൻഡുകളെ വരെ പിന്തുണയ്ക്കുന്നു NACK, അയക്കുന്നയാളെ പാക്കറ്റ് ഷഫിൾ ചെയ്യാനും ഈ പ്രക്രിയയിൽ കുറച്ച് ബൈറ്റുകൾ ഉപയോഗിക്കാനും കൂടുതൽ സഹിഷ്ണുത കാണിക്കാൻ സഹായിക്കുന്നു. സെലക്ടീവ് ACK (ചാക്ക്) ടിസിപിയിൽ എല്ലാ സാഹചര്യങ്ങളിലും ഈ പ്രശ്നം പരിഹരിക്കില്ല.
• കണക്ഷൻ മൈഗ്രേഷൻ. ഒരു 64-ബിറ്റ് ഐഡി ഉപയോഗിച്ചാണ് ക്യുഐസി കണക്ഷനുകൾ തിരിച്ചറിയുന്നത്, അതിനാൽ ഒരു ക്ലയൻ്റ് ഐപി വിലാസങ്ങൾ മാറ്റുകയാണെങ്കിൽ, പഴയ കണക്ഷൻ ഐഡി തടസ്സമില്ലാതെ പുതിയ ഐപി വിലാസത്തിൽ ഉപയോഗിക്കുന്നത് തുടരാം. Wi-Fi, സെല്ലുലാർ കണക്ഷനുകൾക്കിടയിൽ ഉപയോക്താവ് മാറുന്ന മൊബൈൽ ആപ്ലിക്കേഷനുകൾക്ക് ഇത് വളരെ സാധാരണമായ ഒരു സമ്പ്രദായമാണ്.

QUIC-ലേക്കുള്ള ഇതരമാർഗങ്ങൾ

QUIC തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് പ്രശ്നം പരിഹരിക്കുന്നതിനുള്ള ബദൽ സമീപനങ്ങൾ ഞങ്ങൾ പരിഗണിച്ചു.

ഉപയോക്താക്കൾക്ക് അടുത്തുള്ള TCP കണക്ഷനുകൾ അവസാനിപ്പിക്കുന്നതിന് TPC PoPs (Points of Presence) വിന്യസിക്കാനാണ് ഞങ്ങൾ ആദ്യം ശ്രമിച്ചത്. അടിസ്ഥാനപരമായി, സെല്ലുലാർ നെറ്റ്‌വർക്കിന് അടുത്തുള്ള ഒരു മൊബൈൽ ഉപകരണവുമായുള്ള TCP കണക്ഷൻ PoP-കൾ അവസാനിപ്പിക്കുകയും ട്രാഫിക്കിനെ യഥാർത്ഥ ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് തിരികെ കൊണ്ടുവരികയും ചെയ്യുന്നു. ടിസിപി അടുത്ത് അവസാനിപ്പിക്കുന്നതിലൂടെ, ഞങ്ങൾക്ക് ആർടിടി കുറയ്ക്കാനും ചലനാത്മക വയർലെസ് പരിതസ്ഥിതിയോട് ടിസിപി കൂടുതൽ പ്രതികരിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാനും കഴിയും. എന്നിരുന്നാലും, ഞങ്ങളുടെ പരീക്ഷണങ്ങൾ കാണിക്കുന്നത് ആർടിടിയും നഷ്ടവും സെല്ലുലാർ നെറ്റ്‌വർക്കുകളിൽ നിന്നാണ് വരുന്നതെന്നും PoP-കളുടെ ഉപയോഗം കാര്യമായ പ്രകടന മെച്ചപ്പെടുത്തൽ നൽകുന്നില്ലെന്നും.

ഞങ്ങൾ TCP പാരാമീറ്ററുകൾ ട്യൂൺ ചെയ്യുന്നതും നോക്കി. ഞങ്ങളുടെ വൈവിധ്യമാർന്ന എഡ്ജ് സെർവറുകളിൽ ഒരു TCP സ്റ്റാക്ക് സജ്ജീകരിക്കുന്നത് ബുദ്ധിമുട്ടായിരുന്നു, കാരണം വ്യത്യസ്ത OS പതിപ്പുകളിൽ ഉടനീളം TCP-ക്ക് വ്യത്യസ്തമായ നടപ്പിലാക്കലുകൾ ഉണ്ട്. ഇത് നടപ്പിലാക്കാനും വ്യത്യസ്ത നെറ്റ്‌വർക്ക് കോൺഫിഗറേഷനുകൾ പരിശോധിക്കാനും ബുദ്ധിമുട്ടായിരുന്നു. അനുമതികളുടെ അഭാവം മൂലം മൊബൈൽ ഉപകരണങ്ങളിൽ ടിസിപി നേരിട്ട് കോൺഫിഗർ ചെയ്യുന്നത് സാധ്യമല്ല. കൂടുതൽ പ്രധാനമായി, 0-RTT കണക്ഷനുകളും മെച്ചപ്പെടുത്തിയ RTT പ്രവചനവും പോലുള്ള സവിശേഷതകൾ പ്രോട്ടോക്കോളിൻ്റെ ആർക്കിടെക്ചറിന് നിർണായകമാണ്, അതിനാൽ TCP മാത്രം ട്യൂൺ ചെയ്യുന്നതിലൂടെ കാര്യമായ നേട്ടങ്ങൾ കൈവരിക്കുക അസാധ്യമാണ്.

അവസാനമായി, വീഡിയോ സ്‌ട്രീമിംഗിൻ്റെ പ്രശ്‌നപരിഹാരം നൽകുന്ന നിരവധി UDP-അധിഷ്‌ഠിത പ്രോട്ടോക്കോളുകൾ ഞങ്ങൾ വിലയിരുത്തി—ഞങ്ങളുടെ കാര്യത്തിൽ ഈ പ്രോട്ടോക്കോളുകൾ സഹായിക്കുമോ എന്ന് കാണാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. നിർഭാഗ്യവശാൽ, അവർക്ക് പല സുരക്ഷാ ക്രമീകരണങ്ങളിലും കാര്യമായ കുറവുണ്ടായിരുന്നു, കൂടാതെ മെറ്റാഡാറ്റയ്ക്കും നിയന്ത്രണ വിവരങ്ങൾക്കും ഒരു അധിക TCP കണക്ഷനും ആവശ്യമായിരുന്നു.

സുരക്ഷയും പ്രകടനവും കണക്കിലെടുക്കുമ്പോൾ, ഇൻ്റർനെറ്റ് ട്രാഫിക്കിൻ്റെ പ്രശ്‌നത്തിന് സഹായിക്കുന്ന ഒരേയൊരു പ്രോട്ടോക്കോൾ ക്യുഐസി മാത്രമാണെന്ന് ഞങ്ങളുടെ ഗവേഷണം തെളിയിച്ചിട്ടുണ്ട്.

പ്ലാറ്റ്‌ഫോമിലേക്ക് ക്യുഐസിയുടെ സംയോജനം

QUIC വിജയകരമായി ഉൾച്ചേർക്കുന്നതിനും മോശം കണക്റ്റിവിറ്റി പരിതസ്ഥിതികളിൽ ആപ്ലിക്കേഷൻ പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിനും, ഞങ്ങൾ പഴയ സ്റ്റാക്ക് (HTTP/2 over TLS/TCP) QUIC പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് മാറ്റി. ഞങ്ങൾ നെറ്റ്‌വർക്ക് ലൈബ്രറി ഉപയോഗിച്ചു ക്രോണറ്റ് നിന്ന് Chromium പദ്ധതികൾ, പ്രോട്ടോക്കോളിൻ്റെ യഥാർത്ഥ, Google പതിപ്പ് അടങ്ങിയിരിക്കുന്നു - gQUIC. ഏറ്റവും പുതിയ IETF സ്പെസിഫിക്കേഷൻ പിന്തുടരുന്നതിനായി ഈ നടപ്പാക്കലും നിരന്തരം മെച്ചപ്പെടുത്തുന്നു.

QUIC-നുള്ള പിന്തുണ ചേർക്കുന്നതിനായി ഞങ്ങൾ ആദ്യം ഞങ്ങളുടെ Android ആപ്പുകളിലേക്ക് Cronet സംയോജിപ്പിച്ചു. മൈഗ്രേഷൻ ചെലവ് പരമാവധി കുറയ്ക്കുന്ന തരത്തിലാണ് സംയോജനം നടത്തിയത്. ലൈബ്രറി ഉപയോഗിച്ച പഴയ നെറ്റ്‌വർക്കിംഗ് സ്റ്റാക്ക് പൂർണ്ണമായും മാറ്റിസ്ഥാപിക്കുന്നതിന് പകരം OkHttp, OkHttp API ചട്ടക്കൂടിന് കീഴിൽ ഞങ്ങൾ ക്രോനെറ്റ് സംയോജിപ്പിച്ചിരിക്കുന്നു. ഈ രീതിയിൽ സംയോജനം ചെയ്യുന്നതിലൂടെ, ഞങ്ങളുടെ നെറ്റ്‌വർക്ക് കോളുകളിലെ മാറ്റങ്ങൾ ഞങ്ങൾ ഒഴിവാക്കി (ഇവ ഉപയോഗിക്കുന്നു റിട്രോഫിറ്റ്) API തലത്തിൽ.

ആൻഡ്രോയിഡ് ഉപകരണങ്ങൾക്കുള്ള സമീപനത്തിന് സമാനമായി, നെറ്റ്‌വർക്കിൽ നിന്നുള്ള HTTP ട്രാഫിക്കിനെ തടസ്സപ്പെടുത്തി, iOS-ലെ Uber ആപ്പുകളിലേക്ക് ഞങ്ങൾ Cronet നടപ്പിലാക്കി എപിഐഉപയോഗിക്കുന്നത് NSURLപ്രോട്ടോക്കോൾ. iOS ഫൗണ്ടേഷൻ നൽകുന്ന ഈ സംഗ്രഹം, പ്രോട്ടോക്കോൾ-നിർദ്ദിഷ്ട URL ഡാറ്റ കൈകാര്യം ചെയ്യുകയും കാര്യമായ മൈഗ്രേഷൻ ചെലവുകളില്ലാതെ ഞങ്ങളുടെ iOS ആപ്ലിക്കേഷനുകളിലേക്ക് Cronet-നെ സംയോജിപ്പിക്കാൻ കഴിയുമെന്ന് ഉറപ്പാക്കുകയും ചെയ്യുന്നു.

Google ക്ലൗഡ് ബാലൻസറുകളിൽ QUIC പൂർത്തിയാക്കുന്നു

പിൻഭാഗത്ത്, QUIC പൂർത്തീകരണം നൽകുന്നത് Google ക്ലൗഡ് ലോഡ് ബാലൻസിങ് ഇൻഫ്രാസ്ട്രക്ചർ ആണ്, അത് ഉപയോഗിക്കുന്നു alt-svc QUIC പിന്തുണയ്ക്കുന്നതിനുള്ള പ്രതികരണങ്ങളിലെ തലക്കെട്ടുകൾ. പൊതുവേ, ഓരോ HTTP അഭ്യർത്ഥനയിലും ബാലൻസർ ഒരു alt-svc തലക്കെട്ട് ചേർക്കുന്നു, ഇത് ഇതിനകം തന്നെ ഡൊമെയ്‌നിനായുള്ള QUIC പിന്തുണയെ സാധൂകരിക്കുന്നു. ഒരു ക്രോനെറ്റ് ക്ലയൻ്റ് ഈ ഹെഡറിനൊപ്പം ഒരു HTTP പ്രതികരണം ലഭിക്കുമ്പോൾ, ആ ഡൊമെയ്‌നിലേക്കുള്ള തുടർന്നുള്ള HTTP അഭ്യർത്ഥനകൾക്കായി അത് QUIC ഉപയോഗിക്കുന്നു. ബാലൻസർ QUIC പൂർത്തിയാക്കിക്കഴിഞ്ഞാൽ, ഞങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ ഈ പ്രവർത്തനം HTTP2/TCP വഴി ഞങ്ങളുടെ ഡാറ്റാ സെൻ്ററുകളിലേക്ക് വ്യക്തമായി അയയ്ക്കുന്നു.

പ്രകടനം: ഫലങ്ങൾ

മികച്ച പ്രോട്ടോക്കോളിനായി ഞങ്ങളുടെ തിരയലിൻ്റെ പ്രധാന കാരണം ഔട്ട്‌പുട്ട് പ്രകടനമാണ്. ആരംഭിക്കുന്നതിന്, ഞങ്ങൾ ഒരു നിലപാട് സൃഷ്ടിച്ചു നെറ്റ്വർക്ക് എമുലേഷൻവ്യത്യസ്ത നെറ്റ്‌വർക്ക് പ്രൊഫൈലുകൾക്ക് കീഴിൽ QUIC എങ്ങനെ പ്രവർത്തിക്കുമെന്ന് കണ്ടെത്താൻ. യഥാർത്ഥ ലോക നെറ്റ്‌വർക്കുകളിൽ QUIC-ൻ്റെ പ്രകടനം പരിശോധിക്കുന്നതിന്, പാസഞ്ചർ ആപ്പിലെ HTTP കോളുകൾക്ക് സമാനമായ എമുലേറ്റഡ് നെറ്റ്‌വർക്ക് ട്രാഫിക് ഉപയോഗിച്ച് ന്യൂഡൽഹിയിൽ ചുറ്റിക്കറങ്ങി ഞങ്ങൾ പരീക്ഷണങ്ങൾ നടത്തി.

പരീക്ഷണം 1

പരീക്ഷണത്തിനുള്ള ഉപകരണങ്ങൾ:

• TCP, QUIC എന്നിവയിലൂടെ യഥാക്രമം HTTPS ട്രാഫിക് അനുവദിക്കുന്നുവെന്ന് ഉറപ്പാക്കാൻ OkHttp, Cronet സ്റ്റാക്കുകൾ ഉപയോഗിച്ച് Android ഉപകരണങ്ങൾ പരിശോധിക്കുക;
• പ്രതികരണങ്ങളിൽ ഒരേ തരത്തിലുള്ള HTTPS തലക്കെട്ടുകൾ അയയ്‌ക്കുകയും അവയിൽ നിന്നുള്ള അഭ്യർത്ഥനകൾ സ്വീകരിക്കുന്നതിന് ക്ലയൻ്റ് ഉപകരണങ്ങളെ ലോഡുചെയ്യുകയും ചെയ്യുന്ന ഒരു ജാവ അടിസ്ഥാനമാക്കിയുള്ള എമുലേഷൻ സെർവർ;
• TCP, QUIC കണക്ഷനുകൾ അവസാനിപ്പിക്കുന്നതിന് ഭൗതികമായി ഇന്ത്യയോട് ചേർന്ന് സ്ഥിതി ചെയ്യുന്ന ക്ലൗഡ് പ്രോക്സികൾ. ടിസിപി അവസാനിപ്പിക്കുമ്പോൾ ഞങ്ങൾ ഒരു റിവേഴ്സ് പ്രോക്സി ഓൺ ഉപയോഗിച്ചു NGINX, QUIC-യ്‌ക്കായി ഒരു ഓപ്പൺ സോഴ്‌സ് റിവേഴ്‌സ് പ്രോക്‌സി കണ്ടെത്തുന്നത് ബുദ്ധിമുട്ടായിരുന്നു. Chromium-ൽ നിന്നുള്ള അടിസ്ഥാന QUIC സ്റ്റാക്ക് ഉപയോഗിച്ച് ഞങ്ങൾ തന്നെ QUIC-നായി ഒരു റിവേഴ്സ് പ്രോക്സി നിർമ്മിച്ചു പ്രസിദ്ധീകരിച്ചു ഓപ്പൺ സോഴ്‌സ് ആയി ക്രോമിയത്തിലേക്ക്.

ചിത്രം 6. TCP vs QUIC റോഡ് ടെസ്റ്റ് സ്യൂട്ടിൽ OkHttp, Cronet എന്നിവയുള്ള Android ഉപകരണങ്ങൾ, കണക്ഷനുകൾ അവസാനിപ്പിക്കുന്നതിനുള്ള ക്ലൗഡ് പ്രോക്സികൾ, ഒരു എമുലേഷൻ സെർവർ എന്നിവ ഉൾപ്പെടുന്നു.

പരീക്ഷണം 2

Google QUIC ലഭ്യമാക്കിയപ്പോൾ Google ക്ലൗഡ് ലോഡ് ബാലൻസിങ്, ഞങ്ങൾ ഒരേ ഇൻവെൻ്ററി ഉപയോഗിച്ചു, പക്ഷേ ഒരു പരിഷ്‌ക്കരണത്തോടെ: NGINX-ന് പകരം, ഉപകരണങ്ങളിൽ നിന്നുള്ള TCP, QUIC കണക്ഷനുകൾ അവസാനിപ്പിക്കുന്നതിനും എമുലേഷൻ സെർവറിലേക്ക് HTTPS ട്രാഫിക്കിലേക്ക് നയിക്കുന്നതിനും ഞങ്ങൾ Google ലോഡ് ബാലൻസറുകൾ സ്വീകരിച്ചു. ബാലൻസറുകൾ ലോകമെമ്പാടും വിതരണം ചെയ്യപ്പെടുന്നു, എന്നാൽ ഉപകരണത്തിന് ഏറ്റവും അടുത്തുള്ള PoP സെർവർ ഉപയോഗിക്കുക (ജിയോലൊക്കേഷന് നന്ദി).

ചിത്രം 7. രണ്ടാമത്തെ പരീക്ഷണത്തിൽ, TCP, QUIC എന്നിവയുടെ പൂർത്തീകരണ ലേറ്റൻസി താരതമ്യം ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു: Google ക്ലൗഡ് ഉപയോഗിച്ചും ഞങ്ങളുടെ ക്ലൗഡ് പ്രോക്സി ഉപയോഗിച്ചും.

തൽഫലമായി, നിരവധി വെളിപ്പെടുത്തലുകൾ ഞങ്ങളെ കാത്തിരുന്നു:

• PoP വഴിയുള്ള അവസാനിപ്പിക്കൽ TCP പ്രകടനം മെച്ചപ്പെടുത്തി. ബാലൻസറുകൾ ടിസിപി കണക്ഷനുകൾ ഉപയോക്താക്കൾക്ക് അടുത്ത് നിർത്തുകയും വളരെ ഒപ്റ്റിമൈസ് ചെയ്യുകയും ചെയ്യുന്നതിനാൽ, ഇത് കുറഞ്ഞ ആർടിടികൾക്ക് കാരണമാകുന്നു, ഇത് ടിസിപി പ്രകടനം മെച്ചപ്പെടുത്തുന്നു. QUIC-യെ ബാധിച്ചിട്ടില്ലെങ്കിലും, ടെയിൽ ലേറ്റൻസി (10-30 ശതമാനം വരെ) കുറയ്ക്കുന്ന കാര്യത്തിൽ അത് ഇപ്പോഴും TCP-യെക്കാൾ മികച്ച പ്രകടനം കാഴ്ചവച്ചു.
• വാലുകൾ ബാധിക്കുന്നു നെറ്റ്വർക്ക് ഹോപ്സ്. ഞങ്ങളുടെ QUIC പ്രോക്‌സി, Google-ൻ്റെ ലോഡ് ബാലൻസറുകളേക്കാൾ ഉപകരണങ്ങളിൽ നിന്ന് (ഏകദേശം 50 എംഎസ് ഉയർന്ന ലേറ്റൻസി) ഉള്ളതാണെങ്കിലും, ഇത് സമാനമായ പ്രകടനം കാഴ്ചവച്ചു - ടിസിപിയുടെ 15-ാമത്തെ പെർസെൻറ്റൈലിൽ 20% കുറവ്, ലേറ്റൻസിയിൽ 99% കുറവ്. അവസാന മൈൽ പരിവർത്തനം നെറ്റ്‌വർക്കിലെ തടസ്സമാണെന്ന് ഇത് സൂചിപ്പിക്കുന്നു.

ചിത്രം 8: രണ്ട് പരീക്ഷണങ്ങളിൽ നിന്നുള്ള ഫലങ്ങൾ കാണിക്കുന്നത് QUIC ഗണ്യമായി TCP-യെ മറികടക്കുന്നു എന്നാണ്.

ട്രാഫിക്കിനെതിരെ പോരാടുക

പരീക്ഷണങ്ങളിൽ നിന്ന് പ്രചോദനം ഉൾക്കൊണ്ട്, ഞങ്ങളുടെ Android, iOS ആപ്ലിക്കേഷനുകളിൽ QUIC പിന്തുണ ഞങ്ങൾ നടപ്പിലാക്കിയിട്ടുണ്ട്. Uber പ്രവർത്തിക്കുന്ന നഗരങ്ങളിൽ QUIC-ൻ്റെ സ്വാധീനം നിർണ്ണയിക്കാൻ ഞങ്ങൾ A/B ടെസ്റ്റിംഗ് നടത്തി. പൊതുവേ, ടെലികോം ഓപ്പറേറ്റർമാർ, നെറ്റ്‌വർക്ക് തരം എന്നിവയിലുടനീളമുള്ള ടെയിൽ കാലതാമസത്തിൽ കാര്യമായ കുറവ് ഞങ്ങൾ കണ്ടു.

താഴെയുള്ള ഗ്രാഫുകൾ, മാക്രോ മേഖലയും വ്യത്യസ്ത നെറ്റ്‌വർക്ക് തരങ്ങളും - LTE, 95G, 99G എന്നിവ പ്രകാരം ടെയിലുകളിലെ (3, 2 ശതമാനം) ശതമാനം മെച്ചപ്പെടുത്തലുകൾ കാണിക്കുന്നു.

ചിത്രം 9. യുദ്ധ പരീക്ഷണങ്ങളിൽ, ലേറ്റൻസിയുടെ കാര്യത്തിൽ ക്യുഐസി ടിസിപിയെ മറികടന്നു.

മുന്നോട്ട് മാത്രം

ഒരുപക്ഷേ ഇത് ഒരു തുടക്കം മാത്രമായിരിക്കാം - ഉൽപ്പാദനത്തിലേക്ക് QUIC റിലീസ് ചെയ്യുന്നത് സ്ഥിരവും അസ്ഥിരവുമായ നെറ്റ്‌വർക്കുകളിൽ ആപ്ലിക്കേഷൻ പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിന് അതിശയകരമായ അവസരങ്ങൾ നൽകി, അതായത്:

കവറേജ് വർദ്ധിപ്പിച്ചു

യഥാർത്ഥ ട്രാഫിക്കിലെ പ്രോട്ടോക്കോളിൻ്റെ പ്രകടനം വിശകലനം ചെയ്ത ശേഷം, ഏകദേശം 80% സെഷനുകളും QUIC വിജയകരമായി ഉപയോഗിച്ചതായി ഞങ്ങൾ കണ്ടു. всех അഭ്യർത്ഥനകൾ, അതേസമയം 15% സെഷനുകൾ QUIC, TCP എന്നിവയുടെ സംയോജനമാണ് ഉപയോഗിച്ചത്. യഥാർത്ഥ യുഡിപി പരാജയങ്ങളും മോശം നെറ്റ്‌വർക്ക് അവസ്ഥകളും തമ്മിൽ വേർതിരിച്ചറിയാൻ കഴിയാത്തതിനാൽ, ക്രോനെറ്റ് ലൈബ്രറി ടിസിപിയിലേക്ക് മടങ്ങുന്നതിനാലാണ് ഈ കോമ്പിനേഷൻ സംഭവിച്ചതെന്ന് ഞങ്ങൾ അനുമാനിക്കുന്നു. ക്യുഐസിയുടെ തുടർന്നുള്ള നടപ്പാക്കലിനായി ഞങ്ങൾ പ്രവർത്തിക്കുമ്പോൾ ഈ പ്രശ്‌നത്തിനുള്ള ഒരു പരിഹാരം ഞങ്ങൾ ഇപ്പോൾ നോക്കുകയാണ്.

QUIC ഒപ്റ്റിമൈസേഷൻ

മൊബൈൽ ആപ്പുകളിൽ നിന്നുള്ള ട്രാഫിക് ലേറ്റൻസി സെൻസിറ്റീവ് ആണ്, എന്നാൽ ബാൻഡ്‌വിഡ്ത്ത് സെൻസിറ്റീവ് അല്ല. കൂടാതെ, ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ പ്രധാനമായും സെല്ലുലാർ നെറ്റ്‌വർക്കുകളിൽ ഉപയോഗിക്കുന്നു. പരീക്ഷണങ്ങളെ അടിസ്ഥാനമാക്കി, ഉപയോക്താക്കൾക്ക് അടുത്തുള്ള TCP, QUIC എന്നിവ അവസാനിപ്പിക്കാൻ ഒരു പ്രോക്സി ഉപയോഗിക്കുന്നുണ്ടെങ്കിലും ടെയിൽ ലേറ്റൻസികൾ ഇപ്പോഴും ഉയർന്നതാണ്. തിരക്ക് നിയന്ത്രിക്കൽ മെച്ചപ്പെടുത്തുന്നതിനും ക്യുഐസി ലോസ് റിക്കവറി അൽഗോരിതങ്ങളുടെ കാര്യക്ഷമത മെച്ചപ്പെടുത്തുന്നതിനുമുള്ള വഴികൾ ഞങ്ങൾ സജീവമായി അന്വേഷിക്കുകയാണ്.

ഇവയും മറ്റ് നിരവധി മെച്ചപ്പെടുത്തലുകളും ഉപയോഗിച്ച്, നെറ്റ്‌വർക്കും പ്രദേശവും പരിഗണിക്കാതെ ഉപയോക്തൃ അനുഭവം മെച്ചപ്പെടുത്താൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു, ഇത് ലോകമെമ്പാടും സൗകര്യപ്രദവും തടസ്സമില്ലാത്തതുമായ പാക്കറ്റ് ഗതാഗതം കൂടുതൽ ആക്‌സസ് ചെയ്യാൻ കഴിയും.

അവലംബം: www.habr.com