HTTP Keep-Alive和Websockets之间的行为差异是什么？

Question

49

最近我一直在深入研究WebSockets。创建了自己的服务器，还有一个公共演示。虽然我在HTTP方面没有如此详细的经验或知识（尽管由于WebSocket请求被升级为HTTP请求，所以我有一些）。

在我的服务器端，它会记录每个请求的详细信息，其中包括一堆HTTP保持活动的请求。我的服务器不处理它们，因为它们不是WebSocket请求。但这引起了我的好奇心。

WebSockets的整个大事情就是连接保持活动状态。然后你可以在两个方向（甚至同时）传递消息。我读到过Keep-Alive HTTP连接是相对较新的发展（我不知道在人类时间中有多少年，只知道它只包含在最新的标准1.1中，现在是否已经老了？）

我想我可以假设两者之间有行为上的区别，否则就没有websocket标准的理由了？它们之间有什么区别呢？

- Roger F. Gay

3个回答

9

你应该了解COMET，这是一种设计模式，展示了HTTP Keep-Alive的局限性。Keep-Alive现在已经超过12年了，因此它不是HTTP的新特性。问题在于它不够充分；客户端和服务器不能真正地异步通信。客户端必须始终使用“挂起”请求才能从服务器获取消息；服务器可能不能随时向客户端发送消息。

- EricLaw

8

HTTP vs Websockets

REST (HTTP)

以下情况可能意味着您使用HTTP有误:

WebSockets

WebSocket设计不允许显式或透明代理缓存消息，这可能会降低客户端性能。
WebSocket协议仅支持影响连接建立的错误场景。一旦建立连接并交换消息，任何其他错误场景都必须在消息层面设计中解决，但WebSockets允许比REST更高的效率，因为它们不需要每个发送和接收的消息的HTTP请求/响应开销。
当客户端需要快速响应更改（特别是无法预测的更改）时，WebSocket可能最适合。
这使得该协议非常适合用于“fire and forget”消息场景，并且对于事务要求并不太适用。
WebSockets专门为长时间连接场景而设计，避免了建立连接和发送HTTP请求/响应头的开销，从而大大提高了性能。

以下情况可能意味着您使用WebSockets有误:

当需要进行单向通信或定期轮询时，HTTP调用是一个不错的选择。但是，在需要双向通信或实时数据传输时，WebSocket或HTTP 2.0是更好的选择。这是因为HTTP调用在每次请求和响应之间都要建立新的连接，而WebSocket和HTTP 2.0可以保持长时间连接并实时传输数据。

- A Qadeer Qureshi

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Zarick Lau · Accepted Answer

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

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