websocket以及http的區別筆記

區別

'http'

HTTP1.1默認使用持久鏈接（persistent connection），在一個TCP鏈接上也能夠傳輸多個Request/Response消息對，可是HTTP的基本模型仍是一個Request對應一個Response

連接方式：主要有幾種

• 輪詢（polling），輪詢就會形成對網絡和通訊雙方的資源的浪費，且非實時。
• 長輪詢，客戶端發送一個超時時間很長的Request，服務器hold住這個鏈接，在有新數據到達時返回Response，相比1，佔用的網絡帶寬少了，其餘相似。穩定性有待考究
• 長鏈接，其實有些人對長鏈接的概念是模糊不清的，我這裏講的實際上是HTTP的長鏈接（1）

• 若是你使用Socket來創建TCP的長鏈接（2）

• 那麼，這個長鏈接（2）跟咱們這裏要討論的WebSocket是同樣的，實際上TCP長鏈接就是WebSocket的基礎，可是若是是HTTP的長鏈接，本質上仍是Request/Response消息對，仍然會形成資源的浪費、實時性不強等問題。

  

websocket的協議基礎基於http 握手+傳輸

而真正在WS的握手過程當中起到做用的是下面幾個header域。
1 Upgrade：upgrade是HTTP1.1中用於定義轉換協議的header域。它表示，若是服務器支持的話，客戶端但願使用現有的「網絡層」已經創建好的這個「鏈接（此處是TCP鏈接）」，切換到另一個「應用層」（此處是WebSocket）協議。

2 Connection：HTTP1.1中規定Upgrade只能應用在「直接鏈接」中，因此帶有Upgrade頭的HTTP1.1消息必須含有Connection頭，由於Connection頭的意義就是，任何接收到此消息的人（每每是代理服務器）都要在轉發此消息以前處理掉Connection中指定的域（不轉發Upgrade域）。
若是客戶端和服務器之間是經過代理鏈接的，那麼在發送這個握手消息以前首先要發送CONNECT消息來創建直接鏈接。

3 Sec-WebSocket-＊：第7行標識了客戶端支持的子協議的列表（關於子協議會在下面介紹），第8行標識了客戶端支持的WS協議的版本列表，第5行用來發送給服務器使用（服務器會使用此字段組裝成另外一個key值放在握手返回信息裏發送客戶端）。

4 Origin：做安全使用，防止跨站攻擊，瀏覽器通常會使用這個來標識原始域。

複製代碼

• WebSocket協議Uri

1 若是上一步中的TCP鏈接創建失敗，則此WebSocket鏈接失敗。
2 若是協議是wss，則在上一步創建的TCP鏈接之上，使用TSL發送握手信息。若是失敗，則此WebSocket鏈接失敗；若是成功，則之後的全部數據都要經過此TSL通道進行發送。
複製代碼

• WebSocket使用注意點

服務端 若是請求是HTTPS，則首先要使用TLS進行握手，若是失敗，則關閉鏈接，若是成功，則以後的數據都經過此通道進行發送

以後服務端能夠進行一些客戶端驗證步驟

若是一切都成功，則返回成功的Response握手消息。

• 服務端發送的成功的Response握手

Upgrade頭域，內容爲websocket

Connection頭域，內容爲Upgrade

Sec-WebSocket-Accept頭域，其內容的生成步驟：

首先將Sec-WebSocket-Key的內容加上字符串258EAFA5-E914-47DA-95CA-C5AB0DC85B11（一個UUID）。

將#1中生成的字符串進行SHA1編碼。

將#2中生成的字符串進行Base64編碼。

• Sec-WebSocket-Protocol頭域（可選）
• Sec-WebSocket-Extensions頭域（可選）

與HTTP比較
一樣做爲應用層的協議，WebSocket在現代的軟件開發中被愈來愈多的實踐，和HTTP有不少類似的地方，這裏將它們簡單的作一個純我的、非權威的比較：

相同點:
都是基於TCP的應用層協議。
都使用Request/Response模型進行鏈接的創建。
在鏈接的創建過程當中對錯誤的處理方式相同，在這個階段WS可能返回和HTTP相同的返回碼。
均可以在網絡中傳輸數據。

不一樣點:
WS使用HTTP來創建鏈接，可是定義了一系列新的header域，這些域在HTTP中並不會使用。
WS的鏈接不能經過中間人來轉發，它必須是一個直接鏈接。
WS鏈接創建以後，通訊雙方均可以在任什麼時候刻向另外一方發送數據。
WS鏈接創建以後，數據的傳輸使用幀來傳遞，再也不須要Request消息。
WS的數據幀有序。
```複製代碼