WebSocket原理，实现持久连接

WebSocket是HTML5出的协议，，也就是说HTTP协议没有变化，或者说没关系，但HTTP是不支持持久连接的（长连接，循环连接的不算）

• ajax 轮询
  场景再现：客户端：啦啦啦，有没有新信息(Request)
  服务端：没有（Response）
  客户端：啦啦啦，有没有新信息(Request)
  服务端：没有。。（Response）
  客户端：啦啦啦，有没有新信息(Request)
  服务端：你好烦啊，没有啊。。（Response）
  客户端：啦啦啦，有没有新消息（Request）
  服务端：好啦好啦，有啦给你。（Response）
  客户端：啦啦啦，有没有新消息（Request）
  服务端：。。。。。没。。。。没。。。没有（Response）
  —loop
• long poll
  原理跟 ajax轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。场景再现客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request）服务端：额。。 等待到有消息的时候。。来 给你（Response）客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request） -loop
• long poll 和ajax 轮询总结
  服务端不能主动联系客户端，只能有客户端发起。
  缺陷
  ajax轮询 需要服务器有很快的处理速度和资源。（速度）
  long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小）
  所以ajax轮询 和long poll 都有可能发生这种情况。
  客户端：啦啦啦啦，有新信息么？
  服务端：月线正忙，请稍后再试（503 Server Unavailable）
  客户端：。。。。好吧，啦啦啦，有新信息么？
  服务端：月线正忙，请稍后再试（503 Server Unavailable）

HTTP还是一个无状态协议
通俗的说就是，服务器因为每天要接待太多客户了，是个健忘鬼，你一挂电话，他就把你的东西全忘光了，把你的东西全丢掉了。你第二次还得再告诉服务器一遍。
Websocket出现了。他解决了HTTP的这几个难题。
首先，被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。所以上面的情景可以做如下修改。
客户端：啦啦啦，我要建立Websocket协议，需要的服务：chat，Websocket协议版本：17（HTTP Request）
服务端：ok，确认，已升级为Websocket协议（HTTP Protocols Switched）
客户端：麻烦你有信息的时候推送给我噢。。
服务端：ok，有的时候会告诉你的。
服务端：balabalabalabala
服务端：balabalabalabala
服务端：哈哈哈哈哈啊哈哈哈哈
服务端：笑死我了哈哈哈哈哈哈哈

就变成了这样，只需要经过一次HTTP请求，就可以做到源源不断的信息传送了。（在程序设计中，这种设计叫做回调，即：你有信息了再来通知我，而不是我傻乎乎的每次跑来问你）
这样的协议解决了上面同步有延迟，而且还非常消耗资源的这种情况。

那么为什么他会解决服务器上消耗资源的问题呢？其实我们所用的程序是要经过两层代理的，即HTTP协议在Nginx等服务器的解析下，然后再传送给相应的Handler（PHP等）来处理。简单地说，我们有一个非常快速的接线员（Nginx），他负责把问题转交给相应的客服（Handler）。本身接线员基本上速度是足够的，但是每次都卡在客服（Handler）了，老有客服处理速度太慢。，导致客服不够。Websocket就解决了这样一个难题，建立后，可以直接跟接线员建立持久连接，有信息的时候客服想办法通知接线员，然后接线员在统一转交给客户。这样就可以解决客服处理速度过慢的问题了。同时，在传统的方式上，要不断的建立，关闭HTTP协议，由于HTTP是非状态性的，每次都要重新传输identity info（鉴别信息），来告诉服务端你是谁。虽然接线员很快速，但是每次都要听这么一堆，效率也会有所下降的，同时还得不断把这些信息转交给客服，不但浪费客服的处理时间，而且还会在网路传输中消耗过多的流量/时间。但是Websocket只需要一次HTTP握手，所以说整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求，这样就解决了接线员要反复解析HTTP协议，还要查看identity info的信息。同时由客户主动询问，转换为服务器（推送）有信息的时候就发送（当然客户端还是等主动发送信息过来的。。），没有信息的时候就交给接线员（Nginx），不需要占用本身速度就慢的客服（Handler）了
WebSocket连接的过程是：
1）客户端发起http请求，经过3次握手后，建立起TCP连接；http请求里存放WebSocket支持的版本号等信息，如：Upgrade、Connection、WebSocket-Version等；
2）服务器收到客户端的握手请求后，同样采用HTTP协议回馈数据；
3）客户端收到连接成功的消息后，开始借助于TCP传输信道进行全双工通信。

客户端发送数据格式类似：

GET /webfin/websocket/ HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: xqBt3ImNzJbYqRINxEFlkg==
Origin: http://localhost:8080
Sec-WebSocket-Version: 13

服务端收到报文后返回的数据格式类似：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: K7DJLdLooIwIG/MOpvWFB3y3FE8=

比如一个使用WebSocket应用于视频的业务思路如下：
1）使用心跳维护websocket链路，探测客户端端的网红/主播是否在线
2）设置负载均衡7层的proxy_read_timeout默认为60s
3）设置心跳为50s，即可长期保持Websocket不断开

Nginx代理webSocket经常中断的解决方法（也就是如何保持长连接）

现象描述：用nginx反代代理某个业务，发现平均1分钟左右，就会出现webSocket连接中断，然后查看了一下，是nginx出现的问题。
产生原因：nginx等待第一次通讯和第二次通讯的时间差，超过了它设定的最大等待时间，简单来说就是超时！

解决方法1
其实只要配置nginx.conf的对应localhost里面的这几个参数就好
proxy_connect_timeout;
proxy_read_timeout;
proxy_send_timeout;

解决方法2
发心跳包，原理就是在有效地再读时间内进行通讯，重新刷新再读时间

配置示例：

http {
    server {
        location / {
            root   html;
            index  index.html index.htm;
            proxy_pass http://webscoket;
            proxy_http_version 1.1;
            proxy_connect_timeout 4s;                #配置点1
            proxy_read_timeout 60s;                  #配置点2，如果没效，可以考虑这个时间配置长一点
            proxy_send_timeout 12s;                  #配置点3
            proxy_set_header Upgrade $http_upgrade; 
            proxy_set_header Connection "Upgrade";  
        }
    }
}

关于上面配置2的解释
这个是服务器对你等待最大的时间，也就是说当你webSocket使用nginx转发的时候，用上面的配置2来说，如果60秒内没有通讯，依然是会断开的，所以，你可以按照你的需求来设定。比如说，我设置了10分钟，那么如果我10分钟内有通讯，或者10分钟内有做心跳的话，是可以保持连接不中断的，详细看个人需求

WebSocket与Socket的关系

• Socket其实并不是一个协议，而是为了方便使用TCP或UDP而抽象出来的一层，是位于应用层和传输控制层之间的一组接口。当两台主机通信时，必须通过Socket连接，Socket则利用TCP/IP协议建立TCP连接。TCP连接则更依靠于底层的IP协议，IP协议的连接则依赖于链路层等更低层次。
• WebSocket就像HTTP一样，则是一个典型的应用层协议。
  总的来说：Socket是传输控制层接口，WebSocket是应用层协议。