HTTP Keep-Alive 和 Websockets 之间的行为区别是什么？答案

【问题标题】：What's the behavioral difference between HTTP Keep-Alive and Websockets?HTTP Keep-Alive 和 Websockets 之间的行为区别是什么？
【发布时间】：2011-11-29 01:19:30
【问题描述】：

我最近一直在详细使用 websockets。创建了我自己的服务器，并且有一个public demo。我没有这么详细的经验或知识：http。（虽然由于websocket请求是升级的http请求，我也有一些。）

在我这边，服务器会报告每次点击的详细信息。其中有一堆http keep-alive请求。我的服务器不处理它们，因为它们不是 websocket 请求。但这引起了我的好奇心。

websockets 的最大特点是连接保持活跃。然后你可以在两个方向传递消息（同时甚至）。我读过 Keep-Alive HTTP 连接是一个相对较新的发展（我不知道人们用了多少年，只是它只包含在最新的标准 - 1.1 - 现在真的旧了吗？）

我想我可以假设两者之间存在行为差异，或者没有理由制定 websocket 标准？有什么区别？

【问题讨论】：

标签： http websocket

【解决方案1】：

自 HTTP 1.0 以来的 Keep Alive HTTP 标头，用于指示 HTTP 客户端希望与 HTTP 服务器保持持久连接。主要目的是消除为每个 HTTP 请求打开 TCP 连接的需要。然而，虽然有一个持久连接打开，但客户端和服务器之间的通信协议仍然遵循基本的 HTTP 请求/响应模式。换句话说，服务器端无法将数据推送到客户端。

WebSocket 是完全不同的机制，用于建立持久的全双工连接。通过这种全双工连接，服务器端可以将数据推送到客户端，并且客户端应该可以随时处理来自服务器端的数据。

引用维基百科上的相应条目以供参考： 1)http://en.wikipedia.org/wiki/HTTP_persistent_connection 2)http://en.wikipedia.org/wiki/WebSocket

【讨论】：

好的。这正是我的按钮。即使使用保持活动连接，HTTP 仍然是请求/响应。 Websockets 摇滚！
为什么他们不添加一个功能/可能是 HTTP 本身的标头，这会使它的行为类似于本机 TCP 连接，其中任何一方（发送方/接收方）可以随时发送任意次数?他们是否引入了新的协议 WebSocket 事实！只是为了实现这一点，“HTTP on Steroids”使用升级选项，一旦使用普通 HTTP 机制设置初始握手（TCP）？
该委员会最初是作为一个 HTTP 委员会开始的，但 WebSocket 人们想要的东西太不同了，他们决定拆分。 WebSocket 协议握手确实以 HTTP 请求开始，其中“升级”参数设置为“Websocket”。
您所说的“主要目标是消除......”，您的意思是“主要目标是消除......”吗？
但是既然是持久连接，那是不是意味着即使数据不符合 HTTP 协议的格式，你仍然可以发送任何内容？

【解决方案2】：

您应该阅读COMET，这是一种显示 HTTP Keep-Alive 限制的设计模式。 Keep-Alive 现在已经超过 12 年了，所以它不是 HTTP 的新特性。问题是这还不够。客户端和服务器无法以真正异步的方式进行通信。客户端必须始终使用“挂起”请求才能从服务器获取消息；服务器可能不会随时向客户端发送消息。

【讨论】：

【解决方案3】：

HTTP 与 Websockets

REST (HTTP)

当资源的表示很少更改或期望多个客户端检索资源时，资源将从缓存中受益。
HTTP 方法具有众所周知的幂等性和安全性。如果可以多次发出请求而不会产生唯一的结果，则该请求是“幂等的”。
HTTP 设计允许响应描述请求、资源的错误，或提供细微的状态信息以区分成功场景。
具有请求和响应功能。
HTTP v1.1 可能允许多个请求重用单个连接，通常会有一小段超时时间来控制资源消耗。

如果...

，您可能会错误地使用 HTTP

您的设计依赖于客户端经常轮询服务，而不需要用户采取行动。
您的设计需要经常调用服务来发送小消息。
客户端需要对资源的更改快速做出反应，并且无法预测更改何时发生。
由此产生的设计成本过高。问问自己：WebSocket 解决方案的设计、实施、测试和操作工作量是否大大减少？

WebSockets

WebSocket 设计不允许显式或透明代理缓存消息，这会降低客户端性能。
WebSocket 协议仅支持影响连接建立的错误场景。建立连接并交换消息后，必须在消息层设计中解决任何额外的错误场景，但与 REST 相比，WebSockets 允许更高的效率，因为它们不需要发送的每条消息的 HTTP 请求/响应开销并收到。
当客户端需要对更改（尤其是无法预测的更改）做出快速反应时，WebSocket 可能是最好的选择。
这使得该协议非常适合“即发即弃”的消息传递场景，但不适合事务性要求。
WebSocket 专为长期连接场景而设计，它们避免了建立连接和发送 HTTP 请求/响应标头的开销，从而显着提升了性能

如果出现以下情况，您可能会错误地使用 WebSockets..

该连接仅用于极少数事件或极少的时间，客户端不需要快速响应事件。
您的功能需要同时向同一个服务打开多个 WebSocket。
您的功能打开一个 WebSocket，发送消息，然后关闭它，然后重复这个过程。
您正在消息层中重新实现请求/响应模式。
由此产生的设计成本过高。问问自己：HTTP 解决方案的设计、实施、测试和操作工作量是否大大减少？

参考：https://blogs.windows.com/buildingapps/2016/03/14/when-to-use-a-http-call-instead-of-a-websocket-or-http-2-0/

【讨论】：