對這四個概念不太清楚，今天專門搜索瞭解一下，總結一下：
長連接：在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協議，無法自動穿越防火牆。
實例：網絡互動遊戲。