對這四個概念不太清楚，今天專門搜尋瞭解一下，總結一下：

長連線：在HTTP 1.1，客戶端發出請求，服務端接收請求，雙方建立連線，在服務端沒有返回之前保持連線，當客戶端再發送請求時，它會使用同一個連線。這一直繼續到客戶端或伺服器端認為會話已經結束，其中一方中斷連線。

優勢：減少了連線請求，降低TCP阻塞，減少了延遲，實時性較好。

劣勢：可能會影響效能，因為它在檔案被請求之後還保持了不必要的連線很長時間。

短連線：在HTTP1.0中，客戶端傳送請求，伺服器接收請求，雙方建立連線，伺服器響應資源，請求結束。

長輪詢：（我自己的理解）客戶端不斷髮送請求，獲取伺服器上的資料。也有人說是長連線的一種，是這樣嗎？？？

WebSocket：客戶端傳送一次http websocket請求，伺服器響應請求，雙方建立持久連線，並進行雙向資料傳輸，後面不進行HTTP連線，而是使用TCP連線。

什麼是長連線、短連線？ 在HTTP/1.0中預設使用短連線。也就是說，客戶端和伺服器每進行一次HTTP操作，就建立一次連線，任務結束就中斷連線。當客戶端瀏覽器訪問的某個HTML或其他型別的web頁中包含有其他的Web資源（如JavaScript檔案、影象檔案、CSS檔案等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。

而從HTTP/1.1起，預設使用長連線，用以保持連線特性。使用長連線的HTTP協議，會在響應頭加入這行程式碼：

Connection:keep-alive 在使用長連線的情況下，當一個網頁開啟完成後，客戶端和伺服器之間用於傳輸HTTP資料的TCP連線不會關閉，客戶端再次訪問這個伺服器時，會繼續使用這一條已經建立的連線。Keep-Alive不會永久保持連線，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間。實現長連線需要客戶端和服務端都支援長連線。

HTTP協議的長連線和短連線，實質上是TCP協議的長連線和短連線。

TCP長連線

我們再模擬一下長連線的情況：client向server發起連線，server接受client連線，雙方建立連線，client與server完成一次請求後，它們之間的連線並不會主動關閉，後續的讀寫操作會繼續使用這個連線。

長連線和短連線的優點和缺點 由上可以看出，長連線可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對於頻繁請求資源的客戶端適合使用長連線。在長連線的應用場景下，client端一般不會主動關閉連線，當client與server之間的連線一直不關閉，隨著客戶端連線越來越多，server會保持過多連線。這時候server端需要採取一些策略，如關閉一些長時間沒有請求發生的連線，這樣可以避免一些惡意連線導致server端服務受損；如果條件允許則可以限制每個客戶端的最大長連線數，這樣可以完全避免惡意的客戶端拖垮整體後端服務。

短連線對於伺服器來說管理較為簡單，存在的連線都是有用的連線，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費較多時間和頻寬。

長連線和短連線的產生在於client和server採取的關閉策略。不同的應用場景適合採用不同的策略。

長輪詢 長輪詢本身不是一種真正的推送技術，而只是傳統輪詢技術的一個變種。然而，其能夠在真正推送技術無法實現時模擬推送機制。

在長輪詢機制中，客戶端像傳統輪詢一樣從伺服器請求資料。然而，如果伺服器沒有可以立即返回給客戶端的資料，則不會立刻返回一個空結果，而是保持這個請求等待資料到來（或者恰當的超時），之後將資料作為結果返回給客戶端。

例如，BOSH是一個常見的、長久的、在TCP困難或無法實現的情況下（如在使用瀏覽器的情況下）使用長輪詢模擬TCP的技術。這也是一種XMPP中隱含的技術，蘋果公司將其用於iCloud推送支援。

WebSocket介紹 WebSocket一種在單個 TCP 連線上進行全雙工通訊的協議。WebSocket通訊協議於2011年被IETF定為標準RFC 6455，並被RFC7936所補充規範。WebSocket API也被W3C定為標準。

WebSocket 使得客戶端和伺服器之間的資料交換變得更加簡單，允許服務端主動向客戶端推送資料。在 WebSocket API 中，瀏覽器和伺服器只需要完成一次握手，兩者之間就直接可以建立永續性的連線，並進行雙向資料傳輸。

現在，很多網站為了實現推送技術，所用的技術都是輪詢。輪詢是在特定的的時間間隔（如每1秒），由瀏覽器對伺服器發出HTTP請求，然後由伺服器返回最新的資料給客戶端的瀏覽器。這種傳統的模式帶來很明顯的缺點，即瀏覽器需要不斷的向伺服器發出請求，然而HTTP請求可能包含較長的頭部，其中真正有效的資料可能只是很小的一部分，顯然這樣會浪費很多的頻寬等資源。

