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

Question

我最近一直在研究websockets.创建了我自己的服务器,并有一个公共演示.我没有这样详细的经验或知识重新:http.(虽然因为websocket请求是升级的http请求,所以我有一些.)

在我的结尾,服务器报告每个命中的细节.其中包括一堆http keep-alive请求.我的服务器不处理它们,因为它们不是websocket请求.但它让我的好奇心得到了提升.

websockets的重要一点是连接保持活跃.然后你可以在两个方向传递消息(同时甚至).我已经读过,Stay-Alive HTTP连接是一个相对较新的开发(我不知道人们有多少年的时间,只是它只包含在最新的标准中 - 1.1 - 现在真的老了吗？)

我想我可以假设两者之间存在行为差异,或者没有理由选择websocket标准？有什么不同？

Answer 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

Answer 2

您应该阅读COMET,这是一种显示HTTP Keep-Alive限制的设计模式.Keep-Alive现在已超过12年,因此它不是HTTP的新功能.问题是它还不够; 客户端和服务器无法以真正的异步方式进行通信.客户端必须始终使用"挂起"请求才能从服务器返回消息; 服务器可能不只是在任何时候向客户端发送消息.

Answer 3

HTTP 与 Websockets

休息 (HTTP)

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

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

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

网络套接字

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