整理一份計(jì)算機(jī)網(wǎng)絡(luò)基礎(chǔ)！

計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)

計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)有：

• OSI的七層協(xié)議體系結(jié)構(gòu)
• TCP/IP的四層協(xié)議體系結(jié)構(gòu)
• 五層協(xié)議的體系結(jié)構(gòu)

其中，OSI的七層協(xié)議體系結(jié)構(gòu)理論雖然完整，但它既復(fù)雜又不實(shí)用。廣泛應(yīng)用的是TCP/IP四層體系結(jié)構(gòu)。

五層協(xié)議的體系結(jié)構(gòu)只是為了介紹網(wǎng)絡(luò)原理而設(shè)計(jì)的，實(shí)際應(yīng)用的還是TCP/IP四層體系結(jié)構(gòu)。

TCP/IP協(xié)議族

1、TCP/IP協(xié)議模型

首先，我們需要知道一個(gè)協(xié)議族的概念。協(xié)議族是多個(gè)協(xié)議的統(tǒng)稱。，TCP/IP就是一個(gè)協(xié)議族。

其包含IP、TCP、UDP、HTTP、FTP、MQTT等協(xié)議。TCP/IP協(xié)議模型：

（圖片：《計(jì)算機(jī)網(wǎng)絡(luò)》謝希仁、《TCP/IP協(xié)議詳解》）

TCP/IP協(xié)議模型分四層，上層依賴于下層。

從下到上看：

（1）第一層鏈路層（網(wǎng)絡(luò)接口層）：

鏈路層規(guī)定了數(shù)據(jù)幀能被網(wǎng)卡接收的條件，最常見的方式是利用網(wǎng)卡的 MAC 地址，發(fā)送方會(huì)在欲發(fā)送的數(shù)據(jù)幀的首部加上接收方網(wǎng)卡的 MAC 地址信息，接收方只有監(jiān)聽到屬于自己的MAC 地址信息后，才會(huì)去接收并處理該數(shù)據(jù)。

（2）網(wǎng)絡(luò)層（網(wǎng)際層）：

網(wǎng)絡(luò)層實(shí)現(xiàn)了數(shù)據(jù)包在主機(jī)之間的傳遞 。相關(guān)協(xié)議：IP、ICMP等協(xié)議。

（3）傳輸層（運(yùn)輸層）：

傳輸層可以區(qū)分?jǐn)?shù)據(jù)包是屬于哪一個(gè)應(yīng)用程序的。相關(guān)協(xié)議：TCP、UDP協(xié)議。

（4）應(yīng)用層

應(yīng)用層提供特定的應(yīng)用服務(wù)。相關(guān)協(xié)議：HTTP、MQTT、FTP等協(xié)議。

應(yīng)用層以下的工作完成了數(shù)據(jù)的傳遞工作，應(yīng)用層則決定了你如何應(yīng)用和處理這些數(shù)據(jù)，之所以會(huì)有許多的應(yīng)用層協(xié)議， 是因?yàn)榛ヂ?lián)網(wǎng)中傳遞的數(shù)據(jù)種類很多、差異很大、應(yīng)用場(chǎng)景十分多樣。

2、網(wǎng)絡(luò)數(shù)據(jù)的發(fā)送與接收

（圖片來源：野火《LWIP應(yīng)用開發(fā)實(shí)戰(zhàn)指南》）

發(fā)送數(shù)據(jù)時(shí)， 將數(shù)據(jù)向下交給傳輸層。傳輸層會(huì)在數(shù)據(jù)前面加上傳輸層首部（此處以 TCP 協(xié)議為例， 傳輸層首部為 TCP 首部，也可以是 UDP 首部）， 然后向下交給網(wǎng)絡(luò)層。

同樣地，網(wǎng)絡(luò)層會(huì)在數(shù)據(jù)前面加上網(wǎng)絡(luò)層首部（IP 首部） ，然后將數(shù)據(jù)向下交給鏈路層， 鏈路層會(huì)對(duì)數(shù)據(jù)進(jìn)行最后一次封裝，即在數(shù)據(jù)前面加上鏈路層首部（此處使用以太網(wǎng)接口為例） ，然后將數(shù)據(jù)交給網(wǎng)卡。

數(shù)據(jù)的接收過程與發(fā)送過程正好相反，可以概括為 TCP/IP 的各層協(xié)議對(duì)數(shù)據(jù)進(jìn)行解析的過程。

