HTTP/1.1, HTTP/2 և HTTP/3

01HTTP/1.1՝ մեկ հարցում միաժամանակ

HTTP/1.1-ը (1997, ճշգրտված RFC 9112-ում) տեքստային է։ Keep-alive-ը թույլ է տալիս կապը վերաօգտագործել, բայց յուրաքանչյուր կապում հարցումներին պատասխանվում է խիստ մեկը մյուսի հետևից․ եթե մեկ պատասխանը դանդաղ է, դրա հետևում ամեն ինչ սպասում է։ Սա head-of-line blocking է HTTP մակարդակում։ Բրաուզերները դա շրջանցում են՝ յուրաքանչյուր host-ի համար բացելով մոտ վեց կապ, իսկ ծրագրավորողներն օգտագործում էին հնարքներ՝ domain sharding մի քանի hostname-ների միջև, image sprite-ներ և ամբողջ JavaScript-ի միավորում մեկ ֆայլում։ Header-ներն ուղարկվում են պարզ տեքստով յուրաքանչյուր հարցման հետ, ուստի cookie-ներն ու user agent-ները հազարավոր անգամներ են կրկնվում։ Անալոգիա՝ մեկ դրամարկղ, որտեղ յուրաքանչյուր գնորդ պետք է ավարտի, մինչև հաջորդը սկսի, ուստի խանութները բացում են վեց դրամարկղ։

02HTTP/2՝ multiplexing և HPACK

HTTP/2-ը (2015, այժմ RFC 9113) պահպանում է նույն մեթոդները, header-ները և status code-երը, բայց wire format-ը փոխում է բինար frame-երի։ Նրա գլխավոր հնարավորությունը multiplexing-ն է․ շատ հարցումներ և պատասխաններ միաժամանակ անցնում են մեկ TCP կապով՝ որպես անկախ stream-ներ, frame առ frame խառնված։ Մեկ դանդաղ պատասխանն այլևս չի արգելափակում մյուսներին HTTP մակարդակում։ HPACK-ը սեղմում է header-ները՝ օգտագործելով նախկինում ուղարկված արժեքների աղյուսակ, այնպես որ կրկնվող cookie-ներն ու header-ները արժեն մի քանի բայթ։ Prioritization-ը թույլ է տալիս բրաուզերին ազդանշել, թե ինչն է ամենակարևորը։ Server push-ը գոյություն ուներ, բայց հեռացվեց բրաուզերներից, որովհետև հազվադեպ էր օգնում․ 103 Early Hints-ը preload-ի հետ փոխարինում է այն։ Գործնականում բրաուզերները HTTP/2 օգտագործում են միայն TLS-ի վրա, որը համաձայնեցվում է ALPN-ի միջոցով handshake-ի ժամանակ։

• Մեկ կապ յուրաքանչյուր origin-ի համար՝ վեցի փոխարեն․ ավելի քիչ handshake-եր։
• Domain sharding-ն այժմ վնասում է․ այն ստիպում է լրացուցիչ կապեր բացել։
• Շատ փոքր ֆայլերը նորմալ են․ bundle-ները բաժանեք ըստ route-ի՝ մեկ հսկա ֆայլի փոխարեն։

03Մնացած խնդիրը՝ TCP head-of-line blocking

HTTP/2-ը շտկեց արգելափակումը HTTP շերտում, բայց ոչ դրա տակ։ TCP-ն երաշխավորում է, որ բայթերը հասնում են հերթականությամբ։ Եթե մեկ փաթեթ կորչում է, TCP-ն դրանից հետո եկած ամեն ինչ պահում է, մինչև կորած փաթեթը վերաուղարկվի, նույնիսկ այլ stream-երին պատկանող տվյալները։ Մաքուր գրասենյակային ցանցում դա հազվադեպ է։ 1–2% փաթեթների կորուստ ունեցող մոբայլ ցանցերում մեկ կորած փաթեթը կանգնեցնում է այդ կապի բոլոր պատկերները, սկրիպտները և API կանչերը։ Վատ պայմաններում մեկ կապով HTTP/2-ը կարող է նույնիսկ ավելի դանդաղ լինել, քան վեց կապով HTTP/1.1-ը։ TCP-ն նաև ապրում է օպերացիոն համակարգի kernel-ում, ուստի այն բարելավելը տարիներ է պահանջում OS-ի թարմացումների համար։ Ահա թե ինչու էր պետք նոր տրանսպորտ։

