Сравнительный анализ скорости передачи и надёжности протоколов транспортного уровня при передаче файлов и потокового мультимедиа

В настоящее время в сети Интернет ключевыми транспортными протоколами остаются Transmission Control Protocol (TCP) и User Datagram Protocol (UDP), предложенные в 1974 и 1980 годах соответственно. Оба протокола входят в состав стека TCP/IP и на протяжении десятилетий являются основой функционирования глобальной сети. Однако стремительное развитие технологий приводит к тому, что даже относительно небольшой временной интервал, например пять лет, может существенно изменить требования к сетевой архитектуре, что стимулирует необходимость их модернизации и появления новых решений [1].

Одним из таких решений стал протокол QUIC, впервые представленный в 2013 году. Его название традиционно трактуется как «Quick UDP Internet Connections» («быстрые интернет-соединения на базе UDP»). Основная идея разработки заключалась в создании альтернативы TCP, способной обеспечить более высокую производительность и повышенный уровень безопасности [2].

Архитектурные особенности QUIC предполагают ряд преимуществ: сокращение времени установки соединения и возможность мультиплексирования потоков. В то же время отдельные его пакеты могут быть значительно более объемными по сравнению с TCP [3]. Несмотря на продолжительный срок существования, широкого распространения протокол пока не получил: его реализация ограничивается, в основном, веб-серверами Google и браузерами на базе Chromium, поддерживающими технологию лишь частично.

Исследованию работы QUIC посвящено множество работ как в контексте функционирования глобальной сети [2–5], так и в беспроводных средах передачи данных [7–9]. В данной статье рассматривается базовый сценарий: клиент и сервер размещены в пределах одной сети. В рамках эксперимента проводится сравнение производительности TCP, TCP+TLS и QUIC при передаче файлов различных размеров, а также сравнение качества работы QUIC и UDP в условиях потоковой передачи видео.

Особенности транспортного протокола

QUIC

QUIC – это транспортный протокол, разработанный для повышения эффективности передачи данных в сетях с высокой задержкой и потерями пакетов. Изначально созданный компанией Google и позже стандартизованный IETF в RFC 9000 [2], QUIC нацелен на повышение производительности сетевого трафика, сокращение задержек при установлении соединений и обеспечение более высокого уровня безопасности по сравнению с TCP [3].

QUIC работает поверх UDP и предоставляет функциональность, аналогичную TCP, включая контроль перегрузки и надежную доставку данных. Однако его ключевые особенности делают протокол более эффективным. В QUIC встроено шифрование на основе TLS 1.3 [4], что исключает необходимость отдельного этапа установки защищенного соединения, как в TCP+TLS. Это обеспечивает защиту данных на уровне протокола и снижает риск атак типа понижения уровня защиты и «человек посередине» (MITM).

В отличие от TCP, где потеря одного пакета блокирует доставку всех последующих данных (Head-of-Line Blocking), QUIC использует мультиплексирование потоков, позволяя передавать данные для каждого потока независимо. Это предотвращает задержки и повышает устойчивость к потерям пакетов, что особенно важно для высоконагруженных систем, таких как веб-сервисы и приложения для потоковой передачи данных.

Кроме того, QUIC интегрирует усовершенствованные механизмы контроля перегрузок и потерь пакетов. Он поддерживает более гибкие алгоритмы управления перегрузкой, способные адаптироваться к изменяющимся условиям сети. В отличие от TCP, использующего статические алгоритмы, QUIC допускает применение современных подходов, таких как BBR, что обеспечивает более высокую пропускную способность и стабильность передачи данных.

Важным аспектом QUIC является ускоренное установление соединения. Протокол позволяет выполнить полный процесс установления всего за один RTT (Round-Trip Time) или даже за ноль RTT при повторных соединениях, тогда как TCP требует как минимум трех RTT (SYN, SYN-ACK, ACK + TLS) [10] (рисунок 1).

Распространение QUIC продолжает расти: его внедрение уже наблюдается в таких технологиях, как HTTP/3, что делает его основным компонентом современных интернет-коммуникаций.

Рисунок 1. Схема работы HTTPS через TCP+TLS и QUIC

Структура экспериментального стенда

Экспериментальный стенд состоит из трех узлов: клиента, сервера и маршрутизатора, соединенных внутри одной сети. Клиент передавал файл на сервер через маршрутизатор, выполнявший функции маршрутизации сетевого трафика (рисунок 2).

