常見網路協議彙總

前言

本篇部落格將對基於 TCP/IP的五層網路模型 中的常見協議做以總結 ，目的透過這些具體的協議更深刻的認識整體網路的傳輸流程及相關網路原理

TCP/IP五層網路模型回顧

應用層：為使用者為使用者的應用程式提供網路通訊服務

協議——DNS協議、HTTP協議、HTTPS協議

傳輸層：負責兩臺主機之間的資料傳輸，將資料從傳送端傳輸到接收端

協議——TCP協議、UDP協議

網路層：負責傳輸的地址管理和路由選擇，在眾多複雜的網路環境中確定一條合適的路徑

協議——IP協議

資料鏈路層：負責裝置之間資料幀的傳送和識別，將網路層傳遞的資料包封裝成幀，在處於同一個資料資料鏈路節點的兩個裝置之間傳輸

協議——ARP協議、MTU協議

物理層：負責光電訊號的傳遞方式，實現相鄰計算機節點之間位元流的透明傳輸

對於五層網路模型基本都是耳熟能詳，但是有沒有思考過，網路為什麼要這樣分層呢？

最直接的回答就是為了簡化網路設計的複雜性，通訊協議採用分層結構，各層之間既相互獨立又相互協調工作，如此以來便達到的高效的目的。如同設計模式中對於設計一個複雜的程式時，儘量使程式各功能之間是解耦合的一樣，對於複雜的網路設計，分層設計也是很明智的一種做法。

網路分層的最本質就是每一層獨立的完成一個任務而不必考慮自己任務之外的實現，而因為不同的任務因此就有了每一層所對應的不同裝置。(例項到應用就是，物理層只需要關係0和1的光電訊號如何傳輸，而對它所表達的內容毫不關心；再往上資料鏈路層只需要關心封裝好的資料幀如何準確的送到對應的MAC地址的目的主機中，而不必關心資料包的具體內容和具體會透過何種方式光纖還是區域網…同理往上對於所有層)

應用層協議

應用層協議主要負責各個程式間的通訊，發生網路傳輸一個資料時，先由應用層對資料按照對應的協議封裝，然後交給下一層傳輸層，當經過一系列網路傳輸，資料達到接收端時，一層層的分用，最後一層再由應用層分用，最終得到資料。

DNS協議：

DNS協議是一個應用層協議，建立在TCP和UDP的基礎之上，使用預設埠為53，其預設透過UDP協議通訊，但如果報文過大是則會切換成TCP協議。

域名系統 (DNS) 的作用是將人類可讀的域名 (如，) 轉換為機器可讀的 IP 地址 (如，192.0.2.44)，本質是透過DNS域名和IP地址的對應關係轉換，而這種對應關係則儲存在DNS伺服器中

域名的解析過程：

域名的解析工作大體上可以分為兩個步驟：第一步客戶端向本地DNS伺服器發起一個DNS請求報文，報文裡攜帶需要查詢的域名，第二步本地DNS伺服器向本機回應一個DNS響應報文，報文裡攜帶查詢域名所對應的IP地址

具體流程如下：

在本地快取中查詢，如果有則返回對應IP，如果沒有將請求發給DNS伺服器

當本地DNS伺服器接收到查詢後，先在伺服器管理區域記錄中查詢，若沒有再在伺服器本地快取中查詢，如果沒有將請求傳送到根域名伺服器

根域名伺服器負責解析請求的根域部分，然後將包含下一級域名資訊的DNS服務地址返回給本地DNS伺服器

本地DNS伺服器利用根域名伺服器解析的地址訪問下一級DNS伺服器，得到再下一級域的DNS伺服器地址

按照上述遞迴方法逐級接近查詢目標，最後在有目標域名的DNS伺服器上找到相應的IP地址資訊

本地DNS伺服器將最終查詢到的IP返回給客戶端，讓客戶端訪問對應主機

HTTP協議

HTTP協議是一個簡單的請求——響應協議，它通常執行在TCP之上。它指定了客戶端可能傳送給伺服器什麼樣的訊息以及得到什麼樣的響應。

同其他應用層協議一樣，是為了實現某一類具體應用的協議，並由某一執行在使用者空間的應用程式來實現其功能。HTTP是一種協議規範，這種規範記錄在文件上，為真正透過HTTP進行通訊的HTTP的實現程式。

