Эффективность и перспективы экспериментального протокола Quick User Datagram Protocol Internet Connections

Введение. В настоящее время доступные веб-ресурсы представляют собой ценную базу знаний и неотъемлемую часть функционирования организаций различных направлений. Развитие рынка интернет-рекламы выступает ключевым фактором роста всей рекламной индустрии в Российской Федерации [1]. Обеспечение комфортного взаимодействия конечного пользователя с информационными системами в сети Интернет является приоритетной задачей для компаний любого масштаба. Исследования демонстрируют, что даже незначительное повышение производительности веб-страниц способно оказать существенное положительное влияние на финансовые показатели бизнеса [2][3].

Передача данных в World Wide Web (WWW) осуществляется посредством протокола HTTP, имеющего три основные версии [4]. Поддержка современных протоколов веб-серверами способна благоприятно воздействовать на пользовательский опыт при работе с сайтами [5]. HTTP/3 базируется на протоколе QUIC [6], который разрабатывался как альтернатива Transmission Control Protocol¹ (TCP), применявшемуся в предыдущих версиях HTTP [7], с целью повышения скорости и безопасности интернет-соединений.

Анализ существующей литературы позволяет зафиксировать как достигнутые результаты, так и существенные противоречия между ними. В [8] представлены результаты масштабного развёртывания QUIC в инфраструктуре Google: задержка ответов поискового сервиса сократилась на 8,0 % для настольных платформ и на 3,6 % для мобильных пользователей, частота прерываний видео воспроизведения снизилась на 18,0 % и 15,3 % соответственно. Авторы фиксируют, что выигрыш нарастает с увеличением метрики Round-Trip Time² (RTT) и потерь пакетов, однако оказывается ниже теоретически ожидаемого — в том числе из-за ограничений реализации и специфики сетевого оборудования операторов. Это означает, что перенос выводов на развёртывания умеренного масштаба требует самостоятельной экспериментальной проверки.

В [9] сравнили QUIC и TCP в лабораторной среде с локально установленным сервером и констатировали минимальные различия между HTTP/2 и HTTP/3 при многопоточной передаче. В другой статье, [10], напротив, в аналогичном сценарии с уровнем потерь 12 % зафиксировали пятикратное преимущество HTTP/3 над HTTP/2. Данное противоречие обусловлено различием сетевых условий и остаётся неразрешённым применительно к штатному развёртыванию без симулированных нарушений сети. При этом работы не включают HTTP/1.1 как отправную точку для сравнений и не содержат данных по метрике TTFB.

В работе [11] были исследованы клиент-серверные протоколы с позиций отказоустойчивости и безопасности в реальных сетевых условиях и зафиксировали, что фактический прирост производительности при переходе на QUIC варьируется в зависимости от конфигурации промежуточного сетевого оборудования. Данный вывод согласуется с наблюдением авторов [8] о расхождении между теоретически ожидаемым и практически достигаемым выигрышем от протокола.

В обзорной работе о перспективах HTTP/3 и QUIC [12] показано, что совмещённое рукопожатие QUIC и встроенное шифрование TLS 1.3 формируют теоретическую основу для существенного снижения задержек. Однако учёные указывают на сложности практического развёртывания, обусловленные незрелостью поддержки протокола серверным программным обеспечением, а конкретная конфигурационная процедура в работе не приводится.

В [13] задокументировано, что 19,38 % запросов в крупном мобильном веб-сервисе приходится на фазу медленного старта, в течение которой статически заданный начальный размер окна перегрузок не соответствует реальной полосе пропускания. Тем самым исследование подтверждает, что механизм медленного старта алгоритма CUBIC создаёт измеримые задержки при передаче небольших файлов, из которых обычно состоят веб-страницы, что служит основанием для изучения BBR как альтернативного решения.

В статье [14] обоснован алгоритм BBR, использующий оценку пропускной способности канала и задержки распространения вместо потерь пакетов в качестве сигнала перегрузки. Развёртывание BBR в магистральной сети Google B4 обеспечило рост пропускной способности в 2–25 раз по сравнению с CUBIC. Вместе с тем в публикации анализируются агрегированные показатели пропускной способности, тогда как динамика скорости передачи во времени (характерная для CUBIC пилообразная форма графика в сравнении с более стабильным профилем BBR) экспериментально не визуализируется.

