一、計算機網(wǎng)絡的層次結構

1、兩種模型（TCP/IP四層模型與OSI體系）對應的結構，以及TCP/IP模型各個層級對應的協(xié)議

1、TCP/IP協(xié)議

• TCP/IP 是用于因特網(wǎng) (Internet) 的通信協(xié)議，是對計算機必須遵守的規(guī)則的描述，只有遵守這些規(guī)則，計算機之間才能進行通信。
• TCP/IP是基于TCP和IP這兩個最初的協(xié)議之上的不同的通信協(xié)議的大集合，是一個協(xié)議族。

1-1、TCP（傳輸控制協(xié)議，Transmission Control Protocol）

• 在計算機網(wǎng)絡中屬于傳輸層，是TCP/IP協(xié)議棧中最核心的協(xié)議之一
• 面向連接：一種可靠的傳輸服務，使用前必須先建立連接，傳輸完成后釋放
• 點對點：每一條tcp協(xié)議只能是一對一的，TCP 連接的端點叫做套接字，套接字 socket = (IP 地址：端口號)，每一條 TCP 連接唯一地被通信兩端的兩個端點(即兩個套接字)所確定。（注意：該socket和經(jīng)常說的socket編程中的socket不是一個東西，后者的全稱應該是Socket API）
• 全雙工通信：允許通信雙方的應用進程在任何時候都能發(fā)送數(shù)據(jù)
• 流模式：數(shù)據(jù)被作為無結構的字節(jié)流
• 有序的：為每個由其傳輸?shù)淖侄沃付樞蛱?，對于發(fā)送的每一個分段，接收主機必須在一個指定的時間內(nèi)返回一個確認信息，發(fā)送者未收到確認，數(shù)據(jù)會被重新發(fā)送

1-2、IP協(xié)議（互聯(lián)網(wǎng)協(xié)議，Internet Protocol）

• 在計算機網(wǎng)絡中屬于網(wǎng)際層（網(wǎng)絡層/網(wǎng)絡互連層），是TCP/IP協(xié)議棧中最核心的協(xié)議之一
• 無連接的協(xié)議：主要通過IP地址，保證了聯(lián)網(wǎng)設備的唯一性
• 不可靠的數(shù)據(jù)傳輸：不能保證數(shù)據(jù)包一定能到達對方，數(shù)據(jù)是否會被丟棄以及丟棄之后如何處理

二、HTTP協(xié)議(超文本傳輸協(xié)議，HyperText Transfer Protocol)

• 基于TCP協(xié)議的應用層傳輸協(xié)議，簡單來說就是客戶端和服務端進行數(shù)據(jù)傳輸?shù)囊环N規(guī)則。
• 無狀態(tài)協(xié)議：HTTP協(xié)議本身不會對發(fā)送過的請求和相應的通信狀態(tài)進行持久化處理，由于HTTP是無狀態(tài)協(xié)議，通常在網(wǎng)頁上引入cookie之類技術來記錄狀態(tài)
• 無連接協(xié)議：基于請求-響應的模式，每次連接只處理一個請求，即一個Request和一個Response對應了整個連接，響應后斷開連接。（在后續(xù)的版本中添加了Connection: Keep-Alive實現(xiàn)長連接）
• 任意類型的數(shù)據(jù)對象：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標記
• 半雙工通信：允許數(shù)據(jù)在兩個方向上傳輸，但是在某一時刻，只允許數(shù)據(jù)在一個方向上傳輸

HTTP工作原理

1、客戶端連接到服務器

一個HTTP客戶端與服務器建立一個TCP套接字連接

2、發(fā)送HTTP請求

通過TCP套接字，向服務器發(fā)送一個文本的請求報文（請求行、請求頭、請求數(shù)據(jù)、空行）

3、服務器接受請求并返回HTTP響應

服務器解析請求，將資源寫到TCP套接字，由客戶端讀取響應內(nèi)容（狀態(tài)行、響應頭部、空行、響應數(shù)據(jù)）

4、釋放連接TCP連接

若connection模式為close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接;若connection模式為keepalive，則該連接會保持段時間，在該時間內(nèi)可以繼續(xù)接收請求

5、客戶端解析響應數(shù)據(jù)

通過狀態(tài)行、響應頭等相關內(nèi)容進行資源解析

三、WebSocket協(xié)議

