Почему HTTP/3 такой быстрый?

Программа перевода самородков Сетевой протокол
Почему HTTP/3 такой быстрый?

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

HTTP/3 здесь, и это очень важно для производительности в Интернете. Давайте посмотрим, насколько это может ускорить ваш сайт!

Подождите, разве HTTP/2 не плох? Разве это не было довольно популярно в последние годы? Это так, но в нем все еще естьпроблема. Чтобы решить эти проблемы,новая версияпротокол работает над «отслеживанием стандартов (одна из категорий RFC)».

Хм, а действительно ли HTTP/3 делает Интернет быстрее? Безусловно, может, и мы продемонстрируем это с помощью тестов.

предварительный просмотр

Прежде чем мы углубимся в детали, давайте быстро проведем предварительный просмотр результатов тестов. На приведенной ниже диаграмме мы запрашиваем один и тот же сайт в той же сети с использованием одного и того же браузера, единственная разница заключается в версии протокола HTTP. Каждый сайт неоднократно запрашивался 20 раз, а время ответа измерялось с помощью API производительности браузера. (Подробнее о бенчмаркинге ниже.)

Вы можете ясно видеть улучшения производительности с каждой новой версией протокола HTTP (по сравнению с HTTP/1.1):

Эти различия становятся более заметными, когда географические расстояния больше или сети менее надежны.

Прежде чем углубляться во все тонкости бенчмаркинга HTTP/3, нам нужно знать некоторые предпосылки.

Краткая история HTTP

HTTP (протокол передачи гипертекста 1.0)первая официальная версияЗавершено в 1996 году. Однако в этой версии есть некоторые практические проблемы, и некоторые стандарты необходимо обновить, поэтомуHTTP/1.1Он был выпущен годом позже (в 1997 году). Как говорит автор:

Однако HTTP/1.0 не учитывал должным образом многоуровневые прокси, кэширование, потребность в постоянных соединениях и влияние виртуальных хостов. Кроме того, количество приложений, которые позиционируют себя как «HTTP/1.0», но не полностью используют HTTP/1.0, резко выросло; поэтому нам нужна новая версия протокола, чтобы два взаимодействующих приложения могли подтвердить истинные коммуникационные возможности друг друга.

Спустя 18 лет была выпущена новая версия HTTP. В 2015 годуRFC 7540С большой помпой было объявлено, что HTTP/2 будет стандартизирован в качестве следующей основной версии протокола.

одно соединение, один файл

Если для веб-страницы требуется 10 файлов JavaScript, браузер должен получить все 10 файлов, чтобы завершить загрузку. Во времена HTTP/1.1 только один файл можно было загрузить за раз с TCP-соединением с сервером. Это означает, что файлы загружаются последовательно, и пока один файл задерживается, все последующие загрузки будут заблокированы. Это явление называетсяблокировка в начале очереди; это плохо для производительности страницы.

Чтобы решить эту проблему, браузеры могут открывать несколько соединений TCP для параллельного получения ресурсов. Однако это ресурсоемкий метод. Каждое новое TCP-соединение потребляет ресурсы на клиенте и сервере, а когда вы повторно вводите TLS, в процессе связи будет происходить много согласований SSL. Поэтому нам нужно лучшее решение.

Мультиплексирование в HTTP/2

Самой большой изюминкой HTTP/2 является егомультиплексированиемеханизм. HTTP/2 решенприкладной уровеньПроблема блокировки заголовка строки путем преобразования данных в бинарные (Примечание переводчика: а данные перед передачей разбиваются на кадры, передаются блоками кадров), что позволяет осуществлять мультиплексирование при загрузке нескольких файлов. То есть клиент может запрашивать все 10 файлов одновременно и загружать все 10 файлов параллельно по одному TCP-соединению.

