由于 webSockets 的启动方式(从 HTTP 请求开始，然后重新利用该套接字)，它们与现有网络基础设施 100% 兼容，甚至可以在与现有网络请求相同的端口上运行(例如端口 80 或第 443 章这使得跨域安全变得更简单，并使客户端或服务器端基础架构上的任何人都不必修改任何基础架构以支持 webSocket 连接.这项新技术背后的算法是什么(与长轮询)?本文很好地总结了 webSocket 连接算法和 webSocket 数据格式的工作原理:编写 WebSocket 服务器.它们在性能方面如何比长轮询更好?就其本质而言，长轮询有点像黑客.之所以发明它，是因为没有更好的替代方案可以将服务器启动的数据发送到客户端.以下是步骤:客户端向客户端发出对新数据的 http 请求.如果服务器有一些新数据，它会立即返回该数据，然后客户端发出另一个 http 请求以请求更多数据.如果服务器没有新数据，那么它只是挂在连接上一段时间而不提供响应，使请求挂起(套接字已打开，客户端正在等待响应).如果在请求仍处于待处理状态的任何时候，服务器获取了一些数据，那么它会将这些数据形成一个响应并为待处理的请求返回一个响应.如果一段时间内没有数据传入，那么最终请求将超时.届时，客户端将意识到没有返回新数据，并开始一个新请求.冲洗、起泡、重复.返回的每条数据或挂起请求的每个超时之后都会跟随着来自客户端的另一个 ajax 请求.因此，虽然 webSocket 使用一个长期存在的套接字，客户端或服务器可以通过该套接字向另一个发送数据，但长轮询包括客户端询问服务器你还有更多数据给我吗?"一遍又一遍，每个都有一个新的 http 请求.如果做得好，长轮询会起作用，只是在服务器基础设施、带宽使用、移动电池寿命等方面效率低下...我想要的是对此的解释:Websockets 保持一个C/S 之间的开放连接与长轮询等待不太一样过程?换句话说，为什么 Websockets 不会使服务器过载?在客户端和服务器之间维护一个开放的 webSocket 连接对于服务器来说是一件非常便宜的事情(它只是一个 TCP 套接字).不活动但打开的 TCP 套接字不占用服务器 CPU，只需要很少量的内存来跟踪套接字.正确配置的服务器一次可以容纳数十万个打开的套接字.另一方面，进行长轮询的客户端，即使没有新信息发送给它，也必须定期重新建立连接.每次重新建立新连接时，都会有 TCP 套接字拆卸和新连接，然后是传入的 HTTP 请求需要处理.这里有一些关于缩放主题的有用参考:600kAWS 上使用 Node.js 的并发 websocket 连接Node.js w/1M 并发连接！ HTML5 WebSocket:Web 可扩展性的巨大飞跃 HTML WebSockets 是否为每个客户端维护一个开放的连接?这个规模吗?How Websockets are implemented?What is the algorithm behind this new tech (in comparison to Long-Polling)?How can they be better than Long-Polling in term of performance?I am asking these questions because here we have a sample code of Jetty websocket implementation (server-side).And that is definately the problem I'm facing when using Long-polling. It stops the process to prevent server overload, doesn't it ? 解决方案 webSockets are implemented as follows:Client makes HTTP request to server with "upgrade" header on the requestIf server agrees to the upgrade, then client and server exchange some security credentials and the protocol on the existing TCP socket is switched from HTTP to webSocket.There is now a lasting open TCP socket connecting client and server.Either side can send data on this open socket at any time.All data must be sent in a very specific webSocket packet format.Because the socket is kept open as long as both sides agree, this gives the server a channel to "push" information to the client whenever there is something new to send. This is generally much more efficient than using client-driven Ajax calls where the client has to regularly poll for new information. And, if the client needs to send lots of messages to the server (perhaps something like a mnulti-player game), then using an already open socket to send a quick message to the server is also more efficient than an Ajax call.Because of the way webSockets are initiated (starting with an HTTP request and then repurposing that socket), they are 100% compatible with existing web infrastructure and can even run on the same port as your existing web requests (e.g. port 80 or 443). This makes cross-origin security simpler and keeps anyone on either client or server side infrastructure from having to modify any infrastructure to support webSocket connections.There's a very good summary of how the webSocket connection algorithm and webSocket data format works here in this article: Writing WebSocket Servers.By its very nature, long-polling is a bit of a hack. It was invented because there was no better alternative for server-initiated data sent to the client. Here are the steps:The client makes an http request for new data from the client.If the server has some new data, it returns that data immediately and then the client makes another http request asking for more data. If the server doesn't have new data, then it just hangs onto the connection for awhile without providing a response, leaving the request pending (the socket is open, the client is waiting for a response).If, at any time while the request is still pending, the server gets some data, then it forms that data into a response and returns a response for the pending request.If no data comes in for awhile, then eventually the request will timeout. At that point, the client will realize that no new data was returned and it will start a new request.Rinse, lather, repeat. Each piece of data returned or each timeout of a pending request is then followed by another ajax request from the client.So, while a webSocket uses one long-lived socket over which either client or server can send data to the other, the long-polling consists of the client asking the server "do you have any more data for me?" over and over and over, each with a new http request.Long polling works when done right, it's just not as efficient on the server infrastructure, bandwidth usage, mobile battery life, etc...Maintaining an open webSocket connection between client and server is a very inexpensive thing for the server to do (it's just a TCP socket). An inactive, but open TCP socket takes no server CPU and only a very small amount of memory to keep track of the socket. Properly configured servers can hold hundreds of thousands of open sockets at a time.On the other hand a client doing long-polling, even one for which there is no new information to be sent to it, will have to regularly re-establish its connection. Each time it re-establishes a new connection, there's a TCP socket teardown and new connection and then an incoming HTTP request to handle.Here are some useful references on the topic of scaling:600k concurrent websocket connections on AWS using Node.jsNode.js w/1M concurrent connections!HTML5 WebSocket: A Quantum Leap in Scalability for the WebDo HTML WebSockets maintain an open connection for each client? Does this scale? 这篇关于Websockets 是如何实现的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！
