UDP-യിലൂടെയുള്ള HTTP - QUIC പ്രോട്ടോക്കോൾ നന്നായി ഉപയോഗിക്കുന്നു

TCP, TLS, HTTP/2 എന്നിവയുടെ എല്ലാ സവിശേഷതകളെയും പിന്തുണയ്‌ക്കുകയും അവയുടെ മിക്ക പ്രശ്‌നങ്ങളും പരിഹരിക്കുകയും ചെയ്യുന്ന UDP-യുടെ മുകളിലുള്ള ഒരു പ്രോട്ടോക്കോൾ ആണ് QUIC (ക്വിക്ക് UDP ഇൻ്റർനെറ്റ് കണക്ഷനുകൾ). ഇതിനെ പലപ്പോഴും ഒരു പുതിയ അല്ലെങ്കിൽ "പരീക്ഷണാത്മക" പ്രോട്ടോക്കോൾ എന്ന് വിളിക്കുന്നു, പക്ഷേ ഇത് പരീക്ഷണ ഘട്ടത്തെ വളരെക്കാലമായി അതിജീവിച്ചു: വികസനം 7 വർഷത്തിലേറെയായി തുടരുകയാണ്. ഈ സമയത്ത്, പ്രോട്ടോക്കോൾ ഒരു സ്റ്റാൻഡേർഡ് ആയിത്തീർന്നില്ല, പക്ഷേ ഇപ്പോഴും വ്യാപകമായിത്തീർന്നു. ഉദാഹരണത്തിന്, ട്രാഫിക് വേഗത്തിലാക്കാനും മൊബൈൽ നെറ്റ്‌വർക്കുകളിലെ കാലതാമസം കുറയ്ക്കാനും Google, Facebook പോലുള്ള ഭീമന്മാർ QUIC ഉപയോഗിക്കുന്നു, കൂടാതെ IETF അതിൻ്റെ പ്രോട്ടോക്കോൾ ഫോർക്ക് HTTP/3 സ്റ്റാൻഡേർഡിൻ്റെ അടിസ്ഥാനമായി പ്രഖ്യാപിച്ചു (HTTP/2 ഉപയോഗിക്കുന്നുണ്ടെങ്കിലും 44.8% മാത്രം സൈറ്റുകൾ).

ആശയം

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

QUIC ഒരു TCP മാറ്റിസ്ഥാപിക്കലും TLS 1.3 നടപ്പിലാക്കലും സംയോജിപ്പിക്കുന്നതിനാൽ, എല്ലാ കണക്ഷനുകളും എല്ലായ്പ്പോഴും എൻക്രിപ്റ്റ് ചെയ്തിരിക്കും, കൂടാതെ അത്തരം ട്രാഫിക് ഡീക്രിപ്റ്റ് ചെയ്യുന്നത് HTTPS വഴി പോകുന്നതിനേക്കാൾ എളുപ്പമല്ല. കൂടാതെ, ക്യുഐസി ആപ്ലിക്കേഷൻ തലത്തിൽ നടപ്പിലാക്കുന്നു, കാരണം ടിസിപി സ്റ്റാക്ക് പൂർണ്ണമായും മാറ്റിസ്ഥാപിക്കേണ്ടിവരും നിത്യത.

HTTP/2-ൽ മൾട്ടിപ്ലക്‌സിംഗിനുള്ള പിന്തുണ ഉണ്ടായിരുന്നിട്ടും, പാക്കറ്റുകൾ ക്രമത്തിൽ വിതരണം ചെയ്യേണ്ടതിൻ്റെ ആവശ്യകത കാരണം ഹെഡ്-ഓഫ്-ലൈൻ ബ്ലോക്കിംഗിൻ്റെ പ്രശ്‌നം അവിടെ തുടർന്നു. UDP-യുടെ മുകളിലാണ് QUIC നടപ്പിലാക്കുന്നത്, അതിനാൽ ഇതിന് തത്വത്തിൽ തടസ്സമില്ല, കൂടാതെ പാക്കറ്റുകൾ എന്നെന്നേക്കുമായി നഷ്‌ടപ്പെടുന്നത് തടയാൻ, അവ അക്കമിട്ടു, "അയൽവാസികളുടെ" ഭാഗങ്ങൾ അടങ്ങിയിരിക്കാം. കൂടാതെ, ഒരൊറ്റ കണക്ഷനുള്ളിലെ വിവിധ തരത്തിലുള്ള അഭ്യർത്ഥനകൾക്കായി ക്യുഐസി മോണോലിത്തിക്ക് ക്യൂവിനെ ഒന്നിലധികം ത്രെഡുകളായി വിഭജിക്കുന്നു. അതിനാൽ, ഒരു പാക്കറ്റ് നഷ്ടപ്പെട്ടാൽ, ഒരു ക്യൂവിൽ മാത്രം പ്രശ്നങ്ങൾ ഉണ്ടാകാം (ഉദാഹരണത്തിന്, ഒരു നിർദ്ദിഷ്ട ഫയൽ കൈമാറുന്നതിന്):

