HTTP/3.0-ը ստացել է առաջարկված ստանդարտ կարգավիճակ

IETF-ը (Internet Engineering Task Force), որը պատասխանատու է ինտերնետ պրոտոկոլների և ճարտարապետության մշակման համար, ավարտել է HTTP/3.0 արձանագրության RFC ձևավորումը և հրապարակել համապատասխան բնութագրերը RFC 9114 (արձանագրություն) և RFC 9204 (արձանագրություն) նույնացուցիչների ներքո։ QPACK վերնագրի սեղմման տեխնոլոգիա HTTP/3-ի համար: HTTP/3.0 հստակեցումը ստացել է «Առաջարկվող ստանդարտի» կարգավիճակ, որից հետո աշխատանքները կսկսվեն RFC-ին նախագծի ստանդարտի կարգավիճակ տալու համար (Նախագիծ ստանդարտ), ինչը իրականում նշանակում է արձանագրության ամբողջական կայունացում և հաշվի առնելով բոլորը: արված մեկնաբանությունները։ Միևնույն ժամանակ հրապարակվել են HTTP/1.1 (RFC 9112) և HTTP/2.0 (RFC 9113) արձանագրությունների տեխնիկական բնութագրերի թարմացված տարբերակները, ինչպես նաև HTTP հարցումների իմաստաբանությունը (RFC 9110) և HTTP քեշավորման կառավարման վերնագրերը սահմանող փաստաթղթեր։ (RFC 9111):

HTTP/3 արձանագրությունը սահմանում է QUIC (Quick UDP Internet Connections) արձանագրության օգտագործումը որպես HTTP/2-ի փոխադրում: QUIC-ը UDP արձանագրության ընդլայնումն է, որն աջակցում է բազմաթիվ կապերի մուլտիպլեքսավորմանը և ապահովում է գաղտնագրման մեթոդներ, որոնք համարժեք են TLS/SSL-ին: Արձանագրությունը ստեղծվել է 2013 թվականին Google-ի կողմից՝ որպես համացանցի համար TCP+TLS համակցության այլընտրանք՝ լուծելով երկար կապի կարգավորումների և TCP-ում բանակցությունների ժամանակի հետ կապված խնդիրները և վերացնելով տվյալների փոխանցման ընթացքում փաթեթների կորստի ժամանակ ձգձգումները:

HTTP/3.0-ը ստացել է առաջարկված ստանդարտ կարգավիճակ

Ներկայումս QUIC և HTTP/3.0 աջակցությունն արդեն ներդրված է բոլոր հայտնի վեբ բրաուզերներում (Chrome-ում, Firefox-ում և Edge-ում HTTP/3-ի աջակցությունը լռելյայն միացված է, իսկ Safari-ում այն ​​պահանջում է «Ընդլայնված > Փորձարարական առանձնահատկություններ > HTTP/3» պարամետրը: միացված լինել): Սերվերի կողմից HTTP/3 իրականացումները հասանելի են nginx-ի համար (առանձին ճյուղով և առանձին մոդուլի տեսքով), Caddy-ի, IIS-ի և LiteSpeed-ի համար։ HTTP/3 աջակցությունը տրամադրվում է նաև Cloudflare բովանդակության առաքման ցանցի կողմից:

QUIC-ի հիմնական հատկանիշները.

  • Բարձր անվտանգություն, որը նման է TLS-ին (ըստ էության, QUIC-ն ապահովում է TLS-ի օգտագործման հնարավորությունը UDP-ի միջոցով);
  • Հոսքի ամբողջականության վերահսկում, փաթեթների կորստի կանխարգելում;
  • Անմիջապես կապ հաստատելու հնարավորություն (0-RTT, դեպքերի մոտավորապես 75%-ում տվյալները կարող են փոխանցվել կապի կարգավորումների փաթեթն ուղարկելուց անմիջապես հետո) և ապահովել հարցում ուղարկելու և պատասխան ստանալու միջև նվազագույն ուշացումներ (RTT, Կլոր ուղևորության ժամանակ);
    HTTP/3.0-ը ստացել է առաջարկված ստանդարտ կարգավիճակ
  • Փաթեթի վերահաղորդման ժամանակ այլ հաջորդական համարի օգտագործումը, որը խուսափում է ստացված փաթեթների նույնականացման հարցում անորոշությունից և ազատվում է ժամանակի ընդմիջումից.
  • Փաթեթի կորուստը ազդում է միայն դրա հետ կապված հոսքի առաքման վրա և չի դադարեցնում տվյալների առաքումը ընթացիկ կապի միջոցով փոխանցվող զուգահեռ հոսքերով.
  • Սխալների ուղղման առանձնահատկություններ, որոնք նվազագույնի են հասցնում կորցրած փաթեթների վերահաղորդման պատճառով հետաձգումները: Փաթեթի մակարդակում սխալների ուղղման հատուկ կոդերի օգտագործումը՝ կորցրած փաթեթային տվյալների վերահաղորդում պահանջող իրավիճակները նվազեցնելու համար:
  • Կրիպտոգրաֆիկ բլոկի սահմանները համահունչ են QUIC փաթեթների սահմաններին, ինչը նվազեցնում է փաթեթների կորուստների ազդեցությունը հետագա փաթեթների բովանդակության վերծանման վրա.
  • TCP հերթի արգելափակման հետ կապված խնդիրներ չկան.
  • Կապի նույնացուցիչի աջակցություն, որը նվազեցնում է շարժական հաճախորդների համար վերամիացում հաստատելու ժամանակը.
  • Միացման գերբեռնվածության վերահսկման առաջադեմ մեխանիզմների միացման հնարավորություն;
  • Օգտագործում է յուրաքանչյուր ուղղության թողունակության կանխատեսման տեխնիկան՝ ապահովելու փաթեթների վերահասցեավորման օպտիմալ տեմպերը՝ կանխելով գերբեռնվածությունը և փաթեթների կորուստը.
  • TCP-ի համեմատ կատարողականի և թողունակության զգալի աճ: Ցույց է տրվել, որ վիդեո ծառայությունների համար, ինչպիսին է YouTube-ը, QUIC-ը 30%-ով նվազեցնում է ռեբուֆերացման գործողությունները տեսանյութեր դիտելիս:

HTTP/1.1 ճշգրտման փոփոխություններից կարելի է նշել բովանդակությամբ մարմնից դուրս փոխադրման վերադարձի (CR) նիշի մեկուսացված օգտագործման արգելքը, այսինքն. Արձանագրության տարրերում CR նիշը կարող է օգտագործվել միայն տողերի սնուցման նիշի (CRLF) հետ միասին: Հատված հարցումների դասավորության ալգորիթմը բարելավվել է՝ կցված դաշտերի և հատվածների տարանջատումը վերնագրերով պարզեցնելու համար: «HTTP Request Smuggling» հարձակումները արգելափակելու համար երկիմաստ բովանդակության հետ աշխատելու վերաբերյալ առաջարկություններ են ավելացվել, որոնք թույլ են տալիս մեզ ներքաշվել այլ օգտատերերի հարցումների բովանդակության մեջ ճակատի և հետին պլանի միջև ընկած հոսքում:

HTTP/2.0 ճշգրտման թարմացումը հստակորեն սահմանում է TLS 1.3-ի աջակցությունը: Հնացել է առաջնահերթությունների սխեման և վերնագրի հետ կապված դաշտերը: HTTP/1.1-ի հետ կապը թարմացնելու չօգտագործված մեխանիզմը հայտարարվել է հնացած։ Նվազեցված պահանջները դաշտերի անուններն ու արժեքները ստուգելու համար: Օգտագործման համար առաջարկվում են նախկինում վերապահված շրջանակների որոշ տեսակներ և պարամետրեր: Միացման հետ կապված արգելված վերնագրի դաշտերը ավելի ճշգրիտ են սահմանված:

Source: opennet.ru

Добавить комментарий