前言

本篇博客將對基于 計(jì)算機(jī)網(wǎng)絡(luò)五層模型 中的常見協(xié)議做以總結(jié) ，目的通過這些具體的協(xié)議更深刻的認(rèn)識整體網(wǎng)絡(luò)的傳輸流程及相關(guān)網(wǎng)絡(luò)原理

計(jì)算機(jī)網(wǎng)絡(luò)五層模型回顧

應(yīng)用層：為用戶為用戶的應(yīng)用進(jìn)程提供網(wǎng)絡(luò)通信服務(wù)

協(xié)議——DNS協(xié)議、HTTP協(xié)議、HTTPS協(xié)議

傳輸層：負(fù)責(zé)兩臺主機(jī)之間的數(shù)據(jù)傳輸，將數(shù)據(jù)從發(fā)送端傳輸?shù)浇邮斩?/p>

協(xié)議——TCP協(xié)議、UDP協(xié)議

網(wǎng)絡(luò)層：負(fù)責(zé)傳輸?shù)牡刂饭芾砗吐酚蛇x擇，在眾多復(fù)雜的網(wǎng)絡(luò)環(huán)境中確定一條合適的路徑

協(xié)議——IP協(xié)議

數(shù)據(jù)鏈路層：負(fù)責(zé)設(shè)備之間數(shù)據(jù)幀的傳送和識別，將網(wǎng)絡(luò)層傳遞的數(shù)據(jù)報封裝成幀，在處于同一個數(shù)據(jù)數(shù)據(jù)鏈路節(jié)點(diǎn)的兩個設(shè)備之間傳輸

協(xié)議——ARP協(xié)議、MTU協(xié)議

物理層：負(fù)責(zé)光電信號的傳遞方式，實(shí)現(xiàn)相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳輸

對于五層網(wǎng)絡(luò)模型基本都是耳熟能詳，但是有沒有思考過，網(wǎng)絡(luò)為什么要這樣分層呢?

最直接的回答就是為了簡化網(wǎng)絡(luò)設(shè)計(jì)的復(fù)雜性，通信協(xié)議采用分層結(jié)構(gòu)，各層之間既相互獨(dú)立又相互協(xié)調(diào)工作，如此以來便達(dá)到的高效的目的。如同設(shè)計(jì)模式中對于設(shè)計(jì)一個復(fù)雜的程序時，盡量使程序各功能之間是解耦合的一樣，對于復(fù)雜的網(wǎng)絡(luò)設(shè)計(jì)，分層設(shè)計(jì)也是很明智的一種做法。

網(wǎng)絡(luò)分層的最本質(zhì)就是每一層獨(dú)立的完成一個任務(wù)而不必考慮自己任務(wù)之外的實(shí)現(xiàn)，而因?yàn)椴煌娜蝿?wù)因此就有了每一層所對應(yīng)的不同設(shè)備。(實(shí)例到應(yīng)用就是，物理層只需要關(guān)系0和1的光電信號如何傳輸，而對它所表達(dá)的內(nèi)容毫不關(guān)心;再往上數(shù)據(jù)鏈路層只需要關(guān)心封裝好的數(shù)據(jù)幀如何準(zhǔn)確的送到對應(yīng)的MAC地址的目的主機(jī)中，而不必關(guān)心數(shù)據(jù)報的具體內(nèi)容和具體會通過何種方式光纖還是局域網(wǎng)…同理往上對于所有層)

應(yīng)用層協(xié)議

應(yīng)用層協(xié)議主要負(fù)責(zé)各個程序間的通信，發(fā)生網(wǎng)絡(luò)傳輸一個數(shù)據(jù)時，先由應(yīng)用層對數(shù)據(jù)按照對應(yīng)的協(xié)議封裝，然后交給下一層傳輸層，當(dāng)經(jīng)過一系列網(wǎng)絡(luò)傳輸，數(shù)據(jù)達(dá)到接收端時，一層層的分用，最后一層再由應(yīng)用層分用，最終得到數(shù)據(jù)。

DNS協(xié)議：

DNS協(xié)議是一個應(yīng)用層協(xié)議，建立在TCP和UDP的基礎(chǔ)之上，使用默認(rèn)端口為53，其默認(rèn)通過UDP協(xié)議通信，但如果報文過大是則會切換成TCP協(xié)議。

