使用 Comet/持久 HTTP 连接时，客户端和后端有哪些缺点？
我正在开发一个需要向最终用户实时更新的应用程序。 但是，我不确定持久 HTTP 连接的后果。 浏览器是否限制一个人可以拥有的连接数？ 后端服务器有几千个长连接可以吗？ 如果我不使用 jetty 之类的东西来管理所有这些连接，会发生什么？
I am developing an application which requires real-time updates to the end user. However, I am not sure of the consequences of having a persistent HTTP connection. Does the browser limit the number of connections one can have? Is it alright for the back end server to have thousands of persistent connections? What happens if I don't use something like jetty to manage all these connections?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，浏览器限制连接数。 对于 IE6，此限制为每个服务器两个，这是相当严格的。 不过，也有解决方法。
这里有一篇关于规避 HTTP 连接限制的好文章： 为了乐趣和利润而规避浏览器连接限制。
正如您提到的，服务器上还存在可扩展性问题。 考虑每个持久 HTTP 连接都会占用服务器上的一个 TCP 端口。 因此，每个 TCP 地址的端口数是服务器具有的每个 IP 地址的理论上限。 由于您的服务器可以有多个 IP 地址，因此可扩展性更可能受到硬件本身的限制。
Yes, the browser limits the number of connections. For IE6, this limit is two per server, which is quite restrictive. There are workarounds, however.
Here's a good article on circumventing the HTTP connection limits: Circumventing browser connection limits for fun and profit.
There is also the question of scalability on the server, as you mention. Consider that each persistent HTTP connection would occupy a TCP port on the server. So, the number of ports per TCP address is a theoretical upper bound for the server, per IP address the server has. Since you can have multiple IP addresses for your server, the more likely limit to scalability will be the hardware itself.