Рисунок 2. Экспериментальный стенд (QUIC, TCP)

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

Маршрутизатор использовался для коммутации пакетов и передачи данных между узлами без дополнительной обработки трафика, что минимизировало влияние внешних факторов на измеряемые параметры.

Подход и методика исследования

План эксперимента предусматривал проведение последовательных тестов передачи данных между клиентом и сервером через маршрутизатор с использованием различных параметров передачи. Цель эксперимента заключалась в сравнении характеристик передачи файлов по протоколам QUIC и TCP.

Этапы эксперимента:

• 1.    Подготовка стенда:

  – настройка клиентского и серверного узлов, установка и конфигурация программного обеспечения для передачи файлов;

  – настройка маршрутизатора для установки прямого соединения между клиентом и сервером;

  – проверка стабильности соединения и корректности работы тестовой среды.

• 2.    Передача данных:

  – последовательная передача файла фиксированного размера (одинакового для всех тестов) от клиента к серверу;

  – проведение тестов с использованием протокола TCP;

  – проведение тестов с использованием протокола TCP+TLS;

  – выполнение аналогичных тестов с использованием протокола QUIC;

  – измерение и регистрация параметров передачи.

• 3.    Обработка и анализ результатов:

• –    захват дампов пакетов с помощью Wireshark для пакетов, отправленных клиентом на сервер;

• –    захват дампов пакетов с помощью Wireshark для пакетов, полученных сервером от клиента;

• –    анализ собранных данных;

  – проведение сравнительного анализа метрик передачи для TCP и QUIC (расчет времени передачи пакетов от клиента к серверу на основе уникального идентификатора каждого пакета).

Данный план эксперимента обеспечивал объективную оценку стабильности передачи и использования канала при передаче файлов с использованием различных транспортных протоколов.

Анализ и сравнение QUIC, TCP и

TCP+TLS

В ходе эксперимента были получены результаты по времени передачи пакетов от клиента к серверу при передаче файлов различного размера с использованием различных протоколов (таблица 1).

Таблица 1. Показатели времени передачи пакетов

Размер файла	QUIC, с.	TCP, с.	TCP+TLS, с.
10 КБ	0,022378	0,09133	0,09445
1 МБ	0,0002337	0,00756	0,00814
5 МБ	0,000152	0,00281	0,00436
100 МБ	0,002646	0,03549	0,03472

Анализ полученных данных показывает, что протокол QUIC демонстрирует значительно меньшую задержку по сравнению с TCP и TCP+TLS при передаче файлов всех размеров. Это преимущество обусловлено архитектурными особенностями QUIC, которые минимизируют накладные расходы, связанные с установлением соединения и передачей данных.

Ключевые факторы, обеспечивающие преимущество QUIC над TCP и TCP+TLS:

• 1.    Более эффективное установление соединения. В отличие от TCP, где требуется трехстороннее рукопожатие, QUIC использует односторонний процесс установки соединения, что сокращает время, необходимое для начала передачи данных.

• 2.    Интегрированное шифрование. QUIC изначально основан на TLS 1.3, устраняя дополнительные обмены пакетами, необходимые для шифрования в TCP+TLS. Это особенно заметно при передаче файлов малого размера, где накладные расходы на установление соединения составляют значительную часть общего времени передачи.

• 3.    Оптимизированный механизм управления перегрузкой. В TCP управление перегрузкой основано на механизме «медленного старта», что вызывает задержки в начале передачи данных. В отличие от этого, QUIC применяет более быстрые стратегии управления перегрузкой, позволяя быстрее достигать максимальной пропускной способности.

• 4.    Сниженное влияние потерь пакетов. В TCP потеря пакета приводит к повторной передаче всего окна перегрузки, что увеличивает время передачи. В QUIC же используется независимое мультиплексирование потоков, которое сокращает задержки, вызванные потерями пакетов [2].

Для файлов небольшого размера (10 КБ, 1 МБ) определяющим фактором общего времени передачи является время установления соединения. В этих случаях TCP и TCP+TLS значительно уступают QUIC, поскольку многочисленные обмены при установке соединения приводят к дополнительным задержкам.

При увеличении размеров файлов (5 МБ, 100 МБ) разница в скорости передачи данных между протоколами сохраняется, но становится менее выраженной. В данной ситуации преимущество QUIC наиболее заметно благодаря более быстрой обработке пакетов и меньшим задержкам, связанным с перегрузкой сети.

