UDP પર HTTP - QUIC પ્રોટોકોલનો સારો ઉપયોગ કરવો

QUIC (ક્વિક UDP ઈન્ટરનેટ કનેક્શન્સ) એ UDP ની ટોચ પર એક પ્રોટોકોલ છે જે TCP, TLS અને HTTP/2 ની તમામ સુવિધાઓને સપોર્ટ કરે છે અને તેમની મોટાભાગની સમસ્યાઓનું નિરાકરણ કરે છે. તેને ઘણીવાર નવો અથવા "પ્રાયોગિક" પ્રોટોકોલ કહેવામાં આવે છે, પરંતુ તે લાંબા સમયથી પ્રાયોગિક તબક્કાથી આગળ નીકળી ગયું છે: વિકાસ 7 વર્ષથી વધુ સમયથી ચાલુ છે. આ સમય દરમિયાન, પ્રોટોકોલ પ્રમાણભૂત બનવાનું મેનેજ કરી શક્યું ન હતું, પરંતુ તે હજી પણ વ્યાપક બન્યું હતું. ઉદાહરણ તરીકે, QUIC નો ઉપયોગ Google અને Facebook જેવા જાયન્ટ્સ દ્વારા ટ્રાફિકને ઝડપી બનાવવા અને મોબાઇલ નેટવર્કમાં વિલંબ ઘટાડવા માટે કરવામાં આવે છે, અને IETF એ તેના પ્રોટોકોલના ફોર્કને HTTP/3 સ્ટાન્ડર્ડનો આધાર જાહેર કર્યો (ભલે HTTP/2 ઉપયોગ કરે છે. માત્ર 44.8% સાઇટ્સ).

કન્સેપ્ટ

ક્વિકને લેગસી TCPના રિપ્લેસમેન્ટ તરીકે વિકસાવવામાં આવ્યું હતું, જે મૂળ રીતે ઓછા-નુકસાનવાળા વાયર્ડ નેટવર્ક્સ માટે ડિઝાઇન કરવામાં આવ્યું હતું. TCP ક્રમમાં પેકેટો પહોંચાડે છે, તેથી જો એક પેકેટ ખોવાઈ જાય, તો આખી કતાર બંધ થઈ જાય છે (હેડ-ઓફ-લાઇન બ્લોકિંગ), જે કનેક્શનની ગુણવત્તા અને સ્થિરતાને નકારાત્મક રીતે અસર કરે છે. મોટા પ્રમાણમાં નુકસાન ટાળવા માટે, સેલ્યુલર નેટવર્ક્સ મોટા બફર્સનો ઉપયોગ કરે છે, જે બદલામાં પ્રોટોકોલની નિરર્થકતા અને ખોટા નકારાત્મક પ્રતિભાવ તરફ દોરી જાય છે (બફરબ્લોટ). વધુમાં, TCP કનેક્શન સ્થાપિત કરવામાં ઘણો સમય વિતાવે છે: SYN/ACK અને TLS વિનંતીઓ અલગથી જાય છે, જેમાં QUICની જેમ એકને બદલે ત્રણ રાઉન્ડટ્રીપની જરૂર પડે છે.

QUIC એ TCP રિપ્લેસમેન્ટ અને TLS 1.3 ના અમલીકરણને જોડતું હોવાથી, બધા કનેક્શન હંમેશા એન્ક્રિપ્ટેડ હોય છે, અને આવા ટ્રાફિકને ડિક્રિપ્ટ કરવું એ HTTPS પર જતા હોય તેના કરતાં વધુ સરળ નથી. વધુમાં, ક્વિક એપ્લીકેશન લેવલ પર લાગુ કરવામાં આવે છે, કારણ કે TCP સ્ટેકનું સંપૂર્ણ રિપ્લેસમેન્ટ લેવાશે અનંતકાળ.

HTTP/2 માં મલ્ટિપ્લેક્સિંગ માટે સમર્થન હોવા છતાં, ક્રમમાં પેકેટો પહોંચાડવાની જરૂરિયાતને કારણે હેડ-ઓફ-લાઇન બ્લોકિંગની સમસ્યા ત્યાં જ રહી. QUIC ને UDP ની ટોચ પર લાગુ કરવામાં આવે છે, તેથી તેમાં સૈદ્ધાંતિક રીતે કોઈ અવરોધ નથી, અને પેકેટોને હંમેશ માટે ખોવાઈ જતા અટકાવવા માટે, તેઓને ક્રમાંકિત કરવામાં આવે છે અને તેમાં "પડોશીઓ" ના ભાગો હોઈ શકે છે, જે નિરર્થકતા પ્રદાન કરે છે. વધુમાં, QUIC એક કનેક્શનમાં વિવિધ પ્રકારની વિનંતીઓ માટે એકવિધ કતારને બહુવિધ થ્રેડોમાં વિભાજિત કરે છે. આમ, જો પેકેટ ખોવાઈ જાય, તો માત્ર એક કતાર માટે સમસ્યાઓ ઊભી થઈ શકે છે (ઉદાહરણ તરીકે, કોઈ ચોક્કસ ફાઈલ ટ્રાન્સફર કરવા માટે):

ઉપયોગ કરો

શરૂઆતમાં, QUIC ને Google ની અંદર વિકસાવવામાં આવ્યું હતું અને મોટાભાગે કંપનીમાં ઉપયોગ માટે તૈયાર કરવામાં આવ્યું હતું. 2013 માં, તેને માનકીકરણ માટે IETF માં સ્થાનાંતરિત કરવામાં આવ્યું હતું (જે હજી પણ ચાલુ છે), અને હવે દરેક વ્યક્તિ તેમની પાસે શું ખૂટે છે તે પ્રસ્તાવિત કરીને પ્રોટોકોલના વિકાસમાં ભાગ લઈ શકે છે. IETF કાર્યકારી જૂથ વાર્ષિક મીટિંગ્સનું આયોજન કરે છે જે દરમિયાન નવા ધોરણને મંજૂરી આપવામાં આવે છે અને નવીનતાઓની ચર્ચા કરવામાં આવે છે. QUIC ના આ અમલીકરણને મુખ્ય ગણવામાં આવે છે અને તે તેના આધારે છે કે HTTP/3 પ્રમાણભૂત પ્રમાણિત છે.

અત્યાર સુધી, મુખ્ય પ્રોટોકોલ તરીકે HTTP/3 નો સમાવેશ કરવા વિશે કોઈ વાત નથી, કારણ કે તે હજી પૂર્ણ થયું નથી અને લગભગ સમર્થિત નથી:

પરંતુ QUIC ને એપ્લિકેશન અને સર્વર વચ્ચે પરિવહન તરીકે લાગુ કરી શકાય છે, જે ઉબેર પર સફળતાપૂર્વક કરવામાં આવ્યું હતું:

QUIC ની રજૂઆત પર Uberની ટિપ્પણી

QUIC ને સફળતાપૂર્વક એમ્બેડ કરવા અને નબળા કનેક્ટિવિટી વાતાવરણમાં એપ્લિકેશન પ્રદર્શનને સુધારવા માટે, અમે જૂના સ્ટેક (HTTP/2 ઓવર TLS/TCP) ને QUIC પ્રોટોકોલ સાથે બદલ્યું છે. અમે નેટવર્ક લાઇબ્રેરીનો ઉપયોગ કર્યો ક્રોનેટ થી ક્રોમિયમ પ્રોજેક્ટ્સ, જેમાં પ્રોટોકોલનું મૂળ, Google સંસ્કરણ છે - gQUIC. નવીનતમ IETF સ્પષ્ટીકરણને અનુસરવા માટે આ અમલીકરણમાં પણ સતત સુધારો કરવામાં આવી રહ્યો છે.

QUIC માટે સમર્થન ઉમેરવા માટે અમે સૌપ્રથમ અમારી Android એપ્લિકેશન્સમાં Cronet એકીકૃત કર્યું. એકીકરણ એવી રીતે હાથ ધરવામાં આવ્યું હતું કે શક્ય તેટલું સ્થળાંતર ખર્ચ ઘટાડવા માટે. લાઇબ્રેરીનો ઉપયોગ કરતા જૂના નેટવર્કિંગ સ્ટેકને સંપૂર્ણપણે બદલવાને બદલે OkHttp, અમે OkHttp API ફ્રેમવર્ક હેઠળ Cronet ને સંકલિત કર્યું છે. આ રીતે એકીકરણ કરીને, અમે અમારા નેટવર્ક કૉલ્સમાં ફેરફારો ટાળ્યા (જેનો ઉપયોગ રીટ્રોફિટ) API સ્તર પર.

