一、ARP協(xié)議

ARP（Address Resolution PRotocol）地址解析協(xié)議，將ip地址解析成MAC地址。

IP地址在OSI模型第三層，MAC地址在OSI第二層，彼此不直接通信；

在通過(guò)以太網(wǎng)發(fā)生IP數(shù)據(jù)包時(shí)，先封裝第三層（32位IP地址）和第二層（48位MAC地址）的報(bào)頭；

但由于發(fā)送數(shù)據(jù)包時(shí)只知道目標(biāo)IP地址，不知道其Mac地址，且不能跨越第二、三層，所以需要使用地址解析協(xié)議。

ARP工作流程分請(qǐng)求和響應(yīng)：

在dos窗口內(nèi)“ping”某個(gè)域名抓取到的包：

二、IP協(xié)議

IP（Internet Protocol）互聯(lián)網(wǎng)協(xié)議，主要目的是使得網(wǎng)絡(luò)間能夠互相通信，位于OSI第三層，負(fù)責(zé)跨網(wǎng)絡(luò)通信的地址。

當(dāng)以廣播方式發(fā)送數(shù)據(jù)包的時(shí)候，是以MAC地址定位，并且需要電腦在同一子網(wǎng)絡(luò)。

當(dāng)不在同一子網(wǎng)絡(luò)就需要路由發(fā)送，這時(shí)候就需要IP地址來(lái)定位。

同樣在dos窗口內(nèi)“ping”某個(gè)域名抓取到的包：

三、TCP協(xié)議

TCP（Transmission Control Protocol）傳輸控制協(xié)議，一種面向連接、可靠、基于IP的傳輸層協(xié)議，主要目的是為數(shù)據(jù)提供可靠的端到端傳輸。

在OSI模型的第四層工作，能夠處理數(shù)據(jù)的順序和錯(cuò)誤恢復(fù)，最終保證數(shù)據(jù)能夠到達(dá)其應(yīng)到達(dá)的地方。

1）標(biāo)志位

SYN： 同步，在建立連接時(shí)用來(lái)同步序號(hào)。SYN=1， ACK=0表示一個(gè)連接請(qǐng)求報(bào)文段。SYN=1，ACK=1表示同意建立連接。

FIN： 終止，F(xiàn)IN=1時(shí)，表明此報(bào)文段的發(fā)送端的數(shù)據(jù)已經(jīng)發(fā)送完畢，并要求釋放傳輸連接。

ACK： 確認(rèn)，ACK = 1時(shí)代表這是一個(gè)確認(rèn)的TCP包，取值0則不是確認(rèn)包。

DUP ACK：重復(fù)，重復(fù)確認(rèn)報(bào)文，有重復(fù)報(bào)文，一般是是丟包或延遲引起的，從這個(gè)報(bào)文看應(yīng)該是丟包了。

URG：緊急，當(dāng)URG=1時(shí)，表示報(bào)文段中有緊急數(shù)據(jù)，應(yīng)盡快傳送

PSH：推送，當(dāng)發(fā)送端PSH=1時(shí)，接收端盡快的交付給應(yīng)用進(jìn)程

RST：復(fù)位，當(dāng)RST=1時(shí)，表明TCP連接中出現(xiàn)嚴(yán)重差錯(cuò)，必須釋放連接，再重新建立連接

2）端口

客戶端與不同服務(wù)器建立連接時(shí)，源端口和目標(biāo)端口可不同。

3）TCP三次握手

4）TCP四次揮手

TCP四次斷開(kāi)，例如關(guān)閉頁(yè)面的時(shí)候就會(huì)斷開(kāi)連接。

5）TCP概念

1. 發(fā)送窗口

無(wú)法簡(jiǎn)單的看出發(fā)送窗口的大小，發(fā)送窗口會(huì)由網(wǎng)絡(luò)因素決定。發(fā)送窗口定義了一次發(fā)的字節(jié)，而MSS定義了這些字節(jié)通過(guò)多少個(gè)包發(fā)送。

2. 擁塞窗口（cwnd）

描述源端在擁塞控制情況下一次最多能發(fā)送的數(shù)據(jù)包的數(shù)量。

在發(fā)送方維護(hù)一個(gè)虛擬的擁塞窗口，并利用各種算法使它盡可能接近真實(shí)的擁塞點(diǎn)。

網(wǎng)絡(luò)對(duì)發(fā)送窗口的限制，就是通過(guò)擁塞窗口實(shí)現(xiàn)的。

3. 在途字節(jié)數(shù)（bytes in flight）

已經(jīng)發(fā)送出去，但尚未被確認(rèn)的字節(jié)數(shù)。

在途字節(jié)數(shù) = Seq + Len - Ack

