[TOC]

Wireshark分析藝術(shù)【讀書總結(jié)】

一，Wireshark實(shí)戰(zhàn)操作

界面的操作分析

三板斧之一：查看統(tǒng)計(jì)洒宝、屬性信息

性能分析三板斧之一：

【統(tǒng)計(jì)->捕獲文件屬性】
Statistics -> Summary讶踪，查看文件屬性信息芯侥，如平均速度泊交、包大小乳讥、包數(shù)等等

判斷流量高低峰、是否過(guò)載

[圖片上傳失敗...(image-7200fa-1541746330755)]

三板斧之二：查看分析專家信息

性能分析三板斧之二：

【分析->專家信息】
Wireshark ->Analyze -> Expert Infos -> Notes廓俭，查看抓包的統(tǒng)計(jì)信息

查看是否有Notes云石、Warnings、errors之類的信息研乒，看看是否有相關(guān)警告和錯(cuò)誤汹忠，判斷網(wǎng)絡(luò)質(zhì)量、重傳亂序等

[圖片上傳失敗...(image-1e2d8b-1541746330755)]

三板斧之三：查看服務(wù)響應(yīng)時(shí)間

性能分析三板斧之三：

【統(tǒng)計(jì)->服務(wù)響應(yīng)時(shí)間】
statistics -> Service Response Time -> xxxxx（如：ONC-RPC -> Program:NFS）

查看各項(xiàng)操作的服務(wù)響應(yīng)時(shí)間雹熬，判斷是否過(guò)載

將seq使用相對(duì)值來(lái)替代真實(shí)值

Edit->Preferences->Protocols->TCP,勾選 Relative Sequence Numbers

啟用之前就是相對(duì)值了宽菜。

查看TCP StreamGraph

Statistics -> TCP StreamGraph -> TCP Sequence Graph（Stevens）

查看數(shù)據(jù)傳輸情況，如傳輸?shù)氖欠窬鶆蚋捅ā⑹欠裼蠺CP Zero Windows之類的

字段含義&提示信息

字段含義就是wireshark的一些提示信息,也就是wireshark抓包的一些info信息铅乡，這些提示信息都是Info這一欄中體現(xiàn)。

1烈菌，[Packer size limited during caputre]

如果某個(gè)包被標(biāo)記提示[Packer size limited during caputre]阵幸，說(shuō)明這個(gè)包沒有抓全花履，可以進(jìn)一步查看下面的frame信息。一般這個(gè)情況是抓包的姿勢(shì)不對(duì)挚赊。某些操作系統(tǒng)中诡壁，tcpdump默認(rèn)只抓取每個(gè)幀的前96個(gè)字節(jié)，因此tcpdump抓包的時(shí)候荠割，可以通過(guò) -s參數(shù)指定要抓取的字節(jié)數(shù)

2妹卿，[TCP ACKed unseen segment]

如果wireshark發(fā)現(xiàn)被Ack的那個(gè)包沒有抓到，就會(huì)提示[TCP ACKed unseen segment]蔑鹦，不過(guò)這個(gè)提示大部分情況都可以忽略纽帖。因?yàn)榇蠖记闆r下，剛開始抓包的時(shí)候举反，都是只抓到了后面的Ack而沒有抓到前面的ACK

3懊直，[TCP Previous segment not captured]

TCP數(shù)據(jù)傳輸中，除了三次握手和四次握手之外火鼻，同一臺(tái)機(jī)器發(fā)出的數(shù)據(jù)段應(yīng)該是連續(xù)的室囊，即后一個(gè)包的Seq等于前一個(gè)包的Seq+Len，正確情況都應(yīng)該是這樣魁索；如果發(fā)現(xiàn)后一個(gè)包的Seq大于前一個(gè)包的Seq+Len融撞，那么就說(shuō)明中間丟了一段數(shù)據(jù)，如果丟失的數(shù)據(jù)在整個(gè)網(wǎng)絡(luò)包中都找不到粗蔚，wireshark就會(huì)提示[TCP Previous segment not captured]尝偎，

出現(xiàn)這種情況的兩個(gè)可能性：

• 數(shù)據(jù)包真的丟了
• 數(shù)據(jù)包并沒有真丟，只是抓包工具漏掉了
  • 如果確認(rèn)Ack包中包含了沒有抓到的包鹏控，那就是抓包工具漏掉了致扯，否則就是真丟了

4，[TCP Out-of-Order]

TCP數(shù)據(jù)傳輸中当辐，除了三次握手和四次握手之外抖僵，同一臺(tái)機(jī)器發(fā)出的數(shù)據(jù)段應(yīng)該是連續(xù)的，即后一個(gè)包的Seq等于前一個(gè)包的Seq+Len缘揪，正確情況都應(yīng)該是這樣耍群；或者說(shuō)后一個(gè)包的Seq應(yīng)該會(huì)大于等于前一個(gè)包的Seq+Len，如果wireshark發(fā)現(xiàn)后一個(gè)包的Seq小于前一個(gè)包的Seq+Len找筝，那么就認(rèn)為是亂序了蹈垢，就會(huì)提示[TCP Out-of-Order]。