В работе [15] документируется, что в реализациях QUIC алгоритм CUBIC остаётся используемым по умолчанию, тогда как BBR предоставляется как опциональный. Проведённые авторами эксперименты в симуляторе ns-3 показывают, что BBR обеспечивает более высокую пропускную способность по сравнению с CUBIC при высоких задержках канала, однако при низкой полосе пропускания уступает ему по числу потерянных пакетов. При этом динамика скорости передачи во времени в работе не анализируется, что оставляет открытым вопрос о стабильности скоростного профиля каждого из алгоритмов.

Приведённый обзор позволяет выделить три взаимосвязанных пробела. В имеющихся работах HTTP/1.1, HTTP/2 и HTTP/3 не сопоставляются одновременно в единых контролируемых условиях: большинство исследований ограничено сравнением HTTP/2 и HTTP/3. Сведения о производительности протоколов существенно расходятся в зависимости от условий тестирования, а оценка в штатных условиях без прокси-серверов и искусственно вносимых потерь пакетов в эмулируемой сетевой среде представлена недостаточно. При этом практическая процедура конфигурирования стандартного веб-сервера для HTTP/3 в научной литературе не задокументирована. Таким образом, научный пробел состоит в отсутствии работ, в которых в рамках единой методологической схемы одновременно: сопоставляются HTTP/1.1, HTTP/2 и HTTP/3 в контролируемых условиях; документируется процедура конфигурирования стандартного веб-сервера для поддержки HTTP/3; оценивается влияние алгоритмов контроля перегрузок CUBIC и BBR на прикладные метрики веб-доступа. Восполнение указанного пробела определяет цель и постановку задач данного исследования.

Целью данного исследования являлась экспериментальная оценка прикладной эффективности HTTP/3 (QUIC) в контролируемых условиях на едином тестовом стенде путём сопоставления HTTP/1.1, HTTP/2 и HTTP/3, анализа влияния алгоритмов контроля перегрузок CUBIC и BBR и документирования процедуры конфигурирования HTTP/3-сервера.

Для достижения поставленной цели были решены следующие задачи:

• развернуть тестовый стенд с поддержкой HTTP/1.1, HTTP/2 и HTTP/3;
• зафиксировать последовательность конфигурирования веб-сервера для работы с HTTP/3;
• измерить и сопоставить TTFB и время полной загрузки страницы для разных версий HTTP;
• сравнить поведение алгоритмов CUBIC и BBR при передаче файла большого объёма;
• интерпретировать полученные результаты с учётом теоретических ожиданий и опубликованных исследований.

Материалы и методы

Оборудование. Для проведения экспериментов был подготовлен тестовый стенд, состоящий из арендованной в датацентре IXcellerate в Москве виртуальной машины с характеристиками: 1 Virtual Central Processing Unit³ (vCPU) 2.4 ГГц, 2 ГБ оперативной памяти под управлением операционной системы Ubuntu 22.04.5 Long-Term Support⁴ (LTS) и личной рабочей станции под Windows 11. Оба устройства имеют выход в интернет. У виртуальной машины есть статический Internet Protocol address⁵ (IP-адрес) в сети интернет с доменным именем serafimdev. com.

План исследования. В рамках работы было запланировано провести три эксперимента: сравнение скорости установления соединения с использованием HTTP/1.1, HTTP/2, HTTP/3; сравнение скорости загрузки тестовой страницы через протоколы HTTP/1.1, HTTP/2, HTTP/3; сравнение скорости передачи информации с использованием протоколов контроля перегрузок CUBIC и BBR.