其中Seq和Len來(lái)自上一個(gè)數(shù)據(jù)發(fā)送方的包，而Ack來(lái)自上一個(gè)數(shù)據(jù)接收方的包。

4. 擁塞點(diǎn)（congestion point）

發(fā)生擁塞時(shí)候的在途字節(jié)數(shù)就是該時(shí)刻的網(wǎng)絡(luò)擁塞點(diǎn)。

先從Wireshark中找到一連串重傳包中的第一個(gè)，再根據(jù)該Seq找到原始包最后計(jì)算該原始包發(fā)送時(shí)刻的在途字節(jié)數(shù)。

5. 慢啟動(dòng)

RFC建議初始擁塞窗口發(fā)送2、3、或4個(gè)MSS，如果發(fā)出去的包都能得到確認(rèn)，則表明還沒(méi)到擁塞點(diǎn)，可以收到n個(gè)確認(rèn)增加n個(gè)MSS

6. 擁塞避免

慢啟動(dòng)持續(xù)一段時(shí)間后，擁塞窗口達(dá)到一個(gè)較大的值，就得放慢RFC建議在每個(gè)往返時(shí)間增加1個(gè)MSS，比如發(fā)了16個(gè)MSS全部確認(rèn)，那么就增加到17個(gè)MSS

7. 超時(shí)重傳

發(fā)出去的包在等待一段時(shí)間（RTO）后，沒(méi)有收到確認(rèn)，就只能重傳了

8. 快速重傳（Fast Retransmit）

不以時(shí)間驅(qū)動(dòng)，而以數(shù)據(jù)驅(qū)動(dòng)重傳。如果包沒(méi)有連續(xù)到達(dá)，就ACK最后那個(gè)可能被丟了的包，如果發(fā)送方連續(xù)收到3次相同的ACK，就重傳。

9. SACK（Selective Acknowledgment）

選擇性確認(rèn)重傳，ACK還是Fast Retransmit的ACK，SACK則是匯報(bào)收到的數(shù)據(jù)，在發(fā)送端就可以根據(jù)回傳的SACK來(lái)知道哪些數(shù)據(jù)到了，哪些沒(méi)有到。

10. 延遲確認(rèn)（Delayed ACK）

如果收到一個(gè)包后暫時(shí)沒(méi)什么數(shù)據(jù)發(fā)給對(duì)方，那就延遲一段時(shí)間再確認(rèn)。假如這段時(shí)間恰好有數(shù)據(jù)要發(fā)送，那數(shù)據(jù)和確認(rèn)信息可以在一個(gè)包中發(fā)送。

11. LSO

LSO拯救CPU而出的創(chuàng)意，為了緩解CPU的壓力，把它的一部分工作外包給了網(wǎng)卡，比如TCP的分段。

啟用LSO之后，TCP層就可以把大于MSS的數(shù)據(jù)塊直接傳給網(wǎng)卡，讓網(wǎng)卡負(fù)責(zé)分段。

比如“Seq=348586，Len=2776”，被網(wǎng)卡分為“Seq=348586，Len=1388”和“Seq=349974，Len=1388”兩個(gè)包。

在發(fā)送端抓包相當(dāng)于站在CPU角度，只看到一個(gè)分段前的大包，而接收端就可以看到兩個(gè)包。

所以才會(huì)出現(xiàn)只見(jiàn)重傳包，不見(jiàn)原始包的情況。

12. Nagle算法

在發(fā)出去的數(shù)據(jù)還沒(méi)有被確認(rèn)之前，假如又有小數(shù)據(jù)生成，那就把小數(shù)據(jù)收集起來(lái)，湊滿一個(gè)MSS或等收到確認(rèn)后再發(fā)送。

13. Vegas算法

通過(guò)監(jiān)控網(wǎng)絡(luò)狀態(tài)來(lái)調(diào)整發(fā)包速度。

當(dāng)網(wǎng)絡(luò)狀態(tài)良好時(shí)，數(shù)據(jù)包的RTT比較穩(wěn)定，這時(shí)可以增大擁塞窗口；

當(dāng)網(wǎng)絡(luò)開(kāi)始繁忙時(shí)，數(shù)據(jù)包開(kāi)始排隊(duì)，RTT就會(huì)變大，這時(shí)就減小擁塞窗口。

6）選項(xiàng)字段

PTR（Pointer Record）：指針記錄，PTR記錄解析IP地址到域名

TTL（Time to live）：

存活時(shí)間，限制數(shù)據(jù)包在網(wǎng)絡(luò)中存在的時(shí)間，防止數(shù)據(jù)包不斷的在IP互聯(lián)網(wǎng)絡(luò)上循環(huán)，初始值一般為64，每經(jīng)過(guò)一個(gè)路由減去1。