要使用HTTP實現(xiàn)雙向通訊，傳統(tǒng)的方式即進行輪詢已達到效果（即每隔一段時間，想服務器發(fā)出請求獲取最新的數(shù)據(jù)），常見的輪詢方式分為輪詢（定時請求）和長輪詢（請求后服務器在有數(shù)據(jù)變化時才響應，客戶端在請求快過期前或請求響應后，再次發(fā)起請求）。

這種傳統(tǒng)的模式帶來很明顯的缺點，即瀏覽器需要不斷的向服務器發(fā)出請求，然而 HTTP 請求與響應可能會包含較長的頭部，其中真正有效的數(shù)據(jù)可能只是很小的一部分，所以這樣會消耗很多帶寬資源。

HTML5定義了 WebSocket 協(xié)議，能更好的節(jié)省服務器資源和帶寬，并且能夠更實時地進行通訊。

• 基于TCP協(xié)議的應用層傳輸協(xié)議
• 持久連接：連接創(chuàng)建后，客戶端和服務端的數(shù)據(jù)傳輸不用新建連接。
• 全雙工通信：客戶端和服務端可以雙向通信
• 較少的開銷：數(shù)據(jù)交換時，數(shù)據(jù)包頭較小

1、WebSocket連接的建立

當客戶端想要使用 WebSocket 協(xié)議與服務端進行通信時, 首先需要確定服務端是否支持 WebSocket 協(xié)議, 因此 WebSocket 協(xié)議的第一步是進行握手, WebSocket 握手采用 HTTP Upgrade 機制, 客戶端可以發(fā)送如下所示的結構發(fā)起握手 (請注意 WebSocket 握手只允許使用 HTTP GET 方法):

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

在 HTTP Header 中設置 Upgrade 字段, 其字段值為 websocket, 并在 Connection 字段指示 Upgrade, 服務端若支持 WebSocket 協(xié)議, 并同意握手:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Version: 13

客戶端校驗返回內(nèi)容，握手成功則將通信協(xié)議升級到WebSocket，至此就可以使用WebSocket協(xié)議進行客戶端-服務端數(shù)據(jù)交換。

2、WebSocket端口：

WebSockets使用HTTP Upgrade機制升級到Web Socket協(xié)議，因此HTTP服務器可以與WebSocket服務器共享默認的HTTP與HTTPS端。默認情況下：WebSocket 協(xié)議使用 80 端口、若運行在 TLS 之上時，默認使用 443 端口

3、WebSocket與Socket的關系

• WebSocket 和 Socket 并無關系
• 套接字（socket）在TCP/IP之上，位于傳輸層和應用層之間的一個抽象層，并不是一個協(xié)議，傳輸層的低一層協(xié)議服務socket，socket服務應用層。socket其實就是是一組API，提供了對TCP/IP的相關操作

4、WebSocket與HTTP的關系

• 都屬于應用層協(xié)議，基于TCP/IP協(xié)議，是可靠的傳輸協(xié)議
• WebSocket支持持久連接，HTTP不支持持久連接（HTTP使用Connection: Keep-Alive也可實現(xiàn)長連接，但HTTP的生命周期還是屬于一個Request對應一個Response）
• WebSocket是雙向通信協(xié)議，HTTP是單向協(xié)議
• WebSocket協(xié)議在第一次握手連接時，通過HTTP協(xié)議
• HTTP服務器可以與WebSocket服務器共享默認的HTTP與HTTPS端（80和443）

四、STOMP協(xié)議（簡單(流)文本定向消息協(xié)議，Simple (or Streaming) Text Orientated Messaging Protocol）

WebSocket協(xié)議只會將字節(jié)流轉換為文本/二進制消息，使用時需要定義應用間所發(fā)送消息的語義，還需要確保Client和Server都能遵循這些語義。比如：在消息中有一個type，當type為subscribe時，表示訂閱消息，當type為message時表示發(fā)送了一條消息。在使用WebSocket的時候，我們不同的地方使用都要做類似的工作：“設計message”，也就是常說的“WebSocket的通信形式層級過低”

• STOMP是一種為MOM(Message Oriented Middleware，面向消息的中間件)設計的簡單文本協(xié)議，提供了一個可互操作的連接格式，用于client之間進行異步消息傳輸?shù)暮唵挝谋緟f(xié)議
• STOMP協(xié)議并不是為websocket設計的, 它是屬于消息隊列的一種協(xié)議，STOMP協(xié)議可以建立在WebSocket之上，也可以建立在其他應用層協(xié)議之上（一般也就是WebSocket了）
• STOMP 提供了一個基于幀的線路格式（借鑒了HTTP），使用不同的幀，表示不同的含義
  

