常見網(wǎng)絡(luò)協(xié)議匯總，真的是詳細(xì)到家了！
網(wǎng)絡(luò)安全工程師學(xué)習(xí)平臺(tái)。這里有網(wǎng)絡(luò)攻防、滲透測試、代碼審計(jì)、系統(tǒng)防護(hù)等行業(yè)資訊 | 技能干貨 | 資料福利 |，等你來get。
文章轉(zhuǎn)自網(wǎng)絡(luò)技術(shù)干貨圈，侵刪
轉(zhuǎn)載請(qǐng)注明以下內(nèi)容：
來源：https://blog.csdn.net/m0_46233999/article/details/119455352
前言
本篇博客將對(duì)基于 計(jì)算機(jī)網(wǎng)絡(luò)五層模型 中的常見協(xié)議做以總結(jié) ，目的通過這些具體的協(xié)議更深刻的認(rèn)識(shí)整體網(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é)兩臺(tái)主機(jī)之間的數(shù)據(jù)傳輸，將數(shù)據(jù)從發(fā)送端傳輸?shù)浇邮斩?br>協(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ù)幀的傳送和識(shí)別，將網(wǎng)絡(luò)層傳遞的數(shù)據(jù)報(bào)封裝成幀，在處于同一個(gè)數(shù)據(jù)數(shù)據(jù)鏈路節(jié)點(diǎn)的兩個(gè)設(shè)備之間傳輸
協(xié)議——ARP協(xié)議、MTU協(xié)議物理層：負(fù)責(zé)光電信號(hào)的傳遞方式，實(shí)現(xiàn)相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳輸
對(duì)于五層網(wǎng)絡(luò)模型基本都是耳熟能詳，但是有沒有思考過，網(wǎng)絡(luò)為什么要這樣分層呢？
最直接的回答就是為了簡化網(wǎng)絡(luò)設(shè)計(jì)的復(fù)雜性，通信協(xié)議采用分層結(jié)構(gòu)，各層之間既相互獨(dú)立又相互協(xié)調(diào)工作，如此以來便達(dá)到的高效的目的。如同設(shè)計(jì)模式中對(duì)于設(shè)計(jì)一個(gè)復(fù)雜的程序時(shí)，盡量使程序各功能之間是解耦合的一樣，對(duì)于復(fù)雜的網(wǎng)絡(luò)設(shè)計(jì)，分層設(shè)計(jì)也是很明智的一種做法。
網(wǎng)絡(luò)分層的最本質(zhì)就是每一層獨(dú)立的完成一個(gè)任務(wù)而不必考慮自己任務(wù)之外的實(shí)現(xiàn)，而因?yàn)椴煌娜蝿?wù)因此就有了每一層所對(duì)應(yīng)的不同設(shè)備。(實(shí)例到應(yīng)用就是，物理層只需要關(guān)系0和1的光電信號(hào)如何傳輸，而對(duì)它所表達(dá)的內(nèi)容毫不關(guān)心；再往上數(shù)據(jù)鏈路層只需要關(guān)心封裝好的數(shù)據(jù)幀如何準(zhǔn)確的送到對(duì)應(yīng)的MAC地址的目的主機(jī)中，而不必關(guān)心數(shù)據(jù)報(bào)的具體內(nèi)容和具體會(huì)通過何種方式光纖還是局域網(wǎng)…同理往上對(duì)于所有層)
應(yīng)用層協(xié)議
應(yīng)用層協(xié)議主要負(fù)責(zé)各個(gè)程序間的通信，發(fā)生網(wǎng)絡(luò)傳輸一個(gè)數(shù)據(jù)時(shí)，先由應(yīng)用層對(duì)數(shù)據(jù)按照對(duì)應(yīng)的協(xié)議封裝，然后交給下一層傳輸層，當(dāng)經(jīng)過一系列網(wǎng)絡(luò)傳輸，數(shù)據(jù)達(dá)到接收端時(shí)，一層層的分用，最后一層再由應(yīng)用層分用，最終得到數(shù)據(jù)。
DNS協(xié)議：
DNS協(xié)議是一個(gè)應(yīng)用層協(xié)議，建立在TCP和UDP的基礎(chǔ)之上，使用默認(rèn)端口為53，其默認(rèn)通過UDP協(xié)議通信，但如果報(bào)文過大是則會(huì)切換成TCP協(xié)議。
域名系統(tǒng) (DNS) 的作用是將人類可讀的域名 (如，www.baidu.com) 轉(zhuǎn)換為機(jī)器可讀的 IP 地址 (如，192.0.2.44)，本質(zhì)是通過DNS域名和IP地址的對(duì)應(yīng)關(guān)系轉(zhuǎn)換，而這種對(duì)應(yīng)關(guān)系則保存在DNS服務(wù)器中
域名的解析過程：
域名的解析工作大體上可以分為兩個(gè)步驟：第一步客戶端向本地DNS服務(wù)器發(fā)起一個(gè)DNS請(qǐng)求報(bào)文，報(bào)文里攜帶需要查詢的域名，第二步本地DNS服務(wù)器向本機(jī)回應(yīng)一個(gè)DNS響應(yīng)報(bào)文，報(bào)文里攜帶查詢域名所對(duì)應(yīng)的IP地址
具體流程如下：
“”
在本地緩存中查詢，如果有則返回對(duì)應(yīng)IP，如果沒有將請(qǐng)求發(fā)給DNS服務(wù)器
當(dāng)本地DNS服務(wù)器接收到查詢后，先在服務(wù)器管理區(qū)域記錄中查詢，若沒有再在服務(wù)器本地緩存中查詢，如果沒有將請(qǐng)求發(fā)送到根域名服務(wù)器
根域名服務(wù)器負(fù)責(zé)解析請(qǐng)求的根域部分，然后將包含下一級(jí)域名信息的DNS服務(wù)地址返回給本地DNS服務(wù)器
本地DNS服務(wù)器利用根域名服務(wù)器解析的地址訪問下一級(jí)DNS服務(wù)器，得到再下一級(jí)域的DNS服務(wù)器地址
按照上述遞歸方法逐級(jí)接近查詢目標(biāo)，最后在有目標(biāo)域名的DNS服務(wù)器上找到相應(yīng)的IP地址信息
本地DNS服務(wù)器將最終查詢到的IP返回給客戶端，讓客戶端訪問對(duì)應(yīng)主機(jī)
HTTP協(xié)議
HTTP協(xié)議是一個(gè)簡單的請(qǐng)求——響應(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ù)器提出請(qǐng)求；
服務(wù)器接受請(qǐng)求，并根據(jù)請(qǐng)求返回相應(yīng)的數(shù)據(jù)作為應(yīng)答響應(yīng)；
客戶端與服務(wù)器關(guān)閉連接。
HTTP協(xié)議報(bào)文格式
HTTP報(bào)文由從客戶機(jī)到服務(wù)器的請(qǐng)求(Request)和從服務(wù)器到客戶機(jī)的響應(yīng)(Respone)構(gòu)成
請(qǐng)求由請(qǐng)求行，請(qǐng)求頭，請(qǐng)求體組成
請(qǐng)求行中包含請(qǐng)求方法、路徑、版本號(hào)，請(qǐng)求頭為多個(gè)key-value數(shù)據(jù)，請(qǐng)求正文包含一些請(qǐng)求的數(shù)據(jù)
響應(yīng)由響應(yīng)行，響應(yīng)頭，響應(yīng)體組成
響應(yīng)行中包含狀態(tài)碼，狀態(tài)碼描述，版本號(hào)，響應(yīng)頭為多個(gè)key-value數(shù)據(jù)，響應(yīng)正文包含一些響應(yīng)的數(shù)據(jù)
常見HTTP響應(yīng)狀態(tài)碼匯總
“200 OK ：客戶端請(qǐng)求成功
”
3XX系列
“301 Moved Permanently ：請(qǐng)求的資源以被永久的移動(dòng)到新URL中，返回的Response中包含一個(gè)Location，瀏覽器會(huì)自動(dòng)重定向到新URL，以后請(qǐng)求都會(huì)被新的URL替代
”
302 Found ：與301類似，但請(qǐng)求的資源只是臨時(shí)的被移動(dòng)到新的URL中，下次請(qǐng)求客戶端繼續(xù)使用原URL
307 Temporary Redirect ：臨時(shí)重定向，類似于302，使用GET請(qǐng)求重定向
4XX系列
“400 Bad Request ：客戶端請(qǐng)求語法錯(cuò)誤，服務(wù)器無法理解（在 ajax 請(qǐng)求后臺(tái)數(shù)據(jù)時(shí)比較常見）
”
401 Unauthorized ：請(qǐng)求要求用戶的身份認(rèn)證
403 Forbidden ：服務(wù)器理解客戶端請(qǐng)求，但是拒絕執(zhí)行（一般用于用戶級(jí)別為達(dá)到要求等等不支持訪問）
404 Not Found ：服務(wù)器無法根據(jù)客戶端請(qǐng)求找到對(duì)應(yīng)資源
405 Method Not Allowed ：服務(wù)器不支持該方法
5XX系列
“500 Internal Server Error ：服務(wù)器內(nèi)部錯(cuò)誤，無法完成請(qǐng)求
”
503 Service Unavailable ：由于超載或系統(tǒng)維護(hù)，服務(wù)器暫時(shí)的無法處理客戶端的請(qǐng)求。延時(shí)的長度可包含在服務(wù)器的Retry-After頭信息中
HTTP協(xié)議的特點(diǎn)
支持服務(wù)器/客戶端模式
傳輸較快速，客戶端向服務(wù)器發(fā)送請(qǐng)求，只需要傳輸請(qǐng)求方法和路徑
靈活，HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象
無連接，每次連接只能處理一個(gè)請(qǐng)求，服務(wù)器處理完客戶端請(qǐng)求，客戶端收到響應(yīng)后就斷開連接
無狀態(tài)，協(xié)議本身對(duì)事務(wù)處理沒有記憶能力，如果后序連接需要之前發(fā)送的信息時(shí)就需要重傳
HTTP1.0和HTTP1.1和HTTP2.0的區(qū)別：
HTTP1.0和HTTP1.1的區(qū)別：
“”
長連接：HTTP1.0只支持瀏覽器與服務(wù)器的短連接，即每次請(qǐng)求都要重新建立連接，服務(wù)器無法記錄每個(gè)歷史請(qǐng)求，HTTP1.1支持長連接即在一次連接下，瀏覽器可以向服務(wù)器發(fā)送多次請(qǐng)求
增加Host字段：HTTP1.0中認(rèn)為每個(gè)服務(wù)器都綁定這唯一一個(gè)IP，所有發(fā)送的請(qǐng)求頭URL中沒有host信息，而HTTP1.1在請(qǐng)求和響應(yīng)中都支持了host頭域，且請(qǐng)求消息中如果沒有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤(400 Bad Request)
緩存：HTTP1.1在1.0的基礎(chǔ)上加入了一些cache的新特性，當(dāng)緩存對(duì)象的Age超過Expire時(shí)變?yōu)閟tale對(duì)象，cache不需要直接拋棄stale對(duì)象，而是與源服務(wù)器進(jìn)行重新激活（revalidation）。
錯(cuò)誤提示：HTTP1.0中定義了16個(gè)狀態(tài)碼，對(duì)錯(cuò)誤或警告的提示不夠具體。HTTP1.1引入了一個(gè)Warning頭域，增加對(duì)錯(cuò)誤或警告信息的描述，并且還新增了24個(gè)狀態(tài)響應(yīng)碼，如409(Conflict)表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410(Gone)表示服務(wù)器上的某個(gè)資源被永久性的刪除
HTTP1.X和HTTP2.0的區(qū)別
“”
增加二進(jìn)制格式解析：HTTP1.X解析基于文本，而文本格式本身就具有多樣性，很多場景下不方便，而引入二進(jìn)制后，只有0和1組合，使解析更加方便也增強(qiáng)了健壯性
多路復(fù)用：即每個(gè)request都是是用作連接共享機(jī)制的，每個(gè)request都對(duì)應(yīng)一個(gè)id，使一個(gè)連接可以有多個(gè)請(qǐng)求，再根據(jù)id將request歸屬到不同的服務(wù)端請(qǐng)求里
header壓縮：HTTP1.X中，每次傳輸都要寫點(diǎn)header頭，占用了大量數(shù)據(jù)，因此HTTP2.0在客戶端和服務(wù)端各保存了一份header fields表，每次傳輸時(shí)只需傳輸header的更新信息，將header fields表更新即可實(shí)現(xiàn)header傳輸
服務(wù)端推送：HTTP2.0也添加了server push功能
HTTPS協(xié)議
HTTPS同樣作為應(yīng)用層協(xié)議，可以說它是HTTP的升級(jí)版，增加了傳輸數(shù)據(jù)的安全性，HTTPS協(xié)議是在HTTP的基礎(chǔ)上增加了一個(gè)SSL外殼，HTTPS運(yùn)行在SSL上，SSL運(yùn)行在TCP上，對(duì)數(shù)據(jù)的加密工作就是在SSL上完成的
其保證安全性的做法是通過證書驗(yàn)證和對(duì)信息混合加密的方式
混合加密技術(shù)：
“混合加密技術(shù)：結(jié)合對(duì)稱加密與非對(duì)稱加密
”
服務(wù)端生成私鑰，再通過私鑰生成公鑰，然后將公鑰放在證書中頒發(fā)給客戶端
使用公鑰和私鑰以非對(duì)稱方式加密生成密鑰
客戶端接下來的傳輸數(shù)據(jù)中，都會(huì)用密鑰以對(duì)稱方式對(duì)信息加密，再傳輸給服務(wù)端
對(duì)于，上述提到的公鑰和私鑰，我們規(guī)定用公鑰加密的內(nèi)容必須用私鑰才能解開，同樣，私鑰加密的內(nèi)容只有公鑰能解開_
所以HTTPS傳輸數(shù)據(jù)是用被密鑰加密的密文和用公鑰加密的私鑰來保證數(shù)據(jù)安全的
“HTTPS加密，只用對(duì)稱加密可以嗎？
”
不行！無法保證安全性，因?yàn)橹挥脤?duì)稱加密即只用密鑰對(duì)數(shù)據(jù)加密傳輸?shù)脑挘绻麄鬏斖局?，信息被第三方劫持，獲取到密鑰，那接下來的傳輸，第三方都可以通過密鑰對(duì)數(shù)據(jù)解密從而得到原始數(shù)據(jù)。
“HTTPS加密，只用非對(duì)稱加密可以嗎？兩次呢？
”
同樣不行，如果只用非對(duì)稱加密?？蛻舳嗣看蝹鬏敂?shù)據(jù)用公鑰加密，服務(wù)端再用私鑰解密這一方向看似安全，但當(dāng)服務(wù)端發(fā)送數(shù)據(jù)用私鑰加密，客戶端收到用公鑰解密時(shí)，第三方劫持到信息，但可能在此之前就獲得公鑰，因?yàn)槭状畏?wù)端向客戶端發(fā)送公鑰是明文傳輸?shù)摹?br>而換個(gè)角度如果使用兩次非對(duì)稱加密，即兩組公鑰，兩組私鑰，客戶端服務(wù)端各持一組，理論上可以達(dá)到安全，但實(shí)際HTTPS并未采用，因?yàn)榉菍?duì)稱加密耗時(shí)十分大
證書：
單有混合加密技術(shù)，看似已經(jīng)保證了傳輸?shù)陌踩?，?shí)則還是有漏洞，問題就在于服務(wù)器根本無法識(shí)別發(fā)送過來的公鑰是否是自己的，如此以來在第三方劫持到數(shù)據(jù)后，自行再定義一個(gè)公鑰B，并將公鑰B傳回給客服端，此時(shí)客戶端就會(huì)利用該公鑰B重新加密數(shù)據(jù)然后發(fā)送，此時(shí)第三方就可以通過自己的公鑰B解密得到原始數(shù)據(jù)了。
證書就解決了這一問題，指定頒發(fā)的為CA機(jī)構(gòu)，當(dāng)網(wǎng)站使用HTTPS時(shí)，會(huì)向CA機(jī)構(gòu)申請(qǐng)一個(gè)數(shù)字證書，證書中可以存放公鑰、數(shù)據(jù)等信息，由此以來，服務(wù)端就可以通過證書來向客戶端證明正確的公鑰是哪一個(gè)，以此保證安全。
而對(duì)于證書，還有一些自己的放篡改機(jī)制，防止第三方獲取到使用
傳輸層協(xié)議
傳輸層的主要功能是為了實(shí)現(xiàn)“端口到端口”的通信，以確保一條數(shù)據(jù)發(fā)送到主機(jī)上后，能夠正確的傳遞到對(duì)應(yīng)的端口上
UDP協(xié)議
UDP 為應(yīng)用程序提供了一種無需建立連接就可以發(fā)送封裝的 IP 數(shù)據(jù)包的方法，但是UDP也有自己的缺陷，一旦進(jìn)行通信，就不知道對(duì)方是否接收到數(shù)據(jù)了，很有可能會(huì)造成傳輸數(shù)據(jù)的丟包問題
特點(diǎn)：
無連接：只需要知道目的ip和端口號(hào)就可以發(fā)送數(shù)據(jù)，無需建立連接
不可靠：沒有一系列機(jī)制來應(yīng)對(duì)傳輸數(shù)據(jù)時(shí)的丟包問題
面向數(shù)據(jù)報(bào)發(fā)送：應(yīng)用層交給UDP什么樣的報(bào)文，UDP就會(huì)發(fā)送什么樣的，不會(huì)進(jìn)行拆分，合并
UDP一次傳輸?shù)臄?shù)據(jù)大小有限，最大64k
UDP的傳輸流程
UDP的適用范圍：
由于UDP不屬于連接型協(xié)議，所以具有資源消耗小。處理速度優(yōu)的特點(diǎn)，因此經(jīng)常使用與視頻、音頻通話傳輸中，因?yàn)榘l(fā)送的數(shù)據(jù)較多，偶爾丟包一兩個(gè)不會(huì)產(chǎn)生太大影響
TCP
因?yàn)樯鲜鲋v到UDP的傳輸是不可靠的，經(jīng)常會(huì)導(dǎo)致連接錯(cuò)誤、數(shù)據(jù)丟包問題，針對(duì)這些問題規(guī)定了另一個(gè)傳輸層協(xié)議——TCP協(xié)議，TCP是一種面向連接、可靠的、基于字節(jié)流的傳輸層協(xié)議
TCP的特點(diǎn)：
面向連接：在傳輸數(shù)據(jù)是，要先建立起客戶端與服務(wù)端的連接，才能進(jìn)行數(shù)據(jù)傳輸
可靠的通信：TCP輸出數(shù)據(jù)中，會(huì)基于內(nèi)部的各種機(jī)制保證數(shù)據(jù)傳輸?shù)侥康亩丝?/p>
基于字節(jié)流：TCP傳輸數(shù)據(jù)是基于字節(jié)傳輸?shù)?，易于?duì)數(shù)據(jù)的拆分與合并發(fā)送
TCP的頭部比UDP的開銷要打，因?yàn)橐娣鸥嗟男畔?/p>
TCP與UDP的區(qū)別：
UDP是無連接的，TCP是有連接的
UDP是不可靠的，TCP是可靠的
UDP面向數(shù)據(jù)報(bào)，TCP面向字節(jié)流
UDP比TCP的傳輸消耗小，速度更快
這里分享一張神圖，以便于更加形象的理解TCP和UDP的區(qū)別
網(wǎng)絡(luò)層
網(wǎng)絡(luò)層是基于數(shù)據(jù)鏈路層和傳輸層之間的第三層協(xié)議，它在數(shù)據(jù)鏈路層提供的兩個(gè)相鄰端點(diǎn)之間的數(shù)據(jù)幀的傳送功能上，進(jìn)一步管理網(wǎng)絡(luò)中的數(shù)據(jù)通信，將數(shù)據(jù)設(shè)法從源端經(jīng)過若干個(gè)中間節(jié)點(diǎn)傳送到目的端，從而向傳輸層提供最基本的端到端的數(shù)據(jù)傳送服務(wù)
網(wǎng)絡(luò)層的目的是實(shí)現(xiàn)兩個(gè)端系統(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é)議可以將多個(gè)交換網(wǎng)絡(luò)連接起來，在源地址和目的地址之間傳輸數(shù)據(jù)包，同時(shí)它還能提供數(shù)據(jù)的組裝功能，以適應(yīng)不同網(wǎng)絡(luò)對(duì)數(shù)據(jù)包大小的要求
預(yù)研知識(shí)：
“IP地址：
”
IP地址是互聯(lián)網(wǎng)協(xié)議特有的一種地址，它是IP協(xié)議提供的一種統(tǒng)一的地址格式，IP地址為互聯(lián)網(wǎng)的每個(gè)網(wǎng)絡(luò)和每臺(tái)主機(jī)分配了一個(gè)邏輯地址，以此來屏蔽物理地址的差異
“IP地址的格式：
”
IP地址為32位地址，被分為4個(gè)部分，如XXX.XXX.XXX.XXX，IP地址又被劃分為兩個(gè)部分
網(wǎng)絡(luò)號(hào)：前三部分用于標(biāo)識(shí)網(wǎng)段，保證相互連接的兩個(gè)網(wǎng)段有不同標(biāo)識(shí)
主機(jī)號(hào)：由最后一部分組成，用于標(biāo)識(shí)主機(jī)，保證處于同一網(wǎng)段的兩臺(tái)主機(jī)有不同的主機(jī)號(hào)
通過合理設(shè)置主機(jī)號(hào)和網(wǎng)絡(luò)號(hào), 就可以保證在相互連接的網(wǎng)絡(luò)中, 每臺(tái)主機(jī)的IP地址都不相同4
“MAC地址：
”
被稱為物理地址，是用來標(biāo)識(shí)網(wǎng)絡(luò)中每個(gè)設(shè)備的，MAC地址是設(shè)備出廠之后就寫死的
“引入IP地址的目的：
”
在單個(gè)局域網(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)過一次簡單的利用兩個(gè)計(jì)算機(jī)之間的MAC地址建立通信，而是需要進(jìn)行多次的通信，每次跳轉(zhuǎn)都會(huì)體目的主機(jī)更近一步，經(jīng)歷都次跳轉(zhuǎn)，最終找到目的主機(jī)實(shí)現(xiàn)通信，而這個(gè)過程中，要知道每次向哪跳轉(zhuǎn)才能更接近目的主機(jī)，必須使用一種邏輯化、層次化的尋址方案對(duì)網(wǎng)絡(luò)進(jìn)行組織，這就是 IP 地址
“IP協(xié)議數(shù)據(jù)報(bào)格式
”
IP協(xié)議的工作方式：
由于網(wǎng)絡(luò)分為同網(wǎng)段和不同網(wǎng)段，所以會(huì)分成兩種方式
同網(wǎng)段：如果源地址主機(jī)和目的地址主機(jī)處于同一網(wǎng)段，則目的IP地址被 ARP協(xié)議 解析為MAC地址后，源主機(jī)會(huì)根據(jù)目的MAC地址直接將數(shù)據(jù)包發(fā)送給目的主機(jī)
不同網(wǎng)段：
如果源地址主機(jī)和目的地址主機(jī)不處于同一網(wǎng)段，則數(shù)據(jù)包會(huì)經(jīng)歷多個(gè)過程最終發(fā)送給目的主機(jī)
1、網(wǎng)關(guān)(一般為路由器)的 IP地址 被 ARP協(xié)議 解析為 MAC地址，根據(jù)該 MAC地址 源主機(jī)會(huì)將數(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ā)送到更高一級(jí)網(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é)議又叫控制報(bào)文協(xié)議，ICMP協(xié)議用于在IP 和 路由器之間傳遞控制消息，描述網(wǎng)絡(luò)是否通暢、主機(jī)是否可達(dá)、路由器是否可用等網(wǎng)絡(luò)狀態(tài)，ICMP本身并不傳輸數(shù)據(jù)，但對(duì)于用戶間數(shù)據(jù)的傳遞起著重要的作用
作用：
在數(shù)據(jù)包從源主機(jī)傳輸?shù)侥康闹鳈C(jī)的過程中，會(huì)經(jīng)歷一個(gè)或多個(gè)路由器，而數(shù)據(jù)包在經(jīng)過這些路由器傳輸過程中，可能會(huì)遇到很多問題，最終導(dǎo)致數(shù)據(jù)包沒有成功傳遞給目的主機(jī)。為了了解數(shù)據(jù)包在傳輸過程中在哪個(gè)環(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 地址對(duì)應(yīng)的 MAC 地址，才能正確地發(fā)送數(shù)據(jù)包。
ARP的工作流程：
如圖展示的是同一網(wǎng)段下的兩臺(tái)主機(jī)，ARP的工作流程
主機(jī)A以廣播的形式向該網(wǎng)段內(nèi)的所有主機(jī)發(fā)送ARP請(qǐng)求，請(qǐng)求中包含了目的主機(jī)的IP地址
主機(jī)B接收到請(qǐng)求，通過請(qǐng)求中的目的IP地址發(fā)現(xiàn)自己是主機(jī)A要找的，返回響應(yīng)，響應(yīng)包括主機(jī)B的 MAC地址
ARP緩存：
在請(qǐng)求目標(biāo)主機(jī)的 MAC 地址時(shí)，每次獲取目標(biāo)主機(jī) MAC 地址都需要發(fā)送一次 ARP 請(qǐng)求，然后根據(jù)響應(yīng)獲取到 MAC 地址。
為了避免重復(fù)發(fā)送 ARP 請(qǐng)求，每臺(tái)主機(jī)都有一個(gè) ARP 高速緩存。當(dāng)主機(jī)得到 ARP 響應(yīng)后，將目標(biāo)主機(jī)的 IP 地址和物理地址存入本機(jī) ARP 緩存中，并保留一定時(shí)間。
只要在這個(gè)時(shí)間范圍內(nèi)，下次請(qǐng)求 MAC 地址時(shí)，直接查詢 ARP 緩存，而無須再發(fā)送 ARP 請(qǐng)求，從而節(jié)約了網(wǎng)絡(luò)資源。
物理層
物理層，顧名思義就是用物理手段將兩個(gè)要通信的電腦連接起來，主要用來傳輸0、1光電信號(hào)，因?yàn)檫@一層過于偏硬件，所以本文不做過多的贅述
整體的網(wǎng)絡(luò)傳輸流程
經(jīng)過以上對(duì)網(wǎng)絡(luò)傳輸層中每一層理解下面我們來看看，當(dāng)訪問一個(gè)網(wǎng)頁時(shí)，到底發(fā)生了什么？
主機(jī)A：發(fā)送http://www.baidu.com網(wǎng)絡(luò)數(shù)據(jù)報(bào)
DNS解析：將域名轉(zhuǎn)換成對(duì)應(yīng)IP地址(本機(jī)DNS緩存棧開始找—>逐級(jí)向上查找，如果根域服務(wù)器找不到，表示公網(wǎng)上沒有該域名主機(jī))
找到IP后：通過目的IP找到對(duì)應(yīng)的目的MAC地址
根據(jù)目的IP計(jì)算目的主機(jī)是否和主機(jī)A處于同一網(wǎng)段
如在同網(wǎng)段：接通過ARP協(xié)議解析出對(duì)應(yīng)的目的MAC，跳轉(zhuǎn)到底9步
如不在同一網(wǎng)段：發(fā)送數(shù)據(jù)報(bào)到網(wǎng)關(guān)，現(xiàn)在ARP緩存表查找，通過網(wǎng)關(guān)IP查找MAC地址，找不到發(fā)送查詢MAC廣播數(shù)據(jù)報(bào)，最終返回網(wǎng)關(guān)自己的MAC
交換機(jī)轉(zhuǎn)發(fā)：在MAC地址轉(zhuǎn)換表中找到對(duì)應(yīng)MAC交換機(jī)接口
路由器接收：分用數(shù)據(jù)報(bào)
途中的設(shè)備：與第7步同樣操作如目的IP對(duì)應(yīng)的MAC地址不是當(dāng)前設(shè)備則繼續(xù)重復(fù)該操作繼續(xù)往更接近目的IP的路由發(fā)送
找到目的主機(jī)B，主機(jī)B的服務(wù)器開始接受分用請(qǐng)求，解析，最終組織響應(yīng)
同上述操作一樣，由主機(jī)B向主機(jī)A發(fā)送數(shù)據(jù)
最終主機(jī)A接受到數(shù)據(jù)報(bào)，經(jīng)過分用，解析，最終得到響應(yīng)
