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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | 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請求，并連接服務端端口，執行雙方握手過程，客戶端發送數據格式類似：
1 2 3 4 5 6 7 | GET /webfin/websocket/ HTTP/1.1Host: localhostUpgrade: websocketConnection: UpgradeSec-WebSocket-Key: xqBt3ImNzJbYqRINxEFlkg==Origin: http://localhost:8080Sec-WebSocket-Version: 13 |
可以看到，客戶端發起的WebSocket連接報文類似傳統HTTP報文，Upgrade：websocket參數值表明這是WebSocket類型請求，Sec-WebSocket-Key是WebSocket客戶端發送的一個 base64編碼的密文，要求服務端必須返回一個對應加密的Sec-WebSocket-Accept應答，否則客戶端會拋出Error during WebSocket handshake錯誤，并關閉連接。
2）服務端收到報文后返回的數據格式類似：
1 2 3 4 | HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-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
發心跳包，原理就是在有效地再讀時間內進行通訊，重新刷新再讀時間
配置示例：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 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是應用層協議。