HTTP是基於TCP協議，且面向連線的。典型的HTTP事務處理有如下的過程：

客戶端與伺服器建立連線；

客戶端向伺服器提出請求；

伺服器接受請求，並根據請求返回相應的資料作為應答響應；

客戶端與伺服器關閉連線。

HTTP協議報文格式

HTTP報文由從客戶機到伺服器的請求(Request)和從伺服器到客戶機的響應(Respone)構成

請求由請求行，請求頭，請求體組成

請求行中包含請求方法、路徑、版本號，請求頭為多個key-value資料，請求正文包含一些請求的資料

響應由響應行，響應頭，響應體組成

響應行中包含狀態碼，狀態碼描述，版本號，響應頭為多個key-value資料，響應正文包含一些響應的資料

常見HTTP響應狀態碼彙總

200 OK ：客戶端請求成功

3XX系列

301 Moved Permanently ：請求的資源以被永久的移動到新URL中，返回的Response中包含一個Location，瀏覽器會自動重定向到新URL，以後請求都會被新的URL替代

302 Found ：與301類似，但請求的資源只是臨時的被移動到新的URL中，下次請求客戶端繼續使用原URL

307 Temporary Redirect ： 臨時重定向，類似於302，使用GET請求重定向

4XX系列

400 Bad Request ： 客戶端請求語法錯誤，伺服器無法理解（在 ajax 請求後臺資料時比較常見）

401 Unauthorized ：請求要求使用者的身份認證

403 Forbidden ： 伺服器理解客戶端請求，但是拒絕執行（一般用於使用者級別為達到要求等等不支援訪問）

404 Not Found ： 伺服器無法根據客戶端請求找到對應資源

405 Method Not Allowed ： 伺服器不支援該方法

5XX系列

500 Internal Server Error ： 伺服器內部錯誤，無法完成請求

503 Service Unavailable ：由於超載或系統維護，伺服器暫時的無法處理客戶端的請求。延時的長度可包含在伺服器的Retry-After頭資訊中

HTTP協議的特點

支援伺服器/客戶端模式

傳輸較快速，客戶端向伺服器傳送請求，只需要傳輸請求方法和路徑

靈活，HTTP允許傳輸任意型別的資料物件

無連線，每次連線只能處理一個請求，伺服器處理完客戶端請求，客戶端收到響應後就斷開連線

無狀態，協議本身對事務處理沒有記憶能力，如果後序連線需要之前傳送的資訊時就需要重傳

HTTP1.0和HTTP1.1和HTTP2.0的區別：

HTTP1.0和HTTP1.1的區別：

長連線：HTTP1.0只支援瀏覽器與伺服器的短連線，即每次請求都要重新建立連線，伺服器無法記錄每個歷史請求，HTTP1.1支援長連線即在一次連線下，瀏覽器可以向伺服器傳送多次請求

增加Host欄位：HTTP1.0中認為每個伺服器都繫結這唯一一個IP，所有傳送的請求頭URL中沒有host資訊，而HTTP1.1在請求和響應中都支援了host頭域，且請求訊息中如果沒有Host頭域會報告一個錯誤(400 Bad Request)

快取：HTTP1.1在1.0的基礎上加入了一些cache的新特性，當快取物件的Age超過Expire時變為stale物件，cache不需要直接拋棄stale物件，而是與源伺服器進行重新啟用（revalidation）。

錯誤提示：HTTP1.0中定義了16個狀態碼，對錯誤或警告的提示不夠具體。HTTP1.1引入了一個Warning頭域，增加對錯誤或警告資訊的描述，並且還新增了24個狀態響應碼，如409(Conflict)表示請求的資源與資源的當前狀態發生衝突；410(Gone)表示伺服器上的某個資源被永久性的刪除

HTTP1.X和HTTP2.0的區別

增加二進位制格式解析：HTTP1.X解析基於文字，而文字格式本身就具有多樣性，很多場景下不方便，而引入二進位制後，只有0和1組合，使解析更加方便也增強了健壯性

多路複用：即每個request都是是用作連線共享機制的，每個request都對應一個id，使一個連線可以有多個請求，再根據id將request歸屬到不同的服務端請求裡

