Performance 码头腹板箱性能

在吞吐量部分的Jetty页面上显示：

我们已经设计了Jetty，以便在多个同时连接的实际负载下实现可扩展性能，并且我们可以通过数万个HTTP连接和数十万个同时WebSocket连接实现出色的效果

---

那么，这两个协议的实现有什么不同呢？Jetty如何只处理数万个HTTP连接以及更多的WebSocket连接？WebSocket连接是否更便宜？怎么可能？如果HTTP和WebSocket实现都使用Java NIO（只是猜测），那么为什么性能会有差异呢？

只有在测量WebSocket连接和HTTP连接的共同点（例如每秒发送消息）时，才能真正比较它们。如果您这样做，那么webSocket在带宽和网络流量方面都有巨大的优势，因为它是一个已经建立的连接，而http连接必须从头开始为每条消息重新建立，并且为每条消息建立连接要付出代价

为了建立连接，webSocket连接和http连接都有大量开销。至少，建立TCP连接的TCP开销有点像这样：

归功于

此外，典型的HTTP请求还将包括一些开销，如cookie和其他头

然而，webSocket连接只执行一次，然后保持连接打开，以便将来的消息可以直接通过该连接发送。HTTP连接是暂时的，它被连接，数据被发送，响应被接收，然后连接被断开。如果需要发送另一个请求，则必须从头建立另一个HTTP连接

虽然HTTP连接的无状态特性对于客户端偶尔发出请求并且经常向不同的服务器发出请求的情况非常有用，但如果给定的客户端向同一主机发出大量请求，这并不理想。在这种情况下，建立一个连接，保持该连接处于打开状态，然后在需要时通过现有连接发送消息，效率会更高

考虑到您所提到的文章的一般背景以及它所讨论的其他方面，在提到可伸缩性方面的差异时，这一差异似乎就是本文所指的

---

这是另一个相关的答案：

是的，但在我提到的文章中，他们谈到了同步HTTP和WebSocket连接，因此，如果不是如您所述的数据带宽，那么为什么他们可以建立比HTTP更多的同步WebSocket连接，由于HTTP和WebSocket连接都依赖于TCP，Jetty仍然必须处理来自客户端的每个请求，无论是HTTP还是WebSocket。