一般而言袖裕，小跨度的亂序影響不大曹抬，如果是大跨度的亂序則會(huì)導(dǎo)致快速重傳。舉例如下陆赋，如果一個(gè)包的順序是1沐祷、2嚷闭、3、4赖临、5被打亂成2胞锰、1、3兢榨、4嗅榕、5則屬于小跨度亂序，影響不大吵聪；如果被打亂成2凌那、3、4吟逝、5帽蝶、1，則會(huì)觸發(fā)足夠多的Dup ACK块攒，從而導(dǎo)致1號(hào)包的重傳励稳。

5，[TCP Dup ACK]

當(dāng)亂序或者丟包發(fā)生時(shí)囱井，接收方就會(huì)收到一些Seq號(hào)比期望值大的包驹尼，TCP協(xié)議每收到一個(gè)這種包就會(huì)ACK一次期望的Seq值，通過(guò)這個(gè)方式告知發(fā)送方庞呕，因此就產(chǎn)生了一些重復(fù)的Ack新翎。Wireshark抓到這些重復(fù)的Ack就會(huì)提示[TCP Dup ACK].

6，[TCP Fast Retransmission]

當(dāng)發(fā)送方連續(xù)收到3個(gè)或者以上[TCP Dup ACK]時(shí)住练，就意識(shí)到之前發(fā)的包可能丟了地啰，于是根據(jù)RFC的規(guī)定就會(huì)開始快速重傳。[TCP Dup ACK]是接收方回應(yīng)給發(fā)送方的澎羞，因此發(fā)送方就能夠感知到并當(dāng)連續(xù)收到3個(gè)以上的時(shí)候就開啟快速重傳髓绽。

快重傳算法規(guī)定敛苇，發(fā)送方只要一連收到3個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段妆绞，而不必繼續(xù)等待設(shè)置的重傳計(jì)數(shù)器時(shí)間到期。

7枫攀，[TCP Retransmission]

如果一個(gè)包真的丟了括饶，又沒有后續(xù)包可以在接收方觸發(fā)[Dup Ack]，那么就不會(huì)開啟快速重傳来涨，這種情況發(fā)送方只能等到超時(shí)后再發(fā)送重傳图焰，超時(shí)重傳的包就會(huì)被wireshark標(biāo)記并提示[TCP Retransmission]

TCP 超時(shí)與重傳應(yīng)該是 TCP 最復(fù)雜的部分之一，超時(shí)重傳是 TCP 保證可靠傳輸?shù)幕A(chǔ)蹦掐。當(dāng) TCP 在發(fā)送數(shù)據(jù)時(shí)技羔，數(shù)據(jù)和 ack 都有可能會(huì)丟失僵闯，因此，TCP 通過(guò)在發(fā)送時(shí)設(shè)置一個(gè)定時(shí)器來(lái)解決這種問(wèn)題藤滥。如果定時(shí)器溢出還沒有收到確認(rèn)鳖粟，它就重傳數(shù)據(jù)。關(guān)鍵之處就在于超時(shí)和重傳的策略拙绊，需要考慮兩方面：

• 超時(shí)時(shí)間設(shè)置
• 重傳的頻率（次數(shù)）

在 Linux 較高的內(nèi)核版本中向图，比如 3.15 中，已經(jīng)有了至少 9 個(gè)定時(shí)器：超時(shí)重傳定時(shí)器标沪，持續(xù)定時(shí)器榄攀，ER延遲定時(shí)器，PTO定時(shí)器金句，ACK延遲定時(shí)器檩赢，SYNACK定時(shí)器，蔽ツ活定時(shí)器漠畜，F(xiàn)IN_WAIT2定時(shí)器，TIME_WAIT定時(shí)器坞靶。

8憔狞，[TCP zerowindow]

TCP包中“win=xxx”代表接收窗口的大小，表示這個(gè)包的發(fā)送方當(dāng)前還有多少緩沖區(qū)可以接受數(shù)據(jù)彰阴。當(dāng)wireshark發(fā)行一個(gè)包中的“win=0”時(shí)瘾敢，就會(huì)標(biāo)記提示[TCP zerowindow]，表示緩沖區(qū)已經(jīng)滿了尿这，無(wú)法再接收數(shù)據(jù)了簇抵。

一般的，在緩沖區(qū)滿之前射众，窗口大小應(yīng)該是逐漸減小的過(guò)程碟摆。

9，[TCP window Full]

如果一個(gè)包的發(fā)送方已經(jīng)把對(duì)方所聲明的接收窗口大小耗盡了叨橱，就會(huì)被wireshark標(biāo)記為[TCP window Full]典蜕。比如某一端在握手時(shí)聲明自己的接收窗口只有65535，也就意味著對(duì)端最多只能給他發(fā)送65535字節(jié)的數(shù)據(jù)而無(wú)需確認(rèn)罗洗，即“在途字節(jié)數(shù)”最多只能是65535愉舔，當(dāng)wireshark計(jì)算出對(duì)端已經(jīng)有65535字節(jié)未被確認(rèn)時(shí)，就會(huì)發(fā)生這個(gè)提示伙菜。

[TCP window Full]和上面的[TCP zerowindow]比較容易混淆轩缤，前者表示這個(gè)包的發(fā)送方暫時(shí)沒有辦法再發(fā)送數(shù)據(jù)了；后者表示這個(gè)包的發(fā)送方?jīng)]有辦法再接收數(shù)據(jù)了；兩者都會(huì)意味著要暫停數(shù)據(jù)傳輸

10火的，[TCP segment of reassembled PDU]

