轉(zhuǎn)自：https://www.cnblogs.com/strick/p/6262284.html

一、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： 終止，FIN=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四次斷開，例如關(guān)閉頁(yè)面的時(shí)候就會(huì)斷開連接。

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)，則表明還沒到擁塞點(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）后，沒有收到確認(rèn)，就只能重傳了

8. 快速重傳（Fast Retransmit）

不以時(shí)間驅(qū)動(dòng)，而以數(shù)據(jù)驅(qū)動(dòng)重傳。如果包沒有連續(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ù)到了，哪些沒有到。

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

如果收到一個(gè)包后暫時(shí)沒什么數(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)只見重傳包，不見原始包的情況。

12. Nagle算法

在發(fā)出去的數(shù)據(jù)還沒有被確認(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ò)開始繁忙時(shí)，數(shù)據(jù)包開始排隊(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ò)層中，如果帶了就丟棄沒帶就分片

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. 沒有Seq和Ack等概念，省去了建立連接的開銷，DNS解析就使用UDP協(xié)議。

2）UDP的劣勢(shì)

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

2. 沒有重傳機(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中沒有保存IP地址記錄，A就會(huì)發(fā)請(qǐng)求給根域名服務(wù)器B

如果B中也沒有，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工作流程如下：

下面是報(bào)文首部字段的說(shuō)明，表格的摘自《圖解HTTP》。

HTTP請(qǐng)求頭域：

?Accept	?用戶代理能夠處理的媒體類型（MIME）及媒體類型的相對(duì)優(yōu)先級(jí)，“text/plain;q=0.3”
?Accpet-Charset	?通知服務(wù)器用戶代理支持的字符集及字符集的相對(duì)優(yōu)先順序，“iso-8859-5”
?Accept-Encoding	?告知服務(wù)器用戶代理支持的內(nèi)容編碼及優(yōu)先級(jí)順序“gzip,deflate”
?Accept-Language	?告知服務(wù)器用戶代理能夠處理的自然語(yǔ)言集及優(yōu)先級(jí)，“zh-cn,zh;q=0.7”
?Authorization	?用戶代理的認(rèn)證信息（證書值），“Basic dWVub3NlbjpwYNzd==”
?Expect	?期望出現(xiàn)的某種特定行為，錯(cuò)誤時(shí)返回“417 Expectation Failed”，“100-continue”
?From	?用戶的電子郵箱地址，為了顯示搜索引擎等用戶代理負(fù)責(zé)人的聯(lián)系方式，“info@ha.com”
?Host	?請(qǐng)求的資源所處的互聯(lián)網(wǎng)主機(jī)名和端口號(hào)，必須包含在請(qǐng)求頭中，“www.hh.com”
?If-Match	?條件請(qǐng)求，只有當(dāng)If-Match字段值與ETag匹配才會(huì)接受請(qǐng)求，否則返回“412 Precondition Failed”
?If-Modified-Since	?若字段值早于資源的更新時(shí)間（Last-Modified），資源未更新，返回“304 Not Modified”
?If-None-Match	?與If-Match相反
?If-Range	?字段值和請(qǐng)求資源的ETag或時(shí)間一致時(shí)，作為范圍請(qǐng)求處理，反之，返回全體資源
?If-Unmodified-Since	?與If-Modified-Since作用相反
?Max-Forwards	?以十進(jìn)制整數(shù)形式指定可經(jīng)過(guò)的服務(wù)器最大數(shù)目。服務(wù)器轉(zhuǎn)發(fā)一次，減少1，當(dāng)為0就不進(jìn)行轉(zhuǎn)發(fā)
?Proxy-Authorization	?接收從代理服務(wù)器發(fā)來(lái)的認(rèn)證質(zhì)詢時(shí)，發(fā)送此字段，告知服務(wù)器認(rèn)證所需要的信息
?Range	?只需獲取部分資源的范圍請(qǐng)求，“5001-10000”從5001字節(jié)到10000字節(jié)的資源。
?Referer	?請(qǐng)求的原始資源的URI，也就是上一頁(yè)
?TE	?客戶端能夠處理響應(yīng)的傳輸編碼方式及相對(duì)優(yōu)先級(jí)，還可指定Trailer字段分塊傳輸編碼的方式。“gzip,deflate;q=0.5”
User-Agent	?創(chuàng)建請(qǐng)求的瀏覽器和用戶代理名稱等信息

HTTP應(yīng)答頭域：

?Accpet-Ranges	?告知客戶端服務(wù)器是否能處理范圍請(qǐng)求，以指定獲取服務(wù)器端某個(gè)部分的資源。“bytes”
?Age	?源服務(wù)器在多久前創(chuàng)建了響應(yīng)，字段值單位為秒
?ETag	?客戶端實(shí)體標(biāo)識(shí)，一種可以將資源以字符串形式做唯一標(biāo)識(shí)的方式
?Location	?將響應(yīng)接收方引導(dǎo)至某個(gè)與請(qǐng)求URI位置不同的資源，會(huì)配置3xx：Redirection的響應(yīng)
?Proxy-Authenticate	?由代理服務(wù)器所要求的認(rèn)證信息發(fā)送給客戶端
?Retry-After	?告知客戶端應(yīng)該在多久（秒數(shù)或具體日期）之后再次發(fā)送請(qǐng)求，主要配合“503 Service Unavailable”或“3xx Redirect”。
?Server	?當(dāng)前服務(wù)器上安裝的HTTP服務(wù)器應(yīng)用程序的信息，包括版本號(hào)等。“Apache/2.2.6 (Unix) PHP/5.2.5”
?Vary	?對(duì)緩存進(jìn)行控制，設(shè)置“Accept-Language”，如果字段值相同，就從緩存返回響應(yīng)。
?WWW-Authenticate	?HTTP訪問(wèn)認(rèn)證，告知客戶端適用于訪問(wèn)請(qǐng)求URI所指定資源的認(rèn)證方案（Basic或Digest）和帶參數(shù)提示的質(zhì)詢（challenge）

HTTP通用頭域：

Cache-Control	操作緩存的工作機(jī)制，多個(gè)指令用“,”分割，“private,max-age=0,no-cache”
Connection	控制不再轉(zhuǎn)發(fā)給代理的首部字段與管理持久連接，“keep-alive”
Date	HTTP報(bào)文的日期和時(shí)間
Pragema	HTTP1.1之前的遺留字段，作為向后兼容定義，只用在客戶端發(fā)送的請(qǐng)求中。“no-cache”
Trailer	說(shuō)明在報(bào)文主體后記錄了哪些首部字段，可應(yīng)用在分塊編碼傳輸時(shí)。在報(bào)文最后寫了重要信息
Transfer-Encoding	傳輸報(bào)文主體時(shí)采用的編碼方式，分塊傳輸“chunked”
Upgrade	檢測(cè)HTTP協(xié)議及其他協(xié)議是否可使用更高版本進(jìn)行通信
Via	追蹤客戶端與服務(wù)器之間的請(qǐng)求和響應(yīng)報(bào)文的傳輸路徑，各個(gè)代理服務(wù)器會(huì)往Via添加自己的服務(wù)器信息
Warning	告知用戶一些與緩存相關(guān)問(wèn)題的警告

HTTP實(shí)體頭域：

?Allow	?告知客戶端能夠支持Request-URI指定資源的所有HTTP方法，“GET,HEAD”。當(dāng)不支持，會(huì)返回“405 Method Not Allowed”
?Content-Encoding	?服務(wù)器對(duì)實(shí)體的主體部分選用的內(nèi)容編碼方式，在不丟失內(nèi)容的前提下進(jìn)行壓縮。“gzip”
?Content-Language	?實(shí)體主體使用的自然語(yǔ)言（中文或英文等）
?Content-Length	?主體部分的大小（單位是byte）
?Content-Location	?給出與報(bào)文主體部分相對(duì)應(yīng)的URI，與Location不同
?Content-MD5	?一串由MD5算法生成的值，目的在于檢查報(bào)文主體在傳輸過(guò)程中是否保持完整，以及確認(rèn)傳輸?shù)竭_(dá)
?Content-Range	?針對(duì)范圍請(qǐng)求，作為響應(yīng)返回的實(shí)體的哪個(gè)部分符合范圍請(qǐng)求，單位為byte。“bytes 5001-10000/10000”
?Content-Type	?實(shí)體主體內(nèi)對(duì)象的媒體類型，與Accpet一樣，字段值用type/subtype形式賦值。“text/html; charset=UTF-8”
?Expires	?將資源失效的日期告知客戶端。當(dāng)首部字段Cache-Control有指定max-age指令時(shí)，優(yōu)先處理max-age指令
?Last-Modified	?指明資源最終修改時(shí)間，一般來(lái)說(shuō)，這個(gè)值就是Request-URI指定資源被修改的時(shí)間

詳細(xì)信息可以參考MDN的《HTTP?Headers》

MIME?(Multipurpose Internet Mail Extensions) 是描述消息內(nèi)容類型的因特網(wǎng)標(biāo)準(zhǔn)，一種通知客戶端其接收文件的多樣性的機(jī)制，文件后綴名在網(wǎng)頁(yè)上并沒有明確的意義。

?

八、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）

總結(jié)

以上是生活随笔為你收集整理的【转】Wireshark网络抓包(三)——网络协议的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。