域名系統(tǒng) (DNS) 的作用是將人類可讀的域名 (如，www.baidu.com) 轉(zhuǎn)換為機(jī)器可讀的 IP 地址 (如，192.0.2.44)，本質(zhì)是通過DNS域名和IP地址的對應(yīng)關(guān)系轉(zhuǎn)換，而這種對應(yīng)關(guān)系則保存在DNS服務(wù)器中

域名的解析過程：

域名的解析工作大體上可以分為兩個步驟：第一步客戶端向本地DNS服務(wù)器發(fā)起一個DNS請求報文，報文里攜帶需要查詢的域名，第二步本地DNS服務(wù)器向本機(jī)回應(yīng)一個DNS響應(yīng)報文，報文里攜帶查詢域名所對應(yīng)的IP地址

具體流程如下：

在本地緩存中查詢，如果有則返回對應(yīng)IP，如果沒有將請求發(fā)給DNS服務(wù)器

當(dāng)本地DNS服務(wù)器接收到查詢后，先在服務(wù)器管理區(qū)域記錄中查詢，若沒有再在服務(wù)器本地緩存中查詢，如果沒有將請求發(fā)送到根域名服務(wù)器

根域名服務(wù)器負(fù)責(zé)解析請求的根域部分，然后將包含下一級域名信息的DNS服務(wù)地址返回給本地DNS服務(wù)器

本地DNS服務(wù)器利用根域名服務(wù)器解析的地址訪問下一級DNS服務(wù)器，得到再下一級域的DNS服務(wù)器地址

按照上述遞歸方法逐級接近查詢目標(biāo)，最后在有目標(biāo)域名的DNS服務(wù)器上找到相應(yīng)的IP地址信息

本地DNS服務(wù)器將最終查詢到的IP返回給客戶端，讓客戶端訪問對應(yīng)主機(jī)

HTTP協(xié)議

HTTP協(xié)議是一個簡單的請求——響應(yīng)協(xié)議，它通常運(yùn)行在TCP之上。它指定了客戶端可能發(fā)送給服務(wù)器什么樣的消息以及得到什么樣的響應(yīng)。

同其他應(yīng)用層協(xié)議一樣，是為了實(shí)現(xiàn)某一類具體應(yīng)用的協(xié)議，并由某一運(yùn)行在用戶空間的應(yīng)用程序來實(shí)現(xiàn)其功能。HTTP是一種協(xié)議規(guī)范，這種規(guī)范記錄在文檔上，為真正通過HTTP進(jìn)行通信的HTTP的實(shí)現(xiàn)程序。

HTTP是基于TCP協(xié)議，且面向連接的。典型的HTTP事務(wù)處理有如下的過程：

客戶端與服務(wù)器建立連接;

客戶端向服務(wù)器提出請求;

服務(wù)器接受請求，并根據(jù)請求返回相應(yīng)的數(shù)據(jù)作為應(yīng)答響應(yīng);

客戶端與服務(wù)器關(guān)閉連接。

HTTP協(xié)議報文格式

HTTP報文由從客戶機(jī)到服務(wù)器的請求(Request)和從服務(wù)器到客戶機(jī)的響應(yīng)(Respone)構(gòu)成

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

請求行中包含請求方法、路徑、版本號，請求頭為多個key-value數(shù)據(jù)，請求正文包含一些請求的數(shù)據(jù)

響應(yīng)由響應(yīng)行，響應(yīng)頭，響應(yīng)體組成

響應(yīng)行中包含狀態(tài)碼，狀態(tài)碼描述，版本號，響應(yīng)頭為多個key-value數(shù)據(jù)，響應(yīng)正文包含一些響應(yīng)的數(shù)據(jù)

常見HTTP響應(yīng)狀態(tài)碼匯總

200 OK ：客戶端請求成功

3XX系列

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

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

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

4XX系列

400 Bad Request ： 客戶端請求語法錯誤，服務(wù)器無法理解(在 ajax 請求后臺數(shù)據(jù)時比較常見)

401 Unauthorized ：請求要求用戶的身份認(rèn)證

403 Forbidden ： 服務(wù)器理解客戶端請求，但是拒絕執(zhí)行(一般用于用戶級別為達(dá)到要求等等不支持訪問)

