Расшифровать новые функции HTTP/2 и HTTP/3

внешний интерфейс JavaScript

предисловие

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

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

1. Что изменилось с момента изобретения HTTP/1.1?

Если вы внимательно посмотрите на загрузки, необходимые для открытия домашних страниц самых популярных веб-сайтов, вы обнаружите очень четкую тенденцию. В последние годы объем загружаемых данных, необходимых для загрузки домашней страницы веб-сайта, постепенно увеличивался и превысил 2100 тыс. Но что нас должно больше беспокоить, так это то, что среднее количество ресурсов, которые необходимо загрузить каждой странице для завершения отображения и рендеринга, превысило 100.

Как видно из приведенного ниже графика, с 2011 года размер передаваемых данных и среднее количество запрашиваемых ресурсов продолжали расти и не показывают признаков замедления. Зеленая линия на графике показывает увеличение размера передаваемых данных, а красная линия — увеличение среднего количества запрашиваемых ресурсов.

С тех пор как в 1997 году был выпущен HTTP/1.1, мы уже давно используем HTTP/1.x, но с бурным развитием Интернета в последнее десятилетие содержание веб-страниц изменилось с текстового на насыщенное. мультимедиа (например, изображения, звук, видео), и появляется все больше и больше приложений (таких как чат, живое видео), которые предъявляют высокие требования к содержимому страницы в реальном времени, поэтому некоторые функции, указанные в протоколе, в то время больше не могут удовлетворить потребности современных сетей.

2. Дефекты HTTP/1.1

1. Высокая задержка — снижение скорости загрузки страницы

Хотя в последние годы пропускная способность сети очень быстро росла, мы не наблюдали соответствующего снижения сетевой задержки.Проблема задержки в сети в основном связана с блокировкой заголовка линии, что приводит к невозможности полного использования полосы пропускания..

Блокировка начала очереди означает, что когда запрос в последовательности запросов, отправляемых последовательно, блокируется по какой-либо причине, все запросы, поставленные в очередь позже, также блокируются, что приводит к задержке получения данных клиентом. Для блокировки начальных строк люди пробовали следующие решения:

  • Распределите ресурсы одной и той же страницы по разным доменным именам, чтобы увеличить лимит подключений.В Chrome есть механизм, который по умолчанию позволяет устанавливать 6 постоянных TCP-соединений одновременно для одного и того же доменного имени., при использовании постоянных подключений, несмотря на то, что канал TCP может использоваться совместно,Но одновременно в конвейере может обрабатываться только один запрос., другие запросы могут находиться в состоянии блокировки только до завершения текущего запроса. Кроме того, если одновременно происходит 10 запросов под одним и тем же доменным именем, то 4 из них перейдут в состояние ожидания в очереди до завершения текущих запросов.
  • Sprites объединяет несколько маленьких изображений в одно большое изображение, а затем использует JavaScript или CSS, чтобы снова «вырезать» маленькие изображения.
  • Встраивание — это еще один способ предотвратить отправку большого количества запросов небольших изображений. Исходные данные изображения встраиваются в URL-адрес в файле CSS, чтобы уменьшить количество сетевых запросов.
.icon1 {
    background: url(data:image/png;base64,<data>) no-repeat;
  }
.icon2 {
    background: url(data:image/png;base64,<data>) no-repeat;
  }
  • Объединение использует такие инструменты, как веб-пакет, для упаковки нескольких небольших файлов JavaScript в один больший файл JavaScript, но если один из файлов будет изменен, большой объем данных будет повторно загружен в несколько файлов.

2. Функции без сохранения состояния — огромные HTTP-заголовки

Поскольку заголовок сообщения обычно содержит множество фиксированных полей заголовка, таких как «Агент пользователя», «Cookie», «Принять», «Сервер» (как показано на рисунке ниже), до сотен байтов или даже тысяч байтов, но Тело часто составляет всего несколько десятков байтов (например, запросы GET, 204/301/304 ответ), стал отъявленным «старшим сыном». Контент, переносимый в заголовке, слишком велик, что в определенной степени увеличивает стоимость передачи. Что еще хуже, многие значения полей в тысячах сообщений запросов и ответов повторяются, что очень расточительно.