К сожалению, в коммуникационном процессе HTTP/2 по-прежнему существует проблема блокировки заголовка строки, а источник оказывается на следующем уровне — наиболее уязвимым звеном в цепочке передачи становится TCP. Любой поток данных с потерей пакетов должен ждать пакетПередайте повторно, прежде чем продолжить.

Однако из-за параллельного характера мультиплексирования HTTP/2, который невидим для механизма восстановления потерянных пакетов TCP, потерянный или неупорядоченный пакет может остановить все активные транзакции, независимо от того, затронуты ли они непосредственно потерей пакета или нет.

Фактически, в среде с высокой потерей пакетов HTTP/1.1 работает лучше именно потому, что HTTP/2 открывает слишком много параллельных TCP-соединений!

Истинное мультиплексирование в QUIC и HTTP/3

Теперь о HTTP/3. Основное различие между HTTP/2 и HTTP/3 заключается в используемом транспортном протоколе. В отличие от предыдущего протокола TCP, HTTP/3 использует совершенно новый протокол —QUIC. QUIC — это транспортный протокол общего назначения, который решает проблему блокировки очереди, вызванную HTTP/2 из-за TCP. Этот протокол позволяет создавать через UDPПоследовательность потоков с отслеживанием состояния(Это очень похоже на TCP).

Транспортный протокол QUIC включает в себя мультиплексирование потоков и управление потоком для каждого потока, аналогичные реализованным в HTTP/2. Обеспечивая надежность на уровне потока и контроль перегрузки по всему соединению, по сравнению с отображением TCP,QUIC может еще больше повысить производительность HTTP.

Если вам все равно, как сработал тест, просто перейдите к результатам ниже!

Сравнительный анализ HTTP/3

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

HTML

Чтобы лучше соответствовать фактическому варианту использования, в этом тесте рассматривались три сценария: небольшой сайт, сайт с контентом (много изображений и несколько ресурсов JavaScript) и одностраничное приложение (много ресурсов JavaScript). Я посмотрел на несколько реальных сайтов и подсчитал среднее количество изображений и файлов JavaScript на сайт, а затем написал несколько демонстрационных сайтов, которые соответствовали количеству (и размеру) этих ресурсов.

  • маленький сайт
    • 10файлы JavaScript от 2 до 100 кБ;
    • 10Изображение размером от 1кБ до 50кБ;
    • общий объем загрузки600 kB, всего 20 блокирующих ресурсов.
  • содержательный сайт
    • 50файлы JavaScript размером от 2 КБ до 1 МБ;
    • 55образ размером от 1 кБ до 1 МБ;
    • общий объем загрузки10MB, всего 105 блокирующих ресурсов (загляните на cnn.com в инструменты разработчика и поймете, почему это количество такое большое).
  • одностраничное приложение
    • 85файлы JavaScript размером от 2 КБ до 1 МБ;
    • 30изображение размером от 1 кБ до 50 кБ;
    • общий объем загрузки15MB, всего 115 заблокированных ресурсов (посмотрите JIRA (система управления дефектами) в инструментах разработчика).

Сервер

CaddyКак сервер для этого теста, он предоставляет ресурсы и HTML для внешнего мира.

  • Все ответы используютCache-Control: "no-store"Чтобы браузер каждый раз перекачивал ресурс;
  • HTTP/1.1 и HTTP/2 используют TLS 1.2;
  • Использование HTTP/3TLS 1.3;
  • Все соединения HTTP/3 открыты0-RTT.

Географическое положение

Тесты проводились с моего компьютера в Миннесоте в трех отдельных центрах обработки данных (размещенных на Digital Ocean):

  • Нью-Йорк, США
  • Лондон, Англия
  • Бангалор, Индия

клиент

Браузер будет запрашивать одну и ту же страницу 20 раз подряд с 3-секундным интервалом между каждым запросом, и процесс полностью автоматизирован. Сеть рассчитана на 200 Мбит/с. Во время сбора данных на компьютере не было запущено никаких других приложений.

Насколько быстр HTTP/3?