404 Not Found ： 服務(wù)器無法根據(jù)客戶端請求找到對應(yīng)資源

405 Method Not Allowed ： 服務(wù)器不支持該方法

5XX系列

500 Internal Server Error ： 服務(wù)器內(nèi)部錯誤，無法完成請求

503 Service Unavailable ：由于超載或系統(tǒng)維護(hù)，服務(wù)器暫時的無法處理客戶端的請求。延時的長度可包含在服務(wù)器的Retry-After頭信息中

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

支持服務(wù)器/客戶端模式

傳輸較快速，客戶端向服務(wù)器發(fā)送請求，只需要傳輸請求方法和路徑

靈活，HTTP允許傳輸任意類型的數(shù)據(jù)對象

無連接，每次連接只能處理一個請求，服務(wù)器處理完客戶端請求，客戶端收到響應(yīng)后就斷開連接

無狀態(tài)，協(xié)議本身對事務(wù)處理沒有記憶能力，如果后序連接需要之前發(fā)送的信息時就需要重傳

HTTP1.0和HTTP1.1和HTTP2.0的區(qū)別：

HTTP1.0和HTTP1.1的區(qū)別：

長連接：HTTP1.0只支持瀏覽器與服務(wù)器的短連接，即每次請求都要重新建立連接，服務(wù)器無法記錄每個歷史請求，HTTP1.1支持長連接即在一次連接下，瀏覽器可以向服務(wù)器發(fā)送多次請求

增加Host字段：HTTP1.0中認(rèn)為每個服務(wù)器都綁定這唯一一個IP，所有發(fā)送的請求頭URL中沒有host信息，而HTTP1.1在請求和響應(yīng)中都支持了host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤(400 Bad Request)

緩存：HTTP1.1在1.0的基礎(chǔ)上加入了一些cache的新特性，當(dāng)緩存對象的Age超過Expire時變?yōu)閟tale對象，cache不需要直接拋棄stale對象，而是與源服務(wù)器進(jìn)行重新激活(revalidation)。

錯誤提示：HTTP1.0中定義了16個狀態(tài)碼，對錯誤或警告的提示不夠具體。HTTP1.1引入了一個Warning頭域，增加對錯誤或警告信息的描述，并且還新增了24個狀態(tài)響應(yīng)碼，如409(Conflict)表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突;410(Gone)表示服務(wù)器上的某個資源被永久性的刪除

HTTP1.X和HTTP2.0的區(qū)別

增加二進(jìn)制格式解析：HTTP1.X解析基于文本，而文本格式本身就具有多樣性，很多場景下不方便，而引入二進(jìn)制后，只有0和1組合，使解析更加方便也增強(qiáng)了健壯性

多路復(fù)用：即每個request都是是用作連接共享機(jī)制的，每個request都對應(yīng)一個id，使一個連接可以有多個請求，再根據(jù)id將request歸屬到不同的服務(wù)端請求里

header壓縮：HTTP1.X中，每次傳輸都要寫點(diǎn)header頭，占用了大量數(shù)據(jù)，因此HTTP2.0在客戶端和服務(wù)端各保存了一份header fields表，每次傳輸時只需傳輸header的更新信息，將header fields表更新即可實(shí)現(xiàn)header傳輸

服務(wù)端推送：HTTP2.0也添加了server push功能

HTTPS協(xié)議

HTTPS同樣作為應(yīng)用層協(xié)議，可以說它是HTTP的升級版，增加了傳輸數(shù)據(jù)的安全性，HTTPS協(xié)議是在HTTP的基礎(chǔ)上增加了一個SSL外殼，HTTPS運(yùn)行在SSL上，SSL運(yùn)行在TCP上，對數(shù)據(jù)的加密工作就是在SSL上完成的

其保證安全性的做法是通過證書驗(yàn)證和對信息混合加密的方式

混合加密技術(shù)：

混合加密技術(shù)：結(jié)合對稱加密與非對稱加密

服務(wù)端生成私鑰，再通過私鑰生成公鑰，然后將公鑰放在證書中頒發(fā)給客戶端

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

客戶端接下來的傳輸數(shù)據(jù)中，都會用密鑰以對稱方式對信息加密，再傳輸給服務(wù)端