通過(guò)TTL過(guò)濾運(yùn)營(yíng)商劫持包，假的包是搶先應(yīng)答的，所以和真實(shí)包的TTL可能不同（例如ip.ttl == 54）

Seq：數(shù)據(jù)段的序號(hào)，當(dāng)接收端收到亂序的包，就能根據(jù)此序號(hào)重新排序，當(dāng)前Seq等上一個(gè)Seq號(hào)與長(zhǎng)度相加獲取到

Len：數(shù)據(jù)段的長(zhǎng)度，這個(gè)長(zhǎng)度不包括TCP頭

Ack：確認(rèn)號(hào)，接收方向發(fā)送方確認(rèn)已經(jīng)收到了哪些字節(jié)

RTT（Round Trip Time）：也就是一個(gè)數(shù)據(jù)包從發(fā)出去到回來(lái)的時(shí)間

RTO（Retransmission TimeOut）：超時(shí)重傳計(jì)數(shù)器，描述數(shù)據(jù)包從發(fā)送到失效的時(shí)間間隔，是判斷數(shù)據(jù)包丟失與否及網(wǎng)絡(luò)是否擁塞的重要參數(shù)

MTU（Maximum Transmit Unit）：最大傳輸單元

MSS（Maximum Segment Size）：最長(zhǎng)報(bào)文段，TCP包所能攜帶的最大數(shù)據(jù)量，不包含TCP頭和Option。一般為MTU值減去IPv4頭部(至少20字節(jié))和TCP頭部(至少20字節(jié))得到。

Win（Window Size）：聲明自己的接收窗口

TCP Window Scale：窗口擴(kuò)張，放在TCP頭之外的Option，向?qū)Ψ铰暶饕粋€(gè)shift count，作為2的指數(shù)，再乘以TCP定義的接收窗口，得到真正的TCP窗口

DF（Don't fragment）：在網(wǎng)絡(luò)層中，如果帶了就丟棄沒(méi)帶就分片

MF（More fragments）：0表示最后一個(gè)分片，1表示不是最后一片

7）過(guò)濾表達(dá)式

握手請(qǐng)求被對(duì)方拒絕：tcp.flags.reset === 1 && tcp.seq === 1

重傳的握手請(qǐng)求：tcp.flags.syn === 1 && tcp.analysis.retransmission

過(guò)濾延遲確認(rèn)：tcp.analysis.ack_rtt > 0.2 and tcp.len == 0

四、UDP協(xié)議

UDP（User Datagram Protocol）用戶數(shù)據(jù)報(bào)協(xié)議，提供面向事務(wù)的簡(jiǎn)單不可靠信息傳送服務(wù)。

將網(wǎng)絡(luò)數(shù)據(jù)流壓縮成數(shù)據(jù)包的形式。每一個(gè)數(shù)據(jù)包的前8個(gè)字節(jié)保存包頭信息，剩余的包含具體的傳輸數(shù)據(jù)。

雖然UDP是不可靠的傳輸協(xié)議，但它是分發(fā)信息的理想?yún)f(xié)議，例如在屏幕上報(bào)告股票市場(chǎng)、顯示航空信息；

在路由信息協(xié)議RIP（Routing Information Protocol）中修改路由表、QQ聊天、迅雷、網(wǎng)絡(luò)電話等。

TCP的效率不一定比UDP低，只要窗口足夠大，TCP也可以不受往返時(shí)間的約束而源源不斷地傳數(shù)據(jù)。

1）UDP的優(yōu)勢(shì)

1. UDP 協(xié)議的頭長(zhǎng)度不到TCP頭的一半，所以同樣大小的包里UDP攜帶的凈數(shù)據(jù)比TCP包多，

2. 沒(méi)有Seq和Ack等概念，省去了建立連接的開(kāi)銷，DNS解析就使用UDP協(xié)議。

2）UDP的劣勢(shì)

1. 超過(guò)MTU的時(shí)候，發(fā)送方的網(wǎng)絡(luò)層負(fù)責(zé)分片，接收方收到分片后再組裝起來(lái)，這個(gè)過(guò)程會(huì)消耗資源，降低性能。

2. 沒(méi)有重傳機(jī)制，丟包由應(yīng)用層處理，某個(gè)寫操作有6個(gè)包，當(dāng)有一個(gè)丟失的時(shí)候，就要將6個(gè)包重新發(fā)送。

3. 分片機(jī)制存在弱點(diǎn)，接收方是根據(jù)包中的“More fragments”的flag來(lái)判斷是否包已接收完，1表示還有分片，0表示最后一個(gè)分片，可以組裝了。

如果持續(xù)發(fā)送flag為1的UDP，接收方無(wú)法組裝，就有可能耗盡內(nèi)存。

五、ICMP協(xié)議

