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

Question

我最近一直在使用websockets。创建了我自己的服务器，有一个public demo。我没有这样详细的经验或知识重新：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

REST（HTTP）

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

如果......

，您可能错误地使用了HTTP

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

<强>的WebSockets

• WebSocket设计不允许显式或透明代理缓存消息，这会降低客户端性能。
• WebSocket协议仅支持影响连接建立的错误情况。建立连接并交换消息后，必须在消息传递层设计中解决任何其他错误情况，但与REST相比，WebSockets允许更高的效率，因为它们不需要为每个发送的消息提供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/