Web 套接字使用大量资源，如彗星长轮询？
我知道 Comet 长轮询对 Web 服务器不利，因为它们每个连接占用一个线程。因此，您不能让大量用户保持持续连接，否则您的 Web 服务器将崩溃。
这与 HTML 5 中的 Web 套接字相同吗？
如果每个持久连接也占用一个线程，这怎么解决资源问题呢？
I know that Comet long polling are bad for Web servers because they occupy one thread per connection. So you cannot have a lot of users with persistent connections or your web server will crash.
Is this the same with web sockets in HTML 5?
How could this solve the resource problem if it occupies one thread too per persistent connection?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这种假设完全不正确。请参阅我在此处给出的答案 了解更多信息。 （例如）完全可以在 IIS 中使用 IAsyncHttpHandler 来执行长轮询，而不为每个客户端使用线程。
This assumption is totally untrue. See the answer I gave here for more info. It is (for instance) entirely possible to use IAsyncHttpHandler in IIS to perform long-polling, without using a thread per client.
Spender 是正确的，只有糟糕的 Web 服务器（例如带有 mpm_worker 或 mpm_prefork 的 Apache）每个连接使用一个线程/进程。
智能 Comet 或 Websockets 网关（我不久前写过这样一个）将具有事件驱动的架构 - 要么基于 Proactor（具有固定的线程池），要么基于 Reactor（单线程）模式。长轮询应该通过保持活动的 HTTP 连接来完成（对于支持该连接的浏览器 - 大约 99%），在这种情况下，它将具有与 Websockets 类似的性能/可扩展性特征。
Spender is correct, only shitty web servers (e.g. Apache with mpm_worker or mpm_prefork) use a thread/process per connection.
A smart Comet or Websockets gateway (I wrote such one not long ago) will have an event-driven architecture - either based on the Proactor (with a fixed pool of threads) or Reactor (single-threaded) patterns. Long-polling should be done over keep-alive HTTP connections (for the browsers which support that - about 99% of them), in which case it will have similar performance/scalability characteristics as Websockets.