Android ઉપકરણો માટેના અભિગમની જેમ, અમે iOS પર ઉબેર એપ્લિકેશન્સમાં ક્રોનેટનો અમલ કર્યો, નેટવર્કમાંથી HTTP ટ્રાફિકને અટકાવી APIઉપયોગ કરીને NSURLપ્રોટોકોલ. iOS ફાઉન્ડેશન દ્વારા પ્રદાન કરવામાં આવેલ આ એબ્સ્ટ્રેક્શન પ્રોટોકોલ-વિશિષ્ટ URL ડેટાને હેન્ડલ કરે છે અને ખાતરી કરે છે કે અમે નોંધપાત્ર સ્થળાંતર ખર્ચ વિના ક્રોનેટને અમારી iOS એપ્લિકેશન્સમાં એકીકૃત કરી શકીએ છીએ.

માંથી લીધેલું આ અનુવાદ ઉબેર લેખો

બેકએન્ડ પર તેઓએ Google Cloud lb દ્વારા QUIC કનેક્શન્સ પકડ્યા, જે પ્રોટોકોલને સપોર્ટ કરે છે 2018 ના મધ્યથી.

તે આશ્ચર્યજનક નથી કે Google ક્લાઉડ Google-વિકસિત પ્રોટોકોલ સાથે શ્રેષ્ઠ કાર્ય કરે છે, પરંતુ વિકલ્પો શું છે?

Nginx

થોડા સમય પહેલા CloudFlare મેં પાર કરવાનો પ્રયત્ન કર્યો nginx (જે ડિફોલ્ટ રૂપે HTTP/3 ને સપોર્ટ કરતું નથી) તેના Quiche ટૂલ સાથે. અમલીકરણ સિંગલ .પેચ ફાઇલ તરીકે ઉપલબ્ધ છે, જે ઇન્સ્ટોલેશન ટ્યુટોરીયલ સાથે આવે છે:

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 દ્વારા કનેક્ટ કરવું હજી શક્ય નથી, પરંતુ તમે ઉપયોગ કરી શકો છો ક્રોમ કેનેરી અને ધ્વજ સાથે ચલાવો --enable-quic, તમારા સર્વર પર જાઓ અથવા, ઉદાહરણ તરીકે, quic.rocks સાઇટ પર જાઓ અને વિકાસકર્તા સાધનોમાં કનેક્શન પ્રકાર જુઓ:

HTTP/3 ને બદલે તે લખાયેલું છે http2+quic/99, પરંતુ તે અનિવાર્યપણે સમાન વસ્તુ છે.

અન્ય તકનીકો

• QUIC પણ સપોર્ટ કરે છે લિટસ્પીડ (જે ખૂબ જ ધામધૂમથી HTTP/3 દ્વારા Facebook સાથે જોડાયેલ છે) અને પ્રગતિશીલ અનુચર. અપાચે હજી તે કરી શકતું નથી, પરંતુ કામ ચાલુ છે પૂર જોશ માં.
• જાન્યુઆરી 21 અપડેટ WebRTC માટે ડ્રાફ્ટ સ્ટાન્ડર્ડ
• બીજા દિવસે માઈક્રોસોફ્ટ ખુલ્યું msquic અમલીકરણ કોડ, જેમાં IETF સ્ટાન્ડર્ડના તમામ કાર્યો હજુ સુધી ઉપલબ્ધ નથી, પરંતુ આ પહેલેથી જ એક મોટી સફળતા છે.

નિષ્કર્ષ

QUIC માં રસ અસ્થિર છે, પરંતુ વધી રહ્યો છે, અને તેને પ્રમાણિત કરવા માટે કામ ચાલી રહ્યું છે. પ્રોટોકોલના નવા અમલીકરણો લગભગ દર મહિને દેખાય છે, અને દર વર્ષે વધુને વધુ વિકાસકર્તાઓને ખાતરી થાય છે કે QUIC એ ભવિષ્ય છે. TCP સ્ટેકના ભાવિ સંસ્કરણોમાં પ્રોટોકોલનો સમાવેશ કરવો પણ શક્ય છે, જેનો અર્થ છે કે વહેલા કે પછી સમગ્ર ઈન્ટરનેટ વધુ સ્થિર અને ઝડપી જોડાણો પર જશે.

પહેલેથી જ હવે તમે તમારા ઇન્ફ્રાસ્ટ્રક્ચર માટે QUIC ક્રિયાપ્રતિક્રિયાને ગોઠવી શકો છો અથવા તેને બ્રાઉઝર્સને પણ આપી શકો છો - તે બધા પ્રોટોકોલ માટે સમર્થન ઉમેરવાનું આયોજન કરી રહ્યા છે, અને કેનિયુઝ સાથેના ઉદાસી આંકડા વધુ ખુશખુશાલ બનશે.

સોર્સ: www.habr.com