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

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

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

這是一個(gè)Websocket的握手請(qǐng)求

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

這里面有幾個(gè)和一般HTTP Request不一樣的地方，

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

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

服務(wù)端如果開(kāi)啟了Socket監(jiān)聽(tīng)，那么就會(huì)返回這樣的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=

表示接收了請(qǐng)求，并且即將切換到Websocket協(xié)議，所以code是101。Sec-WebSocket-Accept 這個(gè)則是經(jīng)過(guò)服務(wù)器確認(rèn)，并且加密過(guò)后的 Sec-WebSocket-Key。到這里HTTP協(xié)議的任務(wù)就已經(jīng)完成，之后的通信都是基于Websocket協(xié)議了。

本質(zhì)上說(shuō)握手請(qǐng)求就是一個(gè)特殊的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加了兩個(gè)屬性，并且強(qiáng)制升級(jí)到HTTP 1.1，原因是HTTP 1.0不支持keep alive。如果使用HTTP 1.0發(fā)握手請(qǐng)求，服務(wù)端返回101以后就會(huì)直接結(jié)束這次HTTP會(huì)話了。這一點(diǎn)也為之后的坑埋下了伏筆。

自從上線了Websocket服務(wù)之后，就會(huì)經(jīng)常發(fā)現(xiàn)socket無(wú)法建立，獲得504的超時(shí)響應(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)過(guò)SLB（負(fù)載均衡）時(shí)才有，如果直接請(qǐng)求到我們自己的nginx是沒(méi)有問(wèn)題的。但是基于對(duì)阿里的信任，還是覺(jué)得問(wèn)題應(yīng)該還是我們自己這兒。從code review到nginx配置，折騰了五六個(gè)小時(shí)。

最后只有自己搭建的nginx access log上尋找蛛絲馬跡，一開(kāi)始抓到一些響應(yīng)都是499的返回，并且request_time時(shí)間都在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)不及時(shí)，讓SLB發(fā)現(xiàn)60s沒(méi)有報(bào)文交互直接就切斷請(qǐng)求了。

但是因?yàn)槲覀冊(cè)谇岸耸亲隽诵奶模词狗?wù)端不響應(yīng)，只要socket建立通過(guò)心跳肯定也會(huì)在60s內(nèi)進(jìn)行交互。不應(yīng)該出現(xiàn)上面的場(chǎng)景。
之后我們把a(bǔ)ccess log中socket建立成功的請(qǐng)求和不成功的請(qǐng)求分開(kāi)放到一起對(duì)比，發(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

就好像這兩個(gè)請(qǐng)求，同一個(gè)頁(yè)面發(fā)出的，但是一個(gè)成功一個(gè)失敗。失敗的正好就是HTTP/1.0，為什么會(huì)有兩個(gè)版本的協(xié)議呢，
為了證據(jù)更加“確鑿”，我們對(duì)請(qǐng)求進(jìn)行了抓包分析，并將Sec-WebSocket-Key打印到Nginx的access log中方便trace同一個(gè)請(qǐng)求。

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== 的請(qǐng)求，但是在經(jīng)過(guò)SLB進(jìn)入nginx時(shí)候協(xié)議降級(jí)到了1.0.這叫一個(gè)酸爽，趕緊給阿里云開(kāi)了工單，經(jīng)過(guò)大概3~4個(gè)小時(shí)的交流。最終獲得一個(gè)鏈接，里面有這樣的描述

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

這個(gè)大坑就在"注意"那一段，我們的SLB是性能共享型而不是性能保障型。看來(lái)也不是阿里云的問(wèn)題，是我們的SLB檔次不夠高啊。知道原因后，立刻付費(fèi)升級(jí)了保障型。實(shí)測(cè)一下所有問(wèn)題都解決了。

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

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