Firma 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. Протокол (Quick UDP Internet Connections) c 2013 года развивается компанией Google в качестве альтернативы связке TCP+TLS для Web, решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данных. QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования, эквивалентные TLS/SSL.
Główne QUIC:
- Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP);
- Контроль за целостностью потока, предотвращающий потерю пакетов;
- Возможность мгновенно установить соединение (0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения) и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time);
- Не использование при повторной передаче пакета того же номера последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов;
- Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;
- Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.
- Границы криптографических блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов;
- Отсутствие проблем с блокировкой очереди TCP;
- Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов;
- Возможность подключения расширенных механизмов контроля перегрузки соединения;
- Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов;
- Заметный производительности и пропускной способности, по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.
Źródło: opennet.ru