對于，上述提到的公鑰和私鑰，我們規(guī)定用公鑰加密的內(nèi)容必須用私鑰才能解開，同樣，私鑰加密的內(nèi)容只有公鑰能解開_

所以HTTPS傳輸數(shù)據(jù)是用被密鑰加密的密文和用公鑰加密的私鑰來保證數(shù)據(jù)安全的

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

不行!無法保證安全性，因?yàn)橹挥脤ΨQ加密即只用密鑰對數(shù)據(jù)加密傳輸?shù)脑?，如果傳輸途中，信息被第三方劫持，獲取到密鑰，那接下來的傳輸，第三方都可以通過密鑰對數(shù)據(jù)解密從而得到原始數(shù)據(jù)。

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

同樣不行，如果只用非對稱加密。客戶端每次傳輸數(shù)據(jù)用公鑰加密，服務(wù)端再用私鑰解密這一方向看似安全，但當(dāng)服務(wù)端發(fā)送數(shù)據(jù)用私鑰加密，客戶端收到用公鑰解密時，第三方劫持到信息，但可能在此之前就獲得公鑰，因?yàn)槭状畏?wù)端向客戶端發(fā)送公鑰是明文傳輸?shù)摹?/p>

而換個角度如果使用兩次非對稱加密，即兩組公鑰，兩組私鑰，客戶端服務(wù)端各持一組，理論上可以達(dá)到安全，但實(shí)際HTTPS并未采用，因?yàn)榉菍ΨQ加密耗時十分大

證書：

單有混合加密技術(shù)，看似已經(jīng)保證了傳輸?shù)陌踩裕瑢?shí)則還是有漏洞，問題就在于服務(wù)器根本無法識別發(fā)送過來的公鑰是否是自己的，如此以來在第三方劫持到數(shù)據(jù)后，自行再定義一個公鑰B，并將公鑰B傳回給客服端，此時客戶端就會利用該公鑰B重新加密數(shù)據(jù)然后發(fā)送，此時第三方就可以通過自己的公鑰B解密得到原始數(shù)據(jù)了。

證書就解決了這一問題，指定頒發(fā)的為CA機(jī)構(gòu)，當(dāng)網(wǎng)站使用HTTPS時，會向CA機(jī)構(gòu)申請一個數(shù)字證書，證書中可以存放公鑰、數(shù)據(jù)等信息，由此以來，服務(wù)端就可以通過證書來向客戶端證明正確的公鑰是哪一個，以此保證安全。

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

傳輸層協(xié)議

傳輸層的主要功能是為了實(shí)現(xiàn)“端口到端口”的通信，以確保一條數(shù)據(jù)發(fā)送到主機(jī)上后，能夠正確的傳遞到對應(yīng)的端口上

UDP協(xié)議

UDP 為應(yīng)用程序提供了一種無需建立連接就可以發(fā)送封裝的 IP 數(shù)據(jù)包的方法，但是UDP也有自己的缺陷，一旦進(jìn)行通信，就不知道對方是否接收到數(shù)據(jù)了，很有可能會造成傳輸數(shù)據(jù)的丟包問題

特點(diǎn)：

無連接：只需要知道目的ip和端口號就可以發(fā)送數(shù)據(jù)，無需建立連接

不可靠：沒有一系列機(jī)制來應(yīng)對傳輸數(shù)據(jù)時的丟包問題

面向數(shù)據(jù)報發(fā)送：應(yīng)用層交給UDP什么樣的報文，UDP就會發(fā)送什么樣的，不會進(jìn)行拆分，合并

UDP一次傳輸?shù)臄?shù)據(jù)大小有限，最大64k

UDP的傳輸流程

UDP的適用范圍：

由于UDP不屬于連接型協(xié)議，所以具有資源消耗小。處理速度優(yōu)的特點(diǎn)，因此經(jīng)常使用與視頻、音頻通話傳輸中，因?yàn)榘l(fā)送的數(shù)據(jù)較多，偶爾丟包一兩個不會產(chǎn)生太大影響

TCP

因?yàn)樯鲜鲋v到UDP的傳輸是不可靠的，經(jīng)常會導(dǎo)致連接錯誤、數(shù)據(jù)丟包問題，針對這些問題規(guī)定了另一個傳輸層協(xié)議——TCP協(xié)議，TCP是一種面向連接、可靠的、基于字節(jié)流的傳輸層協(xié)議

