参考文档的这一部分涵盖了对 Servlet 堆栈 WebSocket 的支持 消息传递,包括原始 WebSocket 交互、通过 SockJS 进行的 WebSocket 仿真,以及 通过 STOMP 作为 WebSocket 上的子协议发布-订阅消息传递。
WebSocket简介
WebSocket 协议 RFC 6455 提供了一个标准化的 在客户端和服务器之间建立全双工、双向通信通道的方法 通过单个 TCP 连接。它是一种与 HTTP 不同的 TCP 协议,但旨在 通过 HTTP 工作,使用端口 80 和 443,并允许重用现有防火墙规则。
WebSocket 交互从使用 HTTP 标头的 HTTP 请求开始
升级,或者在本例中切换到 WebSocket 协议。以下示例
显示这样的交互:Upgrade
GET /spring-websocket-portfolio/portfolio HTTP/1.1
Host: localhost:8080
Upgrade: websocket (1)
Connection: Upgrade (2)
Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg==
Sec-WebSocket-Protocol: v10.stomp, v11.stomp
Sec-WebSocket-Version: 13
Origin: http://localhost:8080
1 | 标头。Upgrade |
2 | 使用连接。Upgrade |
支持 WebSocket 的服务器返回输出,而不是通常的 200 状态代码 类似于以下内容:
HTTP/1.1 101 Switching Protocols (1)
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0=
Sec-WebSocket-Protocol: v10.stomp
1 | 协议交换机 |
握手成功后,HTTP 升级请求的基础 TCP 套接字将保留 为客户端和服务器打开以继续发送和接收消息。
WebSocket 工作原理的完整介绍超出了本文档的范围。 请参阅 RFC 6455、HTML5 的 WebSocket 章节或许多介绍和 Web 上的教程。
请注意,如果 WebSocket 服务器在 Web 服务器(例如 nginx)后面运行,则 可能需要将其配置为将 WebSocket 升级请求传递到 WebSocket 服务器。同样,如果应用程序在云环境中运行,请选中 云提供商与 WebSocket 支持相关的说明。
HTTP 与 WebSocket
即使 WebSocket 被设计为与 HTTP 兼容并且以 HTTP 请求开头, 重要的是要了解这两种协议导致非常不同 体系结构和应用程序编程模型。
在 HTTP 和 REST 中,应用程序被建模为多个 URL。要与应用程序交互, 客户端访问这些 URL,请求-响应样式。服务器将请求路由 基于 HTTP URL、方法和标头的适当处理程序。
相比之下,在 WebSocket 中,初始连接通常只有一个 URL。 随后,所有应用程序消息都在同一 TCP 连接上流动。这指向 一个完全不同的异步、事件驱动的消息传递体系结构。
WebSocket 也是一种低级传输协议,与 HTTP 不同,它没有规定 消息内容的任何语义。这意味着没有办法路由或处理 除非客户端和服务器在消息语义上达成一致,否则消息。
WebSocket 客户端和服务器可以协商使用更高级别的消息传递协议
(例如,STOMP),通过 HTTP 握手请求上的标头。
如果没有这一点,他们需要提出自己的惯例。Sec-WebSocket-Protocol
何时使用 WebSocket
WebSocket 可以使网页具有动态性和交互性。但是,在许多情况下, AJAX 和 HTTP 流式处理或长轮询的组合可以提供简单且 有效的解决方案。
例如,新闻、邮件和社交源需要动态更新,但可能需要动态更新 每隔几分钟就这样做是完全可以的。协作、游戏和金融应用,在 另一方面,需要更接近实时。
延迟本身并不是决定性因素。如果消息量相对较低(例如, 监控网络故障)HTTP 流式处理或轮询可以提供有效的解决方案。 低延迟、高频率和高音量的结合才能发挥最佳效果 使用 WebSocket 的案例。
还要记住,在互联网上,您无法控制的限制性代理
可能会阻止 WebSocket 交互,因为它们未配置为传递标头,或者因为它们关闭了看似空闲的长期连接。这
意味着将 WebSocket 用于防火墙内的内部应用程序是一个
与面向公众的应用程序相比,它更直接。Upgrade