Какова разница в поведении между HTTP Stay-Alive и Websockets?

В последнее время я работаю с websockets. Создал мой собственный сервер и там публичная демонстрация. У меня нет такого подробного опыта или знаний: http. (Хотя, поскольку запросы websocket обновляются HTTP-запросы, у меня есть некоторые.)

На моем конце сервер сообщает о каждом хите. Среди них есть куча HTTP-запросов на пребывание. Мой сервер не обрабатывает их, потому что они не являются запросами websocket. Но это вызвало мое любопытство.

Вся большая вещь о веб-сайтах заключается в том, что соединение остается в живых. Затем вы можете передавать сообщения в обоих направлениях (одновременно даже). Я читал, что HTTP-соединение Stay-Alive является относительно новой разработкой (я не знаю, сколько лет в людях, только что оно включено только в самый последний стандарт - 1,1) - это на самом деле старый?)

Я предполагаю, что могу предположить, что существует разница в поведении между этими двумя, или не было бы причин для стандарта websocket? Какая разница?

Ответ 1

A Keep Alive HTTP header, поскольку HTTP 1.0, который используется для указания HTTP-клиента, хотел бы поддерживать постоянное соединение с HTTP-сервером. Основными задачами являются устранение необходимости открытия TCP-соединения для каждого HTTP-запроса. Однако, несмотря на то, что открыто постоянное соединение, протокол для связи между клиентом и сервером по-прежнему соответствует основному шаблону HTTP-запроса/ответа. Другими словами, серверная сторона не может передавать данные клиенту.

WebSocket - это совершенно другой механизм, который используется для настройки постоянного, полнодуплексного соединения. Благодаря этому полнодуплексному соединению серверная сторона может передавать данные клиенту и клиенту, как ожидается, будет обрабатывать данные со стороны сервера в любое время.

Цитирование соответствующих записей в Википедии для справки: 1) http://en.wikipedia.org/wiki/HTTP_persistent_connection 2) http://en.wikipedia.org/wiki/WebSocket

Ответ 2

Вы должны прочитать COMET, шаблон дизайна, который показывает пределы HTTP Keep-Alive. Keep-Alive уже более 12 лет, так что это не новая функция HTTP. Проблема в том, что этого недостаточно; клиент и сервер не могут общаться по-настоящему асинхронно. Клиент должен всегда использовать "зависающий" запрос, чтобы получить сообщение с сервера; сервер может не просто отправить сообщение клиенту в любое время, когда он захочет.

Ответ 3

HTTP vs Websockets

REST (HTTP)

Ресурсы извлекают выгоду из кеширования, когда представление ресурса изменяется редко или ожидается, что несколько клиентов извлекут ресурс.
Методы HTTP имеют хорошо известные идемпотентные и безопасные свойства. Запрос является "идемпотентным", если его можно выдавать несколько раз, не приводя к уникальным результатам.
Конструкция HTTP допускает ответы для описания ошибок с запросом, с помощью ресурса или предоставления информации о состоянии, которая будет отличаться от сценариев успеха.
Имейте функцию запроса и ответа.
HTTP v1.1 может разрешать нескольким запросам повторное использование одного соединения, обычно будут небольшие периоды таймаута, предназначенные для управления потреблением ресурсов.

Возможно, вы используете HTTP неправильно, если...

Ваш дизайн зависит от того, как клиент часто звонит в службу, без участия пользователя.
Для вашего дизайна требуются частые служебные вызовы для отправки небольших сообщений.
Клиент должен быстро реагировать на изменение ресурса и не может предсказать, когда произойдет изменение.
Результирующий дизайн не зависит от стоимости. Спросите себя: решение WebSocket существенно меньше усилий для проектирования, внедрения, тестирования и работы?

WebSockets

Конструкция WebSocket не позволяет явным или прозрачным прокси-серверам кэшировать сообщения, что может ухудшить производительность клиента.
Протокол WebSocket предлагает поддержку только для сценариев ошибок, влияющих на установление соединения. После установления соединения и обмена сообщениями любые дополнительные сценарии ошибок должны быть рассмотрены в дизайне слоя обмена сообщениями, но WebSockets позволяют повысить эффективность по сравнению с REST, поскольку для каждого отправляемого сообщения не требуются служебные данные HTTP/и получил.
Когда клиенту необходимо быстро реагировать на изменение (особенно это невозможно предсказать), лучше всего использовать WebSocket.
Это делает протокол хорошо подходящим для сценариев "пожара и забывания" и плохо подходит для транзакционных требований.
WebSockets были разработаны специально для долговременных сценариев подключения, они избегают накладных расходов на установление соединений и отправку заголовков HTTP-запросов/ответов, что приводит к значительному увеличению производительности.

Возможно, вы используете WebSockets неправильно, если..

Соединение используется только для очень небольшого количества событий или очень небольшого количества времени, а клиенту нет - нужно быстро реагировать на события.
Ваша функция требует одновременного открытия нескольких WebSockets для одной и той же службы.
Ваша функция открывает WebSocket, отправляет сообщения, затем закрывает его, затем повторяет этот процесс позже.
Вы повторно реализуете шаблон запроса/ответа на уровне обмена сообщениями.
Результирующий дизайн не зависит от стоимости. Спросите себя: Является ли решение HTTP существенно меньше усилий для проектирования, внедрения, тестирования и работы?

Ссылка: https://blogs.windows.com/buildingapps/2016/03/14/when-to-use-a-http-call-instead-of-a-websocket-or-http-2-0/