3、IP協(xié)議

（1）概念

IP 協(xié)議（Internet Protocol），又稱之為網(wǎng)際協(xié)議， IP 協(xié)議處于 IP 層工作，它是整個(gè)TCP/IP 協(xié)議棧的核心協(xié)議，上層協(xié)議都要依賴 IP 協(xié)議提供的服務(wù)， IP 協(xié)議負(fù)責(zé)將數(shù)據(jù)報(bào)從源主機(jī)發(fā)送到目標(biāo)主機(jī) 。

IP 協(xié)議是一種無連接的不可靠數(shù)據(jù)報(bào)交付協(xié)議，協(xié)議本身不提供任何的錯(cuò)誤檢查與恢復(fù)機(jī)制。

（2）IP地址

在全球的互聯(lián)網(wǎng)中，每個(gè)主機(jī)都要唯一的一個(gè) IP 地址作為身份識(shí)別。每個(gè) IP 地址長(zhǎng)度為 32 比特（4 字節(jié)），使用點(diǎn)分十進(jìn)制記法 來表示，如192.168.0.1。

IP 地址劃分為 5 大類，分別為 A、 B、 C、 D、 E 五類，每一類地址都覺定了其中 IP 地址的一部分組成（圖片來源：野火《LWIP應(yīng)用開發(fā)實(shí)戰(zhàn)指南》）：

（圖片來源：野火《LWIP應(yīng)用開發(fā)實(shí)戰(zhàn)指南》）

（3）局域網(wǎng)、廣域網(wǎng)

• 局域網(wǎng)（Local Area Network， 縮寫為 LAN），又稱內(nèi)網(wǎng)， 指覆蓋局部區(qū)域（如辦公室或樓層）的計(jì)算機(jī)網(wǎng)絡(luò)。

查看本機(jī)內(nèi)網(wǎng)IP：

• 廣域網(wǎng)（Wide Area Network，縮寫為 WAN），又稱廣域網(wǎng)、外網(wǎng)、公網(wǎng)。是連接不同地區(qū)計(jì)算機(jī)以進(jìn)行通信的網(wǎng)絡(luò)。

查看本機(jī)外網(wǎng)IP：

• 查看某網(wǎng)站IP：

• 局域網(wǎng)與廣域網(wǎng)示意圖

（圖片來源：野火《LWIP應(yīng)用開發(fā)實(shí)戰(zhàn)指南》）

無線路由器把電腦、手機(jī)等設(shè)備連接到局域網(wǎng) LAN 上，并分配 IP 地址，即局域網(wǎng) IP ，我們可以稱之為 LAN-IP 。

路由器的地址就是運(yùn)營(yíng)商給我們的一個(gè) IP 地址，這個(gè) IP 地址是有效的，可以看做是 WAN-IP。

LAN-IP 是路由器分配給我們的 IP，那么我們想要跨越邊界進(jìn)入廣域網(wǎng)中， 就需要將 LAN-IP 變成有效的的 IP 地址，也就是 WAN-IP，那么在路由器中就需要將IP 地址進(jìn)行轉(zhuǎn)換，完成 LAN-IP<—>WAN-IP 地址轉(zhuǎn)換（NAT） 。

當(dāng)持有 WAN-IP 的 IP 包順利到達(dá)下一個(gè)邊界 Internet Gateway，這是通往互聯(lián)網(wǎng)Internet 的最后一道關(guān)卡，即邊界。

左邊是廣域網(wǎng)，右邊是互聯(lián)網(wǎng)， 也需要做 WAN-IP 與Global-IP（互聯(lián)網(wǎng)公共 IP）的轉(zhuǎn)換才能進(jìn)入互聯(lián)網(wǎng)中 。

（4）IP數(shù)據(jù)報(bào)

IP 數(shù)據(jù)報(bào)的格式如下所示：

（圖片來源：野火《LWIP應(yīng)用開發(fā)實(shí)戰(zhàn)指南》）

各字段說明：

• 版本號(hào)（4bit）：是IP協(xié)議的版本，對(duì)于IPv4，該值為4；對(duì)于IPv6，該值為6 。
• 首部長(zhǎng)度（4bit）：用于記錄 IP 首部的數(shù)據(jù)的長(zhǎng)度 。
• 服務(wù)類型（8bit）：包括：最小延時(shí)、最大傳輸、最大可靠性、最小消耗等。
• 數(shù)據(jù)報(bào)長(zhǎng)度（16bit）：IP 數(shù)據(jù)報(bào)的總長(zhǎng)度（首部加上數(shù)據(jù)區(qū)域），以字節(jié)為單位。
• 標(biāo)識(shí)（16bit）：識(shí)別號(hào)，主機(jī)每發(fā)一次都會(huì)自動(dòng)增加。
• 標(biāo)志（3bit）：標(biāo)記位，用于標(biāo)記是否被分段。
• 分片偏移量（13bit）：表示當(dāng)前分片所攜帶的數(shù)據(jù)在整個(gè) IP 數(shù)據(jù)報(bào)中的相對(duì)偏移位置（以 8 字節(jié)為單位） 。
• 生存時(shí)間（8bit）：該字段用來確保數(shù)據(jù)報(bào)不會(huì)永遠(yuǎn)在網(wǎng)絡(luò)中循環(huán) 。
• 上層協(xié)議（8bit）：指示了 IP 數(shù)據(jù)報(bào)的數(shù)據(jù)部分應(yīng)交給哪個(gè)特定的傳輸層協(xié)議（TCP、UDP）。
• 首部校驗(yàn)和（16bit）：首部檢驗(yàn)和用于幫助路由器檢測(cè)收到的 IP 數(shù)據(jù)報(bào)首部是否發(fā)生錯(cuò)誤。
• 源IP地址（32bit）。
• 目標(biāo)IP地址（32bit）。
• 選項(xiàng)：選項(xiàng)字段占據(jù) 0~40 個(gè)字節(jié)。
• 數(shù)據(jù)。

4、UDP協(xié)議

UDP 是 User Datagram Protocol 的簡(jiǎn)稱， 中文名是用戶數(shù)據(jù)報(bào)協(xié)議， 是一種無連接、不可靠的協(xié)議。

主要特點(diǎn)：

• 無連接、不可靠。
• 盡可能提供交付數(shù)據(jù)服務(wù)，出現(xiàn)差錯(cuò)直接丟棄，無反饋。
• 支持一對(duì)一， 一對(duì)多， 多對(duì)一，多對(duì)多的交互通信。
• 速度快， UDP 沒有握手、確認(rèn)、窗口、重傳、擁塞控制等機(jī)制 。
• 面向報(bào)文。

UDP 雖然有很多缺點(diǎn)， 但是也不排除其能用于很多場(chǎng)合， 因?yàn)樵谌缃竦木W(wǎng)絡(luò)環(huán)境下，UDP 協(xié)議傳輸出現(xiàn)錯(cuò)誤的概率是很小的， 并且它的實(shí)時(shí)性是非常好， 常用于實(shí)時(shí)視頻的傳輸，比如直播、網(wǎng)絡(luò)電話等。

因?yàn)榧词故浅霈F(xiàn)了數(shù)據(jù)丟失的情況，導(dǎo)致視頻卡幀，這也不是什么大不了的事情，所以， UDP 協(xié)議還是會(huì)被應(yīng)用與對(duì)傳輸速度有要求，并且可以容忍出現(xiàn)差錯(cuò)的數(shù)據(jù)傳輸中。

（1）UDP報(bào)文

（圖片來源：野火《LWIP應(yīng)用開發(fā)實(shí)戰(zhàn)指南》）

端口號(hào)的取值在0~65535 之間；16bit 的總長(zhǎng)度用于記錄 UDP 報(bào)文的總長(zhǎng)度，包括 8 字節(jié)的首部長(zhǎng)度與數(shù)據(jù)區(qū)域。相關(guān)文章：

【socket筆記】TCP、UDP通信總結(jié)

5、TCP協(xié)議

TCP 協(xié)議（TransmissionControl Protocol，傳輸控制協(xié)議），是一個(gè)面向連接的協(xié)議，無論哪一方向另一方發(fā)送數(shù)據(jù)之前，都必須先在雙方之間建立一個(gè)連接，否則將無法發(fā)送數(shù)據(jù)。

TCP數(shù)據(jù)是會(huì)封裝到IP數(shù)據(jù)當(dāng)中，我們現(xiàn)在看看TCP協(xié)議的頭部數(shù)據(jù)定義：

（圖片來源：野火《LWIP應(yīng)用開發(fā)實(shí)戰(zhàn)指南》、《TCP/IP協(xié)議詳解》）

• 16-bit source port number：16位源端口號(hào)
• 16-bit destination prot number：16位目標(biāo)端口號(hào)
• 32-bit sequence number ：32位順序號(hào)
• 32-bit acknowledgment number ：32位應(yīng)答號(hào)
• 4-bit header length：4位頭部長(zhǎng)度
• reserved(6 bit)：保留位
• URG：緊急標(biāo)志位
• ACK：應(yīng)答標(biāo)志位（表明應(yīng)答號(hào)之前的數(shù)據(jù)接收成功）
• PSH：不進(jìn)行緩存直接推送到應(yīng)用的標(biāo)志位
• RST：標(biāo)志重連接的標(biāo)志位
• SYN：同步順序號(hào)以初始化連接的標(biāo)志位
• FIN：發(fā)送數(shù)據(jù)完畢的標(biāo)志位（表明不會(huì)再發(fā)送數(shù)據(jù)過來）
• 16-bit window size：窗口大小（用于控流）
• 16-bit TCP checksum：檢驗(yàn)（檢驗(yàn)傳輸?shù)臄?shù)據(jù)是否正確）
• 16-bit urgent pointer：當(dāng)URG標(biāo)志被設(shè)置時(shí)有效，傳送緊急數(shù)據(jù)。

下面看一下TCP協(xié)議的一些特性：

（1）確認(rèn)與重傳

TCP 提供可靠的運(yùn)輸層， 但它依賴的是 IP 層的服務(wù)， IP 數(shù)據(jù)報(bào)的傳輸是無連接、 不可靠的，因此它要通過確認(rèn)來知道接收方確實(shí)已經(jīng)收到數(shù)據(jù)了。

但數(shù)據(jù)和確認(rèn)都有可能會(huì)丟失， 因此 TCP 通過在發(fā)送時(shí)設(shè)置一個(gè)超時(shí)機(jī)制（定時(shí)器） 來解決這種問題， 如果當(dāng)超時(shí)時(shí)間到達(dá)的時(shí)候還沒有收到對(duì)方的確認(rèn)，它就重傳該數(shù)據(jù)。

（2）緩沖機(jī)制

在發(fā)送方想要發(fā)送數(shù)據(jù)的時(shí)候， 由于應(yīng)用程序的數(shù)據(jù)大小、 類型都是不可預(yù)估的， 而TCP 協(xié)議提供了緩沖機(jī)制來處理這些數(shù)據(jù)。

如在數(shù)據(jù)量很小的時(shí)候， TCP 會(huì)將數(shù)據(jù)存儲(chǔ)在一個(gè)緩沖空間中， 等到數(shù)據(jù)量足夠大的時(shí)候在進(jìn)行發(fā)送數(shù)據(jù)， 這樣子能提供傳輸?shù)男什⑶覝p少網(wǎng)絡(luò)中的通信量。

而且在數(shù)據(jù)發(fā)送出去的時(shí)候并不會(huì)立即刪除數(shù)據(jù)，還是讓數(shù)據(jù)保存在緩沖區(qū)中，因?yàn)榘l(fā)送出去的數(shù)據(jù)不一定能被接收方正確接收，它需要等待到接收方的確認(rèn)再將數(shù)據(jù)刪除。

（3）全雙工通信

在 TCP 連接建立后，那么兩個(gè)主機(jī)就是對(duì)等的，任何一個(gè)主機(jī)都可以向另一個(gè)主機(jī)發(fā)送數(shù)據(jù)，數(shù)據(jù)是雙向流通的，所以 TCP 協(xié)議是一個(gè)全雙工的協(xié)議。

（4）流量控制

TCP 提供了流量控制服務(wù)（flow-control service）以消除發(fā)送方使接收方緩沖區(qū)溢出的可能性。

流量控制是一個(gè)速度匹配服務(wù)，即發(fā)送方的發(fā)送速率與接收方應(yīng)用程序的讀取速率相匹配， TCP 通過讓發(fā)送方維護(hù)一個(gè)稱為接收窗口（receive window）的變量來提供流量控制。

（5）差錯(cuò)控制

除了確認(rèn)與重傳之外， TCP 協(xié)議也會(huì)采用校驗(yàn)和的方式來檢驗(yàn)數(shù)據(jù)的有效性，主機(jī)在接收數(shù)據(jù)的時(shí)候，會(huì)將重復(fù)的報(bào)文丟棄，將亂序的報(bào)文重組。

發(fā)現(xiàn)某段報(bào)文丟失了會(huì)請(qǐng)求發(fā)送方進(jìn)行重發(fā)，因此在 TCP 往上層協(xié)議遞交的數(shù)據(jù)是順序的、無差錯(cuò)的完整數(shù)據(jù)。

關(guān)于TCP協(xié)議的一些其它內(nèi)容如三次握手、四次揮手、示例等可以看以下文章：

C語言、嵌入式應(yīng)用：TCP通信實(shí)例分析

【面試必考】TCP協(xié)議“三次握手”與“四次揮手”

【socket筆記】TCP、UDP通信總結(jié)

6、HTTP協(xié)議

HTTP 協(xié)議是 Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫， 是用于從萬維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議。

它是基于TCP/IP 協(xié)議通信的，因此它也是基于客戶端-服務(wù)器模型運(yùn)作的，是一個(gè)應(yīng)用層協(xié)議，可以用它來傳輸服務(wù)器的各種資源，如文本、圖片、音頻等。

HTTP 協(xié)議的特點(diǎn)：

• 簡(jiǎn)單：當(dāng)客戶端向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑即可獲取服務(wù)器的資源， 請(qǐng)求方法常用的有 GET、 HEAD、 POST 等， 每種方法規(guī)定了客戶端與服務(wù)器通信的類型不同。
• 快捷：由于 HTTP 協(xié)議簡(jiǎn)單，使得 HTTP 服務(wù)器的程序規(guī)模小，因而通信速度很快。
• 靈活：HTTP 允許傳輸任意類型的數(shù)據(jù)對(duì)象， 傳輸?shù)念愋陀?Content-Type 加以標(biāo)記。
• 無連接：簡(jiǎn)單來說就是每進(jìn)行一次 HTTP 通信，都要斷開一次 TCP 連接 。可隨著 HTTP 的普及，文檔中包含大量圖片的情況多了起來，每次請(qǐng)求完都要斷開 TCP 連接，無疑增加通信量的開銷為了解決 TCP的連接問題， HTTP1.1 提出了持久連接的方法。
• 無狀態(tài)： 無狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力。但其實(shí)這種無狀態(tài)對(duì)于用戶來說也是不友好的（比如：很多網(wǎng)站必須要記住已經(jīng)登陸過的用戶，總不能每刷新一次頁面就要求用戶重新輸入帳號(hào)密碼），因此為了解決無狀態(tài)的問題，引入了 Cookie 技術(shù)，這是一種可以讓服務(wù)器知道用戶上一次做了什么操作，并且記錄下來。

（1）URL 與資源

URL 全稱是 Uniform Resource Locator， 中文叫統(tǒng)一資源定位符， 是互聯(lián)網(wǎng)上用來標(biāo)識(shí)某一處資源的絕對(duì)地址，使用它我們就必然能找到資源，除非資源已經(jīng)被轉(zhuǎn)移了。

URI （Uniform Resource Identifiers）是一個(gè)通用的概念，由兩個(gè)子集組成，分別是 URL 和 URN， URL 是通過資源的位置來標(biāo)識(shí)資源，而 URN 更高級(jí)一點(diǎn)，只需通過資源名字即可識(shí)別資源，與他們所處的位置是無關(guān)的，目前暫時(shí)還未推廣 URN。

URL的通用格式如下（絕大部分的 URL 是不會(huì)包含所有組件的內(nèi)容的 ）：

（圖片來源：野火《LWIP應(yīng)用開發(fā)實(shí)戰(zhàn)指南》）

（2）HTTP報(bào)文

① 請(qǐng)求報(bào)文：

（圖片來源：野火《LWIP應(yīng)用開發(fā)實(shí)戰(zhàn)指南》）

