Nginx支持WebSocket反向代理-学习小结

 

WebSocket是目前比较成熟的技术了，WebSocket协议为建立客户端和服务器端须要实时双向通信的webapp提供了一个选择。其为HTML5的一部分，WebSocket相较于原来开发这类app的方法来讲，其能使开发更加地简单。大部分如今的浏览器都支持WebSocket，好比Firefox，IE，Chrome，Safari，Opera，而且愈来愈多的服务器框架如今也一样支持WebSocket。

在实际的生产环境中，要求多个WebSocket服务器必须具备高性能和高可用，那么WebSocket协议就须要一个负载均衡层，NGINX从1.3版本开始支持WebSocket，其能够做为一个反向代理和为WebSocket程序作负载均衡。

WebSocket协议与HTTP协议不一样，但WebSocket握手与HTTP兼容，使用HTTP升级工具将链接从HTTP升级到WebSocket。这容许WebSocket应用程序更容易地适应现有的基础架构。例如，WebSocket应用程序可使用标准HTTP端口80和443，从而容许使用现有的防火墙规则。

WebSocket应用程序能够在客户端和服务器之间保持长时间运行的链接，从而有助于开发实时应用程序。用于将链接从HTTP升级到WebSocket的HTTP升级机制使用Upgrade和Connection头。反向代理服务器在支持WebSocket时面临一些挑战。一个是WebSocket是一个逐跳协议，所以当代理服务器拦截客户端的升级请求时，须要向后端服务器发送本身的升级请求，包括相应的头文件。此外，因为WebSocket链接长期存在，与HTTP使用的典型短时间链接相反，反向代理须要容许这些链接保持打开状态，而不是关闭它们，由于它们彷佛处于空闲状态。

容许在客户机和后端服务器之间创建隧道，NGINX支持WebSocket。对于NGINX将升级请求从客户端发送到后台服务器，必须明确设置Upgrade和Connection标题。

Nginx开启websocket代理功能的配置以下：

1）编辑nginx.conf，在http区域内必定要添加下面配置：
map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

map指令的做用：
该做用主要是根据客户端请求中$http_upgrade 的值，来构造改变$connection_upgrade的值，即根据变量$http_upgrade的值建立新的变量$connection_upgrade，
建立的规则就是{}里面的东西。其中的规则没有作匹配，所以使用默认的，即 $connection_upgrade 的值会一直是 upgrade。而后若是 $http_upgrade为空字符串的话，
那值会是 close。


2）编辑vhosts下虚拟主机的配置文件，在location匹配配置中添加以下内容：
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";

示例以下：
upstream socket.kevin.com {
    hash $remote_addr consistent;
    server 10.0.12.108:9000;
    server 10.0.12.109:9000;
}

 location / {
            proxy_pass http://socket.kevin.com/;
            proxy_set_header Host $host:$server_port;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }

WebSocket 机制
WebSocket是HTML5下一种新的协议。它实现了浏览器与服务器全双工通讯，能更好的节省服务器资源和带宽并达到实时通信的目的。它与HTTP同样经过已创建的TCP链接来传输数据，可是它和HTTP最大不一样是：
1） WebSocket是一种双向通讯协议。在创建链接后，WebSocket服务器端和客户端都能主动向对方发送或接收数据，就像Socket同样；
2）WebSocket须要像TCP同样，先创建链接，链接成功后才能相互通讯。

传统HTTP客户端与服务器请求响应模式以下图所示：

WebSocket模式客户端与服务器请求响应模式以下图：

上图对比能够看出，相对于传统HTTP每次请求-应答都须要客户端与服务端创建链接的模式，WebSocket是相似Socket的TCP长链接通信模式。一旦WebSocket链接创建后，后续数据都以帧序列的形式传输。在客户端断开WebSocket链接或Server端中断链接前，不须要客户端和服务端从新发起链接请求。在海量并发及客户端与服务器交互负载流量大的状况下，极大的节省了网络带宽资源的消耗，有明显的性能优点，且客户端发送和接受消息是在同一个持久链接上发起，实时性优点明显。

相比HTTP长链接，WebSocket有如下特色：
1）是真正的全双工方式，创建链接后客户端与服务器端是彻底平等的，能够互相主动请求。而HTTP长链接基于HTTP，是传统的客户端对服务器发起请求的模式。
2）HTTP长链接中，每次数据交换除了真正的数据部分外，服务器和客户端还要大量交换HTTP header，信息交换效率很低。Websocket协议经过第一个request创建了TCP链接以后，以后交换的数据都不须要发送 HTTP header就能交换数据，这显然和原有的HTTP协议有区别因此它须要对服务器和客户端都进行升级才能实现（主流浏览器都已支持HTML5）。此外还有 multiplexing、不一样的URL能够复用同一个WebSocket链接等功能。这些都是HTTP长链接不能作到的。

总的来讲：
WebSocket与Http相同点
-  都是同样基于TCP的，都是可靠性传输协议。
-  都是应用层协议。

WebSocket与Http不一样点
-  WebSocket是双向通讯协议，模拟Socket协议，能够双向发送或接受信息。HTTP是单向的。
-  WebSocket是须要浏览器和服务器握手进行创建链接的。而http是浏览器发起向服务器的链接，服务器预先并不知道这个链接。

WebSocket与Http联系
WebSocket在创建握手时，数据是经过HTTP传输的。可是创建以后，在真正传输时候是不须要HTTP协议的。

在WebSocket中，只须要服务器和浏览器经过HTTP协议进行一个握手的动做，而后单独创建一条TCP的通讯通道进行数据的传送。
WebSocket链接的过程是：
1）客户端发起http请求，通过3次握手后，创建起TCP链接；http请求里存放WebSocket支持的版本号等信息，如：Upgrade、Connection、WebSocket-Version等；
2）服务器收到客户端的握手请求后，一样采用HTTP协议回馈数据；
3）客户端收到链接成功的消息后，开始借助于TCP传输信道进行全双工通讯。

下面再经过客户端和服务端交互的报文对比WebSocket通信与传统HTTP的不一样点：
1）在客户端，new WebSocket实例化一个新的WebSocket客户端对象，请求相似 ws://yourdomain:port/path 的服务端WebSocket URL，客户端WebSocket对象会自动解析并识别为WebSocket请求，并链接服务端端口，执行双方握手过程，客户端发送数据格式相似：

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

能够看到，客户端发起的WebSocket链接报文相似传统HTTP报文，Upgrade：websocket参数值代表这是WebSocket类型请求，Sec-WebSocket-Key是WebSocket客户端发送的一个 base64编码的密文，要求服务端必须返回一个对应加密的Sec-WebSocket-Accept应答，不然客户端会抛出Error during WebSocket handshake错误，并关闭链接。
2）服务端收到报文后返回的数据格式相似：

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

Sec-WebSocket-Accept的值是服务端采用与客户端一致的密钥计算出来后返回客户端的，HTTP/1.1 101 Switching Protocols表示服务端接受WebSocket协议的客户端链接，通过这样的请求-响应处理后，两端的WebSocket链接握手成功, 后续就能够进行TCP通信了。

在开发方面，WebSocket API 也十分简单：只须要实例化 WebSocket，建立链接，而后服务端和客户端就能够相互发送和响应消息。在WebSocket 实现及案例分析部分能够看到详细的 WebSocket API 及代码实现。

腾讯云公网有日租类型七层负载均衡转发部分支持Websocket，目前包括英魂之刃、银汉游戏等多家企业已接入使用。当出现不兼容问题时，请修改websocket配置，websocket server不校验下图中圈出的字段：

好比一个使用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是应用层协议。