Реализация экспериментов осуществлялась в следующей последовательности. На виртуальной машине был установлен и настроен веб-сервер nginx с тремя поддоменами, каждый из которых обслуживал трафик по одной версии протокола: HTTP/1.1, HTTP/2 и HTTP/3. Для оценки скорости установления соединения на каждом поддомене измерялась метрика TTFB. Затем на сервер был загружен шаблон веб-страницы, состоящий из 32 файлов, и произведены замеры времени её полной загрузки. Для эксперимента по сравнению алгоритмов контроля перегрузок на сервер был размещён файл объёмом 3 ГБ; скачивание выполнялось последовательно при активном алгоритме CUBIC (конфигурация по умолчанию) и после переключения на BBR, в обоих случаях с записью профиля скорости передачи. Последующий анализ результатов исследования включал сравнение полученных данных с теоретическими значениями, полученными на основе приведённой ниже модели.

При использовании HTTP/1.1 с шифрованием TLS 1.2 полное время до отправки первого байта данных складывается из нескольких этапов инициализации соединения (таблица 1), каждый из которых занимает некоторое количество круговых запросов между узлами сети. Таким образом, ожидаемое время инициализации защищённого соединения через HTTP/1.1 получается по формуле (1).

(1)

Протокол QUIC объединяет транспортное и криптографическое рукопожатие на основе TLS 1.3, сокращая суммарные затраты до 1 RTT. По формуле (2) получаем теоретический выигрыш по метрике TTFB.

(2)

Инструменты. Все измерения производили с использованием мобильного интернета 4G. На виртуальной машине был установлен nginx версии 1.27.4, поскольку поддержка HTTP/3 соединений в веб-сервер nginx добавлена с версии 1.25.0⁷.

Для проведения экспериментов было сконфигурировано три поддомена: http1.serafimdev. com, http2.serafimdev. com, http3.serafimdev. com с сертификатами от Let’s Encrypt для протоколов HTTP/1.1, HTTP/2, HTTP/3 соответственно. При конфигурации использовалось программное обеспечение (ПО) автоматизации работы с сертификатами certbot.

Корректность выполненных на сервере настроек была проверена через инструменты разработчика браузера Google Chrome. При обмене данных по протоколу HTTP/3 в столбце протокол должны отображаться значения h3 (рис. 1). Данные инструменты также предоставляют информацию для оценки производительности веб‑страницы и скоростей загрузки её компонентов и применялись для измерения времени полной загрузки страницы.

Метрика TTFB была определена при помощи скрипта на языке программирования JavaScript, который выполнил запросы к серверу с записью значений метрики. Аналогичный подход был применён и для сбора данных, необходимых для визуализации графиков скоростей загрузки ресурсов при различных алгоритмах контроля перегрузки. При проведении измерений было важно отключить кэширование запросов в инструментах разработчика, чтобы исключить влияние локального кэша на результаты. Обработка собранных данных была выполнена с использованием библиотек numpy и matplotlib для Python. Для интеграции нестандартного алгоритма управления перегрузкой BBR в ядро операционной системы — в данном исследовании использовалась Ubuntu 22.04.5 LTS — было необходимо загрузить соответствующий модуль — sudo modprobe tcp_bbr и изменить значение переменной — sudo sysctl -w net.ipv4.tcp_congestion_control=bbr.

Процедуры. Интернет-соединение часто бывает нестабильно, поэтому был применен статистический анализ результатов во избежание влияния выбросов на результаты исследования. В экспериментах по измерению времени инициализации соединения и скорости загрузки страницы замеры для каждого из протоколов были проведены по 20 раз. Затем был применен метод межквартильного размаха для выявления выбросов и среднее арифметическое для агрегации оставшихся измерений в финальный результат. Верхняя и нижняя границы выбросов определялись по формулам (3) и (4).

(3)

(4)

где Q1 — 25-й перцентиль, Q3 — 75-й перцентиль, IQR = Q3 – Q1.

При анализе скорости передачи для замеров использовался модуль JavaScript XMLHttpRequest, предоставляющий количество загруженных байт раз в неравное количество миллисекунд. Из-за маленького промежутка между измерениями и нестабильности сети необработанные данные содержали большое количество выбросов. Для получения более наглядных графиков было применено сглаживание результатов при помощи скользящей средней с окном в 31 измерение.

Результаты исследования