而比較新的技術去做輪詢的效果是Comet。這種技術雖然可以雙向通訊，但依然需要反覆發出請求。而且在Comet中，普遍採用的長連結，也會消耗伺服器資源。

在這種情況下，HTML5定義了WebSocket協議，能更好的節省伺服器資源和頻寬，並且能夠更實時地進行通訊。

Websocket使用ws或wss的統一資源標誌符，類似於HTTPS，其中wss表示在TLS之上的Websocket。如：

ws://example.com/wsapi wss://secure.example.com/ Websocket使用和 HTTP 相同的 TCP 埠，可以繞過大多數防火牆的限制。預設情況下，Websocket協議使用80埠；執行在TLS之上時，預設使用443埠。

WebSocket優點 較少的控制開銷。在連線建立後，伺服器和客戶端之間交換資料時，用於協議控制的資料包頭部相對較小。在不包含擴充套件的情況下，對於伺服器到客戶端的內容，此頭部大小隻有2至10位元組（和資料包長度有關）；對於客戶端到伺服器的內容，此頭部還需要加上額外的4位元組的掩碼。相對於HTTP請求每次都要攜帶完整的頭部，此項開銷顯著減少了。 更強的實時性。由於協議是全雙工的，所以伺服器可以隨時主動給客戶端下發資料。相對於HTTP請求需要等待客戶端發起請求服務端才能響應，延遲明顯更少；即使是和Comet等類似的長輪詢比較，其也能在短時間內更多次地傳遞資料。 保持連線狀態。於HTTP不同的是，Websocket需要先建立連線，這就使得其成為一種有狀態的協議，之後通訊時可以省略部分狀態資訊。而HTTP請求可能需要在每個請求都攜帶狀態資訊（如身份認證等）。 更好的二進位制支援。Websocket定義了二進位制幀，相對HTTP，可以更輕鬆地處理二進位制內容。 可以支援擴充套件。Websocket定義了擴充套件，使用者可以擴充套件協議、實現部分自定義的子協議。如部分瀏覽器支援壓縮等。 更好的壓縮效果。相對於HTTP壓縮，Websocket在適當的擴充套件支援下，可以沿用之前內容的上下文，在傳遞類似的資料時，可以顯著地提高壓縮率。 WebSocket 是獨立的、建立在 TCP 上的協議。

Websocket 通過 HTTP/1.1 協議的101狀態碼進行握手。

為了建立Websocket連線，需要通過瀏覽器發出請求，之後伺服器進行迴應，這個過程通常稱為“握手”（handshaking）。

WebSocket例子 一個典型的Websocket握手請求如下：

客戶端請求

GET / HTTP/1.1 Upgrade: websocket Connection: Upgrade Host: example.com Origin: http://example.com Sec-WebSocket-Key: sN9cRrP/n9NdMgdcy2VJFQ== Sec-WebSocket-Version: 13 伺服器迴應

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: fFBooB7FAkLlXgRSz0BT3v4hq5s= Sec-WebSocket-Location: ws://example.com/ 附錄知乎一個解釋：

作者：非同步 連結：https://www.zhihu.com/question/19876749/answer/16448614 來源：知乎 輪詢：客戶端定時向伺服器傳送ajax請求，伺服器接到請求後馬上返回響應資訊並關閉連線。 優點：後端程式編寫比較容易。 缺點：請求中有大半是無用，浪費頻寬和伺服器資源。 例項：適於小型應用。 長輪詢：客戶端向伺服器傳送Ajax請求，伺服器接到請求後hold住連線，直到有新訊息才返回響應資訊並關閉連線，客戶端處理完響應資訊後再向伺服器傳送新的請求。 優點：在無訊息的情況下不會頻繁的請求。 缺點：伺服器hold連線會消耗資源。 例項：WebQQ、Hi網頁版、Facebook IM。 另外，對於長連線和socket連線也有區分：

長連線：在頁面裡嵌入一個隱蔵iframe，將這個隱蔵iframe的src屬性設為對一個長連線的請求，伺服器端就能源源不斷地往客戶端輸入資料。 優點：訊息即時到達，不發無用請求。 缺點：伺服器維護一個長連線會增加開銷。 例項：Gmail聊天 Flash Socket：在頁面中內嵌入一個使用了Socket類的 Flash 程式JavaScript通過呼叫此Flash程式提供的Socket介面與伺服器端的Socket介面進行通訊，JavaScript在收到伺服器端傳送的資訊後控制頁面的顯示。 優點：實現真正的即時通訊，而不是偽即時。 缺點：客戶端必須安裝Flash外掛；非HTTP協議，無法自動穿越防火牆。 例項：網路互動遊戲。