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

发布于 2024-12-08 04:25:40 字数 452 浏览 0 评论 0 原文

我最近一直在详细研究 websockets。创建了我自己的服务器，并且有一个公共演示。我没有如此详细的经验或知识：http。（尽管由于 websocket 请求是升级的 http 请求，所以我有一些。）

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

Websocket 的最大特点是连接保持活动状态。然后您可以双向（甚至同时）传递消息。我读到，Keep-Alive HTTP 连接是一个相对较新的发展（我不知道人们的时间有多少年，只是它只包含在最新的标准 - 1.1 - 现在真的很旧吗？）

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

℡Ms空城旧梦 2024-12-15 04:25:40

自 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

回复收藏 0 原文

疧_╮線 2024-12-15 04:25:40

HTTP 与 Websockets

REST (HTTP)

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

如果...，您可能会错误地使用 HTTP...

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

WebSocket

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

如果...，您可能会错误地使用

WebSocket仅用于极少量的事件，或极少量的时间，并且客户端不需要对事件快速做出反应。
您的功能需要同时向同一服务开放多个 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/

HTTP vs Websockets

REST (HTTP)

Resources benefit from caching when the representation of a resource changes rarely or multiple clients are expected to retrieve the resource.
HTTP methods have well-known idempotency and safety properties. A request is “idempotent” if it can be issued multiple times without resulting in unique outcomes.
The HTTP design allows for responses to describe errors with the request, with the resource, or to provide nuanced status information to differentiate between success scenarios.
Have request and response functionality.
HTTP v1.1 may allow multiple requests to reuse a single connection, there will generally be small timeout periods intended to control resource consumption.

You might be using HTTP incorrectly if…

Your design relies on a client polling the service often, without the user taking action.
Your design requires frequent service calls to send small messages.
The client needs to quickly react to a change to a resource, and it cannot predict when the change will occur.
The resulting design is cost-prohibitive. Ask yourself: Is a WebSocket solution substantially less effort to design, implement, test, and operate?

WebSockets

WebSocket design does not allow explicit or transparent proxies to cache messages, which can degrade client performance.
WebSocket protocol offers support only for error scenarios affecting the establishment of the connection. Once the connection is established and messages are exchanged, any additional error scenarios must be addressed in the messaging layer design, but WebSockets allow for a higher amount of efficiency compared to REST because they do not require the HTTP request/response overhead for each message sent and received.
When a client needs to react quickly to a change (especially one it cannot predict), a WebSocket may be best.
This makes the protocol well suited to “fire and forget” messaging scenarios and poorly suited for transactional requirements.
WebSockets were designed specifically for long-lived connection scenarios, they avoid the overhead of establishing connections and sending HTTP request/response headers, resulting in a significant performance boost

You might be using WebSockets incorrectly if..

The connection is used only for a very small number of events, or a very small amount of time, and the client does not - need to quickly react to the events.
Your feature requires multiple WebSockets to be open to the same service at once.
Your feature opens a WebSocket, sends messages, then closes it—then repeats the process later.
You’re re-implementing a request/response pattern within the messaging layer.
The resulting design is cost-prohibitive. Ask yourself: Is a HTTP solution substantially less effort to design, implement, test, and operate?

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

回复收藏 0 原文

内心激荡 2024-12-15 04:25:40

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