Нью-Йорк, США

Вот время отклика для HTTP/2 и HTTP/3 при запросе трех разных сайтов из центра обработки данных в Нью-Йорке:

HTTP/3 в:

  • Скоро появится небольшой сайт200 мс
  • Контент-сайт скоро появится325 мс
  • Скоро появятся одностраничные приложения300 мс

Миннесота находится в 1000 милях (160 км) от Нью-Йорка, это немного для подключения к Интернету. Однако важно отметить, что HTTP/3 способен значительно повысить производительность даже на относительно коротких расстояниях.

Лондон, Англия

В этот тест я также включил тест HTTP/1.1. Чтобы показать, насколько быстрее HTTP/2 и HTTP/3, я выровнял шкалы осей на диаграмме ниже. Вы можете видеть, насколько медленным является HTTP/1.1 для контентных сайтов, настолько медленным, что графики даже не отображаются!

Как видите, прирост скорости более заметен, когда сеть находится дальше.

  • Скоро появится небольшой сайт600 мс(Скорость в Нью-Йорке3 раза)
  • Контент-сайт скоро появится1200 мс(Скорость в Нью-Йорке3,5 раза)
  • Скоро появятся одностраничные приложения1000 мс(Скорость в Нью-Йорке3 раза)

Бангалор, Индия

Улучшение производительности HTTP/3 наиболее заметно при загрузке страниц из Индии. Я не буду тестировать HTTP/1.1, потому что он слишком медленный. Вот сравнение результатов для HTTP/2 и HTTP/3:

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

В любом случае HTTP/3 быстрее, чем исторический HTTP!

Почему HTTP/3 такой быстрый?

истинное мультиплексирование

Истинная природа мультиплексирования HTTP/3 означает, что нигде в стеке не происходит блокировки начала строки. Когда вы запрашиваете ресурсы из более удаленных географических мест, вероятность потери пакетов намного выше, и потребность в повторных передачах TCP возрастает.

0-RTT, меняющий правила игры

Кроме того, HTTP/3 также поддерживает0-RTTСоединения QUIC, сокращающие количество круговых поездок для установления безопасного соединения TLS.

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

Однако не следует слепо включать 0-RTT. Основываясь на вашей модели угроз,возможныйЕсть некоторые проблемы с безопасностью.

Данные 0-RTT имеют более слабые свойства безопасности, чем другие типы данных TLS. Конкретно:

  1. Данные не являются прямым секретом; данные шифруются только с помощью ключа, полученного из предварительного общего ключа (PSK).
  2. Нет гарантии, что между соединениями не будет повтора (Примечание переводчика: см.повторить атаку).

Могу ли я сейчас использовать HTTP/3?

Может быть! Хотя договор ещеИнтернет-Черновикстатус, но есть много разныхпрограмма практики.

В качестве эталона я специально выбралCaddy. мне просто нужно изменитьCaddyfileодин изпростая конфигурацияHTTP/3 включен.

Nginx также имеет экспериментальную поддержку HTTP/3 и работает над этим.Двигаемся к выпуску HTTP/3 (это в ближайшем будущем).

Технологические гиганты, такие как Google и Facebook, уже предоставляют услуги через HTTP/3. В современных браузерахGoogle.comHTTP/3 используется полностью.

Для тех, кто «застрял» в экосистеме Microsoft, сказано, что Windows Server 2022 будет поддерживать HTTP/3, но вам нужно реализовать некоторые«Глубокие» шагичтобы включить его.

Суммировать

HTTP/3 может значительно улучшить взаимодействие с пользователем. Как правило, чем больше ресурсов требуется сайту, тем больше прирост производительности по сравнению с HTTP/3 и QUIC. Поскольку стандарт приближается к завершению, возможно, вам пора подумать о включении HTTP/3 для вашего веб-сайта.

Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллекти другие поля, если вы хотите видеть больше качественных переводов, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории