一、ARP協(xié)議

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

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

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

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

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

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

二、IP協(xié)議

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

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

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

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

三、TCP協(xié)議

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

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

1）標(biāo)志位

SYN： 同步，在建立連接時用來同步序號。SYN=1， ACK=0表示一個連接請求報文段。SYN=1，ACK=1表示同意建立連接。

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

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

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

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

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

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

2）端口

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

3）TCP三次握手

4）TCP四次揮手

TCP四次斷開，例如關(guān)閉頁面的時候就會斷開連接。

5）TCP概念

1. 發(fā)送窗口

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

2. 擁塞窗口（cwnd）

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

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

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

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

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

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

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

4. 擁塞點（congestion point）

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

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

5. 慢啟動

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

6. 擁塞避免

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

7. 超時重傳

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

8. 快速重傳（Fast Retransmit）

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

9. SACK（Selective Acknowledgment）

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

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

如果收到一個包后暫時沒什么數(shù)據(jù)發(fā)給對方，那就延遲一段時間再確認(rèn)。假如這段時間恰好有數(shù)據(jù)要發(fā)送，那數(shù)據(jù)和確認(rèn)信息可以在一個包中發(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”兩個包。

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

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

12. Nagle算法

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

13. Vegas算法

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

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

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

6）選項字段

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

TTL（Time to live）：

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

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

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

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

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

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

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

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

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

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

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

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

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

7）過濾表達(dá)式

握手請求被對方拒絕：tcp.flags.reset === 1 && tcp.seq === 1

重傳的握手請求：tcp.flags.syn === 1 && tcp.analysis.retransmission

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

四、UDP協(xié)議

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

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

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

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

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

1）UDP的優(yōu)勢

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

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

2）UDP的劣勢

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

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

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

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

五、ICMP協(xié)議

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

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

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

六、DNS協(xié)議

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

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

DNS的解析過程：

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

如果B中也沒有，A就發(fā)請求給C，再沒有就發(fā)請求給D，然后是E，找到后將地址發(fā)給DNS客戶機(jī)。

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

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

七、HTTP協(xié)議

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

HTTP工作流程如下：

HTTP請求頭域：

HTTP應(yīng)答頭域：

HTTP通用頭域：

HTTP實體頭域：

八、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在傳輸層對網(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工作分為兩個階段，服務(wù)器認(rèn)證和用戶認(rèn)證。

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

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

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

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

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

3）證書信息

3.密鑰交換

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

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

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

參考資料：

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

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

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

MTU & MSS 詳解記錄

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

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

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

TCP 的那些事兒（下）

TCP segment of a reassembled PDU

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

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