Процедура конфигурирования HTTP/3-сервера. Документация процесса конфигурации тестового стенда является самостоятельной задачей исследования. Для организации доступа к веб-контенту по HTTP/3 необходим сервер с операционной системой и доступ к нему. В исследовании применялся сервер с операционной системой Ubuntu 22.04.5 LTS с удаленным доступом по SSH. В процессе настройки была выявлена ключевая сложность при организации HTTP/3 веб-сервера — необходимость использовать mainline⁸— репозиторий nginx вместо стандартного.

Стандартный репозиторий Ubuntu 22.04.5 LTS содержит nginx версии 1.18, тогда как поддержка HTTP/3 появилась начиная с версии 1.25.0. Для установки актуальной версии необходимо добавить основной репозиторий с последними версиями программного обеспечения в систему, используя команды, показанные на рис. 2.

Приведённые инструкции записывают ключ, которым подписываются пакеты из нового репозитория в системное хранилище доверенных ключей: /usr/share/keyrings и добавляют адрес mainline-репозитория nginx в список источников пакетов /etc/apt/sources.list.d с указанием пути к подписи пакетов. После выполнения этих шагов при установке nginx через менеджер пакетов apt будет использоваться репозиторий, содержащий все последние версии сервиса.

Поскольку шифрование встроено в протокол QUIC, наличие сертификата и доменного имени является обязательным требованием при использовании HTTP/3. На предыдущих версиях протокола HTTP шифрование через TLS является отдельным слоем, что добавляет задержку при установлении соединения, но позволяет организовать незащищённый обмен данными. HTTP без шифрования имеет применение в сетях, где шифрование уже обеспечено через Virtual Private Network⁹ (VPN). Таким образом, использование HTTP/3 в таких сетях приводит к необходимости настройки сертификатов. На используемом тестовом стенде были выпущены сертификаты от компании Let’s Encrypt при помощи программного обеспечения по автоматизации работы с сертификатами — certbot.

Помимо этого, в конфигурационный файл сайта необходимо внести изменения (рис. 3). Ключевыми в конфигурации являются строки 3, 10, 12, 16. Строка 12 содержит инструкцию, разрешающую использование протокола HTTP/3. На строчке 16 указывается заголовок Alt-Svc. При наличии этого заголовка в ответе сервера клиент переходит на использование HTTP/3 (если поддерживается). Поэтому на строчках 2 и 3 указана поддержка стандартных TCP соединений и UDP через QUIC. Впоследствии значение заголовка кэшируется и обмен заголовками по TCP не происходит. Так как QUIC работает на основе TLS версии 1.3, эта версия явно указывается на строке 10.

TTFB. TTFB — метрика, показывающая, сколько времени проходит от отправки запроса до начала передачи ресурса. Для проведения замеров использовался JavaScript скрипт. Полученные значения приведены в таблице 2.

Были получены значения:

• HTTP/1.1: выбросов нет, среднее — 29,27 мс;
• HTTP/2: есть 3 выброса, среднее — 27,23 мс;
• HTTP/3: есть 1 выброс, среднее — 22,52 мс.

(5)

Согласно расчётам по формуле (5), эксперимент показал, что переход с HTTP/1.1 на HTTP/3 с протоколом QUIC обеспечил сокращение времени до первого байта (TTFB) на 23,06 %.

Время загрузки страницы. Для исследования влияния использования протокола QUIC на скорость загрузки обычной веб страницы в открытых источниках был найден шаблон страницы, состоящий из 32 файлов, всего 728 килобайт. Полученные значения представлены в таблице 3.

Были получены значения:

• HTTP/1.1: есть 3 выброса, среднее — 792,7 мс;
• HTTP/2: выбросов нет, среднее — 833,15 мс;
• HTTP/3: есть 1 выброс, среднее — 717,63 мс.

(6)

Расчёт по формуле (6) показывает сокращение времени загрузки страницы на 9,5 % при использовании HTTP/3 и QUIC по сравнению с HTTP/1.1 и TCP.