TCP的特點(diǎn)：

面向連接：在傳輸數(shù)據(jù)是，要先建立起客戶端與服務(wù)端的連接，才能進(jìn)行數(shù)據(jù)傳輸

可靠的通信：TCP輸出數(shù)據(jù)中，會基于內(nèi)部的各種機(jī)制保證數(shù)據(jù)傳輸?shù)侥康亩丝?/p>

基于字節(jié)流：TCP傳輸數(shù)據(jù)是基于字節(jié)傳輸?shù)?，易于對?shù)據(jù)的拆分與合并發(fā)送

TCP的頭部比UDP的開銷要打，因?yàn)橐娣鸥嗟男畔?/p>

TCP與UDP的區(qū)別：

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

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

UDP面向數(shù)據(jù)報，TCP面向字節(jié)流

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

這里分享一張神圖，以便于更加形象的理解TCP和UDP的區(qū)別

網(wǎng)絡(luò)層

網(wǎng)絡(luò)層是基于數(shù)據(jù)鏈路層和傳輸層之間的第三層協(xié)議，它在數(shù)據(jù)鏈路層提供的兩個相鄰端點(diǎn)之間的數(shù)據(jù)幀的傳送功能上，進(jìn)一步管理網(wǎng)絡(luò)中的數(shù)據(jù)通信，將數(shù)據(jù)設(shè)法從源端經(jīng)過若干個中間節(jié)點(diǎn)傳送到目的端，從而向傳輸層提供最基本的端到端的數(shù)據(jù)傳送服務(wù)

網(wǎng)絡(luò)層的目的是實(shí)現(xiàn)兩個端系統(tǒng)之間的數(shù)據(jù)透明傳送，具體功能包括尋址和路由選擇、連接的建立、保持和終止等。它提供的服務(wù)使傳輸層不需要了解網(wǎng)絡(luò)中的數(shù)據(jù)傳輸和交換技術(shù)。

IP協(xié)議

IP協(xié)議是TCP/IP網(wǎng)絡(luò)模型中的核心部分，他提供了一種分層的、無關(guān)硬件的尋址方式，可以在復(fù)雜的路由式網(wǎng)絡(luò)中傳遞數(shù)據(jù)所需的服務(wù)

IP協(xié)議可以將多個交換網(wǎng)絡(luò)連接起來，在源地址和目的地址之間傳輸數(shù)據(jù)包，同時它還能提供數(shù)據(jù)的組裝功能，以適應(yīng)不同網(wǎng)絡(luò)對數(shù)據(jù)包大小的要求

預(yù)研知識：

IP地址：

IP地址是互聯(lián)網(wǎng)協(xié)議特有的一種地址，它是IP協(xié)議提供的一種統(tǒng)一的地址格式，IP地址為互聯(lián)網(wǎng)的每個網(wǎng)絡(luò)和每臺主機(jī)分配了一個邏輯地址，以此來屏蔽物理地址的差異

IP地址的格式：

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

網(wǎng)絡(luò)號：前三部分用于標(biāo)識網(wǎng)段，保證相互連接的兩個網(wǎng)段有不同標(biāo)識

主機(jī)號：由最后一部分組成，用于標(biāo)識主機(jī)，保證處于同一網(wǎng)段的兩臺主機(jī)有不同的主機(jī)號

通過合理設(shè)置主機(jī)號和網(wǎng)絡(luò)號, 就可以保證在相互連接的網(wǎng)絡(luò)中, 每臺主機(jī)的IP地址都不相同4

MAC地址：

被稱為物理地址，是用來標(biāo)識網(wǎng)絡(luò)中每個設(shè)備的，MAC地址是設(shè)備出廠之后就寫死的

引入IP地址的目的：

在單個局域網(wǎng)網(wǎng)段中，計(jì)算機(jī)與計(jì)算機(jī)之間可以使用數(shù)據(jù)鏈路層提供的MAC地址進(jìn)行通信

