Компания 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 все още не се поддържа. За приемане на връзки в настройките трябва да се добави директива 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. Протоколът (Quick UDP Internet Connections) се развива от 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