Скорость передачи. Для эксперимента использовался файл размером 3 ГБ передача которого осуществлялась по протоколу HTTP/2. Выбор HTTP/2 для данного эксперимента обусловлен методологическими соображениями: целью сравнения являлась изолированная оценка влияния алгоритма контроля перегрузок на профиль скорости передачи, без наложения дополнительных эффектов, вносимых транспортным протоколом. Протокол HTTP/3 (QUIC) реализует собственный стек управления перегрузками поверх UDP, тогда как HTTP/2 использует стандартный TCP-стек ядра операционной системы, в котором переключение между алгоритмами CUBIC и BBR осуществляется непосредственно через параметры ядра Linux без изменения логики протокола прикладного уровня. Было произведено скачивание файла с применением алгоритмов контроля перегрузок CUBIC и BBR. На рис. 4 и 5 приведены начальные фрагменты из графиков скорости загрузки при использовании CUBIC и BBR соответственно.

При работе алгоритма BBR скорость большую часть времени держится на одном уровне. Средние значения скорости скачивания получились 13,12 МБ/с для CUBIC и 12,75 МБ/с для BBR.

Площадь под кривой графика отражает количество переданной информации и вычисляется по формуле (7). За первые 3 секунды передачи с использованием CUBIC было передано 23,1568 МБ данных, а с использованием BBR — 27,3622 МБ.

(7)

Обсуждение. Полученные результаты показывают, что практический выигрыш от внедрения HTTP/3 (QUIC) подтверждается экспериментально, однако его величина оказывается существенно ниже теоретически ожидаемой, что требует интерпретации с учётом особенностей сетевой среды, программной реализации и методики измерений.

Сложности конфигурирования и операционные риски. Описанная процедура настройки сопряжена с рядом практических трудностей, которые необходимо учитывать при планировании производственного развёртывания HTTP/3.

Первая сложность связана с невозможностью использования стандартных образов виртуальных машин и контейнеров при автоматизации развёртывания. Большинство официальных образов Ubuntu и популярных контейнерных образов nginx на базе Alpine Linux или Debian включают версию nginx из дистрибутивного репозитория, которая не поддерживает HTTP/3. При использовании таких образов в системах оркестрации (Kubernetes, Docker Compose) каждый узел требует либо ручного добавления mainline-репозитория и переустановки nginx, либо сборки собственного образа с нужной версией. Это усложняет автоматизацию и увеличивает операционные издержки на сопровождение инфраструктуры [17].

Вторая сложность обусловлена механизмом согласования протокола через заголовок Alt-Svc. Первое соединение клиента с сервером всегда устанавливается по TCP (HTTP/1.1 или HTTP/2), и лишь получив в ответе заголовок Alt-Svc, браузер переключается на QUIC при последующих запросах. Если между клиентом и сервером присутствует промежуточный узел — балансировщик нагрузки, обратный прокси или CDN-узел — который не поддерживает QUIC или блокирует UDP-трафик на порту 443, заголовок Alt-Svc либо не доходит до клиента, либо клиент не может установить UDP-соединение. Такое поведение затрудняет диагностику и создаёт риск скрытого отсутствия эффекта от внедрения протокола. Согласно базовой спецификации QUIC [18], при недоступности UDP-транспорта клиент должен откатиться к TCP-соединению без явной сигнализации об ошибке, что делает отсутствие HTTP/3 в реальном трафике трудно диагностируемым без явной инструментальной проверки. Для верификации факта использования HTTP/3 необходима явная проверка через инструменты разработчика браузера или серверные логи с фиксацией версии протокола.

Необходимым условием установления соединения по протоколу HTTP/3 на стороне клиента является наличие браузера с включённой поддержкой QUIC. В браузере Google Chrome поддержка протокола активирована по умолчанию начиная с версии 87, однако в корпоративных средах она может быть отключена групповыми политиками. При отключённой поддержке QUIC браузер не будет устанавливать соединения по HTTP/3 вне зависимости от корректности серверной конфигурации и наличия заголовка Alt-Svc.