04HTTP/3՝ QUIC UDP-ի վրա

HTTP/3-ն (RFC 9114, 2022) աշխատում է QUIC-ի (RFC 9000) վրա՝ UDP-ի վրա կառուցված տրանսպորտ։ QUIC-ն ինքն է իրականացնում հուսալիությունը, congestion control-ը և stream-երը, և յուրաքանչյուր stream անկախ է․ կորած փաթեթը հետաձգում է միայն իր stream-ը։ TLS 1.3-ը ներկառուցված է QUIC-ի մեջ, ուստի նոր կապին պետք է մեկ round trip՝ TCP-ի և TLS-ի երկու կամ երեքի փոխարեն, իսկ վերսկսված կապերը կարող են տվյալներ ուղարկել անմիջապես (0-RTT, որը պետք է սահմանափակել safe, idempotent հարցումներով, որովհետև այն կարող է replay արվել)։ Կապերը նույնականացվում են connection ID-ով, ոչ թե IP-ով և պորտով, այնպես որ Wi-Fi-ից մոբայլ ինտերնետի անցնող հեռախոսը պահպանում է իր կապը։ Header-ներն օգտագործում են QPACK՝ HPACK-ի տարբերակ։ Բրաուզերները HTTP/3-ը հայտնաբերում են Alt-Svc header-ի կամ HTTPS DNS գրառման միջոցով և վերադառնում HTTP/2-ի, եթե UDP 443-ը արգելափակված է։

05Միացում nginx-ում և Cloudflare-ում

nginx 1.25.1 կամ ավելի նոր տարբերակում HTTP/2-ը միացվում է http2 դիրեկտիվով (հին listen ... http2 պարամետրը deprecated է), իսկ HTTP/3-ը՝ նույն պորտի վրա quic listener-ով, որը կառուցված է QUIC մոդուլով, ինչը ներառված է ընթացիկ պաշտոնական փաթեթներում։ HTTP/3-ը հայտարարեք Alt-Svc header-ով և firewall-ում բացեք UDP 443-ը։ Cloudflare-ում HTTP/2-ն ու HTTP/3-ը դեպի այցելուներ լռելյայն միացված են․ դրանք կարող եք ստուգել Speed կամ Network կարգավորումներում։ Cloudflare-ից ձեր origin կապն առանձին է․ այն օգտագործում է HTTP/1.1 կամ HTTP/2 TCP-ի վրա, ուստի Cloudflare-ի հետևում գտնվող origin-ին HTTP/3 պետք չէ։ Ստուգեք curl-ով կամ բրաուզերի Network tab-ի Protocol սյունակով։

1server {
2    listen 443 ssl;
3    listen 443 quic reuseport;   # reuseport only once per port
4    http2 on;
5    http3 on;
6    server_name example.com;
7    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
8    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
9    ssl_protocols TLSv1.2 TLSv1.3;
10    add_header Alt-Svc 'h3=":443"; ma=86400' always;
11}
12# sudo ufw allow 443/udp
13# curl -sI --http2 https://example.com/ | head -1

06Ինչ է դա նշանակում performance-ի աշխատանքի համար

