Кампанія Cloudflare рэалізавала модуль для падтрымкі HTTP/3 у NGINX

Кампанія Cloudflare падрыхтавала модуль для забеспячэння падтрымкі пратаколу HTTP/3 у NGINX. Модуль выкананы ў форме надбудовы над бібліятэкай, якая развіваецца ў Cloudflare. пірог з заварным крэмам з рэалізацыяй транспартнага пратакола QUIC і HTTP/3. Код quiche напісаны на мове Rust, але сам модуль для NGINX напісаны на мове Сі і звяртаецца да бібліятэкі пры дапамозе дынамічнага звязвання. Напрацоўкі адкрыты пад ліцэнзіяй BSD.

Для зборкі дастаткова загрузіць патч да nginx 1.16 і код бібліятэкі quiche, пасля чаго перасабраць nginx з опцыямі "-with-http_v3_module -with-quiche=../quiche". Пры зборцы падтрымка TLS павінна грунтавацца на бібліятэцы BoringSSL («—with-openssl=../quiche/deps/boringssl»), выкарыстанне OpenSSL пакуль не падтрымліваецца. Для прыёму злучэнняў у настройкі трэба дадаць дырэктыву listen са сцягам "quic" (напрыклад "listen 443 quic reuseport").

З кліенцкага ПА падтрымка HTTP/3 ужо дададзеная ў эксперыментальныя зборкі Chrome Canary і ўтыліту curl. На баку сервера да гэтага часу патрабавалася выкарыстоўваць абмежаваныя па сваіх магчымасцях адасобленыя. тэставыя рэалізацыі. Магчымасць апрацоўкі HTTP/3 у nginx дазволіць істотна спрасціць разгортванне сервераў з падтрымкай HTTP/3 і зробіць больш даступным тэставае ўкараненне новага пратаколу. З'яўленне штатнай падтрымкі HTTP/3 у nginx чакаецца у галінцы 1.17.x на працягу 6-12 месяцаў.

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

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

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

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