文章來源地址http://www.zghlxwxcb.cn/news/detail-852534.html

五、MQTT協(xié)議（消息隊列遙測傳輸協(xié)議，Message Queuing Telemetry Transport）

• 基于發(fā)布/訂閱（publish/subscribe）模式的“輕量級”通訊協(xié)議，該協(xié)議構建于TCP/IP協(xié)議上，屬于應用層協(xié)議
• 消息不是直接從發(fā)送器發(fā)送到接收器，是由MQTT server（或稱為 MQTT Broker）分發(fā)。（區(qū)別于WebSocket的點對點）
• 可以以極少的代碼和有限的帶寬，為連接遠程設備提供實時可靠的消息服務，常用于物聯(lián)網(wǎng)（IoT）應用中的設備間通信
• MQTT協(xié)議中有三種身份：發(fā)布者（Publish）、代理（Broker）（服務器）、訂閱者（Subscribe）。其中，消息的發(fā)布者和訂閱者都是客戶端，消息代理是服務器，消息發(fā)布者可以同時是訂閱者。發(fā)布者和消費者之間并不關心對方，都只和代理（Broker）（服務器）打交道
• 提供心跳機制、遺囑消息、QoS 質(zhì)量等級+離線消息、主題和安全管理等多種特性

六、MQTT與WebSocket

1、相同點

• MQTT 和 WebSocket 都是應用層協(xié)議
• 都是使用 TCP 協(xié)議確?？煽總鬏敂?shù)據(jù)
• 都支持雙向通信
• 都使用二進制傳輸

2、通信模型

• WebSocket 是一種簡單的報文協(xié)議，僅僅定義了會話的發(fā)起方式和報文格式及類型。如何使用報文通信全由應用程序控制
• MQTT 是一種比較復雜的消息協(xié)議，規(guī)定了客戶端和服務器的通信模型，是一種面向主題（topic）的消息廣播協(xié)議，基于發(fā)布/訂閱模式
• MQTT 是一套比較復雜的消息投遞協(xié)議，而 WebSocket則只是在TCP協(xié)議之上實現(xiàn)了簡單的報文通信。兩種協(xié)議工作層次不一樣，也就是常說的“WebSocket的通信形式層級過低”

3、連接建立方式

• WebSocket 基于 HTTP/1.1 的 Upgrade 機制協(xié)商會話，協(xié)商完成后協(xié)議由HTTP升級到WebSocket，完成雙工信道的建立
• MQTT 協(xié)議則需要通過 CONNECT 報文協(xié)商會話，TCP連接建立之后，客戶端會主動發(fā)送 CONNECT 報文。服務端準備好之后會回應 CONNACK 報文，完成雙工信道的建立

4、消息收發(fā)方式

• WebSocket 收發(fā)消息不需要對方確認
• MQTT 收發(fā)消息需要根據(jù)投遞級別（QoS）進行確認：QoS 0（最多一次）、QoS 1（最少一次）、QoS 2（恰好一次）

5、?；顧C制

• WebSocket 只規(guī)定了 ping/pong 兩種報文，用于心跳探測，但協(xié)議并不強制要求定時收發(fā)心跳包
• MQTT 則有明確的心跳協(xié)商機制。協(xié)商會話使用的 CONNECT 報文包含 Keep Alive 頭部信息，使用兩個字節(jié)傳輸心跳間隔，單位是秒。會話協(xié)商后需要定時收發(fā) PINGREQ 和 PINGRESP 報文。

6、使用場景

• MQTT是為了物聯(lián)網(wǎng)場景設計的基于TCP的Pub/Sub協(xié)議，有許多為物聯(lián)網(wǎng)優(yōu)化的特性，比如適應不同網(wǎng)絡的QoS、層級主題、遺言等等
• WebSocket是為了HTML5應用方便與服務器雙向通訊而設計的協(xié)議，HTTP握手然后轉TCP協(xié)議，用于取代之前的Server Push、Comet、長輪詢等老舊實現(xiàn)

到了這里，關于HTTP、WebSocket、STOMP、MQTT 協(xié)議的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！