HTTP/2-ը կամ HTTP/3-ը միացնելուց հետո կենտրոնացեք այն բանի վրա, ինչը դեռ ժամանակ է խլում։ Round trip-երը դեռ կարևոր են, ուստի critical path-ը պահեք կարճ՝ preload արեք hero պատկերն ու հիմնական ֆոնտը, խուսափեք redirect-ների երկար շղթաներից և մատուցեք օգտատերերին մոտ CDN-ից։ Բայթերը դեռ կարևոր են, ուստի սեղմեք և ուղարկեք ավելի քիչ JavaScript։ Միավորումը (concatenation) ավելի քիչ կարևոր է, բայց հազարավոր փոքրիկ մոդուլները դեռ overhead ունեն․ bundler-ների route-level splitting-ն օպտիմալ միջինն է։ Խուսափեք domain sharding-ից և ավելորդ third-party origin-ներից, քանի որ յուրաքանչյուր նոր origin պահանջում է DNS, կապի և TLS կարգավորում․ նրանց համար, որոնք պետք է պահեք, օգտագործեք preconnect։ Չափեք իրական օգտատերերին․ HTTP/3-ի բարելավումները հիմնականում երևում են դանդաղ և փաթեթներ կորցնող ցանցերում, ոչ թե ձեր արագ desktop-ում։

07Prioritization. dependency tree-երից մինչև Extensible Priorities

Multiplexing-ը նոր հարց է առաջացնում. երբ քսան պատասխան կիսում են մեկ կապ, որ բայթերն են գնում առաջինը։ HTTP/2-ն ի սկզբանե թույլ էր տալիս client-ներին կառուցել dependency tree՝ կշիռներով, բայց դա բարդ էր, բրաուզերներն այն օգտագործում էին անհետևողական, իսկ շատ սերվերներ անտեսում էին, ուստի RFC 9113-ը այն deprecated դարձրեց։ Փոխարինողը Extensible Priorities-ն է (RFC 9218), որն օգտագործում են HTTP/2-ը և HTTP/3-ը։ Client-ը ուղարկում է պարզ Priority header կամ frame. urgency u՝ 0-ից (ամենաբարձր) մինչև 7, և incremental դրոշակ i, որը նշանակում է, որ պատասխանն օգտակար է նաև կտորներով, ինչպես progressive նկարը։ Սերվերները և CDN-ները համապատասխանաբար են պլանավորում տվյալները, ուստի CSS-ը և LCP նկարը կարող են առաջ անցնել մեծ analytics script-ից։ Էջում fetchpriority-ն և preload-ը այն միջոցներն են, որոնցով ազդում եք, թե ինչ է ուղարկում բրաուզերը։ Եթե ճանապարհին ինչ-որ տեղ prioritization-ը կոտրված է, multiplexing-ը կարող է իրականում ուշացնել կրիտիկական ֆայլերը մեծերի հետևում։

1GET /css/main.css HTTP/2
2priority: u=0
3 
4GET /img/hero.avif HTTP/2
5priority: u=1, i
6 
7GET /js/analytics.js HTTP/2
8priority: u=5

08Flow control և HTTP/2-ին հատուկ հարձակումներ

HTTP/2-ը և QUIC-ը ունեն flow control ըստ stream-ի և ըստ կապի. յուրաքանչյուր կողմ հայտարարում է բայթերի պատուհան, որը պատրաստ է ստանալ, և ուղարկողը պետք է սպասի WINDOW_UPDATE-ին՝ ավելին ուղարկելուց առաջ։ Փոքր լռելյայն պատուհանները կարող են սահմանափակել throughput-ը արագ, երկար կապուղիներում, ահա թե ինչու սերվերները դրանք կարգավորում են։ Multiplexing-ը ստեղծեց նաև denial-of-service-ի նոր pattern-ներ։ 2023-ին Rapid Reset հարձակումը (CVE-2023-44487) հսկայական քանակությամբ բացում և անմիջապես չեղարկում էր stream-ներ, ուստի սերվերներն աշխատանք էին կատարում հարցումների համար, որոնք երբեք չէին հաշվվում concurrency limit-ների մեջ. դա ռեկորդային հեղեղներ առաջացրեց։ HPACK-ը և QPACK-ը header table-ի չափի սահմանափակումներ են պահանջում՝ հիշողության սպառումը կանխելու համար։ Պաշտպանությունը հիմնականում software update-ներն են և ողջամիտ limit-ները. nginx-ը և proxy-ները պահեք patch արված, սահմանափակեք միաժամանակյա stream-ները (http2_max_concurrent_streams, nginx-ում լռելյայն 128), սահմանափակեք header-ների չափը և թողեք, որ CDN-ը կլանի ծավալային հարձակումները։

