QUIC (Quick UDP Internet Connections) — это протокол транспортного уровня на основе UDP, предназначенный для решения проблем производительности TCP в средах с высокой задержкой и потерей пакетов. HTTP/3 — это последняя версия протокола HTTP. Он основан на протоколе QUIC, а не на TCP, и обеспечивает более эффективные и надежные сетевые услуги.
С развитием Интернета существующие сетевые протоколы (такие как TCP и HTTP/2) больше не могут соответствовать требованиям производительности и надежности в некоторых сценариях. QUIC и HTTP/3 призваны решить эти проблемы и предоставить более эффективные и надежные сетевые услуги для современного Интернета.
QUIC был впервые предложен и разработан Google для решения проблем производительности TCP в средах с высокой задержкой и потерей пакетов. С тех пор, как QUIC был впервые раскрыт Google в 2012 году, протокол претерпел множество итераций и оптимизаций и постепенно стал проектом стандарта Internet Engineering Task Force (IETF).
Ключевые цели разработки QUIC включают: сокращение задержки при установлении соединения, повышение эффективности контроля перегрузки и управления потоками, поддержку мультиплексирования и миграции соединений, а также встроенные средства шифрования и безопасности.
QUIC обеспечивает более быстрое установление соединения, лучший контроль перегрузки и более эффективное восстановление ошибок, чем TCP. По сравнению с UDP, QUIC обеспечивает более высокую надежность и безопасность, а также более совершенные механизмы контроля перегрузки и управления потоками.
Реализация квитирования 0-RTT в QUIC в первую очередь опирается на предыдущие взаимодействия между клиентом и сервером. При первом установлении соединения клиент и сервер обмениваются параметрами шифрования и устанавливают общий ключ. Когда клиент снова устанавливает соединение с сервером, он может выполнить рукопожатие 0-RTT, используя предыдущие параметры шифрования. Это означает, что клиент может начать отправку зашифрованных данных сразу во время рукопожатия, не дожидаясь подтверждения от сервера. Этот механизм значительно снижает задержку установления соединения, особенно в сетевых средах с высокой задержкой.
Механизмы управления потоком и контроля перегрузки QUIC аналогичны TCP, но с некоторыми оптимизациями. QUIC использует механизм скользящего окна для управления потоком, чтобы гарантировать, что буфер получателя не переполнится. В то же время алгоритмы управления перегрузкой QUIC (такие как BBR и CUBIC) могут лучше адаптироваться к различным условиям сети и сценариям приложений, эффективно балансируя скорость передачи и перегрузку сети.
QUIC реализует множество алгоритмов контроля перегрузки, включая BBR (Bottleneck Bandwidth и RTT) от Google и традиционный CUBIC.
QUIC позволяет использовать различные алгоритмы контроля перегрузки, что обеспечивает гибкость для различных сетевых сред и сценариев приложений. Эта гибкость является существенным преимуществом QUIC по сравнению с TCP, поскольку алгоритм управления перегрузкой TCP обычно реализуется и определяется операционной системой, в то время как QUIC позволяет прикладному уровню выбирать наиболее подходящий алгоритм по мере необходимости.
Мы можем создать диаграмму последовательности, чтобы продемонстрировать механизмы управления потоками и контроля перегрузки QUIC:
QUIC использует абстракцию, называемую «поток», для поддержки мультиплексирования. При соединении QUIC данные делятся на несколько независимых потоков, каждый из которых имеет свой идентификатор потока и статус передачи. Это позволяет передавать несколько независимых потоков данных параллельно по одному и тому же соединению, тем самым уменьшая накладные расходы на установление и закрытие соединения, а также улучшая использование сетевых ресурсов. По сравнению с мультиплексированием HTTP/2, мультиплексирование QUIC не подвержено проблеме «блокировки начала строки», что еще больше повышает производительность передачи.
QUIC поддерживает миграцию подключений, которая сохраняет постоянство соединения при изменении сетевых адресов или устройств. В первую очередь это достигается за счет использования идентификатора соединения, который представляет собой значение, однозначно идентифицирующее соединение QUIC. Когда сетевой адрес клиента меняется, он может продолжать взаимодействовать, используя тот же идентификатор подключения, что обеспечивает плавную миграцию. Кроме того, QUIC использует UDP в качестве протокола транспортного уровня, который обладает сильными возможностями проникновения NAT и может лучше справляться со сложными сетевыми средами.
Безопасность QUIC обеспечивается встроенными механизмами шифрования и безопасности TLS 1.3. В процессе установления соединения QUIC клиент и сервер обмениваются параметрами шифрования и устанавливают общий ключ. Все передаваемые данные шифруются с использованием этого ключа, обеспечивая сквозную защиту данных и проверку целостности. Этот встроенный механизм шифрования не только повышает безопасность QUIC, но также упрощает реализацию безопасности протоколов прикладного уровня, таких как HTTP/3.
TLS 1.3, основа шифрования QUIC, содержит несколько ключевых улучшений, особенно с точки зрения безопасности и производительности. Во-первых, TLS 1.3 упрощает процесс установления связи и уменьшает количество циклов передачи данных (RTT). В TLS 1.2 для завершения рукопожатия требуются два RTT, тогда как в TLS 1.3 требуется только один RTT, а в некоторых случаях можно даже достичь 0-RTT. Функция 0-RTT позволяет клиентам отправлять зашифрованные данные сразу во время рукопожатия, что очень полезно для уменьшения задержки, особенно при установлении нового сеанса.
Кроме того, TLS 1.3 удаляет некоторые небезопасные алгоритмы шифрования и повышает общую безопасность. Он поддерживает только те наборы шифров, которые считаются безопасными, тем самым уменьшая потенциальные уязвимости безопасности. Эти улучшения делают TLS 1.3 не только более быстрым, но и более безопасным, обеспечивая QUIC прочную основу безопасности.
HTTP/3 является преемником HTTP/2 и призван решить некоторые фундаментальные проблемы HTTP/2 с точки зрения производительности и надежности передачи. HTTP/3 использует протокол QUIC в качестве основного транспорта для обеспечения более эффективных и надежных сетевых услуг.
HTTP/2 представил концепцию мультиплексирования, позволяющую передавать несколько запросов и ответов параллельно по одному соединению. Однако мультиплексирование HTTP/2 построено поверх TCP, а это означает, что на него по-прежнему влияет проблема блокировки заголовка TCP (HOLB). Даже если пакет в одном потоке HTTP/2 потерян, все потоки во всем TCP-соединении должны ждать успешной повторной передачи пакета.
HTTP/3 решает эту проблему с помощью QUIC. Поскольку QUIC основан на UDP, каждый поток передается независимо, и потеря пакетов в одном потоке не повлияет на другие потоки. Это улучшение значительно повышает производительность в средах с потерей пакетов и снижает задержку.
Цели разработки HTTP/3 включают сокращение задержки при установлении соединения, повышение производительности передачи, поддержку мультиплексирования и передачи данных через сервер, а также повышение сетевой безопасности.
HTTP/3 основан на протоколе QUIC и использует такие функции QUIC, как быстрое установление соединения, эффективный контроль перегрузки, мультиплексирование, миграция соединений и встроенное шифрование, чтобы обеспечить более эффективные и надежные сетевые услуги.
Ниже приведена базовая диаграмма-русалка, показывающая рабочий процесс мультиплексирования запросов и ответов HTTP/3, планирования приоритетов и ресурсов, отправки на сервер и сжатия заголовка QPACK.
Таким образом, HTTP/3 обеспечивает более эффективную работу сети, чем HTTP/2, особенно в сетевых средах с высокой задержкой.
Для динамических и интерактивных приложений, таких как онлайн-игры и общение в реальном времени, улучшения, предоставляемые HTTP/3, могут значительно улучшить взаимодействие с пользователем. В этих приложениях задержка в сети и потеря пакетов являются распространенными проблемами, а проблема блокировки заголовка HTTP/2 может привести к медленному реагированию всего приложения. Устраняя эту блокировку начала строки, HTTP/3 гарантирует, что даже если некоторые потоки данных сталкиваются с проблемами, другие потоки данных могут продолжать беспрепятственно передаваться, обеспечивая бесперебойную работу и отзывчивость приложений.
Кроме того, функция 0-RTT HTTP/3 дополнительно сокращает время установления соединения, что особенно полезно для приложений, которым требуется частое установление новых соединений (таких как мобильные приложения и службы коротких сеансов). Это приводит к ускорению загрузки, что является важным улучшением для пользователей, особенно в средах мобильных сетей, где условия сети могут часто меняться.
В сетях доставки контента (CDN) и крупномасштабных распределенных системах преимущества HTTP/3 также весьма очевидны. Этим системам часто необходимо эффективно обрабатывать большое количество одновременных соединений и потоков данных. Функции мультиплексирования и миграции соединений HTTP/3 делают поддержание и оптимизацию этих соединений более эффективными, одновременно уменьшая прерывания соединения, вызванные изменениями в сети, и улучшая общую стабильность и надежность системы.
Короче говоря, технические улучшения HTTP/3 по сравнению с HTTP/2 не только решают некоторые фундаментальные проблемы передачи данных по сети, но также обеспечивают более высокую производительность и лучший пользовательский опыт для различных сетевых приложений. По мере дальнейшей популяризации и оптимизации HTTP/3 ожидается, что он будет играть более важную роль в будущих сетевых коммуникациях.
В настоящее время большинство основных браузеров и серверов уже поддерживают QUIC и HTTP/3, включая Chrome, Firefox, Safari и такие серверы, как Nginx и LiteSpeed.
Хотя QUIC и HTTP/3 уже широко поддерживаются, их популярность в Интернете все еще невысока по разным причинам, таким как проблемы совместимости с сетевыми устройствами, ограничения сетевой политики и т. д.
Развертывание QUIC и HTTP/3 сталкивается с некоторыми проблемами, включая проблемы совместимости сетевых устройств, ограничения сетевой политики, сложность протокола и т. д. Кроме того, поскольку конструкции QUIC и HTTP/3 относительно новы, некоторым сетевым операторам и поставщикам услуг может потребоваться время для адаптации к этим новым технологиям.
характеристика | HTTP/2 | HTTP/3 | QUIC |
---|---|---|---|
тип протокола | Прикладной уровень | Прикладной уровень | транспортный уровень |
базовый транспортный протокол | TCP | QUIC | UDP |
Соединение установлено | Требуется одно или два времени прохождения туда и обратно (RTT) | рукопожатие 0-RTT | рукопожатие 0-RTT |
Управление потоком и контроль перегрузки | Зависит от TCP | Зависит от QUIC | TCP-независимый механизм |
Мультиплексирование | Поддерживается, но могут возникнуть проблемы с блокировкой заголовка. | Поддержка, нет проблем с блокировкой заголовка | Поддержка, нет проблем с блокировкой заголовка |
push-уведомление сервера | поддерживать | поддерживать | Не прямойподдерживать,По протоколу верхнего уровня (например, HTTP/3) передача |
Миграция подключения | Нетподдерживать | поддерживать | поддерживать |
Проникновение NAT | Зависит от TCP, возможно, проблема | Зависит от QUIC, имеет сильные возможности | полагаться UDP с большими возможностями |
Встроенное шифрование | Нетподдерживать,Обычно требует сотрудничества TLS использовать | поддерживать,на основе TLS 1.3 | поддерживать,на основе TLS 1.3 |
Производительность и надежность трансмиссии | В некоторых сценариях могут возникнуть проблемы | проходитьиспользовать QUIC решено HTTP/2 некоторые вопросы | Целью разработки является решение проблем производительности TCP в средах с высокой задержкой и потерей пакетов. |
По мере развития технологий и изменения сетевой среды мы ожидаем, что QUIC и HTTP/3 будут более широко использоваться и развиваться. Направления дальнейшего развития и улучшения могут включать:
Короче говоря, QUIC и HTTP/3, являющиеся ключевыми технологиями современного Интернета, значительно улучшили производительность и надежность сети. Хотя их нынешняя популярность в Интернете все еще невысока, с развитием технологий и продвижением приложений у нас есть основания полагать, что QUIC и HTTP/3 будут играть более важную роль в будущем Интернете.