看到一篇不錯的文章，特意轉載過來，原文地址：長連接、短連接、長輪詢、短輪詢、WebSocket
一、短連接和長連接
短連接：每次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網站這麼頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源。
二、短輪詢和長輪詢
和短連接和長連接有本質區別。長、短連接是客戶端與服務端建立和保持TCP連接的機制；而長、短輪詢是指客戶端請求服務端，服務端給予應答的方式。
短輪詢：重複發送Http請求，查詢目標事件是否完成，優點：編寫簡單，缺點：浪費帶寬和服務器資源
長輪詢：在服務端hold住Http請求（死循環或者sleep等等方式），等到目標時間發生(保持這個請求等待數據到來或者恰當的超時)，返回Http響應。優點：在無消息的情況下不會頻繁的請求，缺點：編寫複雜
三、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