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

Question

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

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

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

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

Answer 1

HTTP-заголовок Keep Alive начиная с 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

Answer 2

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

Answer 3

HTTP против веб-сокетов

REST (HTTP)

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

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

• Ваш дизайн полагается на то, что клиент часто опрашивает службу, и пользователь не предпринимает никаких действий.
• Ваш дизайн требует частых сервисных звонков для отправки небольших сообщений.
• Клиент должен быстро реагировать на изменение ресурса и не может предсказать, когда произойдет изменение.
• Полученный дизайн является непомерно дорогим. Задайте себе вопрос: является ли решение WebSocket значительно меньшими усилиями для проектирования, реализации, тестирования и эксплуатации?

WebSockets

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

Возможно, вы неправильно используете 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/