ഉപയോഗിക്കുക

തുടക്കത്തിൽ, ക്യുഐസി ഗൂഗിളിനുള്ളിൽ വികസിപ്പിച്ചെടുത്തതാണ്, അത് കമ്പനിക്കുള്ളിലെ ഉപയോഗത്തിന് ഏറെക്കുറെ രൂപപ്പെടുത്തിയതാണ്. 2013-ൽ, ഇത് സ്റ്റാൻഡേർഡൈസേഷനായി IETF-ലേക്ക് മാറ്റി (ഇപ്പോഴും അത് തുടരുന്നു), ഇപ്പോൾ എല്ലാവർക്കും നഷ്ടപ്പെട്ടതെന്താണെന്ന് നിർദ്ദേശിച്ചുകൊണ്ട് പ്രോട്ടോക്കോളിൻ്റെ വികസനത്തിൽ പങ്കെടുക്കാം. IETF വർക്കിംഗ് ഗ്രൂപ്പ് വാർഷിക മീറ്റിംഗുകൾ സംഘടിപ്പിക്കുന്നു, ഈ സമയത്ത് ഒരു പുതിയ സ്റ്റാൻഡേർഡ് അംഗീകരിക്കുകയും പുതുമകൾ ചർച്ച ചെയ്യുകയും ചെയ്യുന്നു. ക്യുഐസിയുടെ ഈ നടപ്പാക്കൽ പ്രധാനമായി കണക്കാക്കപ്പെടുന്നു, അതിൻ്റെ അടിസ്ഥാനത്തിലാണ് HTTP/3 നിലവാരം സാക്ഷ്യപ്പെടുത്തിയത്.

ഇതുവരെ, പ്രധാന പ്രോട്ടോക്കോളായി HTTP/3 ഉൾപ്പെടുത്തുന്നതിനെക്കുറിച്ച് ഒരു ചർച്ചയും നടന്നിട്ടില്ല, കാരണം ഇത് ഇതുവരെ പൂർത്തിയായിട്ടില്ല, മിക്കവാറും പിന്തുണയ്ക്കുന്നില്ല:

എന്നാൽ Uber-ൽ വിജയകരമായി നടപ്പിലാക്കിയ ആപ്ലിക്കേഷനും സെർവറും തമ്മിലുള്ള ഗതാഗതമായി QUIC നടപ്പിലാക്കാൻ കഴിയും:

ക്യുഐസിയുടെ ആമുഖത്തെക്കുറിച്ചുള്ള ഊബറിൻ്റെ അഭിപ്രായം

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-നെ സംയോജിപ്പിക്കാൻ കഴിയുമെന്ന് ഉറപ്പാക്കുകയും ചെയ്യുന്നു.

നിന്ന് എടുത്തത് ഈ വിവർത്തനം Uber ലേഖനങ്ങൾ

ബാക്കെൻഡിൽ അവർ Google Cloud lb വഴി QUIC കണക്ഷനുകൾ പിടിച്ചു പ്രോട്ടോക്കോൾ പിന്തുണയ്ക്കുന്നു 2018 പകുതി മുതൽ.

Google വികസിപ്പിച്ച പ്രോട്ടോക്കോളിനൊപ്പം Google ക്ലൗഡ് മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നതിൽ അതിശയിക്കാനില്ല, എന്നാൽ ഇതരമാർഗങ്ങൾ എന്തൊക്കെയാണ്?

നിക്കിക്സ്

അധികം താമസിയാതെ CloudFlare ഞാൻ കടക്കാൻ ശ്രമിച്ചു nginx (ഇത് സ്ഥിരസ്ഥിതിയായി HTTP/3 പിന്തുണയ്ക്കുന്നില്ല) അതിൻ്റെ Quiche ടൂൾ ഉപയോഗിച്ച്. ഒരു ഇൻസ്റ്റലേഷൻ ട്യൂട്ടോറിയലിനൊപ്പം വരുന്ന ഒരൊറ്റ .patch ഫയലായി നടപ്പിലാക്കൽ ലഭ്യമാണ്:

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

ആവശ്യമെങ്കിൽ നിങ്ങളുടെ മൊഡ്യൂളുകൾ ഇവിടെ ബന്ധിപ്പിക്കാവുന്നതാണ്

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

