Ավելի քան 20 տարի մենք դիտում ենք վեբ էջեր՝ օգտագործելով HTTP արձանագրությունը: Օգտատերերի մեծամասնությունը նույնիսկ չի մտածում, թե ինչ է այն և ինչպես է այն աշխատում: Մյուսները գիտեն, որ ինչ-որ տեղ HTTP-ի տակ կա TLS, իսկ դրա տակ՝ TCP, որի տակ IP է և այլն։ Իսկ մյուսները՝ հերետիկոսները, կարծում են, որ TCP-ն անցյալում է, նրանք ցանկանում են ինչ-որ ավելի արագ, հուսալի և ապահով բան: Բայց նոր իդեալական արձանագրություն հորինելու իրենց փորձերում նրանք վերադարձել են 80-ականների տեխնոլոգիային և փորձում են դրա վրա կառուցել իրենց խիզախ նոր աշխարհը։
Մի փոքր պատմություն՝ HTTP/1.1
1997 թվականին տեքստային տեղեկատվության փոխանակման արձանագրությունը HTTP 1.1 տարբերակը ձեռք բերեց իր RFC-ն: Այն ժամանակ պրոտոկոլը օգտագործվել էր բրաուզերների կողմից մի քանի տարի, և նոր ստանդարտը տևեց ևս տասնհինգ։ Արձանագրությունն աշխատում էր միայն հարցում-պատասխան սկզբունքով և նախատեսված էր հիմնականում տեքստային տեղեկատվության փոխանցման համար։
HTTP-ը նախագծված էր TCP արձանագրության վերևում գործարկելու համար՝ ապահովելով, որ փաթեթները հուսալիորեն առաքվում են իրենց նպատակակետին: TCP-ն աշխատում է՝ հաստատելով և պահպանելով հուսալի կապ վերջնական կետերի միջև և տրաֆիկը բաժանելով հատվածների: Սեգմենտներն ունեն իրենց սերիական համարը և ստուգման գումարը: Եթե հանկարծ սեգմենտներից մեկը չգա կամ չգա սխալ ստուգիչ գումարով, ապա փոխանցումը կդադարի մինչև կորցրած հատվածը վերականգնվի:
HTTP/1.0-ում TCP կապը փակվում էր յուրաքանչյուր հարցումից հետո: Սա չափազանց վատն էր, քանի որ... TCP կապի հաստատումը (3-Way-Handshake) դանդաղ գործընթաց է: HTTP/1.1-ը ներկայացրեց keep-alive մեխանիզմը, որը թույլ է տալիս նորից օգտագործել մեկ կապ բազմաթիվ հարցումների համար: Այնուամենայնիվ, քանի որ այն հեշտությամբ կարող է դառնալ խցան, HTTP/1.1-ի տարբեր իրականացումներ թույլ են տալիս մի քանի TCP միացումներ բացել նույն հոսթին: Օրինակ, Chrome-ը և Firefox-ի վերջին տարբերակները թույլ են տալիս մինչև վեց կապ:
Ենթադրվում էր, որ գաղտնագրումը նույնպես պետք է մնա այլ արձանագրություններին, և դրա համար օգտագործվեց TLS արձանագրությունը TCP-ի միջոցով, որը հուսալիորեն պաշտպանեց տվյալները, բայց հետագայում ավելացրեց կապ հաստատելու համար պահանջվող ժամանակը: Արդյունքում ձեռքսեղմման գործընթացը սկսեց այսպիսի տեսք ունենալ.
Cloudflare նկարազարդում
Այսպիսով, HTTP/1.1-ն ուներ մի շարք խնդիրներ.
- Դանդաղ կապի կարգավորում:
- Տվյալները փոխանցվում են տեքստային ձևով, ինչը նշանակում է, որ նկարների, տեսանյութերի և այլ ոչ տեքստային տեղեկատվության փոխանցումն անարդյունավետ է:
- Մեկ TCP կապն օգտագործվում է մեկ հարցման համար, ինչը նշանակում է, որ մյուս հարցումները կամ պետք է գտնեն մեկ այլ կապ կամ սպասեն, մինչև ընթացիկ հարցումը թողարկի այն:
- Աջակցվում է միայն ձգվող մոդելը: Server-push-ի մասին ստանդարտում ոչինչ չկա:
- Վերնագրերը փոխանցվում են տեքստով:
Եթե սերվերի մղումը գոնե իրականացվում է WebSocket արձանագրության միջոցով, ապա մնացած խնդիրներին պետք է ավելի արմատական լուծում տալ:
Մի փոքր արդիականություն՝ HTTP/2
2012 թվականին Google-ը սկսեց աշխատել SPDY (արտասանվում է «արագ») արձանագրության վրա։ Արձանագրությունը նախատեսված էր HTTP/1.1-ի հիմնական խնդիրները լուծելու համար և միևնույն ժամանակ պետք է պահպաներ հետին համատեղելիությունը։ 2015 թվականին IETF աշխատանքային խումբը ներկայացրեց HTTP/2 հստակեցումը՝ հիմնված SPDY արձանագրության վրա։ Ահա HTTP/2-ի տարբերությունները.
- Երկուական սերիականացում.
- Բազմաթիվ HTTP հարցումների բազմապատկում մեկ TCP կապի մեջ:
- Սերվերը դուրս մղել տուփից (առանց WebSocket):
Արձանագրությունը մեծ առաջընթաց էր։ Նա խիստ և չի պահանջում մի քանի TCP կապերի ստեղծում. մեկ հոսթին ուղղված բոլոր հարցումները մուլտիպլեքսվում են մեկի մեջ: Այսինքն՝ մի կապի մեջ կան մի քանի այսպես կոչված հոսքեր, որոնցից յուրաքանչյուրն ունի իր ID-ն։ Բոնուսը տուփով սերվերի հրում է:
Այնուամենայնիվ, մուլտիպլեքսավորումը հանգեցնում է մեկ այլ հիմնական խնդրի. Պատկերացրեք, որ մենք ասինխրոն կերպով կատարում ենք 5 հարցումներ մեկ սերվերի վրա: HTTP/2-ն օգտագործելիս այս բոլոր հարցումները կիրականացվեն նույն TCP կապի շրջանակներում, ինչը նշանակում է, որ եթե որևէ հարցման հատվածներից մեկը կորչի կամ սխալ ստացվի, բոլոր հարցումների և պատասխանների փոխանցումը կդադարի մինչև կորցրած հատվածը չհայտնվի: վերականգնվել է։ Ակնհայտ է, որ որքան վատ է կապի որակը, այնքան դանդաղ է աշխատում HTTP/2-ը: Այն պայմաններում, երբ կորցրած փաթեթները կազմում են բոլոր փաթեթների 2%-ը, զննարկիչում HTTP/1.1-ն ավելի լավ է աշխատում, քան HTTP/2-ը, քանի որ այն բացում է 6 կապ, այլ ոչ թե մեկը:
Այս խնդիրը կոչվում է «head-of-line blocking» և, ցավոք, այն հնարավոր չէ լուծել TCP-ից օգտվելիս:
Նկարազարդումը՝ Դանիել Սթայնբերգի
Արդյունքում, HTTP/2 ստանդարտի մշակողները հիանալի աշխատանք կատարեցին և արեցին գրեթե այն ամենը, ինչ կարելի էր անել OSI մոդելի կիրառական շերտում: Ժամանակն է իջնել տրանսպորտային շերտ և հորինել նոր տրանսպորտային արձանագրություն։
Մեզ պետք է նոր արձանագրություն՝ UDP vs TCP
Շատ արագ պարզ դարձավ, որ բոլորովին նոր տրանսպորտային շերտի արձանագրության ներդրումն անհնարին խնդիր է այսօրվա իրողություններում: Փաստն այն է, որ սարքավորումները կամ միջին տուփերը (երթուղիչները, firewalls, NAT սերվերները...) գիտեն տրանսպորտային շերտի մասին, և նրանց նոր բան սովորեցնելը չափազանց բարդ խնդիր է։ Բացի այդ, տրանսպորտային արձանագրությունների աջակցությունը ներկառուցված է օպերացիոն համակարգերի միջուկում, և միջուկները նույնպես շատ պատրաստ չեն փոխվել:
Եվ այստեղ կարելի էր ձեռքերը բարձրացնել և ասել. «Մենք, իհարկե, կհայտնենք նոր HTTP/3 նախապատվություններով և կուրտիզաններով, բայց դրա ներդրման համար կպահանջվի 10-15 տարի (մոտ այս ժամանակից հետո սարքավորումների մեծ մասը կլինի փոխարինված), բայց կա ևս մեկը, ոչ այնքան Ակնհայտ տարբերակն է օգտագործել UDP արձանագրությունը: Այո, այո, նույն արձանագրությունը, որը մենք օգտագործում էինք ֆայլերը LAN-ով նետել իննսունականների վերջին և XNUMX-ականների սկզբին: Այսօրվա գրեթե բոլոր սարքավորումները կարող են աշխատել դրա հետ:
Որո՞նք են UDP-ի առավելությունները TCP-ի նկատմամբ: Նախ, մենք չունենք տրանսպորտային շերտի նիստ, որի մասին սարքավորումը գիտի: Սա մեզ թույլ է տալիս ինքնուրույն որոշել վերջնակետերի նիստը և այնտեղ լուծել կոնֆլիկտները: Այսինքն՝ մենք չենք սահմանափակվում մեկ կամ մի քանի նիստերով (ինչպես TCP-ում), այլ կարող ենք ստեղծել այնքան, որքան մեզ անհրաժեշտ է։ Երկրորդ, տվյալների փոխանցումը UDP-ի միջոցով ավելի արագ է, քան TCP-ի միջոցով: Այսպիսով, տեսականորեն մենք կարող ենք ճեղքել HTTP/2-ում ձեռք բերված ընթացիկ արագության առաստաղը:
Այնուամենայնիվ, UDP-ն չի երաշխավորում տվյալների հուսալի փոխանցում: Փաստորեն, մենք ուղղակի փաթեթներ ենք ուղարկում՝ հույս ունենալով, որ մյուս ծայրը դրանք կստանա։ Չե՞ք ստացել: Դե, հաջողություն... Սա բավական էր մեծահասակների համար տեսանյութեր փոխանցելու համար, բայց ավելի լուրջ բաների համար անհրաժեշտ է հուսալիություն, ինչը նշանակում է, որ UDP-ի վրա պետք է այլ բան փաթաթել:
Ինչպես HTTP/2-ի դեպքում, Google-ում նոր արձանագրության ստեղծման աշխատանքները սկսվել են 2012 թվականին, այսինքն՝ մոտավորապես նույն ժամանակ, երբ սկսվել են SPDY-ի աշխատանքները: 2013 թվականին Ջիմ Ռոսկինդը ներկայացրեց լայն հանրությանը , իսկ արդեն 2015 թվականին IETF-ում ստանդարտացման համար ներդրվել է Internet Draft-ը։ Արդեն այդ ժամանակ Google-ում Ռոսկինդի մշակած արձանագրությունը շատ տարբերվում էր ստանդարտից, ուստի Google-ի տարբերակը սկսեց կոչվել gQUIC:
Ինչ է QUIC-ը
Նախ, ինչպես արդեն նշվեց, սա UDP-ի վրա փաթաթված է: UDP-ի վերևում բարձրանում է QUIC կապ, որում, HTTP/2-ի նմանությամբ, կարող են գոյություն ունենալ մի քանի հոսքեր: Այս հոսքերը գոյություն ունեն միայն վերջնակետերում և սպասարկվում են ինքնուրույն: Եթե փաթեթի կորուստը տեղի է ունենում մեկ հոսքում, դա չի ազդի մյուսների վրա:
Նկարազարդումը՝ Դանիել Սթայնբերգի
Երկրորդ, գաղտնագրումն այլևս չի իրականացվում առանձին մակարդակով, այլ ներառված է արձանագրության մեջ: Սա թույլ է տալիս կապ հաստատել և փոխանակել հանրային բանալիները մեկ ձեռքսեղմումով, ինչպես նաև թույլ է տալիս օգտագործել 0-RTT ձեռքսեղմման խելացի մեխանիզմը և ընդհանրապես խուսափել ձեռքսեղմման հետաձգումներից: Բացի այդ, այժմ հնարավոր է գաղտնագրել անհատական տվյալների փաթեթները: Սա թույլ է տալիս չսպասել հոսքից տվյալների ստացման ավարտին, այլ ինքնուրույն վերծանել ստացված փաթեթները։ Գործողության այս եղանակը ընդհանուր առմամբ անհնար էր TCP-ում, քանի որ TLS-ը և TCP-ն աշխատում էին միմյանցից անկախ, և TLS-ը չէր կարող իմանալ, թե ինչ մասերի են կտրվելու TCP տվյալները: Եվ հետևաբար, նա չկարողացավ իր սեգմենտները պատրաստել այնպես, որ դրանք տեղավորվեն մեկ առ մեկ TCP սեգմենտների մեջ և կարողանան ինքնուրույն վերծանել: Այս բոլոր բարելավումները թույլ են տալիս QUIC-ին նվազեցնել ուշացումը՝ համեմատած TCP-ի հետ:
Երրորդ, լույսի հոսքի հայեցակարգը թույլ է տալիս անջատել կապը հաճախորդի IP հասցեից: Սա կարևոր է, օրինակ, երբ հաճախորդը մի Wi-Fi մուտքի կետից անցնում է մյուսին՝ փոխելով իր IP-ն: Այս դեպքում, երբ օգտագործում եք TCP, տեղի է ունենում երկարատև գործընթաց, որի ընթացքում առկա TCP կապերի ժամանակն ավարտվում է և նոր կապեր են ստեղծվում նոր IP-ից: QUIC-ի դեպքում հաճախորդը պարզապես շարունակում է փաթեթներ ուղարկել սերվեր նոր IP-ից հին հոսքի ID-ով: Որովհետեւ Հոսքի ID-ն այժմ եզակի է և չի վերաօգտագործվում, սերվերը հասկանում է, որ հաճախորդը փոխել է IP-ն, նորից ուղարկում է կորցրած փաթեթները և շարունակում է հաղորդակցությունը նոր հասցեով:
Չորրորդ՝ QUIC-ն իրականացվում է ոչ թե օպերացիոն համակարգի, այլ հավելվածի մակարդակում: Սա, մի կողմից, թույլ է տալիս արագ փոփոխություններ կատարել արձանագրության մեջ, քանի որ Թարմացում ստանալու համար պարզապես անհրաժեշտ է թարմացնել գրադարանը, այլ ոչ թե սպասել OS-ի նոր տարբերակին: Մյուս կողմից, դա հանգեցնում է պրոցեսորի սպառման ուժեղ աճի:
Եվ վերջապես վերնագրերը. Վերնագրի սեղմումը QUIC-ի և gQUIC-ի միջև տարբերվող բաներից մեկն է: Դրան շատ ժամանակ հատկացնելու իմաստ չեմ տեսնում, պարզապես կասեմ, որ ստանդարտացման ներկայացված տարբերակում վերնագրի սեղմումը հնարավորինս նման է վերնագրի սեղմմանը HTTP/2-ում: Դուք կարող եք կարդալ ավելին .
Որքա՞ն է այն ավելի արագ:
Բարդ հարց է։ Փաստն այն է, որ քանի դեռ չափանիշ չունենք, առանձնահատուկ բան չկա չափելու։ Թերևս միակ վիճակագրությունը, որը մենք ունենք, Google-ի վիճակագրությունն է, որն օգտագործում է gQUIC 2013 թվականից և 2016 թ. որ Chrome դիտարկիչից դեպի իրենց սերվերներ գնացող տրաֆիկի մոտ 90%-ն այժմ օգտագործում է QUIC: Նույն ներկայացման մեջ նրանք հայտնում են, որ gQUIC-ի միջոցով էջերը բեռնվում են մոտ 5%-ով ավելի արագ, իսկ վիդեո հոսքում 30%-ով ավելի քիչ կակազություն կա՝ համեմատած TCP-ի հետ:
2017 թվականին մի խումբ հետազոտողներ Արաշ Մոլավի Կախկիի գլխավորությամբ հրապարակել են ուսումնասիրել gQUIC-ի կատարումը TCP-ի համեմատ:
Ուսումնասիրությունը բացահայտեց gQUIC-ի մի քանի թույլ կողմեր, ինչպիսիք են ցանցային փաթեթների խառնման անկայունությունը, ագահությունը (անարդարությունը) կապուղու թողունակության նկատմամբ և փոքր (մինչև 10 կբ) օբյեկտների ավելի դանդաղ փոխանցում: Վերջինս, սակայն, կարելի է փոխհատուցել՝ օգտագործելով 0-RTT: Ուսումնասիրված բոլոր մյուս դեպքերում gQUIC-ը ցույց է տվել արագության աճ՝ համեմատած TCP-ի հետ: Այստեղ դժվար է խոսել կոնկրետ թվերի մասին։ Ավելի լավ է կարդալ կամ .
Այստեղ պետք է ասել, որ այս տվյալները կոնկրետ gQUIC-ի մասին են, և դրանք չեն համապատասխանում մշակվող ստանդարտին։ Ինչ կլինի QUIC-ի համար. դա դեռ գաղտնիք է, բայց հույս կա, որ gQUIC-ում հայտնաբերված թույլ կողմերը հաշվի կառնվեն և կշտկվեն:
Մի փոքր ապագա. ի՞նչ կասեք HTTP/3-ի մասին:
Բայց այստեղ ամեն ինչ բյուրեղյա պարզ է՝ API-ն ոչ մի կերպ չի փոխվի։ Ամեն ինչ կմնա նույնը, ինչ HTTP/2-ում էր: Դե, եթե API-ն մնա նույնը, ապա HTTP/3-ին անցումը պետք է լուծվի՝ օգտագործելով գրադարանի թարմ տարբերակը հետնամասում, որն աջակցում է QUIC տրանսպորտին: Ճիշտ է, դուք ստիպված կլինեք բավականին երկար ժամանակ պահպանել HTTP-ի հին տարբերակների հետադարձ կապը, քանի որ Ինտերնետը ներկայումս պատրաստ չէ UDP-ի ամբողջական անցմանը:
Ով արդեն աջակցում է
Այստեղ առկա QUIC իրականացումները: Չնայած ստանդարտի բացակայությանը, ցուցակը վատը չէ։
Ներկայումս ոչ մի դիտարկիչ չի աջակցում QUIC-ին արտադրության թողարկումում: Վերջերս տեղեկություն եղավ, որ HTTP/3-ի աջակցությունը ներառված է Chrome-ում, բայց առայժմ միայն Canary-ում:
Backend-ներից միայն HTTP/3-ն աջակցում է и , բայց դեռ փորձնական։ NGINX 2019 թվականի գարնան վերջին , որ սկսել են աշխատել HTTP/3 աջակցության վրա, բայց դեռ չեն ավարտել։
Ի՞նչ խնդիրներ կան։
Դուք և ես ապրում ենք իրական աշխարհում, որտեղ ոչ մի մեծ տեխնոլոգիա չի կարող հասնել զանգվածներին՝ առանց դիմադրության հանդիպելու, և QUIC-ը բացառություն չէ:
Ամենակարևորն այն է, որ դուք պետք է ինչ-որ կերպ բացատրեք զննարկիչին, որ «https://»-ն այլևս փաստ չէ, որ այն տանում է դեպի TCP պորտ 443: Հնարավոր է, որ TCP ընդհանրապես չկա: Դրա համար օգտագործվում է Alt-Svc վերնագիրը: Այն թույլ է տալիս զննարկիչին ասել, որ այս կայքը նույնպես հասանելի է այս կամ այն արձանագրության վրա այս և այն հասցեով: Տեսականորեն սա պետք է աշխատի հմայքի պես, բայց գործնականում մենք կհանդիպենք այն փաստի, որ UDP-ն, օրինակ, կարող է արգելվել firewall-ում՝ DDoS հարձակումներից խուսափելու համար:
Բայց նույնիսկ եթե UDP-ն արգելված չէ, հաճախորդը կարող է լինել NAT երթուղիչի հետևում, որը կազմաձևված է IP հասցեով TCP նիստ անցկացնելու համար, և քանի որ մենք օգտագործում ենք UDP, որը չունի ապարատային նիստ, NAT-ը կապը չի անցկացնի, և QUIC նստաշրջան .
Այս բոլոր խնդիրները պայմանավորված են նրանով, որ UDP-ն նախկինում չի օգտագործվել ինտերնետի բովանդակություն փոխանցելու համար, և ապարատային արտադրողները չէին կարող կանխատեսել, որ դա երբևէ տեղի կունենա: Նույն կերպ, ադմինիստրատորները դեռ իրականում չեն հասկանում, թե ինչպես ճիշտ կարգավորել իրենց ցանցերը, որպեսզի QUIC-ն աշխատի: Այս իրավիճակը աստիճանաբար կփոխվի, և, ամեն դեպքում, նման փոփոխությունները ավելի քիչ ժամանակ կպահանջեն, քան նոր տրանսպորտային շերտի արձանագրության ներդրումը։
Բացի այդ, ինչպես արդեն նկարագրված է, QUIC-ը մեծապես մեծացնում է պրոցեսորի օգտագործումը: Դանիել Ստենբերգ պրոցեսորի աճը մինչև երեք անգամ:
Ե՞րբ կգա HTTP/3-ը:
Ստանդարտ մինչև 2020 թվականի մայիսին, սակայն հաշվի առնելով, որ 2019 թվականի հուլիսին նախատեսված փաստաթղթերն այս պահին անավարտ են մնում, կարելի է ասել, որ ամսաթիվը, ամենայն հավանականությամբ, հետ կհետաձգվի։
Դե, Google-ը օգտագործում է իր gQUIC ներդրումը 2013 թվականից: Եթե նայեք Google որոնողական համակարգին ուղարկված HTTP հարցումին, կտեսնեք սա.
Արդյունքները
QUIC-ն այժմ բավականին կոպիտ, բայց շատ խոստումնալից տեխնոլոգիա է թվում: Հաշվի առնելով, որ վերջին 20 տարիների ընթացքում տրանսպորտային շերտի արձանագրությունների բոլոր օպտիմալացումները հիմնականում վերաբերել են TCP-ին, QUIC-ին, որը շատ դեպքերում ունի լավագույն կատարումը, արդեն չափազանց լավ տեսք ունի:
Այնուամենայնիվ, դեռևս կան չլուծված խնդիրներ, որոնք պետք է լուծվեն առաջիկա մի քանի տարիների ընթացքում: Գործընթացը կարող է հետաձգվել՝ կապված այն բանի հետ, որ կա սարքաշար, որը ոչ ոք չի սիրում թարմացնել, բայց, այնուամենայնիվ, բոլոր խնդիրները բավականին լուծելի են թվում, և վաղ թե ուշ բոլորս կունենանք HTTP/3։
Ապագան հենց անկյունում է:
Source: www.habr.com
