內容整理自：書籍、網絡
編輯排版：嵌入式大雜燴
計算機網絡體系結構有：
其中，OSI的七層協議體系結構理論雖然完整，但它既復雜又不實用。廣泛應用的是TCP/IP四層體系結構。
五層協議的體系結構只是為了介紹網絡原理而設計的，實際應用的還是TCP/IP四層體系結構。
首先，我們需要知道一個協議族的概念。協議族是多個協議的統稱。，TCP/IP就是一個協議族。
其包含IP、TCP、UDP、HTTP、FTP、MQTT等協議。TCP/IP協議模型：
（圖片：《計算機網絡》謝希仁、《TCP/IP協議詳解》）
TCP/IP協議模型分四層，上層依賴于下層。
從下到上看：
鏈路層規定了數據幀能被網卡接收的條件，最常見的方式是利用網卡的 MAC 地址，發送方會在欲發送的數據幀的首部加上接收方網卡的 MAC 地址信息，接收方只有監聽到屬于自己的MAC 地址信息后，才會去接收并處理該數據。
網絡層實現了數據包在主機之間的傳遞 。相關協議：IP、ICMP等協議。
傳輸層可以區分數據包是屬于哪一個應用程序的。相關協議：TCP、UDP協議。
應用層提供特定的應用服務。相關協議：HTTP、MQTT、FTP等協議。
應用層以下的工作完成了數據的傳遞工作，應用層則決定了你如何應用和處理這些數據，之所以會有許多的應用層協議， 是因為互聯網中傳遞的數據種類很多、差異很大、應用場景十分多樣。
（圖片來源：野火《LWIP應用開發實戰指南》）
發送數據時， 將數據向下交給傳輸層。傳輸層會在數據前面加上傳輸層首部（此處以 TCP 協議為例， 傳輸層首部為 TCP 首部，也可以是 UDP 首部）， 然后向下交給網絡層。
同樣地，網絡層會在數據前面加上網絡層首部（IP 首部） ，然后將數據向下交給鏈路層， 鏈路層會對數據進行最后一次封裝，即在數據前面加上鏈路層首部（此處使用以太網接口為例） ，然后將數據交給網卡。
數據的接收過程與發送過程正好相反，可以概括為 TCP/IP 的各層協議對數據進行解析的過程。
IP 協議（Internet Protocol），又稱之為網際協議， IP 協議處于 IP 層工作，它是整個TCP/IP 協議棧的核心協議，上層協議都要依賴 IP 協議提供的服務， IP 協議負責將數據報從源主機發送到目標主機 。
IP 協議是一種無連接的不可靠數據報交付協議，協議本身不提供任何的錯誤檢查與恢復機制。
在全球的互聯網中，每個主機都要唯一的一個 IP 地址作為身份識別。每個 IP 地址長度為 32 比特（4 字節），使用點分十進制記法 來表示，如192.168.0.1。
IP 地址劃分為 5 大類，分別為 A、 B、 C、 D、 E 五類，每一類地址都覺定了其中 IP 地址的一部分組成（圖片來源：野火《LWIP應用開發實戰指南》）：
（圖片來源：野火《LWIP應用開發實戰指南》）
局域網（Local Area Network， 縮寫為
LAN），又稱
內網， 指覆蓋局部區域（如辦公室或樓層）的計算機網絡。
查看本機內網IP：
廣域網（Wide Area Network，縮寫為
WAN），又稱
廣域網、
外網、
公網。是連接不同地區計算機以進行通信的網絡。
查看本機外網IP：
（圖片來源：野火《LWIP應用開發實戰指南》）
無線路由器把電腦、手機等設備連接到局域網 LAN 上，并分配 IP 地址，即局域網 IP ，我們可以稱之為 LAN-IP 。
路由器的地址就是運營商給我們的一個 IP 地址，這個 IP 地址是有效的，可以看做是 WAN-IP。
LAN-IP 是路由器分配給我們的 IP，那么我們想要跨越邊界進入廣域網中， 就需要將 LAN-IP 變成有效的的 IP 地址，也就是 WAN-IP，那么在路由器中就需要將IP 地址進行轉換，完成 LAN-IP<—>WAN-IP 地址轉換（NAT） 。
當持有 WAN-IP 的 IP 包順利到達下一個邊界 Internet Gateway，這是通往互聯網Internet 的最后一道關卡，即邊界。
左邊是廣域網，右邊是互聯網， 也需要做 WAN-IP 與Global-IP（互聯網公共 IP）的轉換才能進入互聯網中 。
IP 數據報的格式如下所示：
（圖片來源：野火《LWIP應用開發實戰指南》）
各字段說明：
UDP 是 User Datagram Protocol 的簡稱， 中文名是用戶數據報協議， 是一種無連接、不可靠的協議。
主要特點：
UDP 雖然有很多缺點， 但是也不排除其能用于很多場合， 因為在如今的網絡環境下，UDP 協議傳輸出現錯誤的概率是很小的， 并且它的實時性是非常好， 常用于實時視頻的傳輸，比如直播、網絡電話等。
因為即使是出現了數據丟失的情況，導致視頻卡幀，這也不是什么大不了的事情，所以， UDP 協議還是會被應用與對傳輸速度有要求，并且可以容忍出現差錯的數據傳輸中。
（圖片來源：野火《LWIP應用開發實戰指南》）
端口號的取值在0~65535 之間；16bit 的總長度用于記錄 UDP 報文的總長度，包括 8 字節的首部長度與數據區域。相關文章：
【socket筆記】TCP、UDP通信總結
TCP 協議（TransmissionControl Protocol，傳輸控制協議），是一個面向連接的協議，無論哪一方向另一方發送數據之前，都必須先在雙方之間建立一個連接，否則將無法發送數據。
TCP數據是會封裝到IP數據當中，我們現在看看TCP協議的頭部數據定義：
（圖片來源：野火《LWIP應用開發實戰指南》、《TCP/IP協議詳解》）
下面看一下TCP協議的一些特性：
TCP 提供可靠的運輸層， 但它依賴的是 IP 層的服務， IP 數據報的傳輸是無連接、 不可靠的，因此它要通過確認來知道接收方確實已經收到數據了。
但數據和確認都有可能會丟失， 因此 TCP 通過在發送時設置一個超時機制（定時器） 來解決這種問題， 如果當超時時間到達的時候還沒有收到對方的確認，它就重傳該數據。
在發送方想要發送數據的時候， 由于應用程序的數據大小、 類型都是不可預估的， 而TCP 協議提供了緩沖機制來處理這些數據。
如在數據量很小的時候， TCP 會將數據存儲在一個緩沖空間中， 等到數據量足夠大的時候在進行發送數據， 這樣子能提供傳輸的效率并且減少網絡中的通信量。
而且在數據發送出去的時候并不會立即刪除數據，還是讓數據保存在緩沖區中，因為發送出去的數據不一定能被接收方正確接收，它需要等待到接收方的確認再將數據刪除。
在 TCP 連接建立后，那么兩個主機就是對等的，任何一個主機都可以向另一個主機發送數據，數據是雙向流通的，所以 TCP 協議是一個全雙工的協議。
TCP 提供了流量控制服務（flow-control service）以消除發送方使接收方緩沖區溢出的可能性。
流量控制是一個速度匹配服務，即發送方的發送速率與接收方應用程序的讀取速率相匹配， TCP 通過讓發送方維護一個稱為接收窗口（receive window）的變量來提供流量控制。
除了確認與重傳之外， TCP 協議也會采用校驗和的方式來檢驗數據的有效性，主機在接收數據的時候，會將重復的報文丟棄，將亂序的報文重組。
發現某段報文丟失了會請求發送方進行重發，因此在 TCP 往上層協議遞交的數據是順序的、無差錯的完整數據。
關于TCP協議的一些其它內容如三次握手、四次揮手、示例等可以看以下文章：
C語言、嵌入式應用：TCP通信實例分析
【面試必考】TCP協議“三次握手”與“四次揮手”
【socket筆記】TCP、UDP通信總結
HTTP 協議是 Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫， 是用于從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳輸協議。
它是基于TCP/IP 協議通信的，因此它也是基于客戶端-服務器模型運作的，是一個應用層協議，可以用它來傳輸服務器的各種資源，如文本、圖片、音頻等。
HTTP 協議的特點：
GET、 HEAD、 POST 等， 每種方法規定了客戶端與服務器通信的類型不同。
Content-Type 加以標記。
HTTP1.1 提出了持久連接的方法。
Cookie 技術，這是一種可以讓服務器知道用戶上一次做了什么操作，并且記錄下來。
URL 全稱是 Uniform Resource Locator， 中文叫統一資源定位符， 是互聯網上用來標識某一處資源的絕對地址，使用它我們就必然能找到資源，除非資源已經被轉移了。
URI （Uniform Resource Identifiers）是一個通用的概念，由兩個子集組成，分別是 URL 和 URN， URL 是通過資源的位置來標識資源，而 URN 更高級一點，只需通過資源名字即可識別資源，與他們所處的位置是無關的，目前暫時還未推廣 URN。
URL的通用格式如下（絕大部分的 URL 是不會包含所有組件的內容的 ）：
（圖片來源：野火《LWIP應用開發實戰指南》）
① 請求報文：
（圖片來源：野火《LWIP應用開發實戰指南》）
method （方法）：HTTP 請求報文的起始行以方法作為開始，方法用來告知服務器要做些什么， 常見的方法有GET、 POST、 HEAD` 等 。
請求 URL（request-URL） ：指定了所請求的資源。
版本（version）：指定報文所使用的 HTTP 協議版本 。
② 應答報文：
（圖片來源：野火《LWIP應用開發實戰指南》）
（圖片來源：野火《LWIP應用開發實戰指南》）
實例：
MQTT 協議全稱是 Message Queuing Telemetry Transport，翻譯過來就是消息隊列遙測傳輸協議，它是物聯網常用的應用層協議。
其運行在 TCP/IP 中的應用層中，依賴 TCP 協議，因此它具有非常高的可靠性，同時它是基于 TCP 協議的<客戶端-服務器>模型發布/訂閱主題消息的輕量級協議。
（圖片來源：野火《LWIP應用開發實戰指南》）
MQTT協議是基于客戶端-服務器模型，在協議中主要有三種身份：發布者（Publisher）、服務器（Broker） 以及訂閱者（Subscriber）。
MQTT 消息的發布者和訂閱者都是客戶端，服務器只是作為一個中轉的存在，將發布者發布的消息進行轉發給所有訂閱該主題的訂閱者。
MQTT 客戶端的功能：
MQTT 服務器常被稱為 Broker（消息代理） 。它的功能有：
MQTT所發的消息包含：主題+內容，客戶端可以訂閱任意主題，若有其它客戶端發布主題時符合所訂閱的主題，就會由網關發送到客戶端。
什么是主題？
MQTT 服務器為每個連接的客戶端（訂閱者）添加一個標簽，該標簽與服務器中的所有訂閱相匹配， 服務器會將消息轉發給與標簽相匹配的每個客戶端。這樣的一個標簽就是主題。
實例：
服務質量：
MQTT提供三種服務質量（Quality of Service，簡寫QoS），供開發者根據不同的情景選擇不同的服務級別：
QoS0：最多發送一次消息，在消息發送出去后，接收者不會發送回應，發送者也不會重發消息。
QoS1：最少發送一次消息（消息最少需要送達一次，也有可送達多次）， QoS 1的 PUBLISH 報文的可變報頭中包含一個報文標識符，需要 PUBACK 報文確認。
QoS2：這是最高等級的服務質量，消息丟失和重復都是不可接受的。只不過使用這個服務質量等級會有額外的開銷，這個等級常用于支付中，因為支付是必須有且僅有一次成功，總不能沒給錢或者給了多次錢吧。
以上就是本次分享的一些計算機網絡基礎知識，計算機網絡的內容很多，一篇文章不可能全部覆蓋，以上也僅僅是一些概括性地抽取一些表層內容過來分享，需要閱讀相關書籍來加深學習。
野火《LWIP應用開發實戰指南》
《計算機網絡》謝希仁
《TCP/IP協議詳解》
https://www.scaugreen.cn/
C語言、嵌入式位操作精華技巧大匯總
認識認識#pragma、#error指令
C語言、嵌入式中幾個非常實用的宏技巧
十年經驗工程師為何被裁？
嵌入式百寶箱：第1期
若覺得文章不錯，轉發分享、在看，也是我們繼續更新的動力。
在公眾號內回復更多資源，可免費獲取嵌入式資料。期待你的關注~
加好友，回暗號【嵌入式大雜燴】，進微信群
免責聲明：本文來源網絡，免費傳達知識，版權歸原作者所有。如涉及作品版權問題，請與我聯系。