header壓縮：HTTP1.X中，每次傳輸都要寫點header頭，佔用了大量資料，因此HTTP2.0在客戶端和服務端各儲存了一份header fields表，每次傳輸時只需傳輸header的更新資訊，將header fields表更新即可實現header傳輸

服務端推送：HTTP2.0也新增了server push功能

HTTPS協議

HTTPS同樣作為應用層協議，可以說它是HTTP的升級版，增加了傳輸資料的安全性，HTTPS協議是在HTTP的基礎上增加了一個SSL外殼，HTTPS執行在SSL上，SSL執行在TCP上，對資料的加密工作就是在SSL上完成的

其保證安全性的做法是透過證書驗證和對資訊混合加密的方式

混合加密技術：

混合加密技術：結合對稱加密與非對稱加密

服務端生成私鑰，再透過私鑰生成公鑰，然後將公鑰放在證書中頒發給客戶端

使用公鑰和私鑰以非對稱方式加密生成金鑰

客戶端接下來的傳輸資料中，都會用金鑰以對稱方式對資訊加密，再傳輸給服務端

對於，上述提到的公鑰和私鑰，我們規定用公鑰加密的內容必須用私鑰才能解開，同樣，私鑰加密的內容只有公鑰能解開

所以HTTPS傳輸資料是用被金鑰加密的密文和用公鑰加密的私鑰來保證資料安全的

HTTPS加密，只用對稱加密可以嗎？

不行！無法保證安全性，因為只用對稱加密即只用金鑰對資料加密傳輸的話，如果傳輸途中，資訊被第三方劫持，獲取到金鑰，那接下來的傳輸，第三方都可以透過金鑰對資料解密從而得到原始資料。

HTTPS加密，只用非對稱加密可以嗎？兩次呢？

同樣不行，如果只用非對稱加密。客戶端每次傳輸資料用公鑰加密，服務端再用私鑰解密這一方向看似安全，但當服務端傳送資料用私鑰加密，客戶端收到用公鑰解密時，第三方劫持到資訊，但可能在此之前就獲得公鑰，因為首次服務端向客戶端傳送公鑰是明文傳輸的。

而換個角度如果使用兩次非對稱加密，即兩組公鑰，兩組私鑰，客戶端服務端各持一組，理論上可以達到安全，但實際HTTPS並未採用，因為非對稱加密耗時十分大

證書：

單有混合加密技術，看似已經保證了傳輸的安全性，實則還是有漏洞，問題就在於伺服器根本無法識別傳送過來的公鑰是否是自己的，如此以來在第三方劫持到資料後，自行再定義一個公鑰B，並將公鑰B傳回給客服端，此時客戶端就會利用該公鑰B重新加密資料然後傳送，此時第三方就可以透過自己的公鑰B解密得到原始資料了。

證書就解決了這一問題，指定頒發的為CA機構，當網站使用HTTPS時，會向CA機構申請一個數字證書，證書中可以存放公鑰、資料等資訊，由此以來，服務端就可以透過證書來向客戶端證明正確的公鑰是哪一個，以此保證安全。

而對於證書，還有一些自己的放篡改機制，防止第三方獲取到使用

傳輸層協議

傳輸層的主要功能是為了實現“埠到埠”的通訊，以確保一條資料傳送到主機上後，能夠正確的傳遞到對應的埠上

UDP協議

UDP 為應用程式提供了一種無需建立連線就可以傳送封裝的 IP 資料包的方法，但是UDP也有自己的缺陷，一旦進行通訊，就不知道對方是否接收到資料了，很有可能會造成傳輸資料的丟包問題

特點：

無連線：只需要知道目的ip和埠號就可以傳送資料，無需建立連線

不可靠：沒有一系列機制來應對傳輸資料時的丟包問題

面向資料包傳送：應用層交給UDP什麼樣的報文，UDP就會傳送什麼樣的，不會進行拆分，合併

UDP一次傳輸的資料大小有限，最大64k

UDP的傳輸流程

UDP的適用範圍：

由於UDP不屬於連線型協議，所以具有資源消耗小。處理速度優的特點，因此經常使用與影片、音訊通話傳輸中，因為傳送的資料較多，偶爾丟包一兩個不會產生太大影響

