HTTP/3: հիմքերը խառնաշփոթ և հրաշալի նոր աշխարհ

Ավելին, քան 20 տարի մենք դիտում ենք վեբ էջեր HTTP արձանագրության միջոցով: Բազմաթիվ օգտատերեր իրականում չեն մտածում, թե ինչ է դա և ինչպես է աշխատում: Այլներն գիտեն, որ ինչ-որ տեղ HTTP-ի տակ կա TLS, իսկ նրա տակ TCP, որի տակ IP և այդպես շարունակ: Իսկ երրորդները՝ հերետիկոսները, կարծում են, որ TCP-ն անցյալ դարի երևույթ է, նրանք ցանկանում են ինչ-որ ավելի արագ, հուսալի և ապահով: Բայց իրենց փորձերում նոր կատարյալ արձանագրություն ստեղծելու նրանք վերադառնում են 80-ականների տեխնոլոգիաների և փորձում են կառուցել իրենց հրաշալի նոր աշխարհը:

Մ sedikit ն պատմություն: HTTP/1.1

1997 թվականին տեքստային տեղեկատվության փոխանակման արձանագրությունն HTTP 1.1 ստացավ իր RFC-ն: Այդ ժամանակ արձանագրությունը արդեն մի քանի տարի օգտագործվում էր բրաուզերներով, իսկ նոր ստանդարտն իր գոյությունը պահպանեց ևս տասնհինգ տարի: Արձանագրությունը գործում էր միայն հարցում-պատասխան սկզբունքի հիման վրա և նախատեսված էր հիմնականում տեքստային տեղեկատվության փոխանցման համար:

HTTP-ն նախագծված էր TCP արձանագրության հիման վրա, որը ապահովում էր փաթեթների հուսալի փոխանցումը հասցեատեր: TCP-ի աշխատանքը հիմնանվել է վերջնական կետերի միջև հուսալի կապի ստեղծման և պահելու վրա, ինչպես նաև տրաֆիկի հատվածների վրա բաժանելու: Հաղորդագրությունները ունեն իրենց հերթական համարը և ստուգման գումարը: Եթե հանկարծ որևէ հատված չհասներ կամ հասներ սխալ ստուգման գումարով, ապա փոխանցումը դադարում էր, մինչև կվերանորոգվի կորան հատվածը:

HTTP/1.0-ում TCP կապը փակվում էր յուրաքանչյուր հարցումից հետո: Դա չափազանց վատն էր, քանի որ TCP կապի ստեղծումը (3-Way Handshake) արագ գործընթաց չէ: HTTP/1.1-ում ներկայացվեց keep-alive մեխանիզմ, որն թույլատրում է կրկնակի օգտագործել մեկ կապ մի քանի հարցումների համար: Բայց քանի որ այն կարող է հեշտությամբ փոխվել Bottleneck-ի, HTTP/1.1-ի տարբեր իրականացմաններում թույլատրվում է բացել մի քանի TCP կապեր մեկ հյուրընկալողի: Օրինակ, Chrome-ում և վերջին Firefox տարբերակներում թույլատրվում է մինչև վեց կապ:

Շփումը նույնպես նախատեսվում էր հանձնել այլ արձանագրություններին, և դրա համար TCP-ի վրա սկսեցին օգտագործել TLS արձանագրությունը, որը բավականին վստահաբար պաշտպանում էր տվյալները, բայց նաև թելադրում էր մի ավելի երկար ժամանակ կապի կարգավորման համար: Վերջում handshake գործընթացը այսպիսին էր:

Cloudflare-ի պատկերը

Այսպիսով, HTTP/1.1-ն ուներ մի շարք խնդիրներ:

• Կապի lenta հաստատում:
• Տվյալները փոխանցվում են տեքստային տեսքով, ինչը նշանակում է, որ պատկերների, տեսանյութերի և այլ ոչ տեքստային տեղեկությունների փոխանցումը արդյունավետ չէ:
• Մի TCP կապը օգտագործվում է մեկ հարցման համար, ինչը նշանակում է, որ մնացած հարցումները պետք է կամ գտնեն այլ կապ, կամ սպասեն, մինչև ընթացիկ հարցումը ազատի այն:
• Պահպանվում է միայն pull-мոդելը: Պահպանված չէ server-push-ի մասին որևէ բան:
• Վերնագրերը փոխանցվում են տեքստով.

Եթե server-push-ը անելիքն է WebSocket պրոտոկոլի միջոցով, ապա մյուս խնդիրները պահանջում էին ավելի արմատական լուծումներ:

Մի փոքր արդիականություն: HTTP/2

2012 թվականին Google-ի խորքում սկսվեց SPDY (պետք է ասվել «սպիդի») պրոտոկոլի մշակումը: Պրոտոկոլը նախատեսված էր HTTP/1.1-ի հիմնական խնդիրները լուծելու համար և պետք է պահպաներ հետադարձ համատեղելիությունը: 2015 թվականին IETF աշխատանքային խումբը ներկայացրեց HTTP/2-ի ստանդարտը, որը հիմնված էր SPDY պրոտոկոլի վրա: Ահա HTTP/2-ի առանձնահատկությունները:

• Բինարային սերիալիզացիա:
• Ամփոփում է մի քանիս HTTP հարցումներ մեկ TCP կապում:
• Առարկայական server-push նախապես (առանց WebSocket-ի):

Պրոտոկոլը մեծ առաջընթաց էր: Այն շատ շատ ավելի արագ է առաջին տարբերակից և ոչ թե պահանջում է մի քանի TCP կապերի ստեղծում. բոլոր հարցումները մեկ հոստի միացնում են մեկում: Բայց մեկ կապի մեջ կա մի քանի հայտնի կոչվող սթրի, որոնք ունեն իրենց ID-ն: Բոնուսը նախապես տրամադրված server-push-ն է:

Սակայն բազմաֆորմացումն առաջացնում է մեկ այլ հիմնախնդիր: Ինչպես պատկերացնում եք, մենք ասինք 5 հարցումներ մի սերվերին: HTTP/2 օգտագործելու դեպքում այս բոլոր հարցումները կիրականացվեն մեկ TCP կապի շրջանակներում, և արդյունքում եթե տվյալ հարցումներից որևէ մեկի որևէ հատվածը կորցվի կամ սխալ հասնի, բոլոր հարցումների և պատասխանների փոխանցումը կդադարեցվի մինչև կորած հատվածը վերականգնվի: Ասենք, որ որքան վատ է կապի որակը, այնքան դանդաղ է աշխատում HTTP/2: Դենիել Ստենբերգի գնահատմամբ, երբ կորած փաթեթները 2%-ն են կազմում ընդհանուրից, HTTP/1.1-ը ցանկալի է բրաուզերում, քան HTTP/2, քանի որ բացում է 6 կապ, այլ ոչ թե մեկ:

Այս խնդիրը կոչվում է «head-of-line blocking» և, ցավոք, TCP օգտագործելու դեպքում լուծել դա հնարավոր չէ:

Դանիել Սթեյնբերգի նկարագրություն

Ի դեպ, HTTP/2 ստանդարտի մշակողները մեծ աշխատանք են կատարել և արել գրեթե ամեն ինչ, ինչ հնարավոր էր OSI մոդելի կիրառական մակարդակում: Ժամանակն է գնալ տրանսպորտային մակարդակ և ստեղծել նոր տրանսպորտային պրոտոկոլ:

Մեզ նոր պրոտոկոլ է պետք: UDP vs TCP

