Кампанія Mozilla паведаміла аб намеры пачаць паэтапнае ўключэнне пратаколаў HTTP/3 і QUIC у выпуску Firefox 88, вызначаным на 19 красавіка (першапачаткова, рэліз чакаўся 20 красавіка, але, судзячы па графіку, ссунуты на адзін дзень). Спачатку падтрымка HTTP/3 будзе актываваная толькі для невялікага адсотка карыстачоў і, калі не паўстане непрадбачаных праблем, будзе даведзена да ўсіх да канца траўня. У начных зборках і бэта-версіях HTTP/3 быў уключаны па змаўчанні ў канцы сакавіка.
Нагадаем, што рэалізацыя HTTP/3 у Firefox заснавана на які развіваецца кампаніяй Mozilla праекце neqo, які прадстаўляе рэалізацыю кліента і сервера для пратаколу QUIC. Код кампанентаў для падтрымкі HTTP/3 і QUIC напісаны на мове Rust. Для кіравання ўключэннем HTTP/3 у about:config прадугледжана опцыя "network.http.http3.enabled". З кліенцкага ПА эксперыментальная падтрымка HTTP/3 таксама дададзена ў Chrome і curl, а для сервераў даступная ў nginx, а таксама ў форме nginx-модуля і тэставага сервера ад кампаніі Cloudflare. На баку сайтаў падтрымка HTTP/3 ужо забяспечана на серверах Google і Facebook.
Пратакол HTTP/3 пакуль знаходзіцца на стадыі чарнавой спецыфікацыі і канчаткова не стандартызаваны ў IETF. Для выкарыстання HTTP/3 патрабуецца падтрымка на баку кліента і сервера адной і той жа версіі чарнавога стандарту QUIC і HTTP/3, якая паказваецца ў загалоўку Alt-Svc (Firefox падтрымлівае чарнавікі спецыфікацыі з 27 па 32).
HTTP/3 вызначае выкарыстанне пратаколу QUIC у якасці транспарта для HTTP/2. Пратакол QUIC (Quick UDP Internet Connections) з 2013 года развіваецца кампаніяй Google у якасці альтэрнатывы звязку TCP+TLS для Web, вырашальнай праблемы з вялікім часам усталёўкі і ўзгадненні злучэнняў у TCP і ўхіляючай затрымкі пры страце пакетаў падчас перадачы дадзеных. QUIC уяўляе сабой надбудову над пратаколам UDP, якая падтрымлівае мультыплексаванне некалькіх злучэнняў і забяспечвае метады шыфравання, эквівалентныя TLS/SSL. У працэсе распрацоўкі ў IETF стандарту ў пратакол былі занесены змены, што прывяло да ўзнікнення двух раўналежна існых галінак, адна для HTTP/3, а другая падтрымоўваная Google (Chrome падтрымлівае абодва варыянту).
Асноўныя асаблівасці QUIC:
- Высокая бяспека, аналагічная TLS (па сутнасці QUIC дае магчымасць выкарыстання TLS па-над UDP);
- Кантроль за цэласнасцю патоку, які прадухіляе страту пакетаў;
- Магчымасць імгненна ўсталяваць злучэнне (0-RTT, прыкладна ў 75% выпадкаў дадзеныя можна перадаваць адразу пасля адпраўкі пакета ўсталёўкі злучэння) і забяспечыць мінімальныя затрымкі паміж адпраўкай запыту і атрыманнем адказу (RTT, Round Trip Time);
- Выкарыстанне пры паўторнай перадачы пакета іншага нумара паслядоўнасці, што дазваляе пазбегнуць двухсэнсоўнасці пры вызначэнні атрыманых пакетаў і пазбавіцца ад таймаўтаў;
- Страта пакета ўплывае на дастаўку толькі злучанага з ім струменя і не спыняе дастаўку дадзеных у раўналежна перадаюцца праз бягучае злучэнне струменях;
- Сродкі карэкцыі памылак, якія мінімізуюць затрымкі з-за паўторнай перадачы страчаных пакетаў. Выкарыстанне спецыяльных кодаў карэкцыі памылак на ўзроўні пакета для скарачэння сітуацый, якія патрабуюць паўторнай перадачы даных страчанага пакета.
- Межы крыптаграфічных блокаў выраўнаваны з межамі пакетаў QUIC, што памяншае ўплыў страт пакетаў на дэкадаванне змесціва наступных пакетаў;
- Адсутнасць праблем з блакіроўкай чаргі TCP;
- Падтрымка ідэнтыфікатара злучэння, які дазваляе скараціць час на ўстаноўку паўторнага злучэння для мабільных кліентаў;
- Магчымасць падлучэння пашыраных механізмаў кантролю перагрузкі злучэння;
- Выкарыстанне тэхнікі прагназавання прапускной здольнасці ў кожным кірунку для забеспячэння аптымальнай інтэнсіўнасці адпраўкі пакетаў, прадухіляючы скочванне ў стан перагрузкі, пры якой назіраецца страта пакетаў;
- Прыкметны прырост прадукцыйнасці і прапускной здольнасці ў параўнанні з TCP. Для відэасэрвісаў, такіх як YouTube, ужыванне QUIC паказала скарачэнне аперацый паўторнай буферызацыі пры праглядзе відэа на 30%.
Крыніца: opennet.ru