HTTP UDP-ի վրա՝ լավ օգտվելով QUIC արձանագրությունից

QUIC (Quick UDP Internet Connections) UDP-ի վերևում գտնվող արձանագրություն է, որն աջակցում է TCP, TLS և HTTP/2-ի բոլոր հնարավորությունները և լուծում դրանց խնդիրների մեծ մասը: Այն հաճախ անվանում են նոր կամ «փորձարարական» արձանագրություն, սակայն այն վաղուց արդեն գերազանցել է փորձնական փուլը. մշակումը շարունակվում է ավելի քան 7 տարի: Այս ընթացքում արձանագրությունը չհասցրեց ստանդարտ դառնալ, բայց այնուամենայնիվ լայն տարածում գտավ։ Օրինակ, QUIC-ն օգտագործվում է այնպիսի հսկաների կողմից, ինչպիսիք են Google-ը և Facebook-ը՝ երթևեկությունն արագացնելու և շարժական ցանցերում ուշացումները նվազեցնելու համար, և IETF-ն արձանագրության իր պատառաքաղը հայտարարեց HTTP/3 ստանդարտի հիմքը (չնայած, որ HTTP/2 օգտագործում է ընդամենը 44.8% կայքեր).

Հայեցակարգ

QUIC-ը մշակվել է որպես ժառանգական TCP-ի փոխարինում, որն ի սկզբանե նախատեսված էր ցածր կորստի լարային ցանցերի համար: TCP-ն առաքում է փաթեթները հերթականությամբ, այնպես որ, եթե մեկ փաթեթը կորչում է, ամբողջ հերթը դադարեցվում է (գլխավոր արգելափակում), ինչը բացասաբար է անդրադառնում կապի որակի և կայունության վրա։ Զանգվածային կորուստներից խուսափելու համար բջջային ցանցերը դիմում են մեծ բուֆերների օգտագործմանը, որն իր հերթին հանգեցնում է արձանագրության ավելորդության և կեղծ բացասական արձագանքի (bufferbloat) Բացի այդ, TCP-ն շատ ժամանակ է ծախսում կապ հաստատելու համար. SYN/ACK և TLS հարցումները գնում են առանձին՝ պահանջելով երեք հետադարձ երթևեկություն մեկի փոխարեն, ինչպես անում է QUIC-ը:

Քանի որ QUIC-ը համատեղում է TCP-ի փոխարինումը և TLS 1.3-ի ներդրումը, բոլոր կապերը միշտ գաղտնագրված են, և այդպիսի երթևեկության վերծանումը հեշտ չէ, քան եթե այն անցնում է HTTPS-ով: Բացի այդ, QUIC-ն իրականացվում է հավելվածի մակարդակում, քանի որ կպահանջվի TCP փաթեթի ամբողջական փոխարինում ընդմիշտ.

Չնայած HTTP/2-ում մուլտիպլեքսավորման աջակցությանը, գլխավոր գծի արգելափակման խնդիրը մնաց այնտեղ՝ փաթեթները կարգի բերելու անհրաժեշտության պատճառով: QUIC-ն իրականացվում է UDP-ի վրա, ուստի այն սկզբունքորեն չունի արգելափակում, և որպեսզի փաթեթները ընդմիշտ չկորցնեն, դրանք համարակալված են և կարող են պարունակել «հարևանների» մասեր՝ ապահովելով ավելորդություն: Բացի այդ, QUIC-ը բաժանում է միաձույլ հերթը մի քանի թելերի՝ մեկ կապի շրջանակներում տարբեր տեսակի հարցումների համար: Այսպիսով, եթե փաթեթը կորչում է, խնդիրներ կարող են առաջանալ միայն մեկ հերթի համար (օրինակ՝ որոշակի ֆայլ փոխանցելու համար).

Օգտագործում