Таким образом, экспериментальные результаты подтверждают, что QUIC является более быстрым протоколом по сравнению с TCP и TCP+TLS, особенно в условиях кратковременных соединений и сетей с высокой задержкой. Это делает его предпочтительным выбором для современных сетевых приложений, требующих минимального времени отклика и высокой надежности передачи данных.

Данный план эксперимента обеспечивал объективную оценку стабильности передачи и исполь- зование канала при передаче файлов с использованием различных транспортных протоколов.

Особенности протокола UDP

Протокол пользовательских дейтаграмм (UDP) является одним из основных транспортных протоколов, работающих поверх IP. Он обеспечивает быструю и простую передачу данных без необходимости установки соединения и гарантий доставки. В отличие от TCP, UDP не выполняет контроль потока, полную проверку целостности данных (кроме базовой контрольной суммы) и повторную передачу потерянных пакетов. Это делает его эффективным в сценариях, где приоритет отдается скорости, а не надежности.

UDP [12] основан на дейтаграммной модели, при которой каждый пакет передается независимо. Пакеты могут приходить в неправильном порядке или теряться из-за перегрузки сети, и сам протокол не предпринимает попыток их восстановления. Заголовок UDP содержит минимальный набор полей: порты источника и назначения, длину пакета и контрольную сумму, используемую для базового обнаружения ошибок. Такая упрощенная структура облегчает обработку пакетов на стороне получателя и снижает задержки передачи

Исследование QUIC и UDP в условиях потоковой передачи видео

В ходе эксперимента по передаче видеопотоков от сервера к клиенту с использованием протоколов QUIC и UDP были выявлены существенные различия в их производительности. Протокол QUIC, как правило, использовал около 80 000 пакетов для завершения передачи, тогда как UDP в среднем требовал 392 000 пакетов.

Для получения этих данных был применен развернутый ранее экспериментальный стенд (рисунок 2), на котором передавался трафик QUIC и UDP. Соединение между узлами осуществлялось по локальной сети Ethernet. Передача видеопотока по UDP выполнялась напрямую от сервера к клиенту, тогда как в случае с QUIC использовались встроенные механизмы протокола для управления перегрузкой и обработки потерь [13]. При передаче данных от сервера к клиенту использовалось программное обеспечение NetLimiter [14], применяемое с целью ограничения пропускной способности канала связи до 5 Мбит/с. Выбор данного значения обусловлен тем, что передаваемый видеопоток имел формат FullHD, кодек H.264, для корректной работы которого минимально требуется пропускная спо- собность порядка 6 Мбит/с [15]. Уменьшение доступной полосы пропускания связано с тем, что при передаче видеопотока по протоколу UDP на низкой скорости проявляются артефакты, тогда как протокол QUIC способен обеспечивать передачу без артефактов в аналогичных условиях.

Разница в количестве переданных пакетов связана с особенностями этих протоколов, а также с их способностью справляться с потерями в сети.

UDP, являясь простым транспортным протоколом, не имеет встроенных механизмов обеспечения надежности. Отсутствие подтверждений доставки и повторной передачи потерянных пакетов приводит к значительным потерям данных в процессе передачи. В проведенных экспериментах было отмечено, что при передаче видео через UDP значительные потери пакетов вызывали выраженные визуальные артефакты на стороне получателя (рисунок 3).

Рисунок 3. Потоковая трансляция по UDP

В большинстве случаев искажения занимают до половины экрана, значительно снижая воспринимаемое качество видео. Основная причина этого заключается в том, что даже незначительные потери пакетов при потоковой передаче видео могут приводить к повреждению кадров или потере фрагментов изображения, так как кодек сжатия видео H.264 зависит от целостности данных.

Кроме того, большое количество пакетов в UDP перегружает буферы маршрутизаторов, что приводит к образованию очередей, задержкам и дополнительным потерям пакетов [16]. При высокой сетевой нагрузке такое состояние перегрузки может существенно замедлить передачу и вызвать еще больше потерь пакетов, делая видеопоток нестабильным и снижая его качество. Изза отсутствия управления потоком UDP также может приводить к неравномерному распределению нагрузки по сети, что в конечном итоге отрицательно сказывается на других сервисах, использующих ту же инфраструктуру.

В отличие от UDP, протокол QUIC разработан с целью обеспечения надежной передачи данных при минимальных задержках. Он использует такие механизмы, как подтверждение получения пакетов, повторная передача утраченных данных и встроенное управление потоком. Эти особенности позволяют QUIC минимизировать потери данных и предотвратить значительное ухудшение качества видеопотока (рисунок 4).

Рисунок 4. Потоковая трансляция по QUIC

QUIC также оптимизирует порядок доставки пакетов посредством мультиплексирования потоков, что дополнительно снижает вероятность задержек и потерь.

Впоследствии полученные видеофайлы были загружены в VQMT [17] для анализа графика SNR (Signal-to-Noise Ratio) (рисунок 5).

Рисунок 5. 36 кадр видеопотока: а) QUIC; б) UDP

Метрика SSIM (Structural Similarity Index) оценивает сходство между двумя изображениями на основе трех компонентов: сходства по яркости, сходства по контрасту и структурного сходства (рисунок 6). Метрика SSIM вычисляется с использованием нескольких окон изображения, а именно между двумя окнами x и у размером N х N , по следующей формуле:

(2 x • у + с, )(2 ^ + c ₂)

SSIM = _₂  _₂—   . x .2    ,   (1)

( x + у + С 1 )( ^х + ° у + с 2 )

где x , y – среднее значение между x и y ; 22

a x , ° _у - дисперсия x и у ;

° _xy - ковариация между x и у ;

с 1 = ( k 1 L )², с ₂ = ( k ₂ L )² - две переменные для стабилизации деления при малых знаменателях;

L – динамический диапазон пикселей;

k ₁ = 0,01 и k ₂ = 0,03 – коэффициенты коррекции.

Рисунок 6. Метрика SSIM, кадр 36

Красный график отражает видеопоток, переданный по протоколу QUIC, а синий график – поток по протоколу UDP.

Метрика MSE (Mean Squared Error) используется для оценки восстановления кадров относительно оригинала (рисунок 7). Для двух видеокадров I и K размером m х n пикселей значение MSE вычисляется по следующей формуле:

mn

MSE =---- ££ [ X ( i , j ) - Y ( i , j ) ] 2 ,   (2)

m •n i=1 j=i где X(i,j) и Y(i,j) – значение компонента яркости пикселя (i, j) для изображений X и Y, соответственно.

Рисунок 7. Метрика MSE, кадр 36

Красный график отражает видеопоток, переданный с использованием протокола QUIC, а синий график – с использованием протокола UDP.

Метрика PSNR (Peak Signal to Noise Ratio, пиковое отношение сигнал/шум) определяется следующим образом:

PSNR = 10log

MAX ² MSE

где MAX – это максимальное значение, принимаемое пикселем изображения. Максимальное значение PSNR установлено на уровне 100 дБ.

Чем выше значение PSNR, тем лучше качество видео (рисунок 8).

Рисунок 8. Метрика PSNR, кадр 36

Красный график отражает переданный видеопоток с использованием протокола QUIC, а синий график – с использованием протокола UDP.

Выводы

Результаты проведенного исследования показывают, что протокол QUIC обладает существенными преимуществами по сравнению с TCP и TCP+TLS, обеспечивая значительно более высокую скорость передачи данных. Экспериментальные измерения продемонстрировали, что использование QUIC сокращает время передачи данных примерно в 10 раз благодаря оптимизированной архитектуре, включающей сокращенное время установки соединения и эффективные механизмы управления потоками.

Сравнение с UDP показало, что QUIC обеспечивает более стабильную передачу видеопотока. Количество пакетов, необходимых для передачи видео в QUIC, в 5 раз меньше, чем в UDP, что снижает нагрузку на сеть и уменьшает вероятность перегрузки буферов маршрутизатора. Кроме того, временные затраты на передачу данных в QUIC ниже, чем в UDP, что свидетельствует о большей скорости передачи и более рациональном использовании сетевых ресурсов.

Одним из ключевых отличий является качество передаваемого видеосигнала. В то время как UDP подвержен значительным потерям пакетов, приводящим к заметным артефактам изображения, включая искажения до половины экрана, использование QUIC обеспечивает целостность видеопотока и предотвращает визуальные дефекты. Таким образом, в сценариях, где критически важны надежность и стабильность передачи данных, а также скорость доставки, применение QUIC является наиболее верным решением, существенно превосходящим UDP по качеству и производительности.