Вопрос или проблема
QUIC заявляет, что использует UDP вместо TCP по причинам производительности загрузки страниц.
Зная, что в UDP нет встроенной функциональности “ACK”, я предполагаю, что они реализуют таймауты при ожидании пакетов, поскольку можно упустить пакеты UDP, не замечая этого. Как реализация таймаутов может быть быстрее, чем использование TCP?
QUIC не “использует UDP” вместо TCP – это часто повторяется, но является слишком буквальным толкованием ‘оси’ многослойной модели.
Точнее было бы сказать, что QUIC сам является заменой TCP, так как он реализует все необходимые функции транспортного протокола – ACK и ретрансляцию, управление потоком, управление перегрузкой и т.д., тогда как уровень UDP служит лишь для мультиплексирования портов и фактически не занимает слот “транспортного протокола”.
(Для большинства целей вы можете рассматривать “X через UDP” так же, как “X через необработанный IP”, поскольку оба предоставляют точно такой же ‘необработанный датаграммный’ сервис, на котором может быть реализован надежный транспорт; на самом деле SCTP является транспортным протоколом, который обычно используется как через UDP, так и через необработанный IP.
Поэтому, если TCP может реализовать ACK на основе IP, в котором их нет, то QUIC или μTP или RTP могут так же хорошо реализовать ACK поверх UDP, в котором их нет.)
В первом приближении вы можете думать о QUIC как о “TCP (и HTTP), реализованном поверх UDP”.
Это позволяет приложениям использовать свою собственную реализацию “TCP”, вместо того чтобы быть вынужденными работать с той реализацией TCP, которую предоставляет хостовая ОС.
Именно поэтому Google разработал QUIC; чтобы приложения Google, такие как Chrome, Google Maps, YouTube и другие, могли иметь надежную реализацию своего “HTTP” транспорта под контролем Google, вместо того чтобы иметь дело с различными наборами функций и различными ошибками в разных стэках TCP в Windows, macOS, iOS, различных дистрибутивах Linux и т.д.
Это также позволяет приложениям Google и другим приложениям, использующим QUIC, использовать модернизации, которые могут еще не быть доступны в стеке TCP каждой ОС. Так, например, вы можете выполнять операции с низкой задержкой 0-RTT с QUIC, которые нельзя выполнить в TCP-стэках, которые пока не поддерживают TCP Fast Open (TFO). Или вы можете использовать более подходящий алгоритм управления перегрузкой, чем тот, который поддерживает стек TCP хостовой ОС. Или, возможно, вы можете поддерживать многопутевые потоки, даже если стек TCP вашей хостовой ОС пока не поддерживает Multipath TCP (MPTCP).
Таким образом, QUIC не обязательно быстрее, чем правильный современный стек TCP; это в основном одно и то же, просто реализованное в коде, который является частью приложения, так что разработчик приложения не привязан к использованию кодов TCP, предоставляемых сетевым стеком ОС.
Ответ или решение
QUIC (Quick UDP Internet Connections) и HTTP/3 действительно используют протокол UDP, чтобы обеспечить более высокую производительность загрузки страниц по нескольким ключевым причинам. Хотя UDP сам по себе не предоставляет механизмы подтверждения (ACK), которые реализованы в TCP, QUIC на самом деле интегрирует все необходимые функции, чтобы обеспечить надежность и управление потоком при использовании UDP.
Как QUIC/HTTP/3 может быть быстрее с использованием UDP?
-
Минимизация задержки: Одним из основных преимуществ использования UDP в QUIC является возможность уменьшения задержки при установлении соединения. В отличие от TCP, который требует трехкратного рукопожатия для установления соединения перед началом передачи данных, QUIC может начать обмен данными уже с одним раундом обмена (1-RTT) или даже с нулевым раундом (0-RTT) в некоторых случаях. Это значительно сокращает время, необходимое для начала передачи данных.
-
Управление потерей пакетов: QUIC реализует собственные механизмы обнаружения потерь и повторной передачи пакетов. Хотя UDP сам по себе не гарантирует доставку пакетов, QUIC использует механизмы временных ограничений и повторной передачи на уровне приложения для повышения надежности. Такой подход позволяет QUIC более эффективно обрабатывать потерю пакетов и устранить задержки, связанные с ожиданием подтверждений, как это происходит в TCP.
-
Адаптивный контроль перегрузки: QUIC является более современным подходом к контролю перегрузки, позволяя использовать более прогрессивные алгоритмы, чем многие традиционные TCP-реализации. Это улучшает общую производительность по сравнению с TCP, который может быть ограничен устаревшими алгоритмами в зависимости от реализации в операционной системе.
-
Параллельная передача потоков: QUIC поддерживает мультиплексирование, что позволяет отправлять несколько потоков данных одновременно по одному соединению. В TCP такое параллельное управление потоками может вызвать блокировку (head-of-line blocking), что может привести к увеличению задержек. QUIC, в свою очередь, умеет обрабатывать потери и производительность отдельных потоков независимо друг от друга, что улучшает общую эффективность.
-
Контроль над реализацией: QUIC предоставляет разработчикам больший контроль над реализацией транспортного протокола, что позволяет им включать функции и улучшения, которые могут не поддерживаться на уровне ОС. Это означает, что приложения могут использовать новейшие подходы к оптимизации производительности, даже если их операционная система не поддерживает последние обновления TCP.
Таким образом, хотя QUIC функционирует над UDP и не наследует автоматическую надежность TCP, он воспроизводит необходимые механизмы надежной передачи данных и управления потоками, интегрируя их в более современном и адаптивном подходе. Это позволяет QUIC/HTTP/3 потенциально обеспечивать более высокую скорость и производительность по сравнению с традиционными реализациями TCP.
В результате, QUIC стал предпочтительным выбором для многих современных приложений и сервисов, стремящихся к улучшению пользовательского опыта за счет более быстрого заряда страниц и лучшего управления сетью.