3. Передача открытого текста – незащищенность

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

Слышали новости о «ловушке бесплатного WiFi»? Хакеры пользуются недостатками передачи открытого текста HTTP и устанавливают точки доступа Wi-Fi в общественных местах, чтобы начать «рыбалку», чтобы обмануть пользователей сети для серфинга в Интернете. Как только вы подключитесь к этой точке доступа Wi-Fi, весь трафик будет перехвачен и сохранен.Если есть конфиденциальная информация, такая как номер банковской карты и пароль веб-сайта, это будет опасно.Хакеры могут притворяться вами и делать все, что захотят.

4. Не поддерживает серверные push-сообщения

3. Введение в протокол SPDY и HTTP/2

1. Протокол SPDY

Как мы упоминали выше, из-за дефектов HTTP/1.x мы добавим изображения спрайтов, встроенные небольшие изображения, будем использовать несколько доменных имен и т. д. для повышения производительности. Однако эти оптимизации обошли протокол.До 2009 года Google раскрывал протокол SPDY, разработанный им самим, в основном для решения проблемы неэффективности HTTP/1.1. Запуск Google SPDY — это формальная трансформация самого протокола HTTP. Уменьшите задержку, сжимайте заголовки и т. д. Практика SPDY доказала эффективность этих оптимизаций и, наконец, привела к рождению HTTP/2.

HTTP/1.1 имеет два основных недостатка: отсутствие безопасности и низкая производительность., из-за огромного исторического бремени HTTP/1.x первоочередное внимание уделяется модификации протокола и совместимости, иначе он уничтожит бесчисленное количество существующих активов в Интернете. Как показано на фиг. SPDY находится под HTTP, над TCP и SSL, поэтому он может быть легко совместим со старой версией протокола HTTP (инкапсулирует содержимое HTTP1.x в новый формат кадра) и может одновременно использовать существующую функцию SSL. время.

После того, как протокол SPDY оказался применимым в браузере Chrome, он был использован в качестве основы HTTP/2, а основные функции были унаследованы от HTTP/2.

2. Введение в HTTP/2

В 2015 году был выпущен HTTP/2. HTTP/2 является заменой текущего протокола HTTP (HTTP/1.x), но это не переписывание, методы/коды состояния/семантика HTTP такие же, как у HTTP/1.x.HTTP/2 основан на SPDY и ориентирован на производительность.Одна из главных целей — использовать только одно соединение между пользователем и веб-сайтом.. Судя по текущей ситуации, некоторые ведущие сайты в стране и за границей в основном реализовали развертывание HTTP/2, и использование HTTP/2 может повысить эффективность примерно на 20-60%.

HTTP/2 состоит из двух спецификаций:

  1. Hypertext Transfer Protocol version 2 - RFC7540
  2. HPACK - Header Compression for HTTP/2 - RFC7541

4. Новые возможности HTTP/2

1. Двоичная передача

Есть две основные причины существенного сокращения объема данных, передаваемых по HTTP/2: передача в двоичном режиме и сжатие заголовков.. Давайте сначала представим двоичную передачу. HTTP/2 использует двоичный формат для передачи данных, а не текстовые сообщения в HTTP/1.x. Двоичный протокол более эффективен для анализа.HTTP/2 разбивает данные запроса и ответа на более мелкие кадры, и они кодируются двоичным кодом..

Он перемещает некоторые функции протокола TCP на прикладной уровень, «разбивает» исходное сообщение «Заголовок + тело» на несколько небольших двоичных «кадров» и использует кадры «HEADERS» для хранения данных заголовка, «DATA» кадры хранят сущности. данные. После кадрирования данных HTP/2 структура сообщения «Заголовок+тело» полностью исчезает, и протокол видит только «фрагменты» один за другим.

В HTTP/2 вся связь под одним и тем же доменным именем осуществляется через одно соединение, которое может передавать любое количество двунаправленных потоков данных. Каждый поток данных отправляется как сообщение, которое, в свою очередь, состоит из одного или нескольких кадров.Несколько кадров могут быть отправлены вне очереди и могут быть повторно собраны в соответствии с идентификатором потока в заголовке кадра..

