Ограничение параллелизма и проблема блокировки заголовка очереди в протоколе HTTP

внешний интерфейс сервер HTTP CSS

последовательное соединение

HTTP/0.9 и более ранние протоколы HTTP/1.0 сериализуют обработку HTTP-запросов. Предположим, что страница содержит 3 файла стилей, которые относятся к одному и тому же протоколу, доменному имени и порту. Затем браузер должен инициировать в общей сложности четыре запроса, и каждый раз может быть открыт только один TCP-канал.После загрузки запрошенного ресурса соединение немедленно разрывается, и открывается новое соединение для обработки следующего запроса в очередь. При постоянном увеличении размера и количества ресурсов страницы время задержки в сети будет продолжать накапливаться, и пользователь столкнется с пустым экраном и потеряет терпение после слишком долгого ожидания.

Параллельное соединение

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

  • IE 7: 2
  • IE 8/9: 6
  • IE 10: 8
  • IE 11: 13
  • Firefox: 6
  • Chrome: 6
  • Safari: 6
  • Opera: 6
  • iOS WebView: 6
  • Android WebView: 6

Постоянное соединение (длинное соединение)

Ранний протокол HTTP занимал отдельное TCP-соединение для каждого запроса, что, несомненно, увеличивало накладные расходы на установление TCP-соединения, накладные расходы на управление перегрузкой и накладные расходы на разрыв соединения.Поддерживаются улучшенные HTTP/1.0 и HTTP/1.1 (по умолчанию).Постоянное соединение. Если запрос завершен, соединение не будет разорвано немедленно, а останется подключенным в течение определенного периода времени, чтобы быстро обработать предстоящий HTTP-запрос и повторно использовать тот же TCP-канал, пока не произойдет сбой обнаружения пульса клиента или не истечет время ожидания соединения с сервером. Эта функция доступна через HTTP-заголовок.Connection: keep-aliveдля активации клиент также может отправитьConnection: closeчтобы активно закрыть соединение. Таким образом, мы видим, что две оптимизации параллельного соединения и постоянного соединения дополняют друг друга.Параллельное соединение позволяет открывать несколько TCP-соединений одновременно при первой загрузке страницы, а постоянное соединение гарантирует, что последующие запросы повторно используют открытые соединения TCP.Это также общий механизм для современных веб-страниц.

трубопроводное соединение

Постоянное соединение позволяет нам повторно использовать соединение для выполнения нескольких запросов, но оно должно соответствовать порядку очереди в FIFO.Он должен гарантировать, что предыдущий запрос успешно прибыл на сервер, успешно обработан и получил первый байт, возвращенный сервером. , запрос. Каналы HTTP позволяют клиентам выполнять несколько запросов подряд в одном и том же TCP-канале, не дожидаясь ответа, что устраняет разницу в задержках при передаче туда и обратно. Но на самом деле это связано с ограничениями протокола HTTP/1.x, который не позволяет данным поступать по каналу с чередованием (мультиплексирование ввода-вывода). Представьте себе ситуацию, когда клиент и сервер одновременно отправляют один HTML-запрос и несколько CSS-запросов, а сервер обрабатывает все запросы параллельно. сталкивается с проблемой и приостанавливается на бесконечное время Это может даже привести к переполнению буфера в тяжелых случаях Эта ситуация называетсяблокировка начала очереди. Поэтому эта схема не была принята в протоколе HTTP/1.x.

Блокировка заголовка строки не является уникальной концепцией в HTTP, а является обычным явлением при обмене кэшированными коммуникационными сетями.

Суммировать

  1. Для одного и того же протокола, доменного имени и порта браузеру разрешено открывать до 6 TCP-соединений одновременно, как правило, верхний предел составляет 6.
  2. Разрешены несколько HTTP-запросов для одного и того же TCP-соединения, но они должны дождаться прибытия первого байта ответа от предыдущего запроса к клиенту.
  3. Из-за проблемы блокировки в начале очереди клиент не может одновременно отправлять все запросы в очереди.Эта проблема была решена в HTTP/2.0.