HTTP/3 и его влияние

Question

Недавно Chrome, Firefox, cURL и др. Объявили о своей поддержке HTTP/3 (ранее это называлось HTTP-over-QUIC).

Каким вы видите его адаптационное воздействие с точки зрения изменений в -

1) Приложения (веб-сайты, мобильные устройства, только сокеты и т. Д.)

2) Инфраструктура хостинга (веб-серверы / серверы приложений, межсетевые экраны, балансировщики нагрузки, CDN, маршрутизаторы, коммутаторы и т. Д.) И провайдеры и т. Д.

3) Безопасность (новые угрозы, уязвимости, инструменты VAPT и т. Д.)

4) Контроль перегрузки

Answer 1

Очень субъективный вопрос, поэтому я не уверен, что он подходит здесь, но вот мои два цента:

1. Не должно иметь никакого отношения к тому, что делает HTTP/2. Он закрывает один крайний случай из этого (потерянные пакеты могут сделать HTTP/2 медленнее на HTTP/2, чем HTTP/1.1), а также потенциально приносит некоторые улучшения производительности при начальной настройке соединения. Если вы еще не переходили на HTTP/2 или не оптимизировали для него, возможно, вы захотите рассмотреть это в процессе подготовки. Приоритеты также должны быть переосмыслены в HTTP/3, но пока не решено, как это сделать. В конце концов, это изменение транспортного уровня, и базовая семантика HTTP/2 не меняется, поэтому для приложений более высокого уровня это должно быть довольно плавным - например, HTTP/2 был в основном для пользователей HTTP / 1.1.

2. Он основан на UDP (с откатом к HTTP/2 и / или HTTP / 1.1 на основе TCP), который будет интересно включить и настроить! Также библиотеки TLS должны быть изменены для поддержки, поэтому может пройти некоторое время, прежде чем мы увидим это на некоторых серверах. CDN уже лидируют, и это будет самый простой способ добиться этого. Как и HTTP/2, вероятно, наиболее важно иметь его на вашем пограничном сервере, а затем перейти на HTTP/2 или даже HTTP / 1.1 для внутреннего трафика сверх этого. Кроме того, он более полно зашифрован, что затрудняет отслеживание и перенаправление трафика, поскольку для средних ящиков читается меньше информации, чем в TCP.

3. См. Ответ 2 выше, который затруднит отслеживание трафика. Кроме того, он очень новый (даже не полностью закончен и не утвержден на момент написания), поэтому могут быть ошибки реализации, такие как были для HTTP/2 (например), и некоторые продукты не будут поддерживать его изначально. С другой стороны, он доступен только через HTTPS, что хорошо для безопасности.

Answer 2

HTTP/3 построен на основе QUIC. Он имеет множество функций.

1. Встроенное обязательное шифрование. Шифрование является частью протокола QUIC, поэтому оно является обязательным. В HTTP/2 и TCP шифрование выполнялось с помощью TLS, который шифрует только данные прикладного уровня, поэтому имеет некоторую уязвимость безопасности, а также требует дополнительного двустороннего обмена. Но в QUIC данные транспортного уровня зашифрованы, и никакого дополнительного обхода не требуется.
2. Прекращается поддержка уязвимых алгоритмов шифрования: используется TLS 1.3, который прекращает поддержку уязвимых алгоритмов шифрования, используемых в TLS 1.2.
3. Нулевое время обратного пути для существующих соединений TLS: ключи TLS хранятся в кеше, поэтому после инициирования соединения TLS последующие соединения с этим сервером не требуют никакого обратного пути.
4. Устранение проблемы блокировки начала строки на транспортном уровне: это еще одна особенность QUIC.
5. Миграция соединения. То есть, когда соединение установлено, клиент может изменить свой адрес. Например, это происходит, когда пользователь переходит с Wi-Fi на сотовые данные и наоборот.