Почему HTTP/3 основан на UDP, надежен ли он?

⚠️Эта статья является первой подписанной статьей сообщества Nuggets, и её перепечатка без разрешения запрещена.

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

Однако так ли это на самом деле? Давайте закроем наши удивленные рты и посмотрим, почему HTTP/3 может быть основан на UDP, и это очень разумный выбор.

Чтобы понять этот выбор, мы сначала должны устранитьUDPнедоразумение.

1. UDP — самый чистый протокол транспортного уровня

На самом деле UDP не так уж ненадежен, как все думают, это только из-за его простоты у вас сложилось такое восприятие. С другой точки зрения,Этофактическисамый чистыйтранспортный уровеньпротокол.

Так где же именно UDP в сетевой передаче? Нам нужно кратко рассмотреть типичную структуру сети.

Физический уровень и уровень соединения

• Физический уровень находится в нижней части сети.Обрабатываемые им сообщения состоят из 1 и 0. Это аппаратный уровень, обеспечивающий нормальную передачу нашей информации.
• Уровень соединения предварительно объединяет эти 1 и 0 для формирования информационного фрейма фиксированной длины (кадра), каждый информационный фрейм содержитSRCиDST(вот MAC-адрес), что позволяет нашим двум машинам взаимодействовать в одноранговой сети.

В настоящее время пакеты сетевых данных не могут покинуть локальную сеть.Если вы хотите передавать в большем масштабе, вам нужна помощь сетевого уровня.

Сетевой уровень

Чтобы сделать эти адреса значимыми,网络层присоединилсяIP协议, найти целевую машину по IP-адресу и, наконец, через преобразование маршрутизатора, уровень подключения отвечает за передачу конкретной информации. Например, я захватил следующий пакет wireshark.

• EthernetIIЭто то, что мы называем Ethernet уровня соединения, а передаваемая информация — это Frame.
• Ниже приведен протокол IPv4, указывающий, что это IP-пакет.

Если вы посмотрите на IP-пакет, то обнаружите, что его формат очень странный: когда промежуточный узел выполняет маршрутизацию, ему необходимо пройти процесс сначала распаковки, а затем переупаковки. Это связано с тем, что протокол IP является протоколом сетевого уровня, а информация его заголовка, такая как IP-адрес, фактически является полезной нагрузкой протокола уровня соединения.

Когда дело доходит до протокола IP, мы очень близки к UDP.

транспортный уровень

Протокол IP решает только проблему связи между компьютерами, но на каждой из наших машин будут разные процессы, как их отличить? Это传输层согласие делать.

Протоколы UDP и TCP идентифицируют процесс, добавляя номер порта. IP-адрес плюс номер порта — это сокет, с которым нам нужно столкнуться при написании кода. Большинство современных сетевых коммуникаций, включая HTTP/1, HTTP/2 и т. д., основаны на TCP.

С точки зрения протокола, UDP на самом деле является самым чистым протоколом, он полностью раскрывает все содержимое протокола IP. По сравнению с протоколом IP он имеет только один номер порта больше, поэтому протокол UDP обладает всеми характеристиками протокола IP. Такие, как беспорядок, не гарантируют надежность (Best Effort). Что касается более продвинутого управления согласованием трафика, такого как механизм перегрузки, UDP вообще не заботится об этом.

UDP, у которого нет функций, значительно сужает область применения по сравнению с TCP. мы обычно ставим**TCP/IP**Протокол вводится целиком, так что игнорируется самый примитивный и чистый протокол UDP.

Давайте взглянем на типичный протокол UDP. Как показано на рисунке выше, по сравнению с IP-протоколом, UDP-протокол имеет всего на два порта больше, на одну длину и на одну контрольную сумму, что действительно является беспрецедентной чистотой.

2. TCP слишком сложен в качестве базового протокола

Вы можете спросить, и TCP, и UDP являются протоколами транспортного уровня, так почему же HTTP/3 не основан на TCP? Это потому, что TCP сам по себе уже очень сложен и имеет слишком много исторического багажа.

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

Мы часто говорим, что трехстороннее рукопожатие (четыре раза, объединенные в три раза) и четыре взмаха рук являются комбинацией логической комбинации Флагов и порядкового номера. Если добавлен протокол безопасности TLS, этот процесс рукопожатия будет длиннее.

После установления соединения эффективность TCP на самом деле не очень высока из-за режима подтверждения ACK на один вопрос и один ответ. Ему приходится передавать много бесполезной информации и ждать.

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

Мы можем взглянуть на подробную схему протокола TCP в Википедии, которая очень подробно описана в «Подробное объяснение TCP/IP, том 1: Протокол». Видно, что деталей еще много.

Так что же такое соглашение? Соглашение должно предусматривать стандарты, которые все соблюдают, и все соглашения являются результатом взаимного согласия общности интересов. Например, если моя распределенная база данных использует протокол уровня доступа MySQL, она должна соответствовать ряду стандартов, сформулированных протоколом MySQL, иначе она не будет работать.