2. Сжатие заголовков

HTTP/2 не использует традиционный алгоритм сжатия, но разрабатывает специальный алгоритм «HPACK», устанавливает «словарь» на обоих концах клиента и сервера, использует индексы для представления повторяющихся строк и использует кодирование Хаффмана для сжатия целых чисел. и струны могут достигать высокой степени сжатия от 50% до 90%.

Конкретно:

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

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

3. Мультиплексирование

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

Каждый может пройтисвязьИнтуитивно почувствуйте, насколько HTTP/2 быстрее, чем HTTP/1.В HTTP/2 с двоичным кадрированием HTTP/2 больше не использует TCP-ссылки для достижения многопоточного параллелизма.

  • Все коммуникации под одним и тем же доменным именем осуществляются по одному соединению.
  • Одно соединение может передавать любое количество двунаправленных потоков данных.
  • Поток данных отправляется в виде сообщения, и сообщение состоит из одного или нескольких кадров.Множественные кадры могут быть отправлены не по порядку, поскольку их можно собрать заново в соответствии с идентификатором потока в заголовке кадра.

Эта функция значительно повышает производительность:

  • Одно и то же доменное имя должно занимать только одно TCP-соединение и использовать одно соединение для параллельной отправки нескольких запросов и ответов, так что процесс загрузки всего ресурса страницы требует только медленного запуска, а также позволяет избежать проблемы конкуренции за пропускную способность между несколько TCP-соединений.
  • Несколько запросов/ответов отправляются параллельно и чередуются, не влияя друг на друга.
  • В HTTP/2 каждый запрос может иметь 31-битное значение приоритета, 0 представляет наивысший приоритет, и чем больше значение, тем ниже приоритет. С этим значением приоритета клиент и сервер могут использовать разные стратегии при обработке разных потоков и отправлять потоки, сообщения и кадры оптимальным образом.

Как показано на рисунке выше, технология мультиплексирования может передавать все данные запроса только через одно TCP-соединение.

4.Server Push

HTTP2 также в определенной степени меняет традиционный режим работы «запрос-ответ»: сервер больше не отвечает на запросы полностью пассивно, а также может создавать новый «поток» для активной отправки сообщений клиенту. Например, когда браузер просто запрашивает HTML, он заранее отправляет клиенту файлы JS и CSS, которые могут быть использованы для уменьшения задержки ожидания, что называется «Server Push» (Server Push, также называемым Cache push).

Например, как показано на рисунке ниже, сервер активно отправляет файлы JS и CSS клиенту, не отправляя эти запросы, когда клиент анализирует HTML.

Кроме того, нужно добавить, что сервер может активно пушить, а клиент тоже имеет право выбирать, получать или нет. Если ресурс, переданный сервером, был кэширован браузером, браузер может отклонить его, отправив кадр RST_STREAM. Active push также соблюдает политику того же источника, другими словами, сервер не может передавать сторонние ресурсы клиенту по своему желанию, но должен быть подтвержден обеими сторонами.

5. Улучшить безопасность

Из соображений совместимости HTTP / 2 продолжает функцию «открытого текста» HTTP / 1. Данные могут передаваться в открытом тексте, как и раньше, и шифрование связи не является обязательным. Однако формат по-прежнему двоичный, но расшифровка не требуется.

Однако, поскольку HTTPS стал общей тенденцией, а основные браузеры, такие как Chrome и Firefox, публично объявили, что они поддерживают только зашифрованный HTTP/2,Таким образом, «де-факто» HTTP/2 зашифрован.. То есть HTTP/2, который обычно встречается в Интернете, использует имя протокола «https» и работает на TLS. Протокол HTTP/2 определяет два строковых идентификатора: «h2» для зашифрованного HTTP/2 и «h2c» для открытого текста HTTP/2.

6. Новые возможности HTTP/3

1. Недостатки HTTP/2

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

  • Задержка в установлении соединений для TCP и TCP+TLS

HTTP/2 использует протокол TCP для передачи, а если используется HTTPS, для безопасной передачи также требуется протокол TLS, а для использования TLS также требуется процесс установления связи.Это требует двух задержек рукопожатия:

