Polling 、Long Polling 和 WebSocket

最近在学习研究WebSocket,了解到Polling 和Long Polling,翻阅了一些博文，根据自己的理解，做个学习笔记

Polling （轮询）：

这种方式就是客户端定时向服务器发送http的Get请求，服务器收到请求后，就将最新的数据返回给客户端，客户端再进行显示，如此反复这一过程；

这种方式虽然可以满足需求，但是也存在些问题；比如客户端每一分钟向服务器发送http的get请求，而在这一分钟里，服务器并没有数据更新，就会将老的数据返回给客户端显示，

这样不仅浪费网络宽带而且也浪费了cpu的利用率；就想着说那可以拉长请求的周期啊，于是就有了下面的Long Polling（长轮询）。

Long Polling（长轮询）：

Long Polling（长轮询）是对Polling（轮询）的一种改进；客户端向服务器发送http的get请求，如果服务器有新的数据更新，则直接将新数据返回给客户端显示；如果没有，则将这个请求保持住，直到服务器有新的数据更新，

再将新的数据返回给客户端显示；当然这个请求是有时效的，如果服务器很久都没有数据更新，则这个get请求会超时，客户端收到超时信息时，则再发起一个get请求；如此重复这一过程。

但是这种方式同样存在一些问题，如果数据更新过快，而数据的返回得等客户端发来一个get请求，才能将该新数据返回给客户端；客户端显示最新数据的最快时间为2×RTT（往返时间），在网络拥塞的情况在，用户是没法接受的；

比如，一个请求来回要4秒，用户在10:10秒发出请求，在10:14看到服务器返回的数据，而服务器在10:13有新的数据更新，则只能等上一个请求数据回去后，在10:14才能再次发出get请求，在10:18秒才能在客户端接受到服务器在10:13更新的数据，也就是在网络正常的情况下，这个数据延迟了5秒，客户端才能看到，数据没法实时更新，用户肯定也接受不了。

另外，由于http数据包的头部数据量往往很大（通常有 400多个字节），但是真正被服务器需要的数据却很少（有时只有10个字节左右），这样的数据包在网络上周期性的传输，难免对网络带宽是一种浪费。于是就有了下面的WebSocket。

WebSocket：

WebSocket是一种双向通信协议，而且协议的头部又不那么庞大；服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话；WebSocket需要通过握手连接

（你先告诉服务器你要给服务器发东西（SYN），服务器应答你并告诉你它也要给你发东西（SYN、ACK），然后你应答服务器（ACK），总共来回了3次，称为3次握手。）

，类 似于TCP它也需要客户端和服务器端进行握手连接，连接成功后才能相互通信。握手连接成功后，服务器就可以主动向客户端推送最新的数据，客户端也可以主动向服务器发送请求，这样就可以实现实时的数据了。

在此WebSocket 协议中，为我们实现即时服务带来了两大好处：

1. Header

互相沟通的Header是很小的-大概只有 2 Bytes

2. Server Push

服务器的推送，服务器不再被动的接收到浏览器的请求之后才返回数据，而是在有新数据时就主动推送给浏览器。

 

创建对象：

var ws = new WebSocket("ws://echo.websocket.org",[name]);

第一个参数为WebSocket服务器的地址,使用ws://开头，另外安全的WebSocket协议使用wss://开头，name为发起握手的协议名称，为可选择项。

 

连接建立时触发：

ws.onopen = (function(){...})();

客户端接收服务端数据时触发：

ws.onmessage = (function(evt){...})();

通信发生错误时触发：

ws.onerror = (function(){...})();

连接关闭时触发：

ws.onclose = (function(){...})();

 

如有不对的地方，望大神指出，感谢！

参考博文：

https://www.cnblogs.com/mazg/p/5467960.html