如果在路由式網(wǎng)絡(luò)中，計(jì)算機(jī)之間就不能用MAC地址實(shí)現(xiàn)通信，主要是因?yàn)樵诼酚墒骄W(wǎng)絡(luò)中，數(shù)據(jù)只是經(jīng)過一次簡單的利用兩個計(jì)算機(jī)之間的MAC地址建立通信，而是需要進(jìn)行多次的通信，每次跳轉(zhuǎn)都會體目的主機(jī)更近一步，經(jīng)歷都次跳轉(zhuǎn)，最終找到目的主機(jī)實(shí)現(xiàn)通信，而這個過程中，要知道每次向哪跳轉(zhuǎn)才能更接近目的主機(jī)，必須使用一種邏輯化、層次化的尋址方案對網(wǎng)絡(luò)進(jìn)行組織，這就是 IP 地址

IP協(xié)議數(shù)據(jù)報格式

IP協(xié)議的工作方式：

由于網(wǎng)絡(luò)分為同網(wǎng)段和不同網(wǎng)段，所以會分成兩種方式

同網(wǎng)段：如果源地址主機(jī)和目的地址主機(jī)處于同一網(wǎng)段，則目的IP地址被 ARP協(xié)議 解析為MAC地址后，源主機(jī)會根據(jù)目的MAC地址直接將數(shù)據(jù)包發(fā)送給目的主機(jī)

不同網(wǎng)段：

如果源地址主機(jī)和目的地址主機(jī)不處于同一網(wǎng)段，則數(shù)據(jù)包會經(jīng)歷多個過程最終發(fā)送給目的主機(jī)

1、網(wǎng)關(guān)(一般為路由器)的 IP地址 被 ARP協(xié)議 解析為 MAC地址，根據(jù)該 MAC地址 源主機(jī)會將數(shù)據(jù)包發(fā)送到網(wǎng)關(guān)

2、網(wǎng)關(guān)根據(jù)數(shù)據(jù)包中的網(wǎng)段ID找到目標(biāo)網(wǎng)絡(luò)，如果找到，將數(shù)據(jù)包發(fā)送給目標(biāo)網(wǎng)路，如果沒有則重復(fù)第一步發(fā)送到更高一級網(wǎng)關(guān)

3、數(shù)據(jù)包經(jīng)過網(wǎng)關(guān)發(fā)送到正確的網(wǎng)段后，目標(biāo)IP被 ARP協(xié)議 解析為MAC地址，在根據(jù)該 MAC地址 將數(shù)據(jù)包發(fā)送給目標(biāo)地址的主機(jī)

ICMP協(xié)議

ICMP協(xié)議又叫控制報文協(xié)議，ICMP協(xié)議用于在IP 和 路由器之間傳遞控制消息，描述網(wǎng)絡(luò)是否通暢、主機(jī)是否可達(dá)、路由器是否可用等網(wǎng)絡(luò)狀態(tài)，ICMP本身并不傳輸數(shù)據(jù)，但對于用戶間數(shù)據(jù)的傳遞起著重要的作用

作用：

在數(shù)據(jù)包從源主機(jī)傳輸?shù)侥康闹鳈C(jī)的過程中，會經(jīng)歷一個或多個路由器，而數(shù)據(jù)包在經(jīng)過這些路由器傳輸過程中，可能會遇到很多問題，最終導(dǎo)致數(shù)據(jù)包沒有成功傳遞給目的主機(jī)。為了了解數(shù)據(jù)包在傳輸過程中在哪個環(huán)節(jié)出了問題，就需要用到ICMP協(xié)議，它可以跟蹤數(shù)據(jù)包，并把消息返回給源主機(jī)。

數(shù)據(jù)鏈路層

數(shù)據(jù)鏈路層是TCP/IP網(wǎng)絡(luò)模型的第二層，基于物理層和網(wǎng)絡(luò)層之間，數(shù)據(jù)鏈路層在物理層提供的服務(wù)的基礎(chǔ)上向網(wǎng)絡(luò)層提供服務(wù)，其最基本的服務(wù)是將源自物理層來的數(shù)據(jù)可靠地傳輸?shù)较噜徆?jié)點(diǎn)的目標(biāo)機(jī)網(wǎng)絡(luò)層。

ARP協(xié)議

