摘要：最終獲得一個鏈接，里面有這樣的描述如何在阿里云負載均衡上啟用支持無需配置，當選用監(jiān)聽時，默認支持無加密版本協(xié)議協(xié)議當選擇監(jiān)聽時，默認支持加密版本的協(xié)議協(xié)議。詳細參見如何使用負載均衡性能保障型實例。

Websocket是HTML5之后的一個新事物，可以方便的實現(xiàn)客戶端到服務(wù)端的長會話，特別適合用于客戶端需要接收服務(wù)端推送的場景。例如在線客服聊天，提醒推送等等。改變了以往客戶端只能通過輪詢或者long poll來獲取服務(wù)端狀態(tài)的限制。

首先我們來看一下Websocket協(xié)議和HTTP有什么關(guān)系呢？
本質(zhì)上說，Websocket和HTTP就不是一個協(xié)議，層級不一樣。但是為了兼容現(xiàn)有瀏覽器的握手規(guī)范，必須借助HTTP協(xié)議建立連接。

這是一個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

這是告訴服務(wù)端這不是一個普通的請求，而是Websocket協(xié)議。Sec-WebSocket-Key 是一個Base64 encode的值，是瀏覽器隨機生成的，用于讓服務(wù)端知道這是一個全新的socket客戶端。

服務(wù)端如果開啟了Socket監(jiān)聽，那么就會返回這樣的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協(xié)議，所以code是101。Sec-WebSocket-Accept 這個則是經(jīng)過服務(wù)器確認，并且加密過后的 Sec-WebSocket-Key。到這里HTTP協(xié)議的任務(wù)就已經(jīng)完成，之后的通信都是基于Websocket協(xié)議了。

本質(zhì)上說握手請求就是一個特殊的HTTP Request，只是需要加一些上文提到的特殊內(nèi)容，從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發(fā)握手請求，服務(wù)端返回101以后就會直接結(jié)束這次HTTP會話了。這一點也為之后的坑埋下了伏筆。

自從上線了Websocket服務(wù)之后，就會經(jīng)常發(fā)現(xiàn)socket無法建立，獲得504的超時響應(yīng)。

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

而且這一響應(yīng)只有在經(jīng)過SLB（負載均衡）時才有，如果直接請求到我們自己的nginx是沒有問題的。但是基于對阿里的信任，還是覺得問題應(yīng)該還是我們自己這兒。從code review到nginx配置，折騰了五六個小時。

最后只有自己搭建的nginx access log上尋找蛛絲馬跡，一開始抓到一些響應(yīng)都是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服務(wù)端建立連接后響應(yīng)不及時，讓SLB發(fā)現(xiàn)60s沒有報文交互直接就切斷請求了。

但是因為我們在前端是做了心跳的，即使服務(wù)端不響應(yīng)，只要socket建立通過心跳肯定也會在60s內(nèi)進行交互。不應(yīng)該出現(xiàn)上面的場景。
之后我們把access log中socket建立成功的請求和不成功的請求分開放到一起對比，發(fā)現(xiàn)不成功的都是HTTP 1.0的協(xié)議。

[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

就好像這兩個請求，同一個頁面發(fā)出的，但是一個成功一個失敗。失敗的正好就是HTTP/1.0，為什么會有兩個版本的協(xié)議呢，
為了證據(jù)更加“確鑿”，我們對請求進行了抓包分析，并將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== 的請求，但是在經(jīng)過SLB進入nginx時候協(xié)議降級到了1.0.這叫一個酸爽，趕緊給阿里云開了工單，經(jīng)過大概3~4個小時的交流。最終獲得一個鏈接，里面有這樣的描述

如何在阿里云負載均衡上啟用WS/WSS支持？
無需配置，當選用HTTP監(jiān)聽時，默認支持無加密版本W(wǎng)ebSocket協(xié)議（WS協(xié)議）；當選擇HTTPS監(jiān)聽時，默認支持加密版本的WebSocket協(xié)議（WSS協(xié)議）。
注意：需要將實例升級為性能保障型實例。詳細參見如何使用負載均衡性能保障型實例。

這個大坑就在"注意"那一段，我們的SLB是性能共享型而不是性能保障型?？磥硪膊皇前⒗镌频膯栴}，是我們的SLB檔次不夠高啊。知道原因后，立刻付費升級了保障型。實測一下所有問題都解決了。

雖然問題解決了，但是其實很難理解廠商的邏輯，為什么性能共享型中某些SLB節(jié)點就會降級HTTP協(xié)議版本呢，要知道1.0版本已經(jīng)是一個相當落后的版本了。

在此記錄一下心路歷程，為了讓其他使用阿里云的同學(xué)不要重蹈覆轍。