Мы рады сообщить, что наша предварительная реализация поддержки 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{}):

  1. listen 443 http3 reuseport; - Добавьте новый параметров конфигурации listen с параметром http3, чтобы указать NGINX прослушивать HTTP/3 соединения на том же порту, что и для HTTP/1.1 и HTTP/2, а именно 443. Параметр reuseport необходим для корректной работы при наличии нескольких рабочих процессов NGINX. Он позволяет ядру распределять входящие HTTP/3 соединения между ними.

  2. ssl_protocols TLSv1.3; - Добавляет TLS 1.3 в список поддерживаемых протоколов, как того требует QUIC. (Возможно, этот параметров конфигурации уже существует, но добавьте ее при необходимости). Для поддержки всего спектра браузеров вам, вероятно, потребуется включить и более старые версии TLS. Информацию о поддержке браузерами TLS 1.3 см. в разделе Можно ли использовать TLS 1.3?

  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.

Комментарии (1)


  1. Drammm
    00.00.0000 00:00

    Post запросы все так же не работают? Я просто уже тестировал сборку nginx http3, все было прекрасно пока не понял, что пост запросы не работают. Погуглил - оказывается это фича quic