Ա bastante արագ է պարզ դարձավ, որ նոր տրանսպորտային պրոտոկոլի ներդրումը ակնհայտորեն դժվար է: Խնդրում եմ, որ տրանսպորտային մակարդGoneՁեալները գիտեն սարքավորումները կամ middle-boxes-ն (ռաուտերներ, firewall-ներ, NAT-զարկերակներ...), և նրանց ինչ-որ նոր բան սովորեցնել չափազանց դժվարություն է: Հետո, տրանսպորտային պրոտոկոլների աջակցությունն իրանական օպերատիվ համակարգերի վրա, նաև kernels-ը շատ չեն փոխվում:

Այստեղ կարելի էր ձեռքերը գցել և ասել "Մենք, իհարկե, նոր HTTP/3 կստեղծենք՝ նախասիրություն և ֆեմն կոչելով, բայց արժանի լինելու ժամանակը լինելու է 10-15 տարի (այսպիսին է ժամանակը, երբ կփոխվի մեծամասնությունը սպառման սարքերի)", բայց կա մեկ այլ, ոչ այնքան ակնհայտ տարբերակ՝ օգտագործել UDP արձանագրությունը: Այո, այո, հենց այդ UDP արձանագրությունը, որի միջոցով մենք փոխանցում էինք ֆայլեր լոկալ ցանցում 90-ականների վերջին եւ 2000-ականների սկզբին: Նեռի սարքերի մեծ մասը այսօր կարող են աշխատել դրա հետ:

Ինչպե՞ս է UDP-ն առավելություն տալիս TCP-ին: Առաջին հերթին այն է, որ մենք չունենք փոխադրման մակարդակի նստաշրջան, որի մասին գիտեր սարքը: Սա մեզ է թույլ տալիս ինքներս սահմանել նստաշրջանը վերջնակետերում և այնտեղ լուծել առաջացած հակամարտությունները: Այսինքն՝ մենք չենք սահմանափակվում մեկ կամ մի քանի նստաշրջաններով (ինչպես TCP-ում), այլ կարող ենք ստեղծել այնքան, որքան մեզ անհրաժեշտ է: Երկրորդ, տվյալների փոխանցումը UDP-ի միջոցով տեղի է ունենում ավելի արագ, քան TCP-ի միջոցով: Այսպիսով, տեսականորեն, մենք կարող ենք գերազանցել ներկայիս արագության սահմանը, որը հասել է HTTP/2-ում:

Այդուհանդերձ, UDP-ն չի երաշխավորում է տվյալների փոխանցման հուսալիությունը: Իրականում մենք պարզապես ուղարկում ենք փաթեթներ, հուսալով, որ մյուս կողմն դրանք կստանա: Չհասցրեցին? Լավ, ցավոք... Սա բավարար էր մեծահասակների համար տեսանյութերի փոխանցման համար, բայց ավելի լուրջ բաների համար անհրաժեշտ է հուսալիություն, և այդպիսով մի բան ավելացնել UDP-ի վերևում:

Ինչպես HTTP/2-ի դեպքում, նոր արձանագրության ստեղծման աշխատանքները սկսել են Google-ում 2012 թվականին, այսինքն՝ միաժամանակ SPDY-ի մշակման հետ: 2013 թվականին Ջիմ Ռոսքինդը ներկայացրեց հասարակության լայն շրջանակներին QUIC արձանագրությունը (Quick UDP Internet Connections), իսկ արդեն 2015 թվականին Internet Draft-ը ներկայացվել է IETF-ում ստանդարտացման համար: Ըստ այդ ժամանակ, Ռոսքինդի կողմից Google-ում մշակված արձանագրությունը շատ է տարբերացել հաստատված ստանդարտից, ուստի Google-ի տարբերակը կոչվեց gQUIC:

Ինչ է QUIC-ը

Առաջին հերթին, ինչպես արդեն նշվել է, դա UDP-ի շուրջ կառուցվածքեր է: UDP-ի վրա բարձրանում է QUIC-կապ, որտեղ նման HTTP/2-ին կարող են գոյություն ունենալ մի քանի հոսքեր: Տրամադրության հոսքերը գոյություն ունեն միայն վերջնական կետերում և ինքնուրույն են սպասարկվում: Եթե մեկ հոսքում փաթեթի կորուստ է տեղի ունեցել, մյուսները դա չեն ազդի:

