Каждое открытие сайта начинается с короткого ритуала знакомства. Браузер стучится в TCP, поверх транспортного соединения поднимается TLS, и только после двух-трёх обменов пакетами в путь уходит первый запрос за содержимым страницы. QUIC переворачивает привычный порядок, объединяя транспорт и шифрование в один быстрый старт поверх UDP. К 2026 году протокол давно вышел из стадии эксперимента: все крупные браузеры понимают HTTP/3, примерно треть сайтов в интернете уже объявляет поддержку, а nginx принял нужные директивы в основной код. Дальше по порядку то, что QUIC меняет в самом механизме передачи, где экономия заметна, где почти неощутима, и как включить новое поколение протокола на своём сервере за считаные минуты.
Транспорт на UDP, который забрал себе работу TLS 1.3
Чтобы понять, откуда у QUIC запас скорости, полезно вспомнить устройство классической схемы. TCP живёт в ядре операционной системы, TLS подключается библиотекой поверх него, HTTP работает над обоими, и три слоя согласуются между собой последовательно, добавляя каждый свои накладные расходы. QUIC стирает эти границы. Протокол ездит поверх UDP, а TLS 1.3 встроен прямо в рукопожатие, поэтому установка соединения и согласование шифрования происходят за один общий обмен пакетами. Отдельного этапа для старта шифрования попросту нет.
Внутри одного QUIC-соединения живёт несколько независимых потоков. Если один пакет затерялся в дороге, замирает только тот поток, к которому относились потерянные пакеты, а остальные продолжают работу. TCP в такой ситуации останавливал очередь целиком, потому что ядро видело сплошной поток байтов и не разбирало, к какому запросу они принадлежат. Эту особенность называют блокировкой начала очереди, и именно она больше всего мешала HTTP/2 на нестабильных сетях. QUIC убирает её на уровне самого транспорта.
Третья деталь касается маршрута. Соединение QUIC идентифицируется не четвёркой адресов и портов, а специальными идентификаторами соединения. Смартфон, переключившийся с домашнего Wi-Fi на мобильный интернет, сохраняет недокачанные файлы и открытые сессии: транспорт продолжает работу с новым адресом без пересборки рукопожатия. Граница между сетями для пользователя исчезает, приложению не требуется ни строчки дополнительного кода.
Бонусом идёт приватность служебной информации. В QUIC зашифровано даже то, что в TCP умели читать промежуточные шлюзы, поэтому сетевое оборудование на пути пакета больше не вмешивается в детали соединения.
Рукопожатие за один оборот пакета и 0-RTT для вернувшихся гостей
Самая наглядная разница видна в арифметике обменов. Классический путь TCP плюс TLS 1.3 требует двух оборотов пакета: один уходит на установку транспортного соединения, второй на согласование шифрования. Если сервер всё ещё работает с TLS 1.2, оборотов становится три. QUIC укладывает весь старт в один оборот, а при повторном визите клиента переходит в режим 0-RTT, когда запрос уходит уже в самом первом пакете, до всякого согласования.
В миллисекундах это выглядит убедительно. При задержке сети 40 мс экономия на первом заходе составит 40 мс, а на повторном до 80 мс. На мобильном интернете с типичными 100-150 мс задержки речь уже о 100-300 мс на одних только рукопожатиях, до какого-либо содержимого. Немного на первый взгляд, но на цепочке из десятков запросов эти миллисекунды складываются в заметную разницу во времени отрисовки первых элементов страницы.
Немного осторожности не помешает. Режим 0-RTT доступен только при повторном подключении, когда браузер ещё хранит ключи возобновления от прошлого визита. Запросы из ранних пакетов можно воспроизвести повторной отправкой, поэтому они пригодны лишь для безопасных операций вроде чтения. Как учесть эту особенность в конфигурации nginx, показано ниже.
Где экономия на глазах, а где она почти неразличима
Выигрыш сильнее всего проявляется там, где сеть слабая. Мобильный интернет в движении, перегруженный Wi-Fi в кафе, связь в зоне неуверенного приёма: всюду периодически теряются пакеты. На HTTP/2 каждая потеря внутри TCP замораживает все потоки сразу, и страница подтормаживает даже при быстром сервере. QUIC изолирует последствия: недошедшие байты тормозят один поток, остальное едет дальше. Простой расчёт показывает масштаб. При RTT 120 мс и потерях порядка одного-двух процентов каждый эпизод потери на TCP добавляет минимум один оборот восстановления, а при неудачном стечении обстоятельств и полный таймаут повтора длиной до секунды. Страница с парой десятков ресурсов собирает несколько таких эпизодов, и каждый из них замирает целиком. QUIC в той же ситуации недосчитывается одного потока из многих, а общая длительность загрузки на подобных сетях сокращается на десятки процентов.
Заметен выигрыш и при большой задержке канала. Чем дальше сервер и чем длиннее оборот пакета, тем дороже каждый лишний RTT. Для аудитории с задержкой 200 мс два сэкономленных оборота превращаются в 400 мс, которые страница не тратит на согласования. Отсюда и любовь к QUIC у проектов с международным трафиком, где путь пакета проходит через полпланеты.
А вот на идеальных каналах разница почти не видна. Сервер в соседнем датацентре, RTT в 5-10 мс, нулевые потери, страница с одним-двумя ресурсами: вся экономия уместится в несколько миллисекунд, которые глаз не различит. Не ускорит QUIC и короткий одиночный запрос к API, который и так укладывается в один оборот. Полезно помнить и про одну оговорку: на время старта, пока идёт рукопожатие, пакеты всех потоков едут в общем защищённом конверте, зато после установки шифрования каждый поток живёт своей жизнью.
Поддержка в браузерах и серверах выросла до массовой
К 2026 году спорить о поддержке со стороны браузеров уже не приходится. Chrome и всё семейство Chromium, включая Edge и Opera, включили протокол по умолчанию ещё в 2020-2021 годах, Firefox подтянулся в 2021-м, а Safari работает с HTTP/3 начиная с macOS Big Sur и уверенно начиная с версии 15.4. Смартфоны на обеих платформах обслуживаются новым транспортом так же, как настольные машины. Иными словами, фактически вся актуальная аудитория способна перейти на HTTP/3, как только сервер объявит о такой возможности.
На стороне серверов картина тоже созрела. LiteSpeed поддерживал QUIC в продакшене раньше остальных, за ним шли Caddy и HAProxy, а nginx завершил интеграцию в 2023 году, когда HTTP/3 вошёл в основную ветку 1.25 без отдельных патчей и экспериментальных сборок. Apache пока держит экспериментальные наработки. Крупные CDN, включая Cloudflare и платформы Google, давно отдают значительную часть ответов через QUIC. Независимые измерения показывают, что около трети всех сайтов в интернете уже объявляют поддержку h3 через заголовок Alt-Svc, а на площадках, где протокол включён, через него нередко проходит больше половины запросов.
Подготовка nginx к работе с QUIC и список условий
Практическая часть начинается с версии. Поддержка QUIC вошла в основную ветку nginx с релиза 1.25.0, а директива http2 on, заменившая старый параметр в listen, появилась начиная с 1.25.1. Всё, что новее, включая современные стабильные линейки, понимает третье поколение протокола из коробки. Модуль http_v3_module в готовых пакетах присутствует, а при самостоятельной сборке его включают флагом --with-http_v3_module, иначе nginx сообщит о неизвестной директиве прямо при запуске.
Осталось перечислить условия, без которых QUIC не заведётся:
- сертификат и закрытый ключ для домена, подойдут и бесплатные от Let's Encrypt;
- включённая поддержка TLS 1.3, потому что QUIC работает только поверх этой версии шифрования;
- открытый входящий UDP на порт 443 в фаерволе и в настройках облака, без UDP браузер не получит ни одного QUIC-пакета;
- TCP-версия HTTPS на том же порту для первичного подключения и для сетей, где UDP-443 перекрыт администраторами;
- однократное указание параметра reuseport для каждого UDP-порта, сколько бы виртуальных серверов ни слушало его одновременно.
Отдельного пояснения заслуживает параметр reuseport в директиве listen. Он создаёт собственный UDP-сокет для каждого рабочего процесса, поэтому воркеры принимают QUIC-соединения независимо и не спорят за общий порт. Нюанс в том, что reuseport на одном и том же адресе и порту допускается указать лишь единожды, иначе nginx упрётся в дублирование параметров прослушивания. Выбор виртуального сервера внутри QUIC-соединения происходит по имени домена из SNI, как и в привычном HTTPS.
Блок server, который включает HTTP/3 вместе с HTTP/2
Минимальный рабочий фрагмент конфигурации выглядит компактнее, чем можно ожидать:
server {
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
server_name example.com;
ssl_certificate /etc/nginx/ssl/example.com.pem;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
ssl_protocols TLSv1.3;
ssl_early_data on;
add_header Alt-Svc 'h3=":443"; ma=86400';
location / {
root /var/www/example.com;
}
}Здесь две директивы listen работают в паре. Первая открывает привычный TCP-порт 443 для HTTPS и HTTP/2, вторая поднимает UDP-сокет для QUIC. Строка http2 on включает второе поколение протокола и не задевает третье, потому что они живут на разных транспортах и друг другу не мешают. Параметр ssl_protocols со значением TLSv1.3 обязателен: QUIC не умеет в старые версии TLS и на TLS 1.2 откажется поднимать соединение.
Заголовок Alt-Svc выполняет роль объявления. Браузер первым делом подключается по TCP, читает заголовок и узнаёт, что на том же порту доступен h3. Со следующего соединения клиент пробует UDP, и если пакеты ходят, остаётся на быстром транспорте. Значение ma=86400 сообщает, что объявление действует сутки. Если QUIC по какой-то причине не заработает, например UDP перекрыт корпоративным фаерволом, браузер молча вернётся к TCP, и пользователь не заметит подмены.
Директива ssl_early_data on открывает режим 0-RTT для повторных подключений. У неё есть цена в безопасности: запросы из ранних пакетов можно воспроизвести повторной отправкой, поэтому они годятся только для идемпотентных операций вроде GET. Когда nginx передаёт запросы приложению, факт работы в 0-RTT принято передавать дальше заголовком Early-Data:
proxy_set_header Early-Data $ssl_early_data;и приложение уже решает, обработать такой запрос или ответить кодом 425 Too Early.
Проверка работы протокола и практические мелочи эксплуатации
Включить директивы мало, нужно убедиться, что трафик действительно переехал на новый транспорт. Быстрая проверка выполняется через curl, собранный с поддержкой HTTP/3: команда curl --http3 https://example.com вернёт ответ, а при детальном выводе покажет, что рукопожатие прошло по QUIC. В браузерах ответ лежит на поверхности: в инструментах разработчика колонка Protocol при успешном переключении показывает h3 вместо h2. В логи nginx удобно добавить переменную $http3, которая отражает, установлено ли соединение поверх QUIC:
log_format quic '$remote_addr [$time_local] "$request" '
'$status $body_bytes_sent $http3';Теперь мелочи, на которых спотыкаются чаще всего. Первой проверяют именно UDP: TCP-сайт открывается безупречно даже тогда, когда QUIC-сокет закрыт фаерволом или оператором связи, и без отдельной проверки легко решить, что всё работает. Дальше вспоминают про кеширование объявлений: браузеры помнят Alt-Svc на срок ma, поэтому после отключения h3 часть клиентов ещё сутки будет пытаться использовать UDP, а затем вернётся к TCP сама.
Для нагруженных проектов пригодятся три служебные директивы. Параметр quic_gso on включает сегментацию на уровне ядра Linux и снижает нагрузку на процессор при отправке множества мелких пакетов. Директива quic_retry on добавляет проверку адреса клиента с отправкой Retry-пакета: пока адрес не подтверждён, сервер не отдаёт больше утроенного объёма полученных пакетов, что отрезает попытки усиления трафика, хотя и добавляет один лишний оборот пакета новым клиентам. Лимит http3_max_concurrent_streams управляет числом одновременных потоков внутри соединения, по умолчанию их 128, и трогать его требуется редко.
В сухом остатке у HTTP/3 не осталось блокирующих преград для внедрения. Поддержка браузеров исчерпывающая, nginx включается четырьмя строками конфигурации, а риски сводятся к открытому UDP-порту и паре настроек безопасности. Сайты с мобильной аудиторией и зарубежным трафиком почувствуют разницу в первые дни, ресурсные тяжеловесы получат меньше подтормаживаний на слабых сетях. Транспорт, который начинался как эксперимент Google, к 2026 году стал рабочим инструментом с понятной настройкой, и момент, когда он превратится в умолчание по всей сети, ближе, чем кажется.