長鏈接、短鏈接、長輪詢和WebSocket

原文連接：http://caibaojian.com/http-connection-and-websocket.html

 

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

長鏈接：在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。如：

//code from http://caibaojian.com/http-connection-and-websocket.html
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
來源：知乎

1. 輪詢：客戶端定時向服務器發送ajax請求，服務器接到請求後立刻返回響應信息並關閉鏈接。
   優勢：後端程序編寫比較容易。
   缺點：請求中有大半是無用，浪費帶寬和服務器資源。
   實例：適於小型應用。
2. 長輪詢：客戶端向服務器發送Ajax請求，服務器接到請求後hold住鏈接，直到有新消息才返回響應信息並關閉鏈接，客戶端處理完響應信息後再向服務器發送新的請求。
   優勢：在無消息的狀況下不會頻繁的請求。
   缺點：服務器hold鏈接會消耗資源。
   實例：WebQQ、Hi網頁版、Facebook IM。

另外，對於長鏈接和socket鏈接也有區分：

1. 長鏈接：在頁面裏嵌入一個隱蔵iframe，將這個隱蔵iframe的src屬性設爲對一個長鏈接的請求，服務器端就能源源不斷地往客戶端輸入數據。
   優勢：消息即時到達，不發無用請求。
   缺點：服務器維護一個長鏈接會增長開銷。
   實例：Gmail聊天
2. Flash Socket：在頁面中內嵌入一個使用了Socket類的 Flash 程序JavaScript經過調用此Flash程序提供的Socket接口與服務器端的Socket接口進行通訊，JavaScript在收到服務器端傳送的信息後控制頁面的顯示。 優勢：實現真正的即時通訊，而不是僞即時。 缺點：客戶端必須安裝Flash插件；非HTTP協議，沒法自動穿越防火牆。 實例：網絡互動遊戲。