使用 WebSockets 是否有服务器成本? [英] Is there a server cost to using WebSockets?
问题描述
我一直在远离 PHP/MySQL 的舒适区，因为语法/封装/程序的东西可能会令人沮丧.
上周，我开始尝试并按照一些教程使用 Node.js/Socket.IO 创建实时聊天应用程序.到目前为止，我从未对 WebSockets 做过任何事情，而且它们看起来真的很酷——服务器和客户端之间的即时通信非常棒.
现在，请原谅我在这里缺乏理解，但是 HTTP 的设置使您不应该能够在客户端和服务器之间保持连接打开——我对 Comet 的基本理解是它强制连接到通过从不终止写入流并仅发送 NUL 字节来保持打开状态.这听起来……服务器密集型.
WebSockets 是如何工作的呢?如果我的聊天应用程序上同时有几百人，服务器会不会过载?当我在服务器上使用 PHP/MySQL 时，服务器一次只处理一个请求——如果我使用 AJAX 和轮询，比如说，每一秒，我想它会迅速升级，因为你有成千上万一分钟的请求数.
我的问题是，WebSockets 是否适用于大型应用程序?没有真正高带宽的服务器是否可行?
我想这归结为:频繁间隔的 AJAX 轮询、Comet 和 WebSockets 之间是否存在显着的服务器负载/用户体验差异?
谢谢！
有很多很好的概述站点可以阅读有关 websocket 通常如何工作的信息，例如 此处 和此处.>
简而言之，它们以某种类型的 HTTP 请求发起连接，然后在客户端和服务器之间建立直接的 TCP 双向连接.
维护客户端的开放套接字会产生一些服务器开销，因此如果您预计一次有数以万计的套接字，则必须确保您的服务器基础设施能够达到这种规模.CPU 负载只会与在任何给定时间有多少插槽忙成正比，因为空闲插槽不占用任何 CPU.
<块引用>使用 WebSocket 是否需要服务器成本?
这实际上取决于您将其与什么进行比较.当服务器需要能够在数据可用时将数据发送到客户端时，通常使用 webSockets(通常称为服务器推送").使用连续连接的 webSocket 的通常替代方法是让客户端重复轮询，一遍又一遍地询问服务器服务器是否有任何新内容.如果将 webSocket 与重复的客户端轮询进行比较，那么 webSocket 通常更高效，并且与频繁轮询客户端相比，使用 webSocket 可以更大程度地扩展服务器.
可以正确配置服务器以支持数十万个同时(并且大部分是空闲的)webSocket 连接，这样服务器的可扩展性限制就受到您发送到所有这些连接客户端的流量的限制.如果您每隔几秒钟就向客户端发送数据，并且您有数十万个连接的客户端，那么使用任何技术都需要大量的服务器马力(和带宽)才能做到这一点，而 webSockets 仍然可能比任何技术都要好竞争技术.但是，如果 webSocket 连接的客户端大多只是闲置，并且只是偶尔向它们发送数据，那么 webSocket 实现可以非常有效地扩展.
以下是有关该主题的其他一些参考资料:
<小时>Comet 库尝试支持类似 WebSocket 的接口，即使没有直接的 WebSocket 支持.这是一些低效的黑客开始出现的地方，因为它试图通过保持开放的 HTTP 连接来模拟双向 TCP 套接字.如果您使用的是真正的 WebSockets，这不是问题.
I've been moving away from my comfort zone in PHP/MySQL because the syntax/encapsulation/procedural stuff can get frustrating.
Last week, I started played around and followed some tutorials to use Node.js/Socket.IO to create a live chat application. Up until this point, I've never done anything with WebSockets, and they seem really cool -- instant communication between server and client is awesome.
Now, forgive my lack of understanding here, but HTTP is set up so that you aren't supposed to be able to keep connections open between client and server -- and my rudimentary understanding of Comet is that it forces the connection to remain open by never terminating the write stream and just sending NUL bytes. This sounds... server-intensive.
How do WebSockets work, then? If I had a couple hundred people on my chat app at once, wouldn't the server be overloaded? When I use PHP/MySQL on a server, the server only processes one request at a time -- and if I were to use AJAX and poll, say, every one second, I imagine that it would escalate quickly as you'd have thousands of requests a minute.
My question is, do WebSockets scale for large applications? Is it practical without having a really high-bandwidth server?
I guess it comes down to: is there a significant server load/user experience difference between AJAX polling at a frequent interval, Comet, and WebSockets?
Thanks!
There are lots of good overview sites to read about how websockets generally work like here and here.
In a nutshell, they initiate a connection with a certain type of HTTP request and then after that, they are a direct TCP bi-directional connection between client and server.
There is some server overhead to maintain an open socket to a client so if you were anticipating tens of thousands of these at once, you would have to make sure your server infrastructure was capable of that scale. The CPU load would only be proportional to how many sockets were busy at any given time as an idle socket doesn't take any CPU.
Is there a server cost to using WebSockets?
It really depends upon what you're comparing it to. webSockets are typically used when the server needs to be able to send data to a client when the data comes available (often called "server push"). The usual alternative to using a continuously connected webSocket is to have the client polling repeatedly, asking the server over and over if the server has anything new. If you compare a webSocket to repeated client polling, then the webSocket is generally way, way more efficient and you could scale your server a lot higher using webSockets than with frequently polling clients.
Servers can be properly configured to support hundreds of thousands of simultaneous (and mostly idle) webSocket connections such that the server scalability limit is limited by how much traffic you're sending to all these connected clients. If you're sending data to a client every few seconds and you have hundreds of thousands of connected clients, then that will take a lot of server horsepower (and bandwidth) to do that with any technology and webSockets would still likely be better than any competing technology. But, if webSocket connected clients are mostly just idle and data is just occasionally sent to them, then a webSocket implementation can scale hugely and efficiently.
Here are some other references on the topic:
websocket vs rest API for real time data?
Websocket vs REST when sending data to server
Why to use websocket and what is the advantage of using it?
HTML5 WebSocket: A Quantum Leap in Scalability for the Web
Push notification | is websocket mandatory?
The Comet library attempts to support a WebSocket-like interface, even when there is no direct WebSocket support. This is where the somewhat inefficient hacks start showing up as it tries to simulate a bi-directional TCP socket by keeping an open HTTP connection. If you are using real WebSockets, this is not an issue.
这篇关于使用 WebSockets 是否有服务器成本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