HTTP/3 പിന്തുണ പ്രവർത്തനക്ഷമമാക്കുക മാത്രമാണ് അവശേഷിക്കുന്നത്

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering in not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

സാധാരണ ബ്രൗസറുകളിൽ HTTP/3 വഴി കണക്റ്റുചെയ്യുന്നത് ഇതുവരെ സാധ്യമല്ല, പക്ഷേ നിങ്ങൾക്ക് ഉപയോഗിക്കാം Chrome കാനറി അത് പതാക ഉപയോഗിച്ച് പ്രവർത്തിപ്പിക്കുക --enable-quic, നിങ്ങളുടെ സെർവറിലേക്ക് പോകുക അല്ലെങ്കിൽ, ഉദാഹരണത്തിന്, quic.rocks സൈറ്റിലേക്ക് പോയി ഡെവലപ്പർ ടൂളുകളിലെ കണക്ഷൻ തരം നോക്കുക:

HTTP/3 ന് പകരം എഴുതിയിരിക്കുന്നു http2+quic/99, എന്നാൽ ഇത് അടിസ്ഥാനപരമായി ഒന്നുതന്നെയാണ്.

മറ്റ് സാങ്കേതികവിദ്യകൾ

• QUIC പിന്തുണയ്ക്കുന്നു ലൈറ്റ്സ്പീഡ് (വലിയ ആവേശത്തോടെ HTTP/3 വഴി Facebook-ലേക്ക് കണക്‌റ്റ് ചെയ്‌തത്) ഒപ്പം പുരോഗമനപരവും കാഡി. അപ്പാച്ചെയ്ക്ക് ഇതുവരെ അത് ചെയ്യാൻ കഴിയില്ല, പക്ഷേ ജോലികൾ നടന്നുകൊണ്ടിരിക്കുകയാണ് മുഴുവൻ സ്വിംഗ്.
• ജനുവരി 21 അപ്ഡേറ്റ് ചെയ്തു WebRTC-യുടെ ഡ്രാഫ്റ്റ് സ്റ്റാൻഡേർഡ്
• കഴിഞ്ഞ ദിവസം മൈക്രോസോഫ്റ്റ് തുറന്നു msquic നടപ്പിലാക്കൽ കോഡ്, ഇതിൽ IETF സ്റ്റാൻഡേർഡിൽ നിന്നുള്ള എല്ലാ ഫംഗ്ഷനുകളും ഇതുവരെ ലഭ്യമല്ല, എന്നാൽ ഇത് ഇതിനകം തന്നെ ഒരു വലിയ മുന്നേറ്റമാണ്.

തീരുമാനം

ക്യുഐസിയിലെ താൽപ്പര്യം അസ്ഥിരമാണ്, പക്ഷേ വളരുന്നു, അത് സ്റ്റാൻഡേർഡ് ചെയ്യുന്നതിനുള്ള പ്രവർത്തനങ്ങൾ നടക്കുന്നു. പ്രോട്ടോക്കോളിൻ്റെ പുതിയ നിർവ്വഹണങ്ങൾ മിക്കവാറും എല്ലാ മാസവും പ്രത്യക്ഷപ്പെടുന്നു, കൂടാതെ ഓരോ വർഷവും കൂടുതൽ കൂടുതൽ ഡവലപ്പർമാർക്ക് QUIC ഭാവിയാണെന്ന് ബോധ്യപ്പെടുന്നു. ടിസിപി സ്റ്റാക്കിൻ്റെ ഭാവി പതിപ്പുകളിൽ പ്രോട്ടോക്കോൾ ഉൾപ്പെടുത്തുന്നത് പോലും സാധ്യമാണ്, അതായത് താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട് മുഴുവൻ ഇൻ്റർനെറ്റും കൂടുതൽ സ്ഥിരതയുള്ളതും വേഗതയേറിയതുമായ കണക്ഷനുകളിലേക്ക് നീങ്ങും.

ഇപ്പോൾ തന്നെ നിങ്ങൾക്ക് നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിനായി QUIC ഇടപെടൽ കോൺഫിഗർ ചെയ്യാനോ ബ്രൗസറുകൾക്ക് നൽകാനോ കഴിയും - അവരെല്ലാം പ്രോട്ടോക്കോളിനുള്ള പിന്തുണ ചേർക്കാൻ പദ്ധതിയിടുന്നു, കൂടാതെ കാനിയസ് ഉള്ള ദുഃഖകരമായ സ്ഥിതിവിവരക്കണക്കുകൾ കൂടുതൽ സന്തോഷപ്രദമാകും.

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