Սկզբում QUIC-ը մշակվել էր Google-ի շրջանակներում և հիմնականում մշակվել էր ընկերության ներսում օգտագործելու համար: 2013 թվականին այն փոխանցվել է IETF-ին ստանդարտացման համար (որը դեռ շարունակվում է), և այժմ բոլորը կարող են մասնակցել արձանագրության մշակմանը` առաջարկելով այն, ինչ բացակայում է։ IETF-ի աշխատանքային խումբը կազմակերպում է տարեկան հանդիպումներ, որոնց ընթացքում հաստատվում է նոր ստանդարտ և քննարկվում են նորարարությունները։ QUIC-ի այս իրականացումը համարվում է հիմնականը և դրա հիման վրա է, որ հավաստագրված է HTTP/3 ստանդարտը:

Առայժմ որևէ խոսակցություն չկա HTTP/3-ը որպես հիմնական արձանագրություն ներառելու մասին, քանի որ այն դեռ ավարտված չէ և գրեթե չի աջակցվում.

Բայց QUIC-ը կարող է իրականացվել որպես փոխադրամիջոց հավելվածի և սերվերի միջև, ինչը հաջողությամբ իրականացվել է Uber-ում.

Uber-ի մեկնաբանությունը QUIC-ի ներդրման վերաբերյալ

QUIC-ը հաջողությամբ զետեղելու և հավելվածի աշխատանքը վատ կապակցված միջավայրում բարելավելու համար մենք փոխարինեցինք հին փաթեթը (HTTP/2՝ TLS/TCP-ով) QUIC արձանագրությամբ: Մենք օգտագործեցինք ցանցային գրադարանը Կրոնետ - ից Chromium նախագծեր, որը պարունակում է արձանագրության բնօրինակ, Google տարբերակը՝ gQUIC: Այս իրականացումը նույնպես մշտապես բարելավվում է՝ հետևելու IETF-ի վերջին ճշգրտմանը:

Մենք նախ ինտեգրեցինք Cronet-ը մեր Android հավելվածներում՝ QUIC-ին աջակցություն ավելացնելու համար: Ինտեգրումն իրականացվել է այնպես, որ հնարավորինս կրճատվեն միգրացիոն ծախսերը։ Գրադարանն օգտագործող հին ցանցային կույտը ամբողջությամբ փոխարինելու փոխարեն OkHttp, մենք ինտեգրել ենք Cronet-ը OkHttp API շրջանակի ներքո: Այս կերպ ինտեգրումը կատարելով՝ մենք խուսափեցինք մեր ցանցային զանգերի փոփոխություններից (որոնք օգտագործվում են Փոխհատուցում) API մակարդակում:

Android սարքերի մոտեցման նման՝ մենք Cronet-ը ներդրեցինք Uber հավելվածներում iOS-ում՝ ընդհատելով HTTP տրաֆիկը ցանցից։ APIօգտագործելով NSURL արձանագրություն. Այս աբստրակցիան, որը տրամադրվել է iOS հիմնադրամի կողմից, մշակում է արձանագրության հատուկ URL-ի տվյալները և երաշխավորում է, որ մենք կարող ենք ինտեգրել Cronet-ը մեր iOS հավելվածներում՝ առանց զգալի միգրացիոն ծախսերի:

վերցված ինչ - որ տեղից այս թարգմանությունը Uber-ի հոդվածներ

Backend-ում նրանք որսացել են QUIC կապեր Google Cloud lb-ի միջոցով, որը աջակցում է արձանագրությանը 2018 թվականի կեսերից։

Զարմանալի չէ, որ Google Cloud-ը հիանալի է աշխատում Google-ի կողմից մշակված արձանագրության հետ, բայց որո՞նք են այլընտրանքները:

Nginx

Ոչ վաղ անցյալում 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 Canary- ը և գործարկել դրոշով --enable-quic, գնացեք ձեր սերվեր կամ, օրինակ, quic.rocks կայք և դիտեք կապի տեսակը Developer Tools-ում.

HTTP/3-ի փոխարեն գրված է http2+quic/99, բայց ըստ էության նույն բանն է։

Այլ տեխնոլոգիաներ

• QUIC-ը նաև աջակցում է LiteSpeed (որը միացել է Facebook-ին HTTP/3-ի միջոցով մեծ աղմուկով) և պրոգրեսիվ Թեյատուփ. Apache-ն դեռ չի կարող դա անել, բայց աշխատանքներն ընթանում են ամբողջ թափով.
• Հունվարի 21-ը թարմացվել է WebRTC ստանդարտի նախագիծը
• Հենց օրերս բացվեց Microsoft-ը msquic իրականացման կոդը, որում դեռևս հասանելի չեն IETF ստանդարտի բոլոր գործառույթները, բայց սա արդեն մեծ առաջընթաց է։

Ամփոփում

QUIC-ի նկատմամբ հետաքրքրությունը անկայուն է, բայց աճում է, և աշխատանքներ են տարվում այն ​​ստանդարտացնելու ուղղությամբ: Արձանագրության նոր իրականացումներ են հայտնվում գրեթե ամեն ամիս, և ամեն տարի ավելի ու ավելի շատ մշակողներ են համոզված, որ QUIC-ը ապագան է: Հնարավոր է նույնիսկ արձանագրությունը ներառել TCP stack-ի ապագա տարբերակներում, ինչը նշանակում է, որ վաղ թե ուշ ամբողջ ինտերնետը կտեղափոխվի ավելի կայուն և արագ կապեր:

Արդեն այժմ դուք կարող եք կարգավորել QUIC փոխազդեցությունը ձեր ենթակառուցվածքի համար կամ նույնիսկ տալ այն բրաուզերներին. նրանք բոլորը ծրագրում են ավելացնել արձանագրության աջակցությունը, և Caniuse-ի տխուր վիճակագրությունը կդառնա ավելի ուրախ:

Source: www.habr.com