09QUIC-ը ներսից. handshake-ներ, loss recovery, migration

QUIC փաթեթները գաղտնագրված են, ներառյալ header-ի մեծ մասը, ուստի միջանկյալ սարքերը չեն կարող ստուգել կամ փոփոխել transport-ի մանրամասները, ինչը պրոտոկոլը զարգացման համար բաց է պահում։ Packet համարները երբեք չեն կրկնվում, նույնիսկ retransmission-ների դեպքում, ինչը վերացնում է TCP-ի անորոշությունը, թե որ պատճենին է վերաբերում acknowledgement-ը, և round trip-ի գնահատումները դարձնում է ավելի ճշգրիտ։ Մինչև client-ի հասցեի validation-ը սերվերը կարող է ուղարկել ստացածից առավելագույնը երեք անգամ ավելի բայթ, ինչը թույլ չի տալիս QUIC-ն օգտագործել amplification հարձակումների համար. բեռի տակ token-ով Retry փաթեթը կարող է նախ հաստատել հասցեն։ Connection ID-ները թույլ են տալիս հեռախոսին փոխել ցանցը առանց նոր handshake-ի, և endpoint-ը ստուգում է նոր ճանապարհը՝ նախքան դրան վստահելը։ Գինը. QUIC-ն աշխատում է user space-ում, գաղտնագրումը կատարվում է ամեն փաթեթի համար, իսկ UDP-ի send և receive ճանապարհները պակաս օպտիմալացված են, քան TCP-ինը, ուստի CPU-ի ծախսը մեկ բայթի համար ավելի բարձր է։ Kernel-ի ֆունկցիաները, ինչպես UDP GSO-ն և ավելի մեծ socket buffer-ները, նվազեցնում են տարբերությունը։

10Discovery, fallback և իրական աշխարհի խառնուրդը

Բրաուզերը նախապես չի կարող իմանալ, որ սերվերը խոսում է HTTP/3-ով։ Սովորական ճանապարհը. առաջին այցն օգտագործում է HTTP/2 TCP-ով, պատասխանը ներառում է Alt-Svc: h3=":443", և հաջորդ կապերը QUIC-ը և TCP-ն մրցեցնում են՝ օգտագործելով այն, որն աշխատում է։ HTTPS DNS record-ը կարող է h3-ը հայտարարել դեռ առաջին կապից առաջ՝ բաց թողնելով այդ քայլը։ Եթե UDP 443-ը արգելափակված է կամ rate-limit է արված firewall-ի կողմից, բրաուզերը լուռ վերադառնում է TCP-ին և կարող է որոշ ժամանակ հիշել ձախողումը, ուստի սխալ կարգավորված սերվերը հազվադեպ է կոտրված թվում. այն պարզապես երբեք HTTP/3 տրաֆիկ չի ստանում։ Սերվերում ստուգեք, որ firewall-ը և ցանկացած cloud security group թույլ են տալիս UDP 443, որ երկու listener-ներում էլ մատուցվում է նույն սերտիֆիկատը, և որ load balancer-ները փոխանցում են UDP։ Log-երում գրանցեք պրոտոկոլը յուրաքանչյուր հարցման համար (nginx-ում $server_protocol)՝ յուրաքանչյուր տարբերակի իրական բաժինը տեսնելու համար։

1# Ask for HTTP/3 directly (curl built with HTTP/3 support)
2curl -sI --http3-only https://example.com/ | head -1
3# Is h3 advertised?
4curl -sI https://example.com/ | grep -i alt-svc
5dig example.com HTTPS +short
6# nginx log format: add the protocol per request
7# log_format main '$remote_addr "$request" $status $server_protocol';