長鏈接、短鏈接、長輪詢、短輪詢、WebSocket釋疑

看到一篇不錯的文章，特地轉載過來，原文地址： 長鏈接、短鏈接、長輪詢、短輪詢、WebSocket

1、短鏈接和長鏈接

短鏈接：每次Http請求都會創建Tcp鏈接，管理容易

長鏈接：只須要創建一次Tcp鏈接，之後Http請求重複使用同一個Tcp鏈接，管理難

HTTP1.1規定了默認保持長鏈接（HTTP persistent connection ，也有翻譯爲持久鏈接），數據傳輸完成了保持TCP鏈接不斷開（不發RST包、不四次揮手），等待在同域名下繼續用這個通道傳輸數據；相反的就是短鏈接
若是服務器沒有告訴客戶端超時時間也不要緊，服務端可能主動發起四次揮手斷開TCP鏈接，客戶端可以知道該TCP鏈接已經無效；另外TCP還有心跳包來檢測當前鏈接是否還活着，方法不少，避免浪費資源。

在長鏈接的應用場景下，client端通常不會主動關閉它們之間的鏈接，Client與server之間的鏈接若是一直不關閉的話，會存在一個問題，隨着客戶端鏈接愈來愈多，server遲早有扛不住的時候，這時候server端須要採起一些策略，如關閉一些長時間沒有讀寫事件發生的鏈接，這樣能夠避免一些惡意鏈接致使server端服務受損；若是條件再容許就能夠以客戶端機器爲顆粒度，限制每一個客戶端的最大長鏈接數，這樣能夠徹底避免某個蛋疼的客戶端連累後端服務。

長鏈接和短鏈接的產生在於client和server採起的關閉策略，具體的應用場景採用具體的策略，沒有十全十美的選擇，只有合適的選擇

應用場景區別：

通常長鏈接（追求實時性高的場景）用於少數client-end to server-end的頻繁的通訊，例如：數據庫的鏈接用長鏈接， 若是用短鏈接頻繁的通訊會形成socket錯誤，並且頻繁的socket 建立也是對資源的浪費。
而像WEB網站的http服務通常都用短連接（追求資源易回收場景），由於長鏈接對於服務端來講會耗費必定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的鏈接用短鏈接會更省一些資源。

2、短輪詢和長輪詢

和短鏈接和長鏈接有本質區別。長、短鏈接是客戶端與服務端創建和保持TCP鏈接的機制；而長、短輪詢是指客戶端請求服務端，服務端給予應答的方式。

短輪詢：重複發送Http請求，查詢目標事件是否完成，優勢：編寫簡單，缺點：浪費帶寬和服務器資源

長輪詢：在服務端hold住Http請求（死循環或者sleep等等方式），等到目標時間發生(保持這個請求等待數據到來或者恰當的超時)，返回Http響應。優勢：在無消息的狀況下不會頻繁的請求，缺點：編寫複雜

3、WebSocket

WebSocket和HTTP長鏈接區別

• HTTP1.1經過使用Connection:keep-alive進行長鏈接，HTTP 1.1默認進行持久鏈接。在一次 TCP 鏈接中能夠完成多個 HTTP 請求，可是對每一個請求仍然要單獨發 header，Keep-Alive不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如Apache）中設定這個時間。
• websocket的長鏈接，是一個真的全雙工，第一次tcp鏈路創建以後，後續數據能夠雙方都進行發送，不須要發送請求頭，而且這個鏈接會持續存在直到客戶端或者服務器端的某一方主動關閉鏈接，與HTTP長鏈接不一樣，WebSocket能夠更靈活的控制鏈接關閉的時機，而不是HTTP協議的Keep-Alive一到，服務端立馬就關閉（這樣很不人性化）。

WebSocket鏈接創建

創建WebSocket鏈接時，須要經過客戶端或者瀏覽器發出握手請求，請求消息示例如圖：

服務端返回給客戶端的應答消息如圖：

爲了創建一個WebSocket鏈接，客戶端瀏覽器首先要向服務器發起一個HTTP請求，這個請求和一般的HTTP請求不一樣，包含了一些附加頭信息，其中附加頭信息「Upgrade: WebSocket」代表這是一個申請協議升級的HTTP請求。服務器端解析這些附加的頭信息，而後生成應答信息返回給客戶端，客戶端和服務器端的WebSocket鏈接就創建起來了，雙方能夠經過這個鏈接通道自由地傳遞信息，而且這個鏈接會持續存在直到客戶端或者服務器端的某一方主動關閉鏈接。

請求消息中的「Sec-WebSocket-Key」是隨機的，服務器端會用這些數據來構造出一個SHA-1的信息摘要，把「Sec-WebSocket-Key」加上一個魔幻字符串「258EAFA5-E914- 47DA-95CA-C5AB0DC85B11」。使用SHA-1加密，而後進行BASE-64編碼，將結果作爲「Sec-WebSocket-Accept」頭的值，返回給客戶端。

---

注：本文爲轉載，原文地址：長鏈接、短鏈接、長輪詢、短輪詢、WebSocket