常見網路協議匯總

前言

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

TCP/IP五層網路模型回顧

• 應用層：為用戶為用戶的應用行程提供網路通信服務
  協議——DNS協議、HTTP協議、HTTPS協議
• 傳輸層：負責兩臺主機之間的資料傳輸，將資料從發送端傳輸到接收端
  協議——TCP協議、UDP協議
• 網路層：負責傳輸的地址管理和路由選擇，在眾多復雜的網路環境中確定一條合適的路徑
  協議——IP協議
• 資料鏈路層：負責設備之間資料幀的傳送和識別，將網路層傳遞的資料報封裝成幀，在處于同一個資料資料鏈路節點的兩個設備之間傳輸
  協議——ARP協議、MTU協議
• 物理層：負責光電信號的傳遞方式，實作相鄰計算機節點之間位元流的透明傳輸

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

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

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

應用層協議

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

DNS協議：

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

域名系統 (DNS) 的作用是將人類可讀的域名 (如，www.baidu.com) 轉換為機器可讀的 IP 地址 (如，192.0.2.44)，本質是通過DNS域名和IP地址的對應關系轉換，而這種對應關系則保存在DNS服務器中

域名的決議程序：

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

具體流程如下：

1. 在本地快取中查詢，如果有則回傳對應IP，如果沒有將請求發給DNS服務器
2. 當本地DNS服務器接收到查詢后，先在服務器管理區域記錄中查詢，若沒有再在服務器本地快取中查詢，如果沒有將請求發送到根域名服務器
3. 根域名服務器負責決議請求的根域部分，然后將包含下一級域名資訊的DNS服務地址回傳給本地DNS服務器
4. 本地DNS服務器利用根域名服務器決議的地址訪問下一級DNS服務器，得到再下一級域的DNS服務器地址
5. 按照上述遞回方法逐級接近查詢目標，最后在有目標域名的DNS服務器上找到相應的IP地址資訊
6. 本地DNS服務器將最終查詢到的IP回傳給客戶端，讓客戶端訪問對應主機

HTTP協議

HTTP協議是一個簡單的請求——回應協議，它通常運行在TCP之上，它指定了客戶端可能發送給服務器什么樣的訊息以及得到什么樣的回應，
同其他應用層協議一樣，是為了實作某一類具體應用的協議，并由某一運行在用戶空間的應用程式來實作其功能，HTTP是一種協議規范，這種規范記錄在檔案上，為真正通過HTTP進行通信的HTTP的實作程式，

HTTP是基于TCP協議，且面向連接的，典型的HTTP事務處理有如下的程序：

1. 客戶端與服務器建立連接；
2. 客戶端向服務器提出請求；
3. 服務器接受請求，并根據請求回傳相應的資料作為應答回應；
4. 客戶端與服務器關閉連接，

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協議的特點

1. 支持服務器/客戶端模式
2. 傳輸較快速，客戶端向服務器發送請求，只需要傳輸請求方法和路徑
3. 靈活，HTTP允許傳輸任意型別的資料物件
4. 無連接，每次連接只能處理一個請求，服務器處理完客戶端請求，客戶端收到回應后就斷開連接
5. 無狀態，協議本身對事務處理沒有記憶能力，如果后序連接需要之前發送的資訊時就需要重傳

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

HTTP1.0和HTTP1.1的區別：

1. 長連接：HTTP1.0只支持瀏覽器與服務器的短連接，即每次請求都要重新建立連接，服務器無法記錄每個歷史請求，HTTP1.1支持長連接即在一次連接下，瀏覽器可以向服務器發送多次請求
2. 增加Host欄位：HTTP1.0中認為每個服務器都系結這唯一一個IP，所有發送的請求頭URL中沒有host資訊，而HTTP1.1在請求和回應中都支持了host頭域，且請求訊息中如果沒有Host頭域會報告一個錯誤(400 Bad Request)
3. 快取：HTTP1.1在1.0的基礎上加入了一些cache的新特性，當快取物件的Age超過Expire時變為stale物件，cache不需要直接拋棄stale物件，而是與源服務器進行重新激活（revalidation），
4. 錯誤提示：HTTP1.0中定義了16個狀態碼，對錯誤或警告的提示不夠具體，HTTP1.1引入了一個Warning頭域，增加對錯誤或警告資訊的描述，并且還新增了24個狀態回應碼，如409(Conflict)表示請求的資源與資源的當前狀態發生沖突；410(Gone)表示服務器上的某個資源被永久性的洗掉

HTTP1.X和HTTP2.0的區別

1. 增加二進制格式決議：HTTP1.X決議基于文本，而文本格式本身就具有多樣性，很多場景下不方便，而引入二進制后，只有0和1組合，使決議更加方便也增強了健壯性
2. 多路復用：即每個request都是是用作連接共享機制的，每個request都對應一個id，使一個連接可以有多個請求，再根據id將request歸屬到不同的服務端請求里
3. header壓縮：HTTP1.X中，每次傳輸都要寫點header頭，占用了大量資料，因此HTTP2.0在客戶端和服務端各保存了一份header fields表，每次傳輸時只需傳輸header的更新資訊，將header fields表更新即可實作header傳輸
4. 服務端推送：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://www.baidu.com網路資料報

1. DNS決議：將域名轉換成對應IP地址(本機DNS快取堆疊開始找—>逐級向上查找，如果根域服務器找不到，表示公網上沒有該域名主機)
2. 找到IP后：通過目的IP找到對應的目的MAC地址
3. 根據目的IP計算目的主機是否和主機A處于同一網段
4. 如在同網段：接通過ARP協議決議出對應的目的MAC，跳轉到底9步
5. 如不在同一網段：發送資料報到網關，現在ARP快取表查找，通過網關IP查找MAC地址，找不到發送查詢MAC廣播資料報，最侄訓傳網關自己的MAC
6. 交換機轉發：在MAC地址轉換表中找到對應MAC交換機介面
7. 路由器接收：分用資料報
   
8. 途中的設備：與第7步同樣操作如目的IP對應的MAC地址不是當前設備則繼續重復該操作繼續往更接近目的IP的路由發送
   
9. 找到目的主機B，主機B的服務器開始接受分用請求，決議，最終組織回應
   
10. 同上述操作一樣，由主機B向主機A發送資料
11. 最終主機A接受到資料報，經過分用，決議，最終得到回應