SocketIO：服务端推送

前言

在介绍SocketIO之前，先说下服务端推送是怎么一回事。所谓服务端推送，就是服务端将数据或者消息实时地推送到客户端上。最常见的场景就是即时通讯，除此之外，视频弹幕、图文直播等功能也用到了服务端推送这项技术。

之所以使用服务端推送，是为了把服务端的数据及时、迅速地推送到客户端，当然，如果能够尽可能地降低服务端的性能损耗，那就再好不过了。

要想及时地获取服务端数据，最简单的实现方案莫过于客户端长轮询了。简而言之，就是客户端起一个定时器，定时向服务端发送HTTP请求查询最新数据，以此实现客户端与服务端的数据保持一致。这种方案的好处是实现简单，坏处就是性能损耗过高，而且数据更新也不及时。由于需要定时向服务器发送HTTP请求，如果客户端数量过多，则服务器需要承受很大的并发压力。再者，服务端的数据更新可能并不频繁，但是客户端也要定期过来询问，这会让服务端和客户端都做很多无用功，效率自然不高。还有一点就是，由于客户端没法做到每时每刻都向服务端请求数据，只能定时请求，假如说相邻2次请求的间隔时间过长，则服务端的数据就没法及时地“推送”到客户端，这会造成数据推送延迟。

 

服务端推送的其他方案

客户端长轮询方案是最简单的方案，但是缺点诸多，业界应该没几家公司会采用。我们都知道，TCP协议是支持双向通信的，也就是说服务端可以向客户端发送数据包，客户端也可以向服务端发送数据包。但由于HTTP协议的限制，基于HTTP协议通信的网络应用只能由客户端主动发起，服务端被动响应，故无法做到服务端向客户端推送数据。虽然HTTP 2.0支持服务端推送，但是HTTP 2.0的服务端推送跟我们这里说的服务端推送还不是一回事，有兴趣的朋友可以去深入了解下。

既然TCP协议支持服务端推送，而HTTP协议不支持，那么事情就好办了。我们传输层依旧使用TCP协议，应用层改用其他协议不就得了。事实上，业界也确实是这么做的。最常见的方案就是使用现成的协议，如WebSocket。当然，也可以使用自定义协议来实现服务端推送。关于WebSocket协议这里不会展开细讲，感兴趣的可以看旧文：