Почему HTTP может обрабатывать только один ожидающий запрос на сокет?

Question

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

Я понимаю, что это ограничение связано с тем, что отсутствует "Id", чтобы связать запрос с его ответом, поэтому единственный способ сопоставить ответ с его запросом - это отправить ответ в тот же сокет, который отправил запрос. Не было бы никакого способа сопоставить ответ на его запрос, если в сокете было более одного ожидающего запроса, поскольку мы можем не получить ответы в том же порядке, в котором были отправлены запросы.

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

Был ли HTTP разработан таким образом для простоты, даже если он менее эффективен или я что-то упустил, и это лучший подход?

Спасибо.

Answer 1

Не верно. Читайте о HTTP1.1 конвейерной обработке. Apache реализует это, а Firefox реализует это. Хотя Firefox отключает его по умолчанию.

Чтобы включить его в Firefox, используйте about:config и напишите 'pipelining' в фильтре.

см .: http://www.mozilla.org/projects/netlib/http/pipelining-faq.html

Answer 2

Есть несколько выводов, которые я бы рассмотрел.

Первый связан с природой самого TCP. TCP страдает от проблемы блокирования заголовка, когда в полете может быть только один невыполненный (неподтвержденный) запрос (уровень соединения / уровень TCP). Учитывая традиционные задержки, это может быть проблемой с точки зрения пользовательского опыта во время загрузки по сравнению с результатами, которые используют сегодня браузеры со схемой параллельного соединения. Чем выше задержка канала, тем больше влияние этого основного ограничения.

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

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

Answer 3

Это в основном для простоты; за эти годы были сделаны различные предложения, которые мультиплексируются в одном соединении (например, SPDY), но ни одно еще не было снято.

Answer 4

Одна проблема при отправке нескольких запросов в одном сокете состоит в том, что это приведет к неэффективной организации очередей.

Например, предположим, что вы находитесь в магазине, есть 2 кассира и 10 человек, ожидающих проверки. Идеальный способ создать линию - это иметь одну очередь из 10 человек, и следующий человек в очереди идет к кассе, когда они становятся доступными. Однако, если вы отправите все запросы сразу, вы, вероятно, отправите 5 человек в кассу А и 5 в кассу В. Однако что, если вы отправили 5 человек с самыми большими корзинами покупок в одну кассу? Это плохая очередь, и что может случиться, если вы поставите в очередь кучу запросов на одном сокете.

ПРИМЕЧАНИЕ: я не говорю, что вы не могли использовать очереди хорошо, но это просто сделать правильно, если нет очереди в одном сокете.

Answer 5

Также следует понимать, что HTTP не обязательно требует заголовок Content-Length для обслуживания данных. Даже если бы каждый HTTP-ответ был идентифицирован, как бы вы управляли потоковым двоичным контентом без длины контента (стиль HTTP / 1.0)? или если клиент отправил заголовок Connection: close, чтобы закрыть клиент из-за неизвестных длин?

Чтобы справиться с этим, вам потребуется HTTP-фрагмент (уже присутствующий) в мультиплексе (я не думаю, что кто-либо реализует это) и добавить некоторые нетривиальные работы во многие программы.