Заметки об изучении базовой концепции HTTP2

внешний интерфейс сервер браузер CDN

HTTP2Спецификация была официально выпущена в мае 2015 года, и до сих пор большинство браузеров и серверов поддерживали этот протокол:

http2-compatibility
(2018-04-09)

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

1 Прошлое и настоящее

HTTP1.1 Мы используем HTTP1.x уже довольно давно, с тех пор как он был выпущен в 1997 году и последний раз пересматривался в 1999 году, но с бурным развитием Интернета в последнее десятилетие некоторые функции, указанные протоколом в то время оказались не в состоянии удовлетворить современные требования сетевых потребностей.

request body

HTTP1.x имеет следующие фатальные недостатки: (в качестве примера возьмем браузер на сервер)

  • Протокол предусматривает, что клиент может иметь до 2 одновременных подключений к одному и тому же домену (обычно от 2 до 8 для реализаций браузера), но для этого необходимо загрузить обычную современную веб-страницу.40 ресурсов
  • Проблема блокировки начала строки: запросы в одном и том же соединении должны быть отправлены и получены последовательно один за другим
  • На основе текстового протокола заголовки запроса и ответа очень велики и не могут быть сжаты.
  • Приоритет ответа не может контролироваться и должен отвечать в порядке запросов.
  • Могут быть только односторонние запросы, то есть то, что запрашивает клиент, сервер может только вернуть.

Именно вышеперечисленные проблемы серьезно сказываются на эффективности и гибкости современного информационного взаимодействия в Интернете.В это время появился более современный и производительный протокол связи HTTP2.

HTTP2 использует多路复用,HPACK头压缩,流 + 二进制帧а также流优先级и другие технические средства для решения вышеуказанных задач.

2 HTTP2

HTTP2предшественником былSPDY-протокол(протокол прикладного уровня, созданный Google в качестве усовершенствования HTTP1), первый проект основан на пересмотренной спецификации SPDY3.HTTP2 должен преодолевать ограничения производительности, улучшать производительность передачи и достигать низкой задержки и высокой пропускной способности при сохранении исходной парадигмы HTTP (без изменения семантики, методов, кодов состояния, URI и полей заголовков HTTP/1.x и т. д. .). .

Особенности HTTP2 включают в себя:

  1. Использование содержимого передачибинарный протокол
  2. использоватьРамкакак наименьшая единица передачи
  3. мультиплексирование
  4. сжатие заголовка
  5. пуш сервера
  6. приоритеты и зависимости
  7. сбрасываемый
  8. управление потоком
  9. Спецификация HTTPS rfc не требует HTTP2 для принудительного использования TLS, но в настоящее время все браузеры и реализации серверов в мире реализуют HTTP2 на основе HTTPS.

2.1 Бинарный

В эпоху HTTP1.x и содержимое, и информация заголовка закодированы в текстовом/ASCII-кодировании.Хотя это выгодно для наблюдения за содержимым непосредственно из запроса, это чрезвычайно затрудняет одновременную передачу (есть пробелы или другие символы). , трудно сказать начало и конец сообщения). Использование двоичной передачи позволяет избежать этой проблемы, поскольку содержимое передачи состоит только из 1 и 0, а различные типы содержимого можно легко идентифицировать по формату, указанному в спецификации «кадра» во втором пункте ниже. Существует очевидное преимущество одновременного использования двоичного кода:Меньший объем передачи.

2.2 Бинарное кадрирование

При сохранении исходной парадигмы HTTP HTTP2 реализуетПреодолейте ограничения производительности, улучшите производительность передачи и добейтесь низкой задержки и высокой пропускной способности.Один из ключей:Добавляется между прикладным уровнем (HTTP2) и транспортным уровнем (TCP или UDP).二进制分帧层.

frame

Фрейм (Frame) — наименьшая единица передачи в HTTP2-связи, все кадры9заголовок октета, за которым следует полезная нагрузка переменной длины

帧结构图
 +-----------------------------------------------+
 |                 长度Length (24)                |
 +---------------+---------------+---------------+
 |   类型Type (8)    |   标志Flags (8)   |
 +-+-------------+---------------+-------------------------------+
 |R|                 流标识符Stream Identifier (31)               |
 +=+=============================================================+
 |                   帧载荷Frame Payload (0...)                 ...
 +---------------------------------------------------------------+

Всего в спецификации определено 10 различных фреймов, два самых основных из которых соответствуют ДАННЫМ и ЗАГОЛОВКАМ HTTP1.x.

Настоящий запрос HTTP2 выглядит так:

steam

2.3 Мультиплексирование и потоковая передача

упоминалось в предыдущем разделеStream IdentifierСвязывает каждый кадр, передаваемый по соединению HTTP2, с «потоком». Поток — это независимая двунаправленная последовательность кадров, которые могут непрерывно обмениваться данными между сервером и клиентом через соединение HTTP2.
Каждое отдельное соединение HTTP2 может содержать несколько параллельных потоков, содержащих чередующиеся кадры с обоих концов. Потоки могут устанавливаться и использоваться клиентом/сервером в одностороннем порядке, использоваться обеими сторонами или закрываться любой из сторон. В потоках порядок, в котором отправляется каждый кадр, имеет решающее значение. Приемник обрабатывает кадры в том порядке, в котором они были получены.

выше«Объяснение HTTP2»Для объяснения конвекции ниже приведен пример небольшого поезда, но лично мне кажется, что этот пример имеет определенное отклонение, и он не позволяет людям понять интуитивно帧-流-连接Связь между следующим является личным пониманием:

A "stream" is an independent, bidirectional sequence of frames exchanged between the client and server within an HTTP/2 connection. --rfc7540 StreamsLayer

«Поток» — это логическое понятие (настоящего транспортного потока не существует), независимая двунаправленная последовательность кадров, которыми обмениваются клиент и сервер в соединении HTTP2, поэтому в спецификацииstreamТакже причина для заключения его в двойные кавычки. Из предыдущего раздела мы можем знать, что единицей передачи HTTP2 являетсяРамка, поток на самом делесгруппированный набор кадровконцепция, зачем вам этот логический набор? ответ多路复用.

Мультиплексирование является основным техническим моментом для решения первой точки (проблема параллелизма) и второй точки (проблема заголовка строки HOLB) ​​дефектов HTTP1.x. Вот 🌰 для иллюстрации:

Предполагая, что TCP-соединение установлено, теперь клиенту необходимо инициировать два запроса, которые выглядят следующим образом с точки зрения потока:

stream-request

Но есть только одно фактическое TCP-соединение, и два фрейма не могут прийти на сервер "одновременно".Мультиплексирование больше похоже на концепцию задач обработки ЦП.并发, а не параллельно, используя термины из спецификацииStream ConcurrencyвместоStream ParallelismТакой вывод тоже можно сделать, поэтому фактическая трансмиссия выглядит следующим образом:

real-transport

На изображении выше есть три момента, на которые следует обратить внимание:

  1. Кадры в одном потоке чередуются!
  2. Кадры заголовка должны предшествовать кадрам данных, потому что и клиент, и сервер полагаются на информацию фрейма заголовка для анализа данных фрейма данных!
  3. Кадр, который приходит первым, не обязательно возвращается первым, быстрый кадр может вернуться первым!

Именно из-за первой приведенной выше характеристики объясняется, почему необходим логический набор «потоков». В то же время через это帧-流-连接Решена комбинация параллелизма запросов (одновременное подключение нескольких запросов) и проблемы с заголовком HOLB (одновременная отправка, асинхронный ответ).

ВойтиHTTP/2: the Future of the InternetИз официальной демонстрации, созданной Akamai, видно, что HTTP2 значительно улучшил производительность по сравнению с предыдущим HTTP1.1.