TCP

因為上述講到UDP的傳輸是不可靠的，經常會導致連線錯誤、資料丟包問題，針對這些問題規定了另一個傳輸層協議——TCP協議，TCP是一種面向連線、可靠的、基於位元組流的傳輸層協議

TCP的特點：

面向連線：在傳輸資料是，要先建立起客戶端與服務端的連線，才能進行資料傳輸

可靠的通訊：TCP輸出資料中，會基於內部的各種機制保證資料傳輸到目的埠

基於位元組流：TCP傳輸資料是基於位元組傳輸的，易於對資料的拆分與合併傳送

TCP的頭部比UDP的開銷要打，因為要存放更多的資訊

關於TCP內部各種機制，在這裡不做過多的介紹，需要博友可以參考之前的一篇部落格網路原理基礎

TCP與UDP的區別：

UDP是無連線的，TCP是有連線的

UDP是不可靠的，TCP是可靠的

UDP面向資料包，TCP面向位元組流

UDP比TCP的傳輸消耗小，速度更快

這裡分享一張神圖，以便於更加形象的理解TCP和UDP的區別

網路層

網路層是基於資料鏈路層和傳輸層之間的第三層協議，它在資料鏈路層提供的兩個相鄰端點之間的資料幀的傳送功能上，進一步管理網路中的資料通訊，將資料設法從源端經過若干個中間節點傳送到目的端，從而向傳輸層提供最基本的端到端的資料傳送服務

網路層的目的是實現兩個端系統之間的資料透明傳送，具體功能包括定址和路由選擇、連線的建立、保持和終止等。它提供的服務使傳輸層不需要了解網路中的資料傳輸和交換技術。

IP協議

IP協議是TCP/IP網路模型中的核心部分，他提供了一種分層的、無關硬體的定址方式，可以在複雜的路由式網路中傳遞資料所需的服務

IP協議可以將多個交換網路連線起來，在源地址和目的地址之間傳輸資料包，同時它還能提供資料的組裝功能，以適應不同網路對資料包大小的要求

預研知識：

IP地址：

IP地址是網際網路協議特有的一種地址，它是IP協議提供的一種統一的地址格式，IP地址為網際網路的每個網路和每臺主機分配了一個邏輯地址，以此來遮蔽實體地址的差異

IP地址的格式：

IP地址為32位地址，被分為4個部分，如XXX.XXX.XXX.XXX，IP地址又被劃分為兩個部分

網路號：前三部分用於標識網段，保證相互連線的兩個網段有不同標識

主機號：由最後一部分組成，用於標識主機，保證處於同一網段的兩臺主機有不同的主機號

透過合理設定主機號和網路號, 就可以保證在相互連線的網路中, 每臺主機的IP地址都不相同4

MAC地址：

被稱為實體地址，是用來標識網路中每個裝置的，MAC地址是裝置出廠之後就寫死的

引入IP地址的目的：

在單個區域網網段中，計算機與計算機之間可以使用資料鏈路層提供的MAC地址進行通訊

如果在路由式網路中，計算機之間就不能用MAC地址實現通訊，主要是因為在路由式網路中，資料只是經過一次簡單的利用兩個計算機之間的MAC地址建立通訊，而是需要進行多次的通訊，每次跳轉都會體目的主機更近一步，經歷都次跳轉，最終找到目的主機實現通訊，而這個過程中，要知道每次向哪跳轉才能更接近目的主機，必須使用一種邏輯化、層次化的定址方案對網路進行組織，這就是 IP 地址

IP協議資料包格式

IP協議的工作方式：

由於網路分為同網段和不同網段，所以會分成兩種方式

同網段：如果源地址主機和目的地址主機處於同一網段，則目的IP地址被 ARP協議 解析為MAC地址後，源主機會根據目的MAC地址直接將資料包傳送給目的主機

不同網段：

如果源地址主機和目的地址主機不處於同一網段，則資料包會經歷多個過程最終傳送給目的主機

1、閘道器(一般為路由器)的 IP地址 被 ARP協議 解析為 MAC地址，根據該 MAC地址 源主機會將資料包傳送到閘道器