ICMP（Internet Control Message Protocol）網(wǎng)際報(bào)文控制協(xié)議，用于傳輸錯(cuò)誤報(bào)告控制信息，對(duì)網(wǎng)絡(luò)安全有極其重要的意義。

例如請(qǐng)求的服務(wù)不可用、主機(jī)或路由不可達(dá)，ICMP協(xié)議依靠IP協(xié)議來(lái)完成任務(wù)，是IP協(xié)議的一個(gè)集成部分。

通常不被用戶網(wǎng)絡(luò)程序直接使用，多用于ping和tracert等這樣的診斷程序。

六、DNS協(xié)議

DNS（Domain Name System）域名系統(tǒng)，DNS就是進(jìn)行域名解析的服務(wù)器。

DNS協(xié)議運(yùn)行在UDP協(xié)議之上，端口為53，工作原理如下：

DNS的解析過(guò)程：

DNS客戶機(jī)向本地域名服務(wù)器A發(fā)送查詢，如果A中沒(méi)有保存IP地址記錄，A就會(huì)發(fā)請(qǐng)求給根域名服務(wù)器B

如果B中也沒(méi)有，A就發(fā)請(qǐng)求給C，再?zèng)]有就發(fā)請(qǐng)求給D，然后是E，找到后將地址發(fā)給DNS客戶機(jī)。

域名解析過(guò)程涉及到遞歸查詢和迭代查詢。

客戶機(jī)再與Web服務(wù)器連接。

七、HTTP協(xié)議

HTTP（HyperText Transfer Protocol）超文本傳輸協(xié)議，HTTP是一個(gè)應(yīng)用層協(xié)議，無(wú)狀態(tài)，由請(qǐng)求和響應(yīng)構(gòu)成，是一個(gè)標(biāo)準(zhǔn)的客戶端服務(wù)器模型。

HTTP工作流程如下：

HTTP請(qǐng)求頭域：

HTTP應(yīng)答頭域：

HTTP通用頭域：

HTTP實(shí)體頭域：

八、HTTPS協(xié)議

HTTPS（Hypertext Transfer Protocol over Secure Socket Layer）基于SSL的HTTP協(xié)議，HTTP的安全版。

使用端口43，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸和身份認(rèn)證的網(wǎng)絡(luò)協(xié)議。

1）HTTPS工作流程

2）SSL

SSL（Secure Sockets Layer）安全套接層，TLS（Transport Layer Security）傳輸層安全是其繼任者。

SSL和TLS在傳輸層對(duì)網(wǎng)絡(luò)連接進(jìn)行加密。

SSL協(xié)議分為兩層，SSL記錄協(xié)議（SSL Record Protocol）和SSL握手協(xié)議（SSL Handshake Protocol）。

SSL記錄協(xié)議建立在TCP之上，提供數(shù)據(jù)封裝、壓縮加密基本功能的支持。

SSL握手協(xié)議建立在SSL記錄協(xié)議之上，在數(shù)據(jù)傳輸之前，通信雙方進(jìn)行身份認(rèn)證、協(xié)商加密算法和交換加密秘鑰等。

SSL工作分為兩個(gè)階段，服務(wù)器認(rèn)證和用戶認(rèn)證。

SSL協(xié)議既用到了公鑰加密（非對(duì)稱加密）又用到了對(duì)稱加密技術(shù)。

3）數(shù)據(jù)包

客戶端與服務(wù)器之間的通信：

1.客戶端發(fā)出請(qǐng)求（Client Hello）

2.服務(wù)器響應(yīng)（Server Hello）

3）證書信息

3.密鑰交換

4.應(yīng)用層信息通信

用戶可以發(fā)送通過(guò)TLS層使用RC4的寫實(shí)例加密過(guò)的普通HTTP消息，也可以解密服務(wù)端RC4寫實(shí)例發(fā)過(guò)來(lái)的消息。

此外，TLS層通過(guò)計(jì)算消息內(nèi)容的HMAC_md5哈希值來(lái)校驗(yàn)每一條消息是否被篡改。

參考資料：

Wireshark網(wǎng)絡(luò)分析的藝術(shù)

Wireshark數(shù)據(jù)包分析實(shí)戰(zhàn)詳解

車小胖談網(wǎng)絡(luò)：MTU 與 MSS

MTU & MSS 詳解記錄

網(wǎng)絡(luò)傳輸分片、MTU、MSS

理解TCP序列號(hào)（Sequence Number）和確認(rèn)號(hào)（Acknowledgment Number）

wireshark抓包圖解 TCP三次握手/四次揮手詳解

TCP 的那些事兒（下）

TCP segment of a reassembled PDU

SSL/TLS協(xié)議運(yùn)行機(jī)制的概述

如何通過(guò)Wireshark查看HTTPS、HTTP/2網(wǎng)絡(luò)包（解碼TLS、SSL）