要理解http長連線和websocket長連線的區別，首先要理解一下什麼是http的長連線和短連線。
首先需要消除乙個誤解：http協議是基於請求/響應模式的，因此客戶端請求後只要服務端給了響應，本次http請求就結束了，沒有長連線這一說。那麼自然也就沒有短連線這一說了。
所謂的http分為長連線和短連線，其實本質上是說的tcp連線。tcp連線是乙個雙向的通道，它是可以保持一段時間不關閉的，因此tcp連線才有真正的長連線和短連線這一說。
http協議是應用層的協議，而tcp才是真正的傳輸層協議，只有負責傳輸的這一層才需要建立連線。
過程：連線->傳輸資料->關閉連線
短鏈結就是瀏覽器和伺服器每進行一次http操作，就建立一次連線，但任務結束就中斷連線。 比如http1.0。
具體就是 瀏覽器client發起並建立tcp連線 -> client傳送httprequest報文 -> server接收到報文->server handle並傳送httpresponse報文給前端,傳送完畢之後立即呼叫socket.close方法->client接收response報文->client最終會收到server端斷開tcp連線的訊號->client 端斷開tcp連線，具體就是呼叫close方法。
也就是說，短連線是指socket連線後，傳送接收完資料後馬上斷開連線。 因為連線後接收了資料就斷開了，所以每次資料接受處理不會有聯絡。 這也是http協議無狀態的原因之一。
過程：連線->傳輸資料->保持連線 -> 傳輸資料-> ………..->一方關閉連線
長連線指建立socket連線後不管是否使用都保持tcp連線。
http1.1預設是長連線，也就是預設connection的值就是keep-alive，本次請求響應結束後，tcp連線將仍然保持開啟狀態，所以瀏覽器可以繼續通過相同的連線傳送請求，節省了很多tcp連線建立和斷開的消耗，還節約了頻寬。
長連線並不是永久連線的。如果一段時間內（具體的時間可以在header當中進行設定，也就是所謂的超時時間），這個連線沒有http請求發出的話，那麼這個長連線就會被斷掉。這一點其實很容易理解，否則的話，tcp連線將會越來越多，直到把伺服器的tcp連線數量撐爆為止。
http1.1中，connection預設為keep-alive引數，官方的說法是可以用這個來作為長連線。那麼問題來了，既然http1.1支援長連線，為什麼還要搞出乙個websocket呢？
keep-alive的確可以實現長連線，但是這個長連線是有問題的，本質上依然是客戶端主動發起-服務端應答的模式，是沒法做到服務端主動傳送通知給客戶端的。也就是說，在乙個http連線中，可以傳送多個request，接收多個response。但是乙個request只能有乙個response。而且這個response也是被動的，不能主動發起。開啟了keep-alive，可以看出依然是一問一答的模式，只是省略了每次的關閉和開啟操作。
websocket是可以互相主動發起的。相對於傳統 http 每次請求-應答都需要客戶端與服務端建立連線的模式，websocket 是類似 tcp 長連線的通訊模式，一旦 websocket 連線建立後，後續資料都以幀序列的形式傳輸。在客戶端斷開 websocket 連線或 server 端斷掉連線前，不需要客戶端和服務端重新發起連線請求。在海量併發及客戶端與伺服器互動負載流量大的情況下，極大的節省了網路頻寬資源的消耗，有明顯的效能優勢，且客戶端傳送和接受訊息是在同乙個持久連線上發起，實時性優勢明顯。
websocket api 是 html5 標準的一部分， 但這並不代表 websocket 一定要用在 html 中，或者只能在基於瀏覽器的應用程式中使用。
在websocket中，只需要伺服器和瀏覽器通過http協議進行乙個握手的動作，然後單獨建立一條tcp的通訊通道進行資料的傳送。websocket同http一樣也是應用層的協議，但是它是一種雙向通訊協議，是建立在tcp之上的。
websocket的流程大概是以下幾步：
1、瀏覽器、伺服器建立tcp連線，三次握手。這是通訊的基礎，傳輸控制層，若失敗後續都不執行。
2、tcp連線成功後，瀏覽器通過http協議向伺服器傳送websocket支援的版本號等資訊。（開始前的http握手）伺服器收到客戶端的握手請求後，同樣採用http協議回饋資料。
3、連線成功後，雙方通過tcp通道進行資料傳輸，不需要http協議。
也就是說websocket在建立握手時，資料是通過http傳輸的。但是建立之後，在真正傳輸時候是不需要http協議的。
websocket 客戶端連線報文
sec-websocket-version: 13客戶端發起的 websocket 連線報文類似傳統 http 報文，」upgrade：websocket」引數值表明這是 websocket 型別請求，「sec-websocket-key」是 websocket 客戶端傳送的乙個 base64 編碼的密文，要求服務端必須返回乙個對應加密的「sec-websocket-accept」應答，否則客戶端會丟擲「error during websocket handshake」錯誤，並關閉連線。
服務端收到報文後返回的資料格式類似：
websocket 服務端響應報文：
sec-websocket-accept: k7djldlooiwig/mopvwfb3y3fe8=「sec-websocket-accept」的值是服務端採用與客戶端一致的金鑰計算出來後返回客戶端的,「http/1.1 101 switching protocols」表示服務端接受 websocket 協議的客戶端連線，經過這樣的請求-響應處理後，客戶端服務端的 websocket 連線握手成功, 後續就可以進行 tcp 通訊了。
參考：
HTTP 長連線和短連線
1.http協議與tcp ip協議的關係 http的長連線和短連線本質上是tcp長連線和短連線。http屬於應用層協議，在傳輸層使用tcp協議，在網路層使用ip協議。ip協議主要解決網路路由和定址問題，tcp協議主要解決如何在ip層之上可靠的傳遞資料報，使在網路上的另一端收到發端發出的所有包，並且順...
HTTP的長連線和短連線
http的長連線和短連線本質上是tcp長連線和短連線。http屬於應用層協議.短連線 瀏覽器和伺服器每進行一次http操作，就建立一次連線，但任務結束就中斷連線。長連線 當乙個網頁開啟完成後，客戶端和伺服器之間用於傳輸http資料的 tcp連線不會關閉，如果客戶端再次訪問這個伺服器上的網頁，會繼續使...
http的長連線和短連線
很久之前就聽說過長連線的說法，而且還知道http1.0協議不支援長連線，從http1.1協議以後，連線預設都是長連線。但終究覺得對於長連線一直懵懵懂懂的，有種抓不到關鍵點的感覺。今天通過一番研究，終於明白了這其中的奧秘。而之前，也看過長連線相關的內容，但一直都是雲裡霧裡的。這次之所以能在這麼短的時間...