只有在Edit->Preferences->Protocols->TCP菜單里啟用了Allow sub dissector to reassemble TCP streams后壶愤，才有可能收到這個(gè)提示。這個(gè)表示可以把屬于同一個(gè)應(yīng)用層PDU的TCP包虛擬的集中起來(lái)

11馏鹤，[Continuation to #]

只有在Edit->Preferences->Protocols->TCP菜單里關(guān)閉了Allow sub dissector to reassemble TCP streams后公你，才有可能收到這個(gè)提示。

12假瞬，[Time-to-live-exceeded(Fragment reasembly time execeeded)]

（Fragment reasembly time execeeded）表示這個(gè)包的發(fā)送方之前收到了一些分片陕靠，但是由于某些原因?qū)е逻t遲無(wú)法組裝起來(lái)。

比如傳輸過(guò)程中有一些分片被丟包了脱茉，那么接收方就無(wú)法組裝起來(lái)剪芥，然后就通過(guò)這個(gè)ICMP的方式告知發(fā)送方

ICMP是（Internet Control Message Protocol）Internet控制報(bào)文協(xié)議。它是TCP/IP協(xié)議族的一個(gè)子協(xié)議琴许，用于在IP主機(jī)税肪、路由器之間傳遞控制消息“裉铮控制消息是指網(wǎng)絡(luò)通不通益兄、主機(jī)是否可達(dá)、路由是否可用等網(wǎng)絡(luò)本身的消息箭券。這些控制消息雖然并不傳輸用戶數(shù)據(jù)净捅，但是對(duì)于用戶數(shù)據(jù)的傳遞起著重要的作用。

二辩块，Wireshark分析TCP協(xié)議

TCP抓包協(xié)議基礎(chǔ)

TCP控制字段

在TCP層蛔六，有個(gè)FLAGS字段，這個(gè)字段有以下幾個(gè)標(biāo)識(shí)：SYN, FIN, ACK, PSH, RST, URG.

抓包顯示的控制字段形態(tài)如下：

[SYN] ： 建立連接废亭、發(fā)起包
[FIN] ： 關(guān)閉連接国章、結(jié)束包
[PSH] ： DATA數(shù)據(jù)傳輸
[ACK] ： ACK回應(yīng)
[RST] ： RESET、連接重置

另外兩個(gè)常用字段：

[Len] ：數(shù)據(jù)包長(zhǎng)度
[Seq] ：數(shù)據(jù)包序列號(hào)

ACK是可能與SYN豆村，F(xiàn)IN等同時(shí)使用的液兽，比如SYN和ACK可能同時(shí)為1，它表示的就是建立連接之后的響應(yīng)掌动，如果只是單個(gè)的一個(gè)SYN四啰，它表 示的只是建立連接

當(dāng)出現(xiàn)FIN包或RST包時(shí)，我們便認(rèn)為客戶端與服務(wù)器端斷開了連接
當(dāng)出現(xiàn)SYN和SYN＋ACK包時(shí)坏匪，我們認(rèn)為客戶端與服務(wù)器建立了一個(gè)連接

抓包方向（client or server）

• 抓包的時(shí)候拟逮，不管是通過(guò)wireshark抓包，還是通過(guò)tcpdump抓包适滓，都需要看看是從客戶端方向抓包耸携，還是從服務(wù)端方向抓包，不同的方向悼凑，抓包的情況完全不一樣晦炊，因?yàn)榫W(wǎng)絡(luò)（公網(wǎng)、實(shí)際環(huán)境）上有很多異常情況發(fā)生嗅绸。

TCP的Ack

對(duì)應(yīng)http而言脾猛，一般就是request->reponse，一問(wèn)一答鱼鸠。但對(duì)應(yīng)TCP而言猛拴，并不一定每個(gè)包都會(huì)ACK。TCP的ACK是一種累積的ACK蚀狰，也就是表示在我這個(gè)ACK之前的所有其他ACK都已經(jīng)確認(rèn)收到了愉昆。

比如，97號(hào)包的ACK=65701麻蹋，96號(hào)包的Seq+Len=64273+1428=65701跛溉，那么就是表示97號(hào)的ACK是對(duì)96號(hào)的回應(yīng)，也就是96號(hào)之前的其他沒有被顯示ACK的包扮授，其實(shí)都已經(jīng)通過(guò)97號(hào)包ACK了芳室，這樣發(fā)送方也就知道了在96號(hào)之前發(fā)出去的所有包對(duì)方都已經(jīng)收到并ACK了。

MSL刹勃、TTL堪侯、RTT

• MSL（Maximum Segment Lifetime），表示“報(bào)文最大生存時(shí)間”荔仁，是所有報(bào)文都遵循的在網(wǎng)絡(luò)上存在的最長(zhǎng)時(shí)間抖格，超過(guò)這個(gè)時(shí)間報(bào)文將被丟棄
  • RFC 793中規(guī)定MSL為2分鐘，實(shí)際應(yīng)用中常用的是30秒咕晋，1分鐘和2分鐘等雹拄。
  • 2MSL即兩倍的MSL，TCP的TIME_WAIT狀態(tài)也稱為2MSL等待狀態(tài)

