В это время в прошлом году отечественная сетевая среда начала популяризировать и развертывать HTTP / 2. Через год популярность HTTP / 2 значительно возросла, а широта и скорость популяризации основных производителей CDN были на переднем крае. отрасли. Даже многие производители CDN внедрили QUIC в прямые трансляции и некоторые сценарии HTTP.
в корявом эссеО чем мы говорим, когда говорим о блокировке заголовка строки HTTP? 》В разделе мы упомянули, что HTTP/2 поверх QUIC в настоящее время является единственной реализацией HTTP, которая решает проблему блокировки заголовка строки на транспортном уровне. В то время как HTTP/2 через TCP, так и HTTP/2 через QUIC (UDP) считались HTTP/2, но протокол, используемый транспортным уровнем, был другим. Это немного двусмысленное название стало историей в ноябре 2018 года:
В обсуждении списка рассылки 28 октября 2018 года, целевой группе по эксплуатации Internet Engineering (IETF) HTTP и Quic Reading Group (IETF) Mark and Quic Project для переименования HTTP-Over-Quic на http / 3 - «четко определено как другое привязку для HTTP Semantics ... чтобы люди понять, что он отличается от квиала «и, после доработки и публикации проекта, наследует рабочую группу QUIC в рабочую группу HTTP. В следующие дни обсуждений предложение Марк Ноттингема было принято членами IETF, которые дали официальное одобрение в ноябре 2018 года за HTTP-Over-Quic, чтобы стать http / 3.
Хотя похоже, что предыдущий HTTP/2 по сравнению с QUIC изменил свое название (насколько я понимаю, может быть более подходящим назвать его HTTP/2.1), но за ним стоит отношение и направление IETF для будущего стандарта HTTP Возможно, через несколько лет введение этого имени прояснит его значение.
Различия между HTTP/3 и HTTP/2 по сравнению с QUIC
QUIC станет универсальным безопасным протоколом транспортного уровня.
На данном этапе QUIC, реализованный Google, несовместим с QUIC, реализованным IETF. Google-версия QUIC может использоваться только с HTTP/2 и имеет некоторые сильные привязки к HTTP/2 на уровне протокола. Например, фрейм QUIC сопоставляет фрейм HTTP/2. Из-за этого многие крупные производители не следят за QUIC, так что HTTP/2 поверх QUIC можно широко использовать только в собственном Chrome, Gmail и другом программном обеспечении Google, которое когда-то вызывало промышленность "только Google делает" иллюзию.
После включения в IETF становится ясно, что Google не может так играть. QUIC позиционируется как протокол безопасного транспортного уровня общего назначения:
Можно приблизительно предположить, что QUIC через UDP станет следующим поколением (или заменой) TLS через TCP, то есть QUIC сможет применяться к любому протоколу прикладного уровня, но на текущем этапе приоритет будет отдаваться приложению и проверке в HTTP. .
Унифицированное использование TLS 1.3 в качестве протокола безопасности
В 2018 году окончательно утвердились несколько важных WEB-стандартов, один из которыхRFC 8446 TLS 1.3, Этот стандарт имеет большое значение для сокращения задержек и улучшения взаимодействия с пользователем, особенно на стороне мобильных устройств. в корявом эссе«Как TLS1.3/QUIC достигает 0-RTT», мы упомянули Хотя и TLS 1.3, и QUIC могут достигать 0-RTT для уменьшения задержки, QUIC самостоятельно реализует набор протоколов безопасности. Главным образом потому, что в то время еще не был выпущен стандарт TLS 1.3, а QUIC требовался набор протоколов безопасности:
The QUIC crypto protocol is the part of QUIC that provides transport security to a connection. The QUIC crypto protocol is destined to die. It will be replaced by TLS 1.3 in the future, but QUIC needed a crypto protocol before TLS 1.3 was even started.
Сегодня был опубликован стандарт TLS 1.3, и HTTP/3 также был включен в IETF, поэтому QUIC логически использует TLS 1.3 в качестве своего протокола безопасности. Google никогда не был вором цыплят и чернил в этих аспектах, как это.
Используйте сжатие заголовков QHPACK вместо HPACK
фактически,QPACKОчень похожий на дизайн HPACK, предлагаемый QPACK в основном предназначен для лучшей адаптации к QUIC, а также является необходимым шагом для Google, чтобы извлечь QUIC из соединения с HTTP/2 и завершить унификацию со стандартом IETF.
Проблемы и проблемы HTTP/3
Проблемы с UDP-подключением
Практически все операторы связи «дискриминируют» UDP-пакеты, и несложно понять, почему все-таки несколько громких DDoS-атак в истории были основаны на UDP. В некоторых районах широкополосный доступ определенного города в Китае прямо запрещает пакеты данных UDP портов, отличных от 53, в то время как другие операторы и IDC строго ограничивают поток UDP, даже если они не запрещают UDP. Этот момент не оптимистичен, но мы считаем, что с популяризацией и продвижением стандарта операторы постепенно изменят свою стратегию дискриминации UDP-трафика. Ситуация за границей будет несколько лучше: по данным Google, доля развернутых ими QUIC снижена менее чем на 10%.
QUIC не поддерживает передачу открытого текста
Для пользователей это преимущество, а не проблема. Это препятствие, которое нельзя игнорировать в среде цензуры внутреннего контента. Но QUIC все-таки будет основан на протоколе TLS, а HTTPS можно популяризировать в Китае, и популярность QUIC может быть более оптимистичной.
UDP потребляет много ресурсов
На текущем этапе UDP потребляет много ресурсов ЦП, а скорость обработки низкая. Это неоспоримый факт, но я считаю, что с увеличением количества приложений UDP оптимизация ядра и оборудования будет продолжаться до тех пор, пока не достигнет или не превысит производительность TCP. А поскольку QUIC реализован на уровне приложения, скорость итерации выше, сложность и стоимость развертывания и обновления меньше, а проблема жесткости протокола, такая как TCP, может быть в определенной степени смягчена.
Узнайте больше о HTTP/3
Для всестороннего понимания HTTP/3 я рекомендую Даниэля Стенберга (автора CURL)HTTP/3 explained, Если вы не хотите читать по-английски, вы можете читатьYi BaiСтуденты перевели китайскую версиюПодробный HTTP/3.
-ЕОФ-
Уведомление об авторских правахПожалуйста, укажите источник,Оригинальная ссылка на эту статью