Դանիել Սթեյնբերգի նկարագրություն

Երկրորդ՝ անգործարկումը այժմ իրականացվում է ոչ թե առանձին մակարդակով, այլ ներառված է արձանագրության մեջ: Սա հնարավորություն է տալիս միացնել կապը և փոխանակել հանրային բանալիները մեկ ձեռքով, ինչպես նաև օգտագործել խորաթափանց 0-RTT ձեռքը ու ընդհանուր առմամբ խուսափել ձգձգումներից ձեռք բռնելու ժամանակ: Բացի այդ, այժմ կարելի է գաղտնագրել առանձին տվյալների փաթեթներ: Սա թույլ է տալիս չսպասել տվյալների ստացման ավարտին համակարգում, այլ մեկուսացված ստացված փաթեթները գաղտնագրել: Այս գործիակը ընդհանրապես հնարավոր չէր TCP-ի դեպքում, քանի որ TLS-ն և TCP-ն աշխատում էին անկախ մեկը մյուսից, և TLS-ն չէր կարող իմանալ, թե որ կտորները կտրելու է TCP-ը: Հետևաբար, TLS-ն չէր կարող նախապատրաստել իր հատվածները այնպես, որ դրանք համապատասխանեն TCP-ի հատվածներին մեկին մեկին և կարողանան գաղտնագրվել տարբեր: Այս բոլոր բարելավումները թույլ են տալիս QUIC-ին նվազեցնել latency-ը TCP-ի համեմատ:

Երրորդ՝ թեթև հոսքերի գաղափարը թույլ է տալիս կապը զարդարել հաճախորդի IP-հասցեի հետ: Սա կարևոր է, օրինակ, երբ հաճախորդը անցնում է մեկ Wi-Fi հասնելու կետից մյուսին, փոխելով իր IP-ն: Այս դեպքում TCP-ի օգտագործման ժամանակ տեղի է ունենում երկար գործընթաց, որի ընթացքում առասպել TCP-հարցումները զարգանում են timeout-ի միջոցով և նոր կապեր են ստեղծվում նոր IP-ով: QUIC-ի դեպքում հաճախորդը պարզապես շարունակում է ծառայել սերվերին փաթեթները նոր IP-ով, բայց հին հոսքի ID-ով: Չի կարողանում, որ հոսքի ID-ն այժմ եզակի է և կրկնակի չի կիրառվում, սերվերը հասկանում է, որ հաճախորդը փոխել է IP-ն, լրացնում է կորած փաթեթները և շարունակվում է հաղորդակցությունը նոր հասցեով:

Չորրորդ՝ QUIC-ը իրականացվում է կիրառման մակարդակում, այլ ոչ թե գործող համակարգում: Սա, մի կողմից, թույլ է տալիս ավելի արագ փոփոխություններ կատարել արձանագրությունում, քանի որ թարմացում ստանալու համար վերապատրաստել անհրաժեշտ է պարզապես թարմացնել գրադարանը, այլ ոչ թե սպասել նոր OS-ի թողարկմանը: Մյուս կողմից, սա հանգեցնում է ուժեղ պրոցեսորի սպառման բարձրացման:

Եվ վերջին, վերնագիծները: Վերնագրերի սեղմումը հենց այն պահերն են, որոնք տարբեր են QUIC և gQUIC-ի միջև: Չգիտեմ, թե ինչու այս հարցին շատ ժամանակ հատկացնեմ, պարզապես կասեմ, որ էջը, որը ներկայացվել է ստանդարտացման համար, վերնագրերի սեղմումը կատարեց առավելագույնս նման HTTP/2-ի վերնագրերի սեղմմանը: Տեղեկություններն ավելի շատ կարող եք կարդալ: այստեղ.

Ինչպես է դա ավելի արագ?