• TTL（Time to live）掌呜，表示生存時(shí)間滓玖，是ip頭的一個(gè)域，生存時(shí)間是由源主機(jī)來(lái)設(shè)置一個(gè)初始值质蕉，但TTL不是存的具體時(shí)間势篡，而是表示可以經(jīng)過(guò)的最大路由數(shù)。

  • 根據(jù)RFC 1812模暗，一個(gè)網(wǎng)絡(luò)包的TTL每減去1就表示它經(jīng)過(guò)一次路由禁悠。一般TTL的初始值為64，如果某個(gè)ACK包的TTL是62兑宇，則意味著是是距離此設(shè)備兩跳的設(shè)備發(fā)出來(lái)的碍侦。
  • TTL在wireshark抓包中的形態(tài)如Time to live: 62
  • TTL=0則數(shù)據(jù)報(bào)將被丟棄，同時(shí)發(fā)送ICMP報(bào)文通知源主機(jī)
  • 一般在緩存、連接心跳中也用到TTL這個(gè)瓷产，他們和TCP協(xié)議中的TTL是有區(qū)別的站玄，緩存、連接心跳中的TTL表示的就是數(shù)據(jù)緩存or剩余的時(shí)間濒旦。

• RTT（round-trip time）株旷，表示客戶到服務(wù)器往返所花時(shí)間，TCP含有動(dòng)態(tài)估算RTT的算法

  • TCP會(huì)持續(xù)估算一個(gè)給定連接的RTT尔邓，因?yàn)镽TT受網(wǎng)絡(luò)傳輸擁塞程序的變化而變化

MAC地址解析

Protocol = ARP
Source 和 Destination 都是MAC地址格式如 00:60:48:ff:12:31

抓包分析中晾剖，如果網(wǎng)絡(luò)不通，發(fā)出去收不到ACK等等之類的梯嗽，要再進(jìn)一步看看每個(gè)包的MAC地址是否正確齿尽，反之有多個(gè)MAC地址導(dǎo)致的一些問(wèn)題

TCP握手和揮手協(xié)議

TCP三次握手&判斷回包

• 三次握手協(xié)議

  • client->server : [SYN] Seq=X win=xxx Len=0 MSS=xxx
  • server->client : [SYN, ACK] Seq=Y，ACK=X+1 win=xxx Len=0 MSS=xxx
  • client->server : [ACK] Seq=X+1慷荔，Ack=Y+1 win=xxx Len=0

• 抓包數(shù)據(jù)雕什，如何判斷一個(gè)包是上一個(gè)包的回包呢？根據(jù)TCP協(xié)議显晶，下一個(gè)包的Ack的值如果等于上一個(gè)包的Seq + Len贷岸，則表示是其回包

  • 上一個(gè)和下一個(gè)，很多情況下并不是連續(xù)的磷雇，也行下一個(gè)回包距離上一個(gè)包已經(jīng)過(guò)了很多包了偿警，因?yàn)橹貍鳌⒀舆t的原因的

• 三次握手的時(shí)候會(huì)相互聲明各自的MSS

TCP四次揮手&三次揮手

• TCP四次揮手協(xié)議

  • client->server : FIN Seq=X唯笙，ACK=Y
  • server->client : Seq=Y螟蒸，ACK=X+1
  • server->client : FIN Seq=Y，ACK=X+1
  • client->server : Seq=X+1崩掘，Ack=Y+1

• 正常而言七嫌，都會(huì)有這樣的四次揮手，但是如果有延遲確認(rèn)苞慢，那么四次揮手就變成了3次揮手诵原，省掉了四次揮手中的第二個(gè)包

  • client->server : FIN Seq=X，ACK=Y
  • server->client : FIN Seq=Y挽放，ACK=X+1
  • client->server : Seq=X+1绍赛，Ack=Y+1

TCP擁塞控制算法

在途字節(jié)數(shù)

• 在途字節(jié)數(shù)【bytes in flight】，表示的是已經(jīng)發(fā)送出去辑畦，但是還沒有被確認(rèn)的字節(jié)數(shù)吗蚌，這個(gè)確認(rèn)指的是對(duì)端發(fā)出ACK確認(rèn)，這個(gè)就是所謂的網(wǎng)絡(luò)承載量纯出；如果在途字節(jié)數(shù)超過(guò)網(wǎng)絡(luò)承載量蚯妇，那么就會(huì)發(fā)生丟包重傳
  • 在途字節(jié)數(shù) = 當(dāng)前發(fā)送方的【Seq + Len】 - 當(dāng)前接收方的【ACK】
    • 這個(gè)“當(dāng)前”僅僅從抓包上的網(wǎng)絡(luò)包序號(hào)去看就可以了敷燎，并不需要這兩個(gè)包有什么關(guān)系，也正因?yàn)檫@兩個(gè)包沒有關(guān)系侮措，所以才是計(jì)算出在途字節(jié)數(shù)的方式
    • 這個(gè)Len懈叹，一般而言乖杠，不應(yīng)該超過(guò)TCP的MSS（最大數(shù)據(jù)字段）分扎，這個(gè)值是1388，注意對(duì)比MTU（1500）

網(wǎng)絡(luò)擁塞