2、閘道器根據資料包中的網段ID找到目標網路，如果找到，將資料包傳送給目標網路，如果沒有則重複第一步傳送到更高一級閘道器

3、資料包經過閘道器傳送到正確的網段後，目標IP被 ARP協議 解析為MAC地址，在根據該 MAC地址 將資料包傳送給目標地址的主機

ICMP協議

ICMP協議又叫控制報文協議，ICMP協議用於在IP 和 路由器之間傳遞控制訊息，描述網路是否通暢、主機是否可達、路由器是否可用等網路狀態，ICMP本身並不傳輸資料，但對於使用者間資料的傳遞起著重要的作用

作用：

在資料包從源主機傳輸到目的主機的過程中，會經歷一個或多個路由器，而資料包在經過這些路由器傳輸過程中，可能會遇到很多問題，最終導致資料包沒有成功傳遞給目的主機。為了瞭解資料包在傳輸過程中在哪個環節出了問題，就需要用到ICMP協議，它可以跟蹤資料包，並把訊息返回給源主機。

資料鏈路層

資料鏈路層是TCP/IP網路模型的第二層，基於物理層和網路層之間，資料鏈路層在物理層提供的服務的基礎上向網路層提供服務，其最基本的服務是將源自物理層來的資料可靠地傳輸到相鄰節點的目標機網路層。

ARP協議

ARP協議是資料進行網路傳輸過程中，透過IP地址向MAC地址的轉換，解決網路層和物理層銜接問題

引入ARP協議的目的：

由於 IP 地址和 MAC 地址定位方式不同，ARP 協議成為資料傳輸的必備協議。主機傳送資訊前，必須透過 ARP 協議獲取目標 IP 地址對應的 MAC 地址，才能正確地傳送資料包。

ARP的工作流程：

如圖展示的是同一網段下的兩臺主機，ARP的工作流程

主機A以廣播的形式向該網段內的所有主機傳送ARP請求，請求中包含了目的主機的IP地址

主機B接收到請求，透過請求中的目的IP地址發現自己是主機A要找的，返回響應，響應包括主機B的 MAC地址

ARP快取：

在請求目標主機的 MAC 地址時，每次獲取目標主機 MAC 地址都需要傳送一次 ARP 請求，然後根據響應獲取到 MAC 地址。

為了避免重複傳送 ARP 請求，每臺主機都有一個 ARP 快取記憶體。當主機得到 ARP 響應後，將目標主機的 IP 地址和實體地址存入本機 ARP 快取中，並保留一定時間。

只要在這個時間範圍內，下次請求 MAC 地址時，直接查詢 ARP 快取，而無須再傳送 ARP 請求，從而節約了網路資源。

物理層

物理層，顧名思義就是用物理手段將兩個要通訊的電腦連線起來，主要用來傳輸0、1光電訊號，因為這一層過於偏硬體，所以本文不做過多的贅述

整體的網路傳輸流程

經過以上對網路傳輸層中每一層理解下面我們來看看，當訪問一個網頁時，到底發生了什麼？

主機A：傳送http://網路資料包

DNS解析：將域名轉換成對應IP地址(本機DNS快取棧開始找—>逐級向上查詢，如果根域伺服器找不到，表示公網上沒有該域名主機)

找到IP後：透過目的IP找到對應的目的MAC地址

根據目的IP計算目的主機是否和主機A處於同一網段

如在同網段：接透過ARP協議解析出對應的目的MAC，跳轉到底9步

如不在同一網段：傳送資料包到閘道器，現在ARP快取表查詢，透過閘道器IP查詢MAC地址，找不到傳送查詢MAC廣播資料包，最終返回閘道器自己的MAC

交換機轉發：在MAC地址轉換表中找到對應MAC交換機介面

路由器接收：分用資料包

途中的裝置：與第7步同樣操作如目的IP對應的MAC地址不是當前裝置則繼續重複該操作繼續往更接近目的IP的路由傳送

找到目的主機B，主機B的伺服器開始接受分用請求，解析，最終組織響應

同上述操作一樣，由主機B向主機A傳送資料

最終主機A接受到資料包，經過分用，解析，最終得到響應

————————————————

版權宣告：本文為CSDN博主「相魚南故」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。

原文連結：https://blog.csdn.net/m0_46233999/article/details/119455352