常見的計算機網絡協議匯總

前言

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

計算機網絡五層模型回顧

應用層：為用戶為用戶的應用進程提供網絡通信服務

協議——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地址

具體流程如下：

在本地緩存中查詢，如果有則返回對應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與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網絡數據報

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接受到數據報，經過分用，解析，最終得到響應

審核編輯：湯梓紅