• 網(wǎng)絡(luò)擁塞點(diǎn)：超過(guò)網(wǎng)絡(luò)承載量而導(dǎo)致的網(wǎng)絡(luò)擁塞胧洒。發(fā)生擁塞時(shí)的在途字節(jié)數(shù)就是該時(shí)刻的網(wǎng)絡(luò)擁塞點(diǎn)畏吓，估算網(wǎng)絡(luò)擁塞點(diǎn)只需要簡(jiǎn)單找到擁塞時(shí)的在途字節(jié)數(shù)即可
  • 擁塞的特征就是連串的丟包、丟包后又會(huì)重傳卫漫；wireshark菲饼、tcpdump等抓包工具可以標(biāo)識(shí)出重傳包
  • 根據(jù)抓包工具，找到一連串重傳包中的第一個(gè)包列赎，然后根據(jù)該包重傳的Seq值找到對(duì)應(yīng)的原始包宏悦，最后，計(jì)算該原始包發(fā)送時(shí)刻的在途字節(jié)數(shù)包吝，這個(gè)就標(biāo)識(shí)當(dāng)前的擁塞點(diǎn)
    • 假如Seq+Len-Ack = 103122饼煞，這個(gè)單位表示字節(jié)，也就是100KB诗越，這個(gè)100KB就是最大的發(fā)送窗口砖瞧，因此需要設(shè)置Linux系統(tǒng)中發(fā)送窗口的值
  • Wireshark ->Analyze -> Expert Info -> Notes菜單可以看到重傳統(tǒng)計(jì)
  • 通過(guò)在途字節(jié)數(shù)只是估算 網(wǎng)絡(luò)擁塞點(diǎn)，并不一定很精確嚷狞，可以采樣多次然后找到合適的值块促；多次采樣后的數(shù)據(jù)，其實(shí)保守的話應(yīng)該取最小值而不是平均值
    • 取最小值是因?yàn)檫@樣最保守床未，這樣才能真正保證網(wǎng)絡(luò)不會(huì)擁塞竭翠；取完之后要設(shè)置Linux的發(fā)送窗口
  • 前面有說(shuō)的，數(shù)據(jù)包的Len最大不應(yīng)該超過(guò)1388薇搁，但是實(shí)際抓包分析過(guò)程中斋扰，卻會(huì)發(fā)現(xiàn)實(shí)際的Len可能是1338的兩倍或者N倍，這個(gè)是什么原因呢只酥？ 這是因?yàn)橛幸粋€(gè)所謂的LSO褥实。
  • 一般網(wǎng)絡(luò)工作方式是：應(yīng)用層把產(chǎn)生的數(shù)據(jù)交給TCP層，TCP再根據(jù)MSS大小進(jìn)行分段裂允，分段由CPU負(fù)責(zé)進(jìn)行损离，最后再交給網(wǎng)卡
  • 如果啟用了LSO：TCP層就把大于MSS的數(shù)據(jù)塊直接交給了網(wǎng)卡，讓網(wǎng)卡去負(fù)責(zé)分段工作绝编。
    • 從發(fā)送方的視角僻澎，相當(dāng)于是站在了CPU視角貌踏，這樣抓包看到的應(yīng)該是分段前的打包。從接收方視角窟勃，相當(dāng)于是站在了網(wǎng)卡視角祖乳，那么看到的就應(yīng)該是分段后的多個(gè)小包
    • LSO出現(xiàn)的意義在于目前網(wǎng)卡經(jīng)常是千兆、萬(wàn)兆秉氧，這樣CPU的負(fù)擔(dān)很重眷昆。比如625MB/s的網(wǎng)絡(luò)流量大約需要耗費(fèi)5GHz的CPU，因此為了緩解CPU的負(fù)擔(dān)汁咏，就把一些分段的工作直接交給網(wǎng)卡去執(zhí)行了亚斋，

一些實(shí)戰(zhàn)經(jīng)驗(yàn)告訴我們，Wireshark ->Analyze -> Expert Info -> Notes統(tǒng)計(jì)中的重傳率如果超過(guò)了0.1%攘滩，就需要采取一些措施了帅刊。但是現(xiàn)實(shí)網(wǎng)絡(luò)環(huán)境下，要低于0.01%的重傳是基本不可能的漂问。

發(fā)送窗口

• 客戶端發(fā)送窗口的兩個(gè)因素：網(wǎng)絡(luò)上的擁塞窗口（cwnd）和服務(wù)器上的接收窗口
  • cwnd的增長(zhǎng)方式是：先“慢啟動(dòng)”赖瞒、再進(jìn)入“擁塞避免”，前者起點(diǎn)低但是能夠快速增長(zhǎng)蚤假、后者起點(diǎn)高但是每一個(gè)RTT只能增加一個(gè)MSS（RTT指往返時(shí)間栏饮，也就是到了下一個(gè)從同一個(gè)方向傳輸?shù)陌?/li>
  • 根據(jù)抓包的數(shù)據(jù)，點(diǎn)開詳情勤哗，查看其“Bytes in flight”值抡爹，可以簡(jiǎn)單等同與cwnd
    • 如果是“慢啟動(dòng)”階段，那么下一個(gè)RTT的包的cwnd應(yīng)該要遠(yuǎn)遠(yuǎn)大于上一個(gè)包的cwnd
    • 如果是“擁塞避免”階段芒划，那么下一個(gè)RTT的包的cwnd應(yīng)該要增加一個(gè)MSS（以太網(wǎng)中的MSS約為1460字節(jié)）冬竟。
    • 如果不符合上述兩種情況，比如cwnd增長(zhǎng)的非常慢民逼，那么就需要根據(jù)cwnd的計(jì)算方式去分析了

TCP Nagle算法和延遲確認(rèn)Delayed ACK

1. Nagle算法：

   • 是為了減少?gòu)V域網(wǎng)的小分組數(shù)目泵殴，從而減小網(wǎng)絡(luò)擁塞的出現(xiàn)；

   • 該算法要求一個(gè)tcp連接上最多只能有一個(gè)未被確認(rèn)的未完成的小分組拼苍，在該分組ack到達(dá)之前不能發(fā)送其他的小分組笑诅，tcp需要收集這些少量的分組，并在ack到來(lái)時(shí)以一個(gè)分組的方式發(fā)送出去疮鲫；其中小分組的定義是小于MSS的任何分組吆你；

   • 該算法的優(yōu)越之處在于它是自適應(yīng)的，確認(rèn)到達(dá)的越快俊犯，數(shù)據(jù)也就發(fā)哦送的越快妇多；而在希望減少微小分組數(shù)目的低速?gòu)V域網(wǎng)上，則會(huì)發(fā)送更少的分組燕侠；

       if there is new data to send
      if the window size >= MSS and available data is >= MSS
        send complete MSS segment now
      else
        if there is unconfirmed data still in the pipe
          enqueue data in the buffer until an acknowledge is received
        else
          send data immediately
        end if
      end if
    end if

2. 延遲ACK：

如果tcp對(duì)每個(gè)數(shù)據(jù)包都發(fā)送一個(gè)ack確認(rèn)者祖，那么只是一個(gè)單獨(dú)的數(shù)據(jù)包為了發(fā)送一個(gè)ack代價(jià)比較高立莉，所以tcp會(huì)延遲一段時(shí)間，如果這段時(shí)間內(nèi)有數(shù)據(jù)發(fā)送到對(duì)端七问，則捎帶發(fā)送ack蜓耻，如果在延遲ack定時(shí)器觸發(fā)時(shí)候，發(fā)現(xiàn)ack尚未發(fā)送械巡，則立即單獨(dú)發(fā)送刹淌；

延遲ACK好處：

(1) 避免糊涂窗口綜合癥；
(2) 發(fā)送數(shù)據(jù)的時(shí)候?qū)ck捎帶發(fā)送坟比，不必單獨(dú)發(fā)送ack芦鳍；
(3) 如果延遲時(shí)間內(nèi)有多個(gè)數(shù)據(jù)段到達(dá)嚷往，那么允許協(xié)議棧發(fā)送一個(gè)ack確認(rèn)多個(gè)報(bào)文段葛账；

3. 當(dāng)Nagle遇上延遲ACK：

試想如下典型操作，寫-寫-讀皮仁，即通過(guò)多個(gè)寫小片數(shù)據(jù)向?qū)Χ税l(fā)送單個(gè)邏輯的操作籍琳，兩次寫數(shù)據(jù)長(zhǎng)度小于MSS，當(dāng)?shù)谝淮螌憯?shù)據(jù)到達(dá)對(duì)端后贷祈，對(duì)端延遲ack趋急，不發(fā)送ack，而本端因?yàn)橐l(fā)送的數(shù)據(jù)長(zhǎng)度小于MSS势誊，所以nagle算法起作用呜达，數(shù)據(jù)并不會(huì)立即發(fā)送，而是等待對(duì)端發(fā)送的第一次數(shù)據(jù)確認(rèn)ack粟耻；這樣的情況下查近，需要等待對(duì)端超時(shí)發(fā)送ack，然后本段才能發(fā)送第二次寫的數(shù)據(jù)挤忙，從而造成延遲霜威；

4. 關(guān)閉Nagle算法：

使用TCP套接字選項(xiàng)TCP_NODELAY可以關(guān)閉套接字選項(xiàng);

如下場(chǎng)景考慮關(guān)閉Nagle算法：

(1) 對(duì)端不向本端發(fā)送數(shù)據(jù)，并且對(duì)延時(shí)比較敏感的操作册烈；這種操作沒法捎帶ack戈泼；
(2) 如上寫-寫-讀操作；對(duì)于此種情況赏僧，優(yōu)先使用其他方式大猛，而不是關(guān)閉Nagle算法：

TCP和UDP的區(qū)別、對(duì)比

主要區(qū)別

TCP和UDP的區(qū)別如TCP是可靠的淀零、UDP是不可靠的挽绩，但是實(shí)際中的表現(xiàn)是何為可靠？何為不可靠窑滞？具體協(xié)議的ACK有何區(qū)別琼牧？

不管對(duì)于TCP還是UDP恢筝，都可能會(huì)被分片，這是由于以太網(wǎng)的MSS決定的巨坊；不同在于分片傳輸?shù)奶幚恚?/p>

• UDP而言撬槽，如果分片傳輸導(dǎo)致某些分片丟失，則接收方無(wú)法完成重組趾撵，這樣發(fā)送方會(huì)將所有分片重傳侄柔，如果發(fā)生重傳則效率就會(huì)比較低。
  • UDP不可靠就在于此占调，沒有一個(gè)機(jī)制保證數(shù)據(jù)被安全送達(dá)暂题，需要應(yīng)用層去負(fù)責(zé)重傳
• TCP而言，TCP的分段機(jī)制可以把數(shù)據(jù)包拆小后封裝在多個(gè)包里究珊，這樣就避免了被網(wǎng)絡(luò)層分片薪者。重傳而言，TCP只需要重傳丟失的那個(gè)包而不需要重傳整個(gè)包
  • TCP可靠也在于此剿涮，TCP會(huì)有機(jī)制保證數(shù)據(jù)被安全送達(dá)言津，而不需要應(yīng)用層去處理重傳
  • 因?yàn)門CP只會(huì)重傳丟失的某個(gè)包而不是整個(gè)包，因此重傳效率比UDP高很多