• method （方法）：HTTP 請(qǐng)求報(bào)文的起始行以方法作為開始，方法用來告知服務(wù)器要做些什么， 常見的方法有GET、 POST、 HEAD` 等 。

• 請(qǐng)求 URL（request-URL） ：指定了所請(qǐng)求的資源。

• 版本（version）：指定報(bào)文所使用的 HTTP 協(xié)議版本 。

② 應(yīng)答報(bào)文：

（圖片來源：野火《LWIP應(yīng)用開發(fā)實(shí)戰(zhàn)指南》）

• 狀態(tài)碼（status）：這是在 HTTP 應(yīng)答報(bào)文中使用的。不同狀態(tài)碼代表不同的含義：

（圖片來源：野火《LWIP應(yīng)用開發(fā)實(shí)戰(zhàn)指南》）

實(shí)例：

7、MQTT協(xié)議

MQTT 協(xié)議全稱是 Message Queuing Telemetry Transport，翻譯過來就是消息隊(duì)列遙測(cè)傳輸協(xié)議，它是物聯(lián)網(wǎng)常用的應(yīng)用層協(xié)議。

其運(yùn)行在 TCP/IP 中的應(yīng)用層中，依賴 TCP 協(xié)議，因此它具有非常高的可靠性，同時(shí)它是基于 TCP 協(xié)議的<客戶端-服務(wù)器>模型發(fā)布/訂閱主題消息的輕量級(jí)協(xié)議。

（1）MQTT通信模型

（圖片來源：野火《LWIP應(yīng)用開發(fā)實(shí)戰(zhàn)指南》）

MQTT協(xié)議是基于客戶端-服務(wù)器模型，在協(xié)議中主要有三種身份：發(fā)布者（Publisher）、服務(wù)器（Broker） 以及訂閱者（Subscriber）。

MQTT 消息的發(fā)布者和訂閱者都是客戶端，服務(wù)器只是作為一個(gè)中轉(zhuǎn)的存在，將發(fā)布者發(fā)布的消息進(jìn)行轉(zhuǎn)發(fā)給所有訂閱該主題的訂閱者。

MQTT 客戶端的功能：

• 發(fā)布消息給其它相關(guān)的客戶端。
• 訂閱主題請(qǐng)求接收相關(guān)的應(yīng)用消息。
• 取消訂閱主題請(qǐng)求移除接收應(yīng)用消息。
• 從服務(wù)端終止連接。

MQTT 服務(wù)器常被稱為 Broker（消息代理） 。它的功能有：

• 接受來自客戶端的網(wǎng)絡(luò)連接請(qǐng)求。
• 接受客戶端發(fā)布的應(yīng)用消息。
• 處理客戶端的訂閱和取消訂閱請(qǐng)求。
• 轉(zhuǎn)發(fā)應(yīng)用消息給符合條件的已訂閱客戶端（包括發(fā)布者自身）。

（2）MQTT消息

MQTT所發(fā)的消息包含：主題+內(nèi)容，客戶端可以訂閱任意主題，若有其它客戶端發(fā)布主題時(shí)符合所訂閱的主題，就會(huì)由網(wǎng)關(guān)發(fā)送到客戶端。

什么是主題？

MQTT 服務(wù)器為每個(gè)連接的客戶端（訂閱者）添加一個(gè)標(biāo)簽，該標(biāo)簽與服務(wù)器中的所有訂閱相匹配， 服務(wù)器會(huì)將消息轉(zhuǎn)發(fā)給與標(biāo)簽相匹配的每個(gè)客戶端。這樣的一個(gè)標(biāo)簽就是主題。

實(shí)例：

服務(wù)質(zhì)量：

MQTT提供三種服務(wù)質(zhì)量（Quality of Service，簡(jiǎn)寫QoS），供開發(fā)者根據(jù)不同的情景選擇不同的服務(wù)級(jí)別：

• QoS0：最多發(fā)送一次消息，在消息發(fā)送出去后，接收者不會(huì)發(fā)送回應(yīng)，發(fā)送者也不會(huì)重發(fā)消息。

• QoS1：最少發(fā)送一次消息（消息最少需要送達(dá)一次，也有可送達(dá)多次）， QoS 1的 PUBLISH 報(bào)文的可變報(bào)頭中包含一個(gè)報(bào)文標(biāo)識(shí)符，需要 PUBACK 報(bào)文確認(rèn)。

• QoS2：這是最高等級(jí)的服務(wù)質(zhì)量，消息丟失和重復(fù)都是不可接受的。只不過使用這個(gè)服務(wù)質(zhì)量等級(jí)會(huì)有額外的開銷，這個(gè)等級(jí)常用于支付中，因?yàn)橹Ц妒潜仨氂星覂H有一次成功，總不能沒給錢或者給了多次錢吧。

以上就是本次分享的一些計(jì)算機(jī)網(wǎng)絡(luò)基礎(chǔ)知識(shí)，計(jì)算機(jī)網(wǎng)絡(luò)的內(nèi)容很多，一篇文章不可能全部覆蓋，以上也僅僅是一些概括性地抽取一些表層內(nèi)容過來分享，需要閱讀相關(guān)書籍來加深學(xué)習(xí)。