Այս հարցը բարդ է: Ցանկանում եմ նշել, որ քանի դեռ لدينا ստանդարտ, առանձնակի չէ, ինչ-որ բան չափել: Հնարավոր է, միակ վիճակագրական տվյալները, որոնց մասին մենք տեղեկություն ունենք, Գուգլի վիճակագրությունն է, որը կիրառում է gQUIC 2013թ-ից սկսված և 2016-ին հայտնել IETF-ին, որ մոտ 90% այն տրաֆիկից, որն ուղարկվում է նրանց սերվերներին Chrome բրաուզերից, այժմ օգտագործում է QUIC: Այս նույն ներկայացման մեջ նրանք հայտնում են, որ gQUIC-ի միջոցով էջերը մուտք են գործում շուրջ 5% ավելի արագ, իսկ հոսքային տեսանյութերում՝ 30% ավելի քիչ դանդաղեցմումներ TCP-ի համեմատ:

2017 թվականին հետազոտողների խումբը, որի ղեկավարն էր Arash Molavi Kakhki, հրապարակեց մեծ աշխատանք gQUIC-ի կատարողականության ուսումնասիրության մասին TCP-ի համեմատությամբ:
Հետազոտությունը բացահայտել է gQUIC-ի մի քանի թույլ կողմեր, ինչպիսիք են տվյալների փաթեթների խառնման նկատմամբ կայունության բացակայությունը, կոռուպցիոն (unfairness) իրողությունը, և փոքր (10 կբ-ից ցածր) օբյեկտների ավելի դանդաղ փոխանցումը: Վերջինս, սակայն, կարող է հաղթահարվել 0-RTT-ի օգտագործմամբ: Ամենագլխավոր դեպքերում gQUIC-ն ցույց է տվել արագության աճ TCP-ի նկատմամբ: Մասնագիտական թվերի մասին խոսելն այստեղ դժվար է։ Լավ կլինի կարդալ հետազոտությունը ինքնին կամ կարճ հրապարակված հոդված.

Այսպիսով, պետք է ասել, որ սա gQUIC-ի վերաբերյալ տվյալներ են, և նրանք արդիական չեն մշակվող ստանդարտի համար: Ինչ կստացվի QUIC-ի դեպքում՝ դեռ մի գաղտնիք է, բայց հույս ունենք, որ gQUIC-ում հայտնաբերված թույլ կողմերը կվերաբերվեն և կարդյունավորվեն:

Մի փոքր ապագայի մասին. Իսկ ինչ է լինում HTTP/3-ի հետ?

Այդ հարցում ամեն ինչ պարզ է. API-ն ոչնչով չի փոխվելու: Բոլորը կմնան այնպիսին, ինչպիսին էին HTTP/2-ում: Եթե API-ն մնում է նախկինի պես, տեղափոխությունը HTTP/3 պետք է իրականացվի բազայինում QUIC-ի աջակցության հետ աջակցող նոր տարբերակի գրադարան օգտագործելով: Այնուամենայնիվ, դեռ երկար ժամանակ պետք է պահել հին HTTP-ի վրա պահուստային տարբերակը, քանի որ ինտերնետն այժմ չի պատրաստվում լիովին անցնել UDP-ի վրա:

Ովքեր արդեն աջակցում են

Ահա 清单 երկրային QUIC-ի գործող տարբերակները: Չնայած ստանդարտի բացակայությանը, ցանկը բավականին լավն է:

Տեղեկատվություն չկա, որ հիմա որևէ գործառնական բրաուզեր աջակցում է QUIC: Պարզապես վերջերս տեղեկություն ստացվեց, որ Chrome-ում ակտիվացրել են HTTP/3-ի աջակցությունը, բայց մինչ այժմ միայն Canary-ում:

HTTP/3-ը աջակցում է միայն Caddy և Cloudflare, քանի որ այն դեռ փորձնական է: NGINX-ը 2019 թվականի գարնանը սկսեց աշխատել HTTP/3-ի աջակցության վրա, բայց դեռ ավարտված չէ: հայտարարել են, որ սկսել են աշխատանք անել HTTP/3-ի աջակցության վրա, սակայն դեռ չեն ավարտել:

Որոնք կան խնդիրները

Մենք ապրում ենք իրական աշխարհում, որտեղ ոչ մի մեծ տեխնոլոգիա չի կարող անցնել զանգվածներին առանց դիմադրության, և QUIC-ը այստեղ բացառություն չէ:

Ամենակարևորը, ինչ-որ կերպ պետք է բացատրենք բրաուզերին, որ “https://”-ը հիմա չի նշանակում, որ այն տանում է TCP-ի 443-րդ պորտին: Այստեղ նույնիսկ TCP կարող է չլինել: Այդ նպատակով օգտագործվում է Alt-Svc վարկածը: Այն թույլ է տալիս հայտնել բրաուզերին, որ այս վեբ կայքը նույնպես հասանելի է հետևյալ պրոտոկոլում որոշակի հասցեով: Teորիկորեն, դա պետք է աշխատի, բայց գործնականում մենք հանդիպում ենք UDP-ի արգելքներին, ինչպիսիք են անձեռնհաս տուֆեից խուսափելու համար:

Բայց նույնիսկ եթե UDP-ն արգելված չէ, հաճախորդը կարող է գտնվում NAT-ռոտերայի տակ, որը սահմանված է TCP-սեսիայի պահման համար IP հասցեով, և քանի որ մենք օգտագործում ենք UDP, որտեղ չկա ապարատային սեսիա, NAT-ն չի պահելու կապը, և QUIC-սեսիան կշարունակվի արդյունքում բռնկվել։.

Այս բոլոր խնդիրները կապված են այն բանի հետ, որ UDP նախկինում օգտագործվում չէր ինտերնետային բովանդակություն փոխանցելու համար, և սարքավորումների արտադրողները չեն կարողացել կանխատեսել, որ նման բան երբեք տեղի կունենա: Միևնույն ժամանակ, ադմիններն առավելագույնս չեն հասկանում, թե ինչպես ճիշտ կարգավորել իրենց ցանցերը QUIC-ի համար: Այս իրավիճակը աստիճանաբար կփոխվի, և խոստովանենք, նման փոփոխությունները ավելի քիչ ժամանակ կլծեն, քան նոր տրանսպորտային մակարդակի պրոտոկոլի ներդրումը։

Բացի այդ, ինչպես արդեն նշվել է, QUIC-ի մշակումը զգալիորեն ավելացնում է պրոցեսորի օգտագործումը։ Դանիել Սթենբերգ գնահատել պրոցեսորի աճը երեք անգամ։

Երբ պահանջվելով HTTP/3

Standart ցանկանում են ընդունել 2020 թվականի մայիսին, բայց հաշվի առնելով, որ ներկայիս պահին դեռևս ոչ ամբողջական են փաստաթղթերը, նախատեսված 2019 թվականի հուլիսին, կարելի է ասել, որ ամսաթիվը ավելի հավանական կհետաձգվի։

Գուգլն արդեն 2013 թվականից օգտագործում է իր gQUIC ներդրումը։ Եթե նայենք HTTP հարցմանը, որը ուղարկվում է Գուգլի որոնիչին, կարող ենք տեսնել հետևյալը՝

Արդուկները

QUIC-ն այժմ տեսնում է որպես բավականին կոպիտ, բայց շատ խոստումնալից տեխնոլոգիա: Շնորհիվ того, что վերջին 20 տարիների ընթացքում տրանսպորտային մակարդակի պրոտոկոլների բոլոր օպտիմիզացիաները վերաբերում էին հիմնականում TCP-ին, QUIC-ը, մեծամասամբ շահող կատարողականությամբ, արդեն իսկ նայելով, առանձնակի լավ է թվում։

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

Անցյալը հեռու չէ!

Ընտանիք: habr.com