在 Jetty 页面 https://webtide.com/why-choose-jetty/ 的 吞吐量 部分中显示：
我们设计的 Jetty 可在许多同时连接的实际负载下实现可扩展性能，并且我们可以通过数万个 HTTP 连接和数十万个同时 WebSocket 连接实现出色的结果。
那么，这两种协议的实现有什么不同，Jetty 是如何处理只有数万个 HTTP 连接和数量级更多的 WebSocket 连接的呢？ WebSocket 连接是否更便宜？怎么可能？如果 HTTP 和 WebSocket 实现都使用 Java NIO（只是猜测），那么为什么会有性能差异呢？
【问题讨论】：
标签： performance http websocket jetty throughput
如果您测量它们的共同点，例如每秒发送消息，您只能将 webSocket 连接与 HTTP 连接进行真正的比较。如果你这样做，那么 webSocket 在带宽和网络流量方面都具有巨大优势，因为它是一个已经建立的连接，而 http 连接必须为每条消息从头开始重新建立，并且为每条消息建立该连接具有成本。
为了建立连接，webSocket 连接和 http 连接都需要大量开销。至少，建立 TCP 连接的 TCP 开销看起来有点像这样：
此外，典型的 HTTP 请求还会包含一些开销，例如 cookie 和其他标头。
然而，webSocket 连接只执行一次，然后保持连接打开，因此以后的消息可以直接通过该连接发送。 HTTP 连接是暂时的，它已连接，发送数据，收到响应，然后断开连接。如果您需要发送另一个请求，则必须从头开始建立另一个 HTTP 连接。
虽然 HTTP 连接的无状态特性非常适合客户端仅偶尔发出请求并且经常向不同服务器发出请求的情况，但如果给定客户端向同一主机发出大量请求，则它并不理想。在这种情况下，建立一个连接，保持该连接打开，然后在需要时通过该现有连接发送消息会更有效。
鉴于您提到的文章的一般背景和它讨论的其他方面，看来这种差异是该文章在提到可伸缩性差异时所指的内容。
这是另一个相关的答案：Ajax vs Socket.io
【讨论】：