①При установлении TCP-соединения необходимо выполнить трехстороннее рукопожатие с сервером, чтобы подтвердить успешное соединение, что означает, что передача данных может быть выполнена только после использования 1,5 RTT.

②Установите соединение TLS.Существует две версии TLS—TLS1.2 и TLS1.3.Время, необходимое каждой версии для установления соединения, различно, требуется примерно 1–2 RTT.

Всего нам нужно провести 3-4 RTT перед передачей данных.

  • Блокировка заголовка TCP не была полностью решена

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

Прочитав это, некоторые люди могут подумать, почему бы напрямую не изменить протокол TCP? На самом деле это невыполнимая задача. Потому что TCP существует слишком долго, он залит в разные устройства, и этот протокол реализован операционной системой, и обновить его не реально.

2. Введение в HTTP/3

Google знал об этих проблемах, когда запускал SPDY, поэтому он запустил новый протокол QUIC, основанный на протоколе UDP, что позволило HTTP работать на QUIC вместо TCP. И этот «HTTP через QUIC» является следующей основной версией протокола HTTP, HTTP/3. Он совершает качественный скачок на базе HTTP/2 и действительно «отлично» решает проблему «блокировки начала строки».

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

3. Новые функции QUIC

Выше мы упоминали, что QUIC основан на UDP, а UDP «без установления соединения» и вообще не требует «рукопожатия» и «взмаха рукой», поэтому он быстрее, чем TCP. Кроме того, QUIC также обеспечивает надежную передачу, гарантируя, что данные могут быть доставлены в пункт назначения. Он также представил «потоковую передачу» и «мультиплексирование», подобные HTTP/2, где один «поток» упорядочен и может быть заблокирован из-за потери пакетов, но другие «потоки» не затрагиваются. В частности, протокол QUIC имеет следующие характеристики:

  • Он реализует функции управления потоком и надежностью передачи, аналогичные TCP.

Хотя UDP не обеспечивает надежной передачи, QUIC добавляет слой поверх UDP для обеспечения надежной передачи данных. Он обеспечивает повторную передачу пакетов, управление перегрузкой и некоторые другие функции, присутствующие в TCP.

  • Реализована функция быстрого рукопожатия.

Поскольку QUIC основан на UDP, QUIC может использовать 0-RTT или 1-RTT для установления соединения, что означает, что QUIC может отправлять и получать данные с максимальной скоростью, что может значительно повысить скорость открытия страницы в первый раз. .Можно сказать, что соединение 0RTT является самым большим преимуществом QUIC в производительности по сравнению с HTTP2..

  • Шифрование TLS интегрировано.

QUIC в настоящее время использует TLS1.3, который имеет больше преимуществ, чем более ранняя версия TLS1.3, наиболее важным из которых является уменьшение количества RTT, затрачиваемых на рукопожатия.

  • Мультиплексирование, полностью решить проблему блокировки головного эскадрильи TCP

В отличие от TCP, в QUIC реализовано, что на одном и том же физическом соединении может быть несколько независимых логических потоков данных (как показано на рисунке ниже). Реализована раздельная передача потока данных, что решает проблему блокировки головного отряда ПТС.

7. Резюме

  • HTTP/1.1 имеет два основных недостатка: недостаточная безопасность и низкая производительность.
  • HTTP/2 полностью совместим с HTTP/1 и представляет собой «более безопасный HTTP, более быстрый HTTPS», сжатие заголовков, мультиплексирование и другие технологии могут в полной мере использовать пропускную способность и уменьшать задержку, тем самым значительно улучшая работу в Интернете;
  • QUIC реализован на основе UDP и является базовым протоколом поддержки в HTTP / 3. Протокол основан на UDP и использует сущность TCP для реализации быстрого и надежного протокола.

Добро пожаловать в публичный аккаунт:Мастер по фронтенду, мы будем свидетелями вашего роста вместе!Порекомендуйте полезный инструмент мониторинга ошибок для всехFundebug, добро пожаловать, чтобы попробовать это бесплатно!

Справочная статья

Категории