Компания Cloudflare за осигуряване на поддръжка за HTTP/3 протокола в NGINX. Модулът е направен под формата на добавка върху библиотеката, разработена в Cloudflare с внедряването на транспортния протокол QUIC и HTTP/3. Кодът на quiche е написан на Rust, но самият модул NGINX е написан на C и осъществява достъп до библиотеката чрез динамично свързване. Разработки под лиценз BSD.
За да сглобите, просто изтеглете към nginx 1.16 и библиотеки за quiche и след това изградете отново nginx с опции "--with-http_v3_module --with-quiche=../quiche". При изграждане поддръжката на TLS трябва да се базира на библиотеката BoringSSL ("--with-openssl=../quiche/deps/boringssl"), използването на OpenSSL все още не се поддържа. За да приемате връзки, трябва да добавите директивата за слушане с флага „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. протокол (Quick UDP Internet Connections) е разработен от Google от 2013 г. като алтернатива на TCP + TLS за уеб, като решава проблеми с дълги времена за настройка и преговори за връзки в TCP и елиминира забавяния в случай на загуба на пакети по време на пренос на данни. QUIC е добавка към UDP протокола, която поддържа мултиплексиране на множество връзки и предоставя методи за криптиране, еквивалентни на TLS/SSL.
Основната QUIC:
- Висока сигурност, подобна на TLS (всъщност QUIC предоставя възможност за използване на TLS през UDP);
- Контрол на целостта на потока за предотвратяване на загуба на пакети;
- Възможност за незабавно установяване на връзка (0-RTT, в около 75% от случаите данните могат да бъдат предадени веднага след изпращане на пакет за настройка на връзка) и осигуряване на минимални закъснения между изпращане на заявка и получаване на отговор (RTT, Round Trip Time) ;
- Не използвайте същия пореден номер при повторно предаване на пакет, което ви позволява да избегнете двусмислието при определяне на получените пакети и да се отървете от изчакванията;
- Загубата на пакет засяга само доставката на свързания с нея поток и не спира доставката на данни в потоци, предавани паралелно през текущата връзка;
- Инструменти за коригиране на грешки, които минимизират закъсненията поради повторно предаване на изгубени пакети. Използване на специални кодове за коригиране на грешки на ниво пакет, за да се намалят ситуациите, които изискват повторно предаване на изгубени пакети данни.
- Границите на криптографските блокове са подравнени с границите на QUIC пакетите, което намалява влиянието на загубата на пакети върху декодирането на съдържанието на следващите пакети;
- Няма проблеми с блокирането на TCP опашката;
- Поддръжка на Connection ID за намаляване на времето за повторно свързване за мобилни клиенти;
- Възможност за свързване на усъвършенствани механизми за контрол на претоварването на връзката;
- Използване на техники за предсказване на честотната лента във всяка посока, за да се осигури оптимална интензивност на изпращане на пакети, предотвратяване на преминаване в състояние на задръстване, при което има загуба на пакети;
- Доловимо производителност и пропускателна способност в сравнение с TCP. За видео услуги като YouTube е показано, че QUIC намалява операциите за повторно буфериране на видео с 30%.
Източник: opennet.ru