1

Часто цитируемый аргумент в основном тот, который содержится в этой картине

Однако это не отражает реальность базового TCP-соединения, которое должно запускаться медленно и когда клиент подтверждает все остальные сегменты, полученные от сервера. Всякий раз, когда клиенту нужно что-то отправить (например, HTTP-запрос), ACK будут поддерживаться. Так где здесь выгода?

2 ответа2

1

Существует несколько причин, по которым конвейеризация выполняется быстрее, чем чисто постоянные HTTP-соединения:

  1. Несколько HTTP-запросов могут быть объединены в один TCP-сегмент
  2. Несколько HTTP-ответов (для небольших файлов) могут быть объединены в один (или меньше) TCP-сегмент (ы)
  3. Медленный старт на самом деле довольно быстрый, а именно экспоненциальный. После n циклов приема-передачи размер пакета уже составляет от 2 ^ n до 2 ^ (n+1) сегментов. Для n = 10 это означает 1024… 2048 сегментов или (обычно) 140… 300 килобайт на RTT.
  4. Если TCP-соединение все еще открыто из предыдущего HTTP-запроса (или набора запросов), мы уже на этапе медленного запуска.

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

1

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

При конвейерной обработке направление канала «клиент - сервер» постоянно заполнено, что обеспечивает максимальную пропускную способность и минимальную задержку.

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

  1. Время, которое требуется последнему кадру первого ответа сервера для прохождения через сеть.
  2. Время, которое требуется клиенту, чтобы действовать после получения этого фрейма и подготовить свой новый запрос.
  3. Время, которое требуется новому клиентскому запросу для транзита по сети.
  4. Время, необходимое серверу для подготовки ответа на новый запрос.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .