websocket和http协议一样，都是基于tcp协议而发展起来的。在TCP两端，同一时间内，双方都可以主动向对方发送数据。这就是所谓的全双工。
http协议，是基于tcp的，但是在同一时间内，客户端和服务器只能有一方主动发数据，这就是所谓的半双工，这是由于http在设计之初，考虑的是看看网页文本的场景，能做到客户端发起请求再由服务器响应，就够了，所以就做了简化。
但是现在应用场景越来越复杂，比如说网页游戏，在相同的时间内，玩家不仅要向服务端传递数据，服务端也需要主动向玩家推送游戏数据，所以用http协议已经不能满足需求了，这时就可以引入websocket协议，来实现全双工的数据发送。
http协议的应用场景
平时在浏览网页时，比如说看到一则新闻标题，点击一下后，就跳转到了新闻详情页，从http角度来看，就是点击之后，前端发送了一个http请求，然后服务端返回http响应，这样我们就能看到新闻具体内容了。这种由客户端主动请求，服务器响应的方式也满足大部分网页的功能场景。但是这种情况下，服务端是不会主动给客户端发送消息的。但是有时候我们登录app后，会受到系统推送的消息，这种我们没有做任何操作，但是服务端却主动推送过来的消息，是怎么实现的呢?
一、使用HTTP不断轮询
这种方法的原理是网页的前端代码里不断定时发HTTP请求到服务器，服务器收到请求后给客户端响应消息。 但这其实是一种伪服务器推送。它其实并不是服务器主动发消息到客户端，而是客户端自己不断偷偷请求服务器，只是用户无感知而已。这种多常见于扫码登录。当出现登录二维码后，前端不能判断用户是否进行了扫码，所以需要每隔一段时间，向后端询问是否有人扫码，当进行扫码后，服务端就会返回登录成功信息，前端就可正常登录，但是这样会有明显的两个问题，由于需要不间断的访问，会产生过多的http请求，造成网络和服务器的压力。而且若访问时间间隔太久，扫码后，会有明显的延迟后，才正常登录。那么有没有更好的方式呢？
二、使用长轮询
我们知道，HTTP请求发出后，一般会给服务器留一定的时间做响应，比如3s，规定时间内没返回，就认为是超时。
如果我们的HTTP请求将超时设置的很大，比如30s，在这30s内只要服务器收到了扫码请求，就立马返回给客户端网页。如果超时，那就立马发起下一次请求。
这样就减少了HTTP请求的个数，并且由于大部分情况下，用户都会在某个30s的区间内做扫码操作，所以响应也是及时的。
websocket是怎么建立的？
要建立websocket连接，首先需要建立http连接，连接建立后，当要升级为websocket时，会在HTTP请求里带上一些特殊的header头。
这些header头的意思是，浏览器想升级协议（Connection: Upgrade），并且想升级成websocket协议（Upgrade: websocket）。
同时带上一段随机生成的base64码（Sec-WebSocket-Key），发给服务器。
如果服务器正好支持升级成websocket协议。就会走websocket握手流程，同时根据客户端生成的base64码，用某个公开的算法变成另一段字符串，放在HTTP响应的 Sec-WebSocket-Accept 头里，同时带上101状态码，发回给浏览器。
之后，浏览器也用同样的公开算法将base64码转成另一段字符串，如果这段字符串跟服务器传回来的字符串一致，那验证通过。
就这样经历了一来一回两次HTTP握手，websocket就建立完成了，后续双方就可以使用webscoket的数据格式进行通信了。