HTTP1.1

http1

HTTP2

http2

В прошлом мы обнаружили, что оптимизация производительности HTTPКлюч не высокая широкополосность, нонизкая задержка.

latency-vs-bandwidth

Как видно из приведенного выше рисунка, когда пропускная способность достигает определенной скорости, улучшение скорости загрузки страницы очень мало, но по мере уменьшения задержки время загрузки страницы будет соответственно продолжать уменьшаться. Из-за функции медленного запуска, называемой «настройкой» в TCP-соединениях, HTTP-соединения, которые изначально являются импульсными и недолговечными, очень неэффективны. В HTTP2, позволяя всем потокам данных совместно использовать одно и то же соединение, TCP-соединения могут использоваться более эффективно, позволяя высокой пропускной способности действительно служить повышению производительности HTTP.

Вышеизложенное является чисто личным пониманием, если что-то не так, пожалуйста, не стесняйтесь указывать и обсуждать, спасибо!

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

мы все знаемСам протокол HTTP не имеет состоянияиз: между каждым запросомнесвязанный, каждый запрос должен содержать все детали, требуемые сервером. Например, запрос 1 отправляет на сервер информацию «Я пользователь А», а затем запрос 2 отправляет информацию «Изменить мое имя пользователя на XX». пользователь A», то сервер не знает, имя пользователя какого пользователя изменить.

Это явно не соответствует текущей архитектуре системы веб-приложений, поскольку общая система должна выполнять аутентификацию, ведение журнала, проверку безопасности и другие ограничения, поэтому необходимо получить информацию о текущем действующем пользователе.Эта информация содержится в виде обычного текста посередине, а решение до HTTP2 обычно заключается в имитации «состояния» с использованием заголовка Cookies, сеанса сервера и т. д. Недостаток использования заголовка Cookies заключается в том, что каждый запрос должен нести огромную и повторяющуюся информацию и не может быть сжат.Если предположить, что заголовок запроса составляет 2 КБ, то сто запросов повторяют информацию размером 200 КБ, что является огромной тратой полосы пропускания.

HTTP2 добавляет две функции для решения вышеуказанных проблем:

  • HPACK, алгоритм, специально разработанный для сжатия заголовков, также указан в отдельном черновике.
    hpack
  • Таблица заголовков, HTTP2 использует «таблицу заголовков» на стороне клиента и сервера для отслеживания и хранения ранее отправленных пар ключ-значение для тех же данных, которые больше не отправляются через каждый запрос и ответ; общее назначение, которое почти не меняется во время связи. пару значений (агент пользователя, допустимые типы мультимедиа и т. д.) необходимо отправить только один раз.
    header-table

2.5 Сервер Push

Эту функцию часто называют «проталкиванием кеша». Основная идея заключается в следующем: когда клиент запрашивает ресурс X, а сервер знает, что ему также может понадобиться ресурс Z, сервер может активно передавать ресурс Z клиенту до того, как клиент отправит запрос Z. Эта функция помогает клиенту поместить Z в кеш для будущего использования.

Нажатие сервера требует, чтобы клиент явно разрешил серверу предоставлять эту функциональность. Но даже в этом случае клиент все еще может выбрать, прерывать ли push-поток. Если нет необходимости, клиент может отправитьRST_STREAMкадр, чтобы прервать толчок.

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

【Традиционная практика】

tradition

Чтобы ускорить этот процесс и сократить время белого экрана, традиционный метод заключается в том, чтобы встроить все ресурсы, необходимые для домашней страницы, в документ и объединить ресурсы, такие как спрайты CSS, сжатие и слияние js и т. д. Как показано ниже:

inline

[HTTP2]

В сценарии HTTP2, когда клиент запрашивает документ, если сервер знает, какие ресурсы нужны странице, он может вернуть эти ресурсы вместе:

push

Уведомление:Активно загружаемые ресурсы могут кэшироваться браузерами!

Итак, вопрос в том, что если клиент уже кэшировал ресурс, сервер все равно каждый раз отправляет клиенту один и тот же ресурс, разве это не большая трата?

Ответ: Получается, что это так, поэтому команда IETF работает надcache-digestТехническая спецификация используется, чтобы помочь клиенту активно сообщать серверу, какие ресурсы были кэшированы и не нуждаются в повторной отправке.

Для сравнения влияния отправки сервера на производительность веб-страницы и использования CDN вы можете обратиться к следующим двум статьям:

  1. measuring-server-push-performance
  2. http://www.ruanyifeng.com/blog/2018/03/http2_server_push.html

Вывод: использование функций мультиплексирования HTTP2 и серверных push-функций не означает, что использование CDN может быть сокращено или даже может быть прекращено, потому что фактическое сокращение географической задержки, вызванное CDN, не может быть решено HTTP2. Вместо этого мы должны подумать о том, как объединить HTTP2. и CDN для дальнейшего повышения эффективности и стабильности сетевых сервисов и сокращения задержек.

2.6 Приоритеты и зависимости

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

С помощью фрейма PRIORITY клиент также может сообщить серверу, от какого другого потока зависит текущий поток. Эта функция позволяет клиенту построить «дерево» приоритетов, где все «подпотоки» будут зависеть от завершения передачи «родительского потока».

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

2.7 Сбрасываемый

Одним из недостатков HTTP 1.x является то, что когдаContent-LengthПосле отправки HTTP-сообщения вам очень сложно его прервать. Конечно, обычно можно разорвать все TCP-соединение (но не всегда), но за счет трехэтапного рукопожатия восстановить новое TCP-соединение.

Лучшее решение — просто завершить текущее переданное сообщение и повторно отправить новое. В http2 мы можем выполнить это требование, отправив кадры RST_STREAM, чтобы избежать потери полосы пропускания и прерывания существующих соединений.

2.8 Управление потоком

Каждый поток http2 имеет собственное опубликованное окно трафика, которое ограничивает данные, отправляемые другим концом. Они очень похожи, если вы знаете, как работает SSH.

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

Только фреймы данных подлежат управлению потоком.

Суммировать

Подытожим преимущества использования HTTP2:

  • Меньший размер передачи, меньшие или опущенные повторяющиеся заголовки сообщений
  • Преодолейте исходный предел параллелизма TCP-соединений, используйте одно TCP-соединение для достижения параллелизма с несколькими запросами, а одно соединение также может снизить нагрузку на сервер (меньше использование памяти и ЦП).
  • Решите проблему заголовка строки HOLB, медленные запросы или запросы, отправленные первыми, не будут блокировать возврат других запросов.
  • В сочетании с CDN для предоставления прокси-сервисов распространения контента с более высокой скоростью в реальном времени и меньшей задержкой, что значительно сокращает время белого экрана.
  • Приоритет передачи данных можно контролировать, что позволяет веб-сайтам осуществлять более гибкое и эффективное управление страницами.
  • Можно остановить (сбросить) передачу данных без прерывания соединений TCP

Эта статья в основном посвящена заметкам об изучении и личному пониманию, впервые опубликованным вxlaoyu.info, Некоторые изображения и тексты цитируются из Интернета, нарушаются и удаляются.

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

  1. Ideal HTTP PerformanceАвтор — Марк Ноттингем, председатель рабочей группы IETF HTTP и главный архитектор корпорации Akamai.
  2. TCP материал
  3. Обзор HTTP2
  4. HTTP2 объяснил
  5. HTTP/2 уже здесь, давайте оптимизировать! Ilya Grigorik, Velocity SC 2015
  6. rfc7540
  7. Резюме HTTP2
  8. Прекрасная повседневная жизнь HTTP2.0 -- alloyteam
Категории