У Chrome дададзена эксперыментальная падтрымка пратаколу HTTP/3

У эксперыментальныя зборкі Chrome Canary дададзена падтрымка пратаколу HTTP/3, які рэалізуе надбудову для забеспячэння працы HTTP па-над пратаколам QUIC. Непасрэдна пратакол QUIC быў дададзены ў браўзэр пяць гадоў таму і з таго часу выкарыстоўваецца для аптымізацыі працы з сэрвісамі Google. Пры гэтым ужывальны ў Chrome варыянт QUIC ад Google у некаторых дэталях адрозніваўся ад варыянту з спецыфікацый IETF, але зараз рэалізацыі сінхранізаваныя.

HTTP/3 стандартуе выкарыстанне QUIC у якасці транспарта для HTTP/2. Для ўключэння HTTP/3 і варыянту QUIC з 23 чарнавіка спецыфікацый IETF патрабуецца запуск Chrome з опцыямі "-enable-quic -quic-version=h3-23", пасля чаго пры адкрыцці тэставага сайта quic.rocks:4433 у рэжыме інспектавання сеткі ў прыладах для распрацоўнікаў актыўнасць па HTTP/3 будзе адлюстроўвацца як "http/2+quic/99".

Нагадаем, што пратакол QUIC (Quick UDP Internet Connections) c 2013 года развіваецца кампаніяй Google у якасці альтэрнатывы звязку TCP+TLS для Web, вырашальнай праблемы з вялікім часам усталёўкі і ўзгадненні злучэнняў у TCP і ўхіляючай затрымкі пры страце пакетаў падчас перадачы дадзеных. QUIC уяўляе сабой надбудову над пратаколам UDP, якая падтрымлівае мультыплексаванне некалькіх злучэнняў і забяспечвае метады шыфравання, эквівалентныя TLS/SSL. Разгляданы пратакол ужо інтэграваны ў серверную інфраструктуру Google, уваходзіць у склад Chrome, запланаваны для ўключэння ў Firefox і актыўна прымяняецца для абслугоўвання запытаў кліентаў на серверах Google.

Асноўныя асаблівасці QUIC:

  • Высокая бяспека, аналагічная TLS (па сутнасці QUIC дае магчымасць выкарыстання TLS па-над UDP);
  • Кантроль за цэласнасцю патоку, які прадухіляе страту пакетаў;
  • Магчымасць імгненна ўсталяваць злучэнне (0-RTT, прыкладна ў 75% выпадках дадзеныя можна перадаваць адразу пасля адпраўкі пакета ўсталёўкі злучэння) і забяспечыць мінімальныя затрымкі паміж адпраўкай запыту і атрыманнем адказу (RTT, Round Trip Time);
  • Не выкарыстанне пры паўторнай перадачы пакета таго ж нумара паслядоўнасці, што дазваляе пазбегнуць двухсэнсоўнасці пры вызначэнні атрыманых пакетаў і пазбавіцца ад таймаўтаў;
  • Страта пакета ўплывае на дастаўку толькі злучанага з ім струменя і не спыняе дастаўку дадзеных у раўналежна перадаюцца праз бягучае злучэнне струменях;
  • Сродкі карэкцыі памылак, якія мінімізуюць затрымкі з-за паўторнай перадачы страчаных пакетаў. Выкарыстанне спецыяльных кодаў карэкцыі памылак на ўзроўні пакета для скарачэння сітуацый, якія патрабуюць паўторнай перадачы даных страчанага пакета.
  • Крыптаграфічныя межы блокаў выраўнаваны з межамі пакетаў QUIC, што памяншае ўплыў страт пакетаў на дэкадаванне змесціва наступных пакетаў;
  • Адсутнасць праблем з блакіроўкай чаргі TCP;
  • Падтрымка ідэнтыфікатара злучэння, які дазваляе скараціць час на ўстаноўку паўторнага злучэння для мабільных кліентаў;
  • Магчымасць падлучэння пашыраных механізмаў кантролю перагрузкі злучэння;
  • Выкарыстанне тэхнікі прагназавання прапускной здольнасці ў кожным кірунку для забеспячэння аптымальнай інтэнсіўнасці адпраўкі пакетаў, прадухіляючы скочванне ў стан перагрузкі, пры якой назіраецца страта пакетаў;
  • Прыкметны прырост прадукцыйнасці і прапускной здольнасці, у параўнанні з TCP. Для відэасэрвісаў, такіх як YouTube, ужыванне QUIC паказала скарачэнне аперацый паўторнай буферызацыі пры праглядзе відэа на 30%.

Крыніца: opennet.ru

Дадаць каментар