Постоянное соединение HTTP против соединения сокета TCP

Из этой статьи в Википедии:

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

  • Означает ли это, что с помощью этого механизма я могу имитировать соединение через TCP-сокет?
  • Используя это, я могу заставить сервер «проталкивать» данные клиенту?
  • Все ли HTTP-соединения, даже то, которое я использую для подключения к Stack Overflow, «постоянны»?
  • Использует ли технология push-сервера COMET этот механизм постоянного подключения HTTP для передачи данных? клиентам?

http tcp persistent
person Kevin Boyd    schedule 26.09.2009    source источник
comment
Постоянные HTTP-соединения - это просто оптимизация. Нет никакой разницы в поведении. Я считаю, что если вы хотите передавать данные клиенту, вы можете использовать фрагментированное кодирование.   -  person derobert    schedule 26.09.2009
comment
@derobert: что такое фрагментированная кодировка?   -  person Kevin Boyd    schedule 26.09.2009

Ответы (2)


arrow_upward
9
arrow_downward

  • Означает ли это, что с помощью этого механизма я могу имитировать соединение через TCP-сокет?

На самом деле, у сокетов есть МНОГИЕ больше возможностей и гибкости.

  • Используя это, я могу заставить сервер «проталкивать» данные клиенту?

Не напрямую, это все еще протокол запроса / ответа; постоянное соединение просто означает, что клиент может использовать один и тот же базовый сокет для отправки нескольких запросов и получения соответствующих ответов.

  • Все ли HTTP-соединения, даже то, которое я использую для подключения к Stack Overflow, «постоянны»?

Если ваш браузер (или специфический сервер) не говорит иначе, да.

  • Использует ли технология передачи сервера COMET этот механизм постоянного HTTP-соединения для передачи данных клиентам?

Вроде как (по крайней мере, для струйки), но с большим количеством взбитых сливок сверху. Существуют и другие подходы к реализации Comet, такие как скрытые фреймы и длинный опрос AJAX, которые могут не требовать постоянных соединений (которые в любом случае дают некоторые брандмауэры и т. Д .;-).

person Alex Martelli    schedule 26.09.2009
comment
Вы говорите, что у сокетов НАМНОГО больше возможностей и гибкости. Каковы эти функции по отношению к постоянному соединению HTTP и какую гибкость они обеспечивают? - person Kevin Boyd; 26.09.2009
comment
Сокеты TCP не накладывают никаких ограничений на то, кто говорит, когда и как - любая сторона может отправлять байты в любое время, не дожидаясь другой (полный дуплекс), поток по сути не разбивается на сообщения определенной длины и т. Д. Вам нужен протокол более высокого уровня сверху, чтобы отказаться от некоторой гибкости и превратить хаос в порядок: HTTP - это всего лишь один из таких протоколов, асимметричный полудуплексный протокол запроса / ответа с сообщениями четко определенной длины (заголовки длины содержимого или разбиение на части). Клиент может ставить запросы один за другим, сервер должен отвечать на каждый запрос. - person Alex Martelli; 26.09.2009

arrow_upward
1
arrow_downward

Фактически, HTTP-сервер может «протолкнуть» данные подключенному HTTP-клиенту без его запроса. См. «Проталкивание HTTP-сервера» на странице http://en.wikipedia.org/wiki/Push_technology. Однако, похоже, это обычно реализуется.

person Michael    schedule 26.02.2011