Интерпретация результатов TTFB. Объединённое рукопожатие QUIC и TLS 1.3, регламентированное в RFC 9001 [19] и опирающееся на спецификацию TLS 1.3 [20], теоретически сокращает инициализацию до 1 RTT, однако практическая эффективность этого механизма чувствительна к особенностям реализации криптографического стека на конкретном оборудовании и в конкретной версии программного обеспечения. Снижение TTFB на 23,06 % при переходе с HTTP/1.1 на HTTP/3 экспериментально подтверждает преимущество объединённого QUIC-рукопожатия, устраняющего дополнительный RTT, характерный для раздельной инициализации TCP и TLS. Вместе с тем измеренный прирост существенно уступает теоретически ожидаемому значению 71,43 %, что объясняется совокупностью факторов.

Обработка UDP-пакетов на промежуточном сетевом оборудовании провайдера зачастую менее оптимизирована по сравнению с TCP-трафиком: маршрутизаторы и межсетевые экраны традиционно настроены под TCP-профиль нагрузки, а часть операторов применяет дополнительную инспекцию или троттлинг UDP-потоков [8][11]. Реализации QUIC в nginx и Google Chrome на момент проведения эксперимента сохраняют экспериментальный статус, что проявляется в неоптимальных значениях параметров стека и дополнительных издержках на уровне приложения. Мобильный канал 4G вносит нестабильную переменную составляющую задержки, которая нивелирует часть выигрыша от сокращения числа RTT при установлении соединения. Аналогичное расхождение между теорией и практикой зафиксировано в масштабном развёртывании QUIC компанией Google, где реальное снижение задержки поиска составило 8,0 % для настольных и 3,6 % для мобильных пользователей вместо теоретически ожидаемых значений [8], а также подтверждено в отечественных исследованиях реальных сетевых условий [11]. Полученный результат согласуется и с данными компании ITSumma¹⁰, зафиксировавшей снижение TTFB на 12,4 %, что в совокупности свидетельствует о системном характере разрыва между теоретической и практической эффективностью протокола на текущем этапе его развития.

Интерпретация времени загрузки страницы. Ускорение полной загрузки тестовой страницы на 9,5 % при использовании HTTP/3 по сравнению с HTTP/1.1 объясняется прежде всего мультиплексированием запросов в рамках одного QUIC-соединения и устранением Head-of-Line¹¹ блокировки на транспортном уровне. При загрузке тестовой страницы, состоящей из 32 файлов, HTTP/3 параллельно обрабатывает все запросы без взаимной блокировки потоков, тогда как HTTP/1.1 ограничен числом параллельных TCP-соединений.

Примечательна аномалия в результатах HTTP/2: его среднее время загрузки (833,15 мс) превысило аналогичный показатель HTTP/1.1 (792,7 мс). Данный эффект является артефактом применённой методологии статистической обработки, а не показателем реальной неэффективности протокола. В выборке HTTP/1.1 метод межквартильного размаха исключил три значения, превышающих верхнюю границу, что существенно снизило итоговое среднее. Средние значения времени загрузки для HTTP/1.1 и HTTP/2 по всем двадцати измерениям без удаления выбросов составляют 843,8 мс и 833,15 мс соответственно, что подтверждает большую эффективность HTTP/2 в скорости загрузки по сравнению с HTTP/1.1. В данных HTTP/2 выбросы по верхней границе отсутствовали, это означает, что протокол обеспечил более равномерное распределение времён отклика за счёт мультиплексирования запросов и приоритизации потоков в рамках одного TCP-соединения. Таким образом, сравнение очищенных средних некорректно отражает реальное соотношение протоколов: HTTP/2 демонстрирует более высокую стабильность и меньшую вариативность, тогда как итоговое среднее значение после удаления выбросов оказалось статистически ниже у HTTP/1.1.

Интерпретация CUBIC и BBR. Средние скорости передачи файла объёмом 3 ГБ при использовании CUBIC (13,12 МБ/с) и BBR (12,75 МБ/с) оказались сопоставимы: разница в 3 % находится в пределах погрешности измерений при нестабильном мобильном канале. Данный результат предсказуем для длительной передачи одного файла: на протяжении сотен секунд оба алгоритма достигают стационарного режима загрузки канала, и различия в стратегии инициализации перестают определять итоговую среднюю скорость.

Принципиальное различие между алгоритмами проявляется в профиле передачи. CUBIC демонстрирует характерный пилообразный профиль скорости (рис. 4): она монотонно возрастает от стартовых значений менее 10 МБ/с до рабочего уровня примерно за четыре секунды, после чего циклически снижается в моменты потерь пакетов. BBR, использующий оценку пропускной способности Bandwidth-Delay Product¹² (BDP), с первых секунд удерживает скорость на стабильном уровне.

При работе с WWW большая часть запрашиваемых файлов имеют небольшой размер. Предположим, что размер одного файла с ресурсами для веб-страницы составляет 63 КБ, начальный размер окна для медленного старта — 10 килобайт (настройка по умолчанию в linux-системах), максимальный размер окна — 64 КБ. При медленном старте в алгоритме CUBIC для увеличения окна перегрузки используется экспонента [21].

(8)

Результат вычислений по формуле (8) свидетельствует о том, что для передачи файла необходимо увеличить размер окна перегрузки в три раза, на что потребуется 3 RTT. Если бы передача с самого начала велась с окном перегрузки равным 64, то можно было бы провести передачу за 1 RTT.

Именно этот стартовый период определяет прикладную значимость BBR для веб-сервисов. Типичный ресурс страницы — скрипт, таблица стилей, шрифт — передаётся за одно-два RTT и укладывается в фазу медленного старта CUBIC, в течение которой алгоритм ещё не вышел на рабочее окно перегрузки. BBR в этом сценарии обеспечивает немедленный выход на оптимальную скорость, что суммарно сокращает время параллельной загрузки множества мелких ресурсов. Таким образом, преимущество BBR перед CUBIC реализуется не на длинных передачах, а при загрузке ресурсов страницы, сопровождающейся множественными короткими запросами сразу после установления соединения.

Количественным подтверждением преимущества BBR в начальной фазе передачи служит сравнение площадей под кривыми графиков скорости, вычисленных по формуле (7) методом трапеций. За первые три секунды передачи алгоритм CUBIC обеспечил передачу 23,16 МБ данных, тогда как BBR — 27,36 МБ, что на 18,2 % больше. Данный результат согласуется с результатами экспериментов в работе [15], где была зафиксирована более высокая пропускная способность BBR при высоких значениях RTT, характерных в том числе для межконтинентальных соединений.

Перспективным направлением дальнейших исследований является экспериментальная проверка преимущества BBR непосредственно в веб-сценарии: измерение времени полной загрузки страницы, состоящей из множества небольших ресурсов, при использовании алгоритмов CUBIC и BBR в сочетании с каждой из версий протокола HTTP. Подобный эксперимент позволит количественно оценить, в какой мере ускоренный выход BBR на рабочую скорость транслируется в сокращение времени загрузки страницы в реальном веб-сценарии, а также определить, при каких сочетаниях версии протокола и алгоритма управления перегрузками прикладной эффект проявляется наиболее отчетливо.

Ограничения исследования и практические рекомендации. Полученные результаты обладают практической ценностью для оценки выгоды перехода на HTTP/3, однако ряд ограничений экспериментального стенда сужает область применимости выводов.

Конфигурация стенда включала единственную виртуальную машину с 1 vCPU и единственного клиента, подключённого через мобильный канал 4G. Мобильный канал привносит нестабильную переменную задержку и непостоянную полосу пропускания, что увеличивает разброс замеров и затрудняет изоляцию эффекта протокола от эффекта канала. Производительность транспортных протоколов существенно зависит от сетевой топологии, значений RTT, уровня потерь пакетов и политик промежуточного оборудования, поэтому перенос результатов на иные сетевые сценарии требует самостоятельной экспериментальной проверки [22][23].

Малый объём выборки (20 замеров на протокол) обеспечивает достаточную точность для первичной оценки, но недостаточен для построения статистически устойчивых доверительных интервалов. Отсутствие географически распределённых клиентов не позволяет оценить влияние высоких RTT — условий, при которых преимущество QUIC теоретически наиболее выражено.

На основании полученных данных можно сформулировать следующие практические рекомендации. Переход на HTTP/3 целесообразен прежде всего для сервисов с большим числом небольших ресурсов на странице, аудиторией с высокими задержками (мобильные пользователи, удалённые регионы) и требованиями к минимизации TTFB. Для сервисов с преобладающей передачей крупных файлов через стабильные проводные соединения практический выигрыш от перехода будет минимальным. Алгоритм BBR рекомендуется к включению совместно с HTTP/3: при сопоставимой средней скорости на длинных передачах он обеспечивает стабильный профиль и сокращает время выхода на рабочую скорость, что критично именно в веб-сценарии множественных коротких запросов.

Для повышения достоверности оценки производительности в последующих исследованиях обосновано сравнение альтернативных серверных реализаций QUIC (помимо nginx), а также анализ влияния прокси-серверов на метрики производительности при использовании QUIC [10].

Заключение. Проведённое исследование подтвердило, что внедрение протокола QUIC даёт практический выигрыш в скорости веб-взаимодействий. Таким образом, было получено сокращение метрики TTFB на 23,06 % и снижение времени загрузки тестовой веб-страницы на 9,5 %. Приведённая в статье модель прогнозирует снижение TTFB не на 23,06 %, а на 71,43 %. Такое расхождение показывает сильное влияние экспериментального статуса протокола на его распространённость на сетевом оборудовании и критичность иных факторов, рассмотренных в статье, для полномасштабного внедрения протокола.

В работе проведено сравнение алгоритмов контроля перегрузок CUBIC (стандартный) и BBR (наиболее распространённый в HTTP/3), а также представлено теоретическое обоснование преимущества BBR при передаче малоразмерных файлов, обусловленного более высокой начальной скоростью и отсутствием механизма медленного старта. Аналогичные достоинства BBR зафиксированы и в зарубежных исследованиях. В частности, в статье [15] отмечается эффективность данного алгоритма в каналах с большим RTT (межконтинентальные соединения) благодаря моделированию пропускной способности канала связи.

Протокол QUIC в сочетании с HTTP/3 на текущем этапе развития сопряжён с определёнными сложностями внедрения, однако обладает значительным потенциалом для построения высокопроизводительных информационных систем, что подтверждается результатами других исследований [24], в том числе применительно к системам с требованиями к надёжной доставке трафика реального времени [25].

Процесс настройки HTTP/3-сервера требует загрузки дополнительных модулей в ядро операционной системы. Это негативно сказывается на распространённости протокола, однако при наличии в организации достаточного количества квалифицированных специалистов для поддержки подобной инфраструктуры переход на HTTP/3 способен обеспечить ощутимые преимущества. Выигрыш по TTFB и отсутствие Head-of-Line блокировок теоретически позволят существенно ускорить загрузку ресурсов страницы. Особенно заметным прирост производительности может оказаться на страницах, содержащих множество небольших ресурсов.

Помимо вопросов производительности, переход на QUIC и HTTP/3 порождает специфические вызовы для инфраструктуры информационной безопасности: встроенное шифрование затрудняет глубокую инспекцию пакетов (DPI) и функционирование систем обнаружения вторжений, что детально рассмотрено в [26] и требует отдельного учёта при планировании производственного внедрения.

Ограничения исследования включают упрощённую конфигурацию тестового стенда (одна виртуальная машина и мобильный 4G-канал), а также небольшую выборку замеров. Полученные результаты обладают прикладной ценностью для оценки целесообразности перехода на HTTP/3, однако нуждаются в подтверждении на более широком спектре сценариев, поскольку производительность транспортных протоколов существенно зависит от сетевой топологии, задержек и потерь. Тема алгоритмов контроля перегрузок может быть раскрыта подробнее в последующих публикациях — в частности, представляется целесообразным сопоставление различных алгоритмов в сочетании с разными версиями протокола HTTP. В современных информационных системах широко применяются прокси-серверы для управления трафиком; перспективным направлением является исследование влияния подобных промежуточных узлов на метрики производительности при использовании QUIC [10].