UDP 比 TCP 更適合語(yǔ)音

語(yǔ)音通話的場(chǎng)景在于不能接受延遲取试，但是可以接受音質(zhì)稍差悬槽。這樣的話，UDP傳輸?shù)臅r(shí)候瞬浓，如果有些包丟失初婆，應(yīng)用層可以選擇忽略并繼續(xù)傳輸其他包，丟到一些包只會(huì)影響到音質(zhì)猿棉，但是保證了流暢性磅叛。TCP而言，會(huì)重傳每個(gè)包铺根，只要丟包就重傳宪躯，這樣就會(huì)導(dǎo)致有一定的延遲，在語(yǔ)音中如果有延遲則并不可取位迂。

因此访雪，TCP和UDP，各自有各自的適合場(chǎng)景掂林。 語(yǔ)音臣缀、視頻中，UDP更合適泻帮，像聲網(wǎng)精置、linphone等都是UDP去處理音視頻。 基礎(chǔ)锣杂、核心協(xié)議交互中必須采用TCP脂倦。

TCP和UDP的效率問(wèn)題

TCP在傳輸過(guò)程都需要往返時(shí)間來(lái)確認(rèn)也就是ACK番宁，而UDP則無(wú)需確認(rèn)，那么UDP的效率一定比TCP高嗎赖阻？這個(gè)是不一定的蝶押，雖然UDP可以一直往外不停的發(fā)包，不用等待ACK火欧；但是TCP有發(fā)送窗口的存在棋电，如果發(fā)送窗口小，并沒有占滿帶寬苇侵，那么肯定受到往返時(shí)間的約束使得效率稍低赶盔，但是如果只要窗口足夠大并且合適，跑滿帶寬榆浓，那么TCP也是可以不受往返時(shí)間的約束而源源不斷的傳輸數(shù)據(jù)于未。

舉例：馬路上只有一輛車來(lái)回跑去拉貨，回程過(guò)程相當(dāng)于空跑（回程相當(dāng)于TCP的ACK）哀军，這樣TCP的效率當(dāng)然低沉眶。但是如果在不擁塞的情況下，盡量提高車輛數(shù)量杉适，是的馬路上的車被剛好充滿，這樣總體的傳輸效率提高了柳击，并且回程的ACK也不受影響猿推。

數(shù)據(jù)包分片、MTU捌肴、MSS

數(shù)據(jù)包分片和重組

分組交換蹬叭，把大的數(shù)據(jù)分割成小包，這樣可以實(shí)現(xiàn)鏈路共享状知，而不至于因?yàn)槟骋环阶枞谢辔濉＜热灰指畛尚“敲幢厝灰_定一個(gè)最大的包大小饥悴，這個(gè)就是MTU（Maximum Transmission Unit）最大傳輸單位坦喘，值為1500字節(jié)。如果除去20個(gè)字節(jié)的包頭結(jié)構(gòu)西设，那么一個(gè)IP包最大的包大小為1500-20=1480字節(jié)瓣铣。如果要傳輸?shù)臄?shù)據(jù)塊超過(guò)1480字節(jié)，那么網(wǎng)絡(luò)層就會(huì)將其分片處理贷揽，封裝為多個(gè)網(wǎng)絡(luò)包傳輸棠笑。對(duì)于TCP而言，TCP協(xié)議層會(huì)主動(dòng)把數(shù)據(jù)分成小段后再交給網(wǎng)絡(luò)層禽绪，TCP的最大分段大小稱之為MSS（Maximum Segment Size）蓖救，這個(gè)MSS被設(shè)置為MTU減去IP頭和TCP頭之后的大小洪规，這樣剛好可以滿足一個(gè)MTU。因?yàn)閁DP沒有MSS的概念循捺，因此就只能交給網(wǎng)絡(luò)層去處理分片了淹冰。

但是需要注意的是，目前有些網(wǎng)絡(luò)是Jumbo Frame（巨幀）或者PPPOE這樣的設(shè)備巨柒，那么他們的MTU則不是1500字節(jié)樱拴。目前發(fā)送方并沒有一個(gè)好的機(jī)制來(lái)確定最佳分片大小，應(yīng)該盡量使得網(wǎng)絡(luò)中的設(shè)備的MTU保持一致洋满。如果網(wǎng)絡(luò)中的設(shè)備的MTU不一致晶乔，那么TCP協(xié)議如何適配MTU呢？我們知道TCP建連的時(shí)候必須要先進(jìn)行三次握手牺勾，TCP在前兩個(gè)握手包中會(huì)相互聲明自己的MSS正罢。如果client端聲明自己的MSS=8960（巨幀），server端申明自己的MSS=1460驻民，那么client在三次握手后就知道了server端的MSS翻具，因此當(dāng)client想要發(fā)送大于server端MSS的包的時(shí)候就會(huì)主動(dòng)將自己的MSS降低為server端的MSS大小，從而適配接收方的MTU回还，可見裆泳，TCP協(xié)議層做了非常多的優(yōu)化和處理

既然有分片，那么接收方必然要進(jìn)行分片重組柠硕，通過(guò)抓包工具可以得知工禾，分片的每個(gè)包都包含了off=xxx，ID=xxx這樣的信息蝗柔，接收方會(huì)把ID相同的分片按照off偏移量進(jìn)行重組闻葵。那么接收方又如何得知那個(gè)包才是最后的分片呢？然后什么時(shí)候開始重組呢癣丧？這里就在于最后一個(gè)分片包有一個(gè)特殊的Flag槽畔，叫More fragment = 0，抓包中的表現(xiàn)形式是..0. ... = More fragment: Not set胁编，這個(gè)就表示它是最后一個(gè)分片厢钧，然后可以開始重組包了。如果是其他分片包掏呼，形如..1. ... = More fragment: set則表示接收方需要緩存坏快，等待其他分片傳輸完成

MTU的實(shí)戰(zhàn)

如果client端的MTU=9000，server端的MTU=1500憎夷，那么當(dāng)client請(qǐng)求server端的時(shí)候莽鸿，client的包經(jīng)過(guò)路由器時(shí)候，要么就被丟包，要么就被分片祥得。如果這個(gè)巨幀包在網(wǎng)絡(luò)層攜帶了DF（Don't fragment）標(biāo)志則被丟棄（設(shè)置則表示不允許分片）兔沃，如果沒有設(shè)置則進(jìn)行分片傳輸。需要注意的是级及，這種情況下如果丟包了重傳還是會(huì)被丟棄乒疏，就成了黑洞了。

測(cè)試中饮焦，可以通過(guò)ping命令模擬這樣的情況：

成功：
ping xxx.xxx.xxx.xxx -l 1472 -f -n 1 

失斉挛狻：
ping xxx.xxx.xxx.xxx -l 1473 -f -n 1 

-f 參數(shù)表示設(shè)置DF標(biāo)志
-l 參數(shù)表示請(qǐng)求字節(jié)

當(dāng)請(qǐng)求字節(jié)設(shè)置為1472的時(shí)候，因?yàn)镮CMP頭部為8字節(jié)县踢、IP頭為20字節(jié)转绷，因此1472+8+20=1500，剛好是一個(gè)MTU硼啤，因此可以ping成功议经。但是第二個(gè)1473+8+20=1501字節(jié)超過(guò)MTU了，又因?yàn)樵O(shè)置了DF標(biāo)志表示不允許分片谴返，因此傳輸失敗煞肾，一般這樣的情況下，路由器會(huì)回復(fù)Packet needs to be fragmented but DF set嗓袱。

抓包的時(shí)候籍救，如果發(fā)現(xiàn)一直重傳，某個(gè)某些相對(duì)較大的包（查看Len值）才重傳索抓，那么可以通過(guò)ping xxx.xxx.xxx.xxx -l [Len] -f值進(jìn)行測(cè)試驗(yàn)證钧忽，通過(guò)這個(gè)ping指定的[Len]的大小變化來(lái)尋得規(guī)律，可能就會(huì)發(fā)現(xiàn)網(wǎng)絡(luò)上某個(gè)設(shè)備的MTU并非1500逼肯，這樣導(dǎo)致了超過(guò)這個(gè)就重傳的現(xiàn)象。

特殊的流控和帶寬

client 和 server端直接一定有交換機(jī)桃煎、路由器等設(shè)備篮幢，如果server端是萬(wàn)兆網(wǎng)卡，client端是千兆網(wǎng)卡为迈，就有可能使得server端發(fā)送過(guò)快導(dǎo)致數(shù)據(jù)堵在交換機(jī)上三椿，從而交換機(jī)在堵滿之后發(fā)生丟包。 但是一般而言葫辐，server端的帶寬本應(yīng)該要大于client端才算合理搜锰，為了避免擁塞，因此需要有一種流控機(jī)制耿战，允許交換機(jī)在過(guò)載時(shí)告知server端放慢速度或者暫停傳輸蛋叼。

有一種“暫停幀”，就能夠滿足這樣的需求：當(dāng)交換機(jī)的緩沖區(qū)即將被填滿時(shí)發(fā)送給server端一個(gè)暫停幀，當(dāng)server端等待一會(huì)兒再發(fā)狈涮，這樣就可以避免溢出丟包狐胎，也避免丟包后的重傳。server端等待多久則由暫停幀中的pause_time指定歌馍，這樣server端在等待pause_time后才會(huì)開始繼續(xù)發(fā)送握巢。當(dāng)然交換機(jī)還可以給server端發(fā)送一個(gè)pause_time=0的暫停幀，告知server端松却，我已經(jīng)消化完了暴浦，可以立即發(fā)送了。

注意晓锻，這的流控和TCP的流控是不一樣的

三歌焦，用Wireshark分析方法論

1. 通過(guò)wireshark排查問(wèn)題，需要分析網(wǎng)絡(luò)包带射，在網(wǎng)絡(luò)包中尋找一些線索同规，然后根據(jù)網(wǎng)絡(luò)協(xié)議作出推斷，接著就是一個(gè)一個(gè)去否定窟社，然后最終找到問(wèn)題所在

2. 需要能夠理解底層TCP協(xié)議券勺，要能夠清楚每一個(gè)字段表示的含義

3. 要善用Wireshark的一些統(tǒng)計(jì)、分析工具灿里；過(guò)濾器等

4. 發(fā)送發(fā)抓包和接收抓包是有極大區(qū)別的

5. 要善用“三板斧“的操作流程和步驟去分析問(wèn)題