ARP協(xié)議是數(shù)據(jù)進(jìn)行網(wǎng)絡(luò)傳輸過程中，通過IP地址向MAC地址的轉(zhuǎn)換，解決網(wǎng)絡(luò)層和物理層銜接問題

引入ARP協(xié)議的目的：

由于 IP 地址和 MAC 地址定位方式不同，ARP 協(xié)議成為數(shù)據(jù)傳輸?shù)谋貍鋮f(xié)議。主機(jī)發(fā)送信息前，必須通過 ARP 協(xié)議獲取目標(biāo) IP 地址對應(yīng)的 MAC 地址，才能正確地發(fā)送數(shù)據(jù)包。

ARP的工作流程：

如圖展示的是同一網(wǎng)段下的兩臺主機(jī)，ARP的工作流程

主機(jī)A以廣播的形式向該網(wǎng)段內(nèi)的所有主機(jī)發(fā)送ARP請求，請求中包含了目的主機(jī)的IP地址

主機(jī)B接收到請求，通過請求中的目的IP地址發(fā)現(xiàn)自己是主機(jī)A要找的，返回響應(yīng)，響應(yīng)包括主機(jī)B的 MAC地址

ARP緩存：

在請求目標(biāo)主機(jī)的 MAC 地址時，每次獲取目標(biāo)主機(jī) MAC 地址都需要發(fā)送一次 ARP 請求，然后根據(jù)響應(yīng)獲取到 MAC 地址。

為了避免重復(fù)發(fā)送 ARP 請求，每臺主機(jī)都有一個 ARP 高速緩存。當(dāng)主機(jī)得到 ARP 響應(yīng)后，將目標(biāo)主機(jī)的 IP 地址和物理地址存入本機(jī) ARP 緩存中，并保留一定時間。

只要在這個時間范圍內(nèi)，下次請求 MAC 地址時，直接查詢 ARP 緩存，而無須再發(fā)送 ARP 請求，從而節(jié)約了網(wǎng)絡(luò)資源。

物理層

物理層，顧名思義就是用物理手段將兩個要通信的電腦連接起來，主要用來傳輸0、1光電信號，因?yàn)檫@一層過于偏硬件，所以本文不做過多的贅述

整體的網(wǎng)絡(luò)傳輸流程

經(jīng)過以上對網(wǎng)絡(luò)傳輸層中每一層理解下面我們來看看，當(dāng)訪問一個網(wǎng)頁時，到底發(fā)生了什么?

主機(jī)A：發(fā)送http://www.baidu.com網(wǎng)絡(luò)數(shù)據(jù)報

DNS解析：將域名轉(zhuǎn)換成對應(yīng)IP地址(本機(jī)DNS緩存棧開始找—>逐級向上查找，如果根域服務(wù)器找不到，表示公網(wǎng)上沒有該域名主機(jī))

找到IP后：通過目的IP找到對應(yīng)的目的MAC地址

根據(jù)目的IP計(jì)算目的主機(jī)是否和主機(jī)A處于同一網(wǎng)段

如在同網(wǎng)段：接通過ARP協(xié)議解析出對應(yīng)的目的MAC，跳轉(zhuǎn)到底9步

如不在同一網(wǎng)段：發(fā)送數(shù)據(jù)報到網(wǎng)關(guān)，現(xiàn)在ARP緩存表查找，通過網(wǎng)關(guān)IP查找MAC地址，找不到發(fā)送查詢MAC廣播數(shù)據(jù)報，最終返回網(wǎng)關(guān)自己的MAC

交換機(jī)轉(zhuǎn)發(fā)：在MAC地址轉(zhuǎn)換表中找到對應(yīng)MAC交換機(jī)接口

路由器接收：分用數(shù)據(jù)報

途中的設(shè)備：與第7步同樣操作如目的IP對應(yīng)的MAC地址不是當(dāng)前設(shè)備則繼續(xù)重復(fù)該操作繼續(xù)往更接近目的IP的路由發(fā)送

找到目的主機(jī)B，主機(jī)B的服務(wù)器開始接受分用請求，解析，最終組織響應(yīng)

同上述操作一樣，由主機(jī)B向主機(jī)A發(fā)送數(shù)據(jù)

最終主機(jī)A接受到數(shù)據(jù)報，經(jīng)過分用，解析，最終得到響應(yīng)

審核編輯：湯梓紅