**Чем ниже протокол, тем выше требования к стабильности. **Протокол TCP был закодирован в операционной системе. Будь то обновление протокола или исправление ошибок, все это нервирует.

3. Почему работает UDP?

Чтобы сбросить с себя бремя истории,HTTP/3выбранныйUDP, в основном для решения проблемы блокировки головы. Его базовый протокол известенQUIC, протокол, работающий на транспортном уровне (или, так сказать, прикладном уровне). иTCPРазница в том, что код QUIC не жестко запрограммирован в ядре операционной системы, а полностью работает в пользовательском пространстве с интегрированным TLS по умолчанию.

Как показано выше, HTTP/3 основан на QUIC, а QUIC полностью основан на UDP.

Но разве UDP не называется без установления соединения? Как он достигает некоторых дополнительных функций, таких как надежность?

фактически,连接Это слово является виртуальным понятием, и такой линии вообще нет в сети.连接Просто для облегчения вашего логического понимания. Учитывая, что ваш текущий клиент-сервер — это клиент, а сервер — это сервер. Тогда взаимодействие пакетов между клиентом и сервером может иметь следующий маршрут.

Когда нет взаимодействия данных, сервер и клиент — это просто две точки. Даже если вы отсоедините сетевой кабель и снова подключите его (без взаимодействия в течение этого периода), они могут продолжать отправлять данные друг другу.

Так называемый UDP без установления соединения фактически ничем не отличается от TCP-соединения. Единственная разница в том, что после того, как UDP отправляет пакет данных, ему все равно, другой конец может получить или не получить информацию. И когда отправленные данные каждый раз подтверждаются ACK, они становятся TCP.

Что касается этой части кода подтверждения, то не имеет значения, находится ли он на транспортном уровне или на прикладном уровне, но имеет значение, размещен ли код в операционной системе или в пакете, который можно обновить самостоятельно. много.

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

Эти различия, давайте сравним различные версии HTTP, и мы будем знать производительность передачи данных.

1. В более ранней реализации HTTP 1.0, если с сервера необходимо получить большое количество ресурсов, для параллельного получения информации будет открыто N коротких TCP-ссылок. Однако из-за трехстороннего рукопожатия и четырехстороннего механизма TCP, когда количество соединений увеличивается, общая стоимость становится относительно большой.
2. В HTTP/1.1 эта ситуация улучшается за счет мультиплексирования длинных соединений, но проблема заключается в том, что из-за механизма подтверждения сообщений TCP и механизма последовательности, а также стратегии управления потоком получение ресурсов должно ставиться в очередь для использования. Запрос должен дождаться передачи другого запроса, прежде чем он сможет начаться.
3. HTTP/2 использует мультиплексирование, и несколько ресурсов могут совместно использовать соединение. Но это решает только мультиплексирование прикладного уровня, который по-прежнему заблокирован при передаче TCP, и последние ресурсы должны дождаться завершения предыдущей передачи, прежде чем продолжить. Это队头阻塞现象(Head-of-line blocking)
4. QUIC абстрагирует понятие потока (stream), несколько потоков могут повторно использовать соединение, тогда концепции скользящих окон работают не на соединение, а на поток. Передача этих пакетов может выполняться одновременно из-за характера успеха или неудачи UDP только для отправки. Серверная часть протокола будет анализировать и кэшировать эти пакеты данных, собирать и систематизировать их. Из-за абстракции концепции потока сбой передачи определенного пакета повлияет только на точность потока, а не на точность всего соединения.

End

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

1. QUIC может реализовать все функциональные требования протокола TCP и интегрировать TLS, превосходя TCP по функциям.
2. Одно соединение, несколько потоков передаются одновременно, истинное мультиплексирование, эффективно устраняющее явление блокировки заголовка строки и превосходящее TCP по производительности.
3. Уменьшите количество рукопожатий, особенно при передаче TSL, и уменьшите задержку рукопожатия.
4. Поскольку его легко обновить, он предоставляет огромное пространство для воображения для обновления и развития протокола.

Причина использования QUIC в основном связана с ограничениями TCP. Соединения являются бесценным ресурсом, и создание, уничтожение и передача по ним требуют много времени. Механизм надежности TCP действительно был очень эффективным на заре развития компьютерных сетей, но с обновлением аппаратного обеспечения его режим передачи ACK ограничивал развитие более высокой производительности с точки зрения эффективности. Поскольку концепция стандарта TCP так глубоко укоренилась, его код существует даже непосредственно в ядре, что затрудняет обновление протокола.

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

Почему это возможно? Или, благодаря чистым свойствам UDP, это всего лишь программный интерфейс протокола IP, на самом деле это чистый лист бумаги и ничего. Если вы хотите, вы можете даже полностью воспроизвести все функции TCP на основе UDP, если вы можете сопоставить серверную и клиентскую части. Это то, что делает QUIC.

⚠️Эта статья является первой подписанной статьей сообщества Nuggets, и её перепечатка без разрешения запрещена.