Мы рады сообщить, что наша предварительная реализация поддержки NGINX для QUIC+HTTP/3 теперь доступна в виде предварительно собранных бинарных пакетов для двух дистрибутивов:
Red Hat Enterprise Linux 9 и двоично-совместимых вариантов
Ubuntu 22.04
Двоичные файлы являются последними сборками из ветки quic отдельного репозитория nginx-quic, в котором размещена предварительная реализация. С тех пор, как мы начали работу над QUIC+HTTP/3 в NGINX, вы все еще можете самостоятельно загрузить и собрать NGINX Open Source с QUIC+HTTP/3 и выбором библиотек SSL/TLS, поддерживающих QUIC. Хотя код помечен как экспериментальный, несколько членов комьюнити сообщили, что они успешно используют nginx-quic в продакшн системах.
Наша основная цель выпуска предварительных двоичных файлов - ускорить и упростить тестирование NGINX с QUIC+HTTP/3. Двоичные файлы не требуют компиляции из исходного кода и могут быть установлены с помощью стандартных инструментов управления пакетами.
На момент написания статьи SSL/TLS, OpenSSL не поддерживают QUIC. Поэтому мы собираем бинарные дистрибутивы с пакетом-библиотекой quictls, который устанавливается автоматически в качестве зависимости. Мы выбрали quictls, потому что в настоящее время он представляет собой наилучшее сочетание стабильности, совместимости и возможностей.
Инструкции по установке бинарного дистрибутива доступны на сайте NGINX QUIC.
Configuring NGINX for QUIC+HTTP/3
Существует несколько новых параметров конфигурации для настройки NGINX для QUIC+HTTP/3, но их легко объединить с командами для HTTP/1.1 и HTTP/2 в существующих блоках конфигурации виртуального сервера (server{}).
Для самой базовой функциональной конфигурации достаточно включить три команды в блок server{} (и дочерней location{}):
listen 443 http3 reuseport;
- Добавьте новый параметров конфигурации listen с параметром http3, чтобы указать NGINX прослушивать HTTP/3 соединения на том же порту, что и для HTTP/1.1 и HTTP/2, а именно 443. Параметр reuseport необходим для корректной работы при наличии нескольких рабочих процессов NGINX. Он позволяет ядру распределять входящие HTTP/3 соединения между ними.ssl_protocols
TLSv1.3;
- Добавляет TLS 1.3 в список поддерживаемых протоколов, как того требует QUIC. (Возможно, этот параметров конфигурации уже существует, но добавьте ее при необходимости). Для поддержки всего спектра браузеров вам, вероятно, потребуется включить и более старые версии TLS. Информацию о поддержке браузерами TLS 1.3 см. в разделе Можно ли использовать TLS 1.3?-
add_header
Alt-Svc'h3=":$server_port";ma=86400';
- Добавьте этот параметр конфигурации, чтобы NGINX добавил заголовок ответа, сообщающий браузеру, что обновление QUIC доступно и через какой порт следует подключаться.По соглашению, порт (представленный здесь переменной $server_port) является тем же, что используется для TLS в HTTP/1.1 и HTTP/2.
Значение ma - это количество секунд, в течение которых клиент может считать, что NGINX принимает трафик HTTP/3 по UDP; по истечении этого времени клиент должен вернуться к TCP. Указанное здесь значение эквивалентно 24 часам.
Пример для блока server{} выглядит следующим образом:
server {
# для лучшей совместимости мы рекомендуем
# использовать один и тот же номер порта для QUIC и TCP
listen 443 http3 reuseport; # QUIC
listen 443 ssl; # TCP
ssl_certificate certs/example.com.crt;
ssl_certificate_key certs/example.com.key;
ssl_protocols TLSv1.3;
location / {
# advertise that QUIC is available on the configured port
add_header Alt-Svc 'h3=":$server_port"; ma=86400';
#proxy_pass <upstream_group>;
#root /<root_directory>;
}
}
Есть еще несколько новых необязательных параметров конфигурации и переменных, связанных с HTTP/3 (не показаны в сниппете), включая следующие:
$http3 - (Переменная) Устанавливается в h3, если запрос отправляется во время сессии HTTP/3 (в противном случае эта строка будет пустой).
quic_retry - (параметр конфигурации) При установке значения "on", указывает NGINX на отправку повторного сообщения QUIC обратно запросчику с указанием нового идентификатора соединения для проверки IP-адреса запросчика. Пакет QUIC retry частично компенсирует тот факт, что трехстороннее рукопожатие соединения TCP не может быть использовано для проверки соединения, поскольку QUIC работает по UDP.
ssl_early_data - (параметр конфигурации) При установке значения "on" указывает NGINX принимать данные приложения в первом запросе, отправленном клиентом по новому соединению TLS 1.3, если предыдущее соединение от этого клиента уже было. Это также известно, как возобновление соединения с нулевым временем обхода (0-RTT). Поддержка отправки "ранних данных" является особенностью TLS 1.3 и способствует улучшению производительности QUIC+HTTP/3 за счет устранения дополнительных обменов сообщениями в обе стороны, необходимых для хендшейка TLS.
Примечание: Возобновление соединения 0-RTT может создать риск для безопасности, поскольку ранние данные подвержены атакам повторного воспроизведения, если они включают метод запроса HTTP, отличный от GET. Подробнее см. раздел о TLS 1.3 в Анонсе NGINX Plus R17 в нашем блоге.
На диаграмме показано, как возобновление соединения 0-RTT с помощью QUIC+HTTP/3 повышает производительность, поскольку клиент может отправить HTTP-запрос в своем первом сообщении при возобновлении QUIC-соединения с NGINX. Для TCP с TLS, напротив, клиент должен выполнить новое рукопожатие TLS с NGINX для установления безопасного соединения, что требует нескольких дополнительных обходов.
Информацию о всех новых параметров конфигурации и переменных можно найти в разделе 3. Конфигурация в README nginx-quic.
Testing NGINX with QUIC+HTTP/3
Как уже говорилось ранее, одной из наших причин выпуска готовых бинарных файлов является упрощение тестирования корректности обработки трафика HTTP/3 в NGINX. Для простого тестирования в командной строке вы можете собрать curl с поддержкой HTTP/3 или использовать готовый контейнер. Кроме того, новые версии большинства браузеров поддерживают QUIC+HTTP/3.
Чтобы убедиться, что ваш сайт с поддержкой QUIC обрабатывает запросы браузеров на подключение по протоколу HTTP/3, вы можете использовать инструменты разработчика браузера для изучения HTTP-заголовков, возвращаемых NGINX. Реализация QUIC+HTTP/3 работает правильно, если NGINX включает рассмотренный выше заголовок Alt-Svc в ответ на первоначальный HTTP-запрос браузера по TCP.
В этот момент браузер, поддерживающий QUIC, создает QUIC-соединение на порту, указанном в директиве Alt-Svc, и последующие HTTP-запросы и ответы передаются по QUIC. Другой способ проверить, что используется QUIC+HTTP/3, - это включить еще одну директиву add_header, чтобы установить значение пользовательского HTTP-заголовка на протокол, фиксируемый переменной $server-protocol. Вы можете отслеживать значение заголовка по мере его изменения от HTTP/1.x до установления QUIC-соединения до HTTP/3.0 при использовании QUIC.
Вот пример блока расположения, в котором пользовательский HTTP-заголовок имеет значение X-protocol:
location / {
# сообщить, что QUIC доступен на настроенном порту
add_header Alt-Svc 'h3=":$server_port"; ma=86400';
# сигнализирует, используем ли мы QUIC+HTTP/3
add_header X-protocol $server_protocol always;
#proxy_pass <upstream_group>;
#root /<root_directory>;
}
Кроме того, существуют такие инструменты, как расширение Chrome HTTP Indicator, которые визуально показывают используемый протокол. (Обратите внимание, что это не рекомендация какого-либо расширения браузера, и вы должны убедиться в том, что любые возможные проблемы безопасности расширения для вас допустимы).
Что дальше
Мы продолжим поставлять наше решение для QUIC+HTTP/3 и предоставим больше примеров оптимизации NGINX в ближайшие недели. Тем временем, пожалуйста, поделитесь результатами собственного тестирования, чтобы помочь нам в принятии решений. Вы можете поделиться своими отзывами в списке рассылки разработчиков NGINX и на канале #quic-http3 в NGINX Community Slack.
Чтобы получать обновления о нашей работе над QUIC+HTTP/3, включая следующую важную веху - слияние репозитория nginx-quic с основной веткой NGINX Open Source - подпишитесь на список рассылки анонсов NGINX.
Drammm
Post запросы все так же не работают? Я просто уже тестировал сборку nginx http3, все было прекрасно пока не понял, что пост запросы не работают. Погуглил - оказывается это фича quic