0%

坑系列之阿里SLB上使用Webscoket

Posted on Disqus:

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

和HTTP协议有什么关系

首先我们来看一下Websocket协议和HTTP有什么关系呢？
本质上说，Websocket和HTTP就不是一个协议，层级不一样。但是为了兼容现有浏览器的握手规范，必须借助HTTP协议建立连接。

这是一个Websocket的握手请求

1
2
3
4
5
6
7
8
9
10
11
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不一样的地方，

1
2
3
4
5
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

1
2
3
4
5
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官方介绍可以看到

1
2
3
4
5
6
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的超时响应。

1
2
3
4
5
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同一个请求。

1
2
3
4
5
6
7
8
9
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版本已经是一个相当落后的版本了。

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

希望对你有帮助，分享或是请我喝杯咖啡吧~