坑系列之阿里SLB上使用Webscoket

2018-03-12 Rufinanupt

Websocket是HTML5之后的一个新事物,可以方便的实现客户端到服务端的长会话,特别适合用于客户端需要接收服务端推送的场景。例如在线客服聊天,提醒推送等等。改变了以往客户端只能通过轮询或者long poll来获取服务端状态的限制。

和HTTP协议有什么关系

首先我们来看一下Websocket协议和HTTP有什么关系呢?

本质上说,Websocket和HTTP就不是一个协议,层级不一样。但是为了兼容现有浏览器的握手规范,必须借助HTTP协议建立连接。

这是一个Websocket的握手请求

GET wss://server.example.com/ HTTP/1.1
Host: server.example.com
Pragma: no-cache
Cache-Control: no-cache
Connection: Upgrade
Upgrade: websocket
Origin: https://server.example.com
Accept-Encoding: gzip, deflate, br
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: fFFIlFcwULSAmQacRAbS2A==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

这里面有几个和一般HTTP Request不一样的地方,

Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: fFFIlFcwULSAmQacRAbS2A==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

这是告诉服务端这不是一个普通的请求,而是Websocket协议。Sec-WebSocket-Key 是一个Base64 encode的值,是浏览器随机生成的,用于让服务端知道这是一个全新的socket客户端。

服务端如果开启了Socket监听,那么就会返回这样的Response

HTTP/1.1 101 Switching Protocols
Date: Fri, 09 Mar 2018 16:24:45 GMT
Connection: upgrade
upgrade: websocket
sec-websocket-accept: i/tCy92JmOXIoZwGi8ROh6CgUwk=

表示接收了请求,并且即将切换到Websocket协议,所以code是101。Sec-WebSocket-Accept 这个则是经过服务器确认,并且加密过后的 Sec-WebSocket-Key。到这里HTTP协议的任务就已经完成,之后的通信都是基于Websocket协议了。

怎么通过nginx转发Websocket的握手请求

本质上说握手请求就是一个特殊的HTTP Request,只是需要加一些上文提到的特殊内容,从 Nignx官方介绍 可以看到

location /wsapp/ {
    proxy_pass http://wsbackend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
}

只是在Request header加了两个属性,并且强制升级到HTTP 1.1,原因是HTTP 1.0不支持keep alive。如果使用HTTP 1.0发握手请求,服务端返回101以后就会直接结束这次HTTP会话了。这一点也为之后的坑埋下了伏笔。

坑从何来

自从上线了Websocket服务之后,就会经常发现socket无法建立,获得504的超时响应。

HTTP/1.1 504 Gateway Time-out
Date: Fri, 09 Mar 2018 03:34:54 GMT
Content-Type: text/html
Content-Length: 272
Connection: keep-alive

而且这一响应只有在经过SLB(负载均衡)时才有,如果直接请求到我们自己的nginx是没有问题的。但是基于对阿里的信任,还是觉得问题应该还是我们自己这儿。从code review到nginx配置,折腾了五六个小时。

最后只有自己搭建的nginx access log上寻找蛛丝马迹,一开始抓到一些响应都是499的返回,并且request_time时间都在60s上下。

[09/Mar/2018:15:04:51 +0800] 100.97.89.10 - - - 10.0.21.11 to: 10.0.20.11:8011: GET /ws/?id=168451&url= http://server.example.com/ HTTP/1.0 upstream_response_time - msec 1520579091.139 request_time 60.000 status 499 client - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

就考虑是不是socket服务端建立连接后响应不及时,让SLB发现60s没有报文交互直接就切断请求了。

但是因为我们在前端是做了心跳的,即使服务端不响应,只要socket建立通过心跳肯定也会在60s内进行交互。不应该出现上面的场景。

之后我们把access log中socket建立成功的请求和不成功的请求分开放到一起对比,发现不成功的都是HTTP 1.0的协议。

[09/Mar/2018:15:03:51 +0800] 100.97.88.238 - - - 10.0.20.11 to: 127.0.0.1:8011: GET /ws/?id=168451&url= http://server.example.com HTTP/1.1 upstream_response_time 11.069 msec 1520579031.198 request_time 11.|

069 status 101 client - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 |

[09/Mar/2018:15:04:32 +0800] 100.97.88.254 - - - 10.0.20.11 to: 127.0.0.1:8011: GET /ws/?id=168451&url= http://server.example.com HTTP/1.0 upstream_response_time - msec 1520579072.716 request_time 36.755 s|

tatus 499 client - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

就好像这两个请求,同一个页面发出的,但是一个成功一个失败。失败的正好就是HTTP/1.0,为什么会有两个版本的协议呢,

为了证据更加“确凿”,我们对请求进行了抓包分析,并将Sec-WebSocket-Key打印到Nginx的access log中方便trace同一个请求。

GET http://server.example.com/ws/ HTTP/1.1
Host: app.linkflowtech.com
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://server.example.com
Sec-WebSocket-Key: 8+qDYeKJGFTWKB2ov4p5TA==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

[09/Mar/2018:17:07:07 +0800] 100.97.88.252 - - - 10.0.21.11 to: 10.0.20.11:8011: GET /ws/ HTTP/1.0 upstream_response_time - msec 1520586427.537 request_time 59.999 status 499 client - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 8+qDYeKJGFTWKB2ov4p5TA==

2018-03-09 17:12:04

可以看到都是 8+qDYeKJGFTWKB2ov4p5TA== 的请求,但是在经过SLB进入nginx时候协议降级到了1.0.这叫一个酸爽,赶紧给阿里云开了工单,经过大概3~4个小时的交流。最终获得一个链接,里面有这样的描述

如何在阿里云负载均衡上启用WS/WSS支持?

无需配置,当选用HTTP监听时,默认支持无加密版本WebSocket协议(WS协议);当选择HTTPS监听时,默认支持加密版本的WebSocket协议(WSS协议)。

注意:需要将实例升级为 性能保障型实例 。详细参见如何使用负载均衡性能保障型实例。

这个大坑就在”注意”那一段,我们的SLB是性能共享型而不是性能保障型。看来也不是阿里云的问题,是我们的SLB档次不够高啊。知道原因后,立刻付费升级了保障型。实测一下所有问题都解决了。

虽然问题解决了,但是其实很难理解厂商的逻辑,为什么性能共享型中某些SLB节点就会降级HTTP协议版本呢,要知道1.0版本已经是一个相当落后的版本了。

在此记录一下心路历程,为了让其他使用阿里云的同学不要重蹈覆辙。