建站
咨詢
售后
建站咨詢
新聞中心
1. 前言
emmm，說起網(wǎng)絡(luò)知識學(xué)習(xí)肯定離不來wireshark工具，這個工具能夠幫助我們快速地定位網(wǎng)絡(luò)問題以及幫助正在學(xué)習(xí)網(wǎng)絡(luò)協(xié)議這塊的知識的同學(xué)驗(yàn)證理論與實(shí)際的一大利器，平時更多的只是停留在初步的使用階段。也是利用部門內(nèi)部的網(wǎng)絡(luò)興趣小組的討論機(jī)會，私下對wireshark的一些進(jìn)階功能，比如專家模式、圖表等功能進(jìn)行調(diào)研，并結(jié)合實(shí)際場景抓包分析對功能進(jìn)行對照說明。
成都創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比巴楚網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式巴楚網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋巴楚地區(qū)。費(fèi)用合理售后完善，10年實(shí)體公司更值得信賴。
2. wireshark中的分析菜單——專家模式
2.1什么是專家模式？
Wireshark的專家信息是非常強(qiáng)大的一個分析模塊，分別對錯誤、警告、注意、對話等數(shù)據(jù)信息做出分類和注釋，對網(wǎng)絡(luò)故障分析提供了強(qiáng)有力的信息依據(jù)，讓你準(zhǔn)確快速地判斷出故障點(diǎn)，并進(jìn)行下一步處理。
2.2 嚴(yán)重性級別的每種分類分別代表什么含義？
?對話（Chat）：關(guān)于正常通信的基本信息；
?注意（Note）：正常通信時的異常數(shù)據(jù)包；
?警告（Warn）：不是正常通信中的異常數(shù)據(jù)包（個人理解為：非正常的通信產(chǎn)生的數(shù)據(jù)包）；
?錯誤（Error）：數(shù)據(jù)包中的錯誤，或者解析器解析時的錯誤；
2.3 除了嚴(yán)重性級別之外，專家信息項(xiàng)還按組進(jìn)行了分類：
?假設(shè)(Assumption)：協(xié)議字段的數(shù)據(jù)不完整，根據(jù)假定值進(jìn)行了剖析
?檢驗(yàn)和(Checksum)：校驗(yàn)和無效
?注釋(Comment)：數(shù)據(jù)包注釋
?調(diào)試(Debug)：調(diào)試信息，你不應(yīng)該在wireshark的發(fā)布版本中看到這個組
?解密(Decryption)：解密問題
?已棄用(Deprecated)：協(xié)議字段已經(jīng)被棄用
?畸形的(Malformed)：格式錯誤的數(shù)據(jù)包或者解析程序有錯誤。此數(shù)據(jù)報的解析已中止
?協(xié)議(Protocol)：違反協(xié)議規(guī)范(比如無效字段值或者非法長度)?？赡軙^續(xù)對該數(shù)據(jù)包進(jìn)行解析
?重新組裝()：重新組裝時出現(xiàn)問題。比如，不是所有的碎片都可用，或者在重新組裝期間發(fā)生異常
?請求代碼(Request Code)：一個應(yīng)用程序請求。通常分配聊天級別。
?響應(yīng)代碼(Response Code)：應(yīng)用程序響應(yīng)代碼表示潛在問題，比如找不到HTTP 404
?安全(Security)：安全問題，比如不安全的實(shí)現(xiàn)
?序列(Sequence)：協(xié)議序列號可疑，比如它不連續(xù)或者檢測到重傳
?未編碼(Undecoded)：解析不完整或者數(shù)據(jù)因?yàn)槠渌麊栴}無法解碼
2.4 TCP的14種專家模式？
?對話消息（Chat）：
窗口更新（window update）：由接收者發(fā)送，用來通知發(fā)送者TCP接收窗口的大小已經(jīng)發(fā)生變化。
?注意消息（Note）：
? 重復(fù)ACK（Duplicate ACK ）：當(dāng)一臺主機(jī)沒有收到下一個期望序列號的數(shù)據(jù)包時，會生成最近一次收到的數(shù)據(jù)的重復(fù)ACK。
注意：其實(shí)重復(fù)確認(rèn)本身并不是問題，但如果接收方連續(xù)發(fā)送多個重復(fù)確認(rèn)，則可以視為網(wǎng)絡(luò)擁塞的信號。TCP協(xié)議中定義了一種擁塞控制機(jī)制，在發(fā)現(xiàn)網(wǎng)絡(luò)擁塞時會觸發(fā)這個機(jī)制，以減緩數(shù)據(jù)傳輸?shù)乃俣?，從而避免擁塞的加劇?nbsp;快速重傳：當(dāng)TCP接收方連續(xù)發(fā)送三個重復(fù)確認(rèn)時，發(fā)送方就會認(rèn)為一個數(shù)據(jù)包已經(jīng)丟失，并立即進(jìn)行快速重傳（Fast Retransmit）操作。它會重新發(fā)送那個沒有收到確認(rèn)的數(shù)據(jù)包，而不是等待超時時間后再重傳。這樣做可以盡快地填補(bǔ)丟失的數(shù)據(jù)包，提高數(shù)據(jù)傳輸速度和效率。
?TCP重傳（retransmission）：數(shù)據(jù)包丟失的結(jié)果。發(fā)生在收到重傳的ACK, 或者數(shù)據(jù)包的重傳計時器超時的時候。
?零窗口探查：在一個零窗口包被發(fā)送出去后，用來監(jiān)視TCP接收窗口的狀態(tài)。
?零窗口探查ACK：用來響應(yīng)零窗口探查數(shù)據(jù)包。
?保活（TCP Keep-Alive Segment ）：當(dāng)一個連接的?；顢?shù)據(jù)出現(xiàn)時觸發(fā)。
??；預(yù)CK(ACK to Tcp keep-alive)：用來響應(yīng)?；顢?shù)據(jù)包。
?窗口已滿：用來通知傳輸主機(jī)接受者的TCP窗口已滿。
?警告信息(Warn):
?上一段丟失(Previous segments not captured)：指明數(shù)據(jù)包丟失。發(fā)生在當(dāng)數(shù)據(jù)流中一個期望序列號被跳過時。
?收到丟失數(shù)據(jù)包的ACK(ACKed segment that was not captured)：發(fā)生在當(dāng)一個數(shù)據(jù)包被確認(rèn)丟失但在之后收到了這個已經(jīng)被確認(rèn)丟失的數(shù)據(jù)包的ACK數(shù)據(jù)包。
?零窗口(TCP Zero Window)：當(dāng)接收方已經(jīng)達(dá)到TCP接收窗口大小時，發(fā)出一個零窗口通知，要求發(fā)送方停止傳輸數(shù)據(jù)。可能是網(wǎng)絡(luò)擁塞或接收方未及時處理數(shù)據(jù)等原因?qū)е碌摹?/p>
?亂序：當(dāng)數(shù)據(jù)包被亂序接收時，會利用序列號進(jìn)行檢測。
?快速重傳輸：一次重傳會在收到一個重復(fù)ACK的20毫秒內(nèi)進(jìn)行。
3. 統(tǒng)計菜單——IO圖表、數(shù)據(jù)流圖
3.1 IO圖表的用途？
Wireshark IO Graph能把原始數(shù)據(jù)過濾并把數(shù)據(jù)以圖表的形式展示出來，是一個非常好用的工具。 基本的Wireshark IO Graph會顯示抓包文件中的整體流量情況。X軸為時間，Y軸是每一時間間隔的報文數(shù)。默認(rèn)情況下，X軸時間單位為1s，Y軸是Packet/tick，可以自己調(diào)節(jié)單位。通過調(diào)節(jié)單位，對于查看流量中的波峰／波谷很有幫助。
3.2 一些常用的排錯過濾條件？
對于排查網(wǎng)絡(luò)延時/應(yīng)用問題有一些過濾條件是非常有用的，下面羅列了一些常用的過濾條件：
?tcp.analysis.lost_segment：表明已經(jīng)在抓包中看到不連續(xù)的序列號。報文丟失會造成重復(fù)的ACK，這會導(dǎo)致重傳。
?tcp.analysis.duplicate_ack：顯示被確認(rèn)過不止一次的報文。大量的重復(fù)ACK是TCP端點(diǎn)之間高延時的跡象。
?tcp.analysis.retransmission：顯示抓包中的所有重傳。如果重傳次數(shù)不多的話還是正常的，過多重傳可能有問題。這通常意味著應(yīng)用性能緩慢和/或用戶報文丟失。
?tcp.analysis.window_update：將傳輸過程中的TCP window大小圖形化。如果看到窗口大小下降為零，這意味著發(fā)送方已經(jīng)退出了，并等待接收方確認(rèn)所有已傳送數(shù)據(jù)。這可能表明接收端已經(jīng)不堪重負(fù)了。
?tcp.analysis.bytes_in_flight：某一時間點(diǎn)網(wǎng)絡(luò)上未確認(rèn)字節(jié)數(shù)。未確認(rèn)字節(jié)數(shù)不能超過你的TCP窗口大小（定義于最初3此TCP握手），為了最大化吞吐量你想要獲得盡可能接近TCP窗口大小。如果看到連續(xù)低于TCP窗口大小，可能意味著報文丟失或路徑上其他影響吞吐量的問題。
?tcp.analysis.ack_rtt：衡量抓取的TCP報文與相應(yīng)的ACK。如果這一時間間隔比較長那可能表示某種類型的網(wǎng)絡(luò)延時（報文丟失，擁塞，等等）。
3.3 IO圖表中的一些常用的函數(shù)？
IO Graphs有六個可用函數(shù)：SUM, MIN, AVG, MAX, COUNT, LOAD。
?MIN（）, AVG（）, MAX（）
MIN、AVG、MAX分別表示幀/報文之間的最小、平均、最大時間，對于查看幀/報文之間的延時非常有用。
我們可以將這些函數(shù)結(jié)合“frame.time_delta”過濾條件看清楚幀延時，并使得往返延時更為明顯。如果抓包文件中包含不同主機(jī)之間的多個會話，而只想知道其中一個pair，可將“frame.time_delta”結(jié)合源和目標(biāo)主機(jī)條件如“ip.addr==x.x.x.x &&ip.addr==y.y.y.y”。
從上圖可見，在第106秒時數(shù)據(jù)流的MAX frame.delta_time達(dá)到0.7秒，這是一個嚴(yán)重延時并且導(dǎo)致了報文丟失。
?Count（）
此函數(shù)計算時間間隔內(nèi)事件發(fā)生的次數(shù)，在查看TCP分析標(biāo)識符時很有用，例如重傳。
?Sum（）
該函數(shù)統(tǒng)計事件的累加值。有兩種常見的用例是看在捕獲TCP數(shù)據(jù)量，以及檢查TCP序列號。
參數(shù)設(shè)置：分別使用客戶端IP 192.168.1.4為源、目的地址，并將SUM功能結(jié)合tcp.len過濾條件；
從圖表中我們可以看到，發(fā)送到客戶端的數(shù)據(jù)量（IP.DST = = 192.168.1.4過濾條件）比來自客戶端的數(shù)據(jù)量要高。在圖中紅色表示。黑條顯示從客戶端到服務(wù)器的數(shù)據(jù)，相對數(shù)據(jù)量很小。這是有道理的，因?yàn)榭蛻糁皇钦埱笪募褪盏街蟀l(fā)送確認(rèn)數(shù)據(jù)，而服務(wù)器發(fā)送大文件。很重要的一點(diǎn)是，如果你交換了圖的順序，把客戶端的IP作為圖1的目標(biāo)地址，并且客戶端IP作為圖2的源地址，采用了FBAR的時候可能看不到正確的數(shù)據(jù)顯示。因?yàn)閳D編號越低表示在前臺顯示，可能會覆蓋較高圖號。
4. 實(shí)例場景分析
參數(shù)設(shè)置：1是HTTP總體流量，顯示形式為packets/tick，時間間隔1秒。圖2是TCP丟失報文片段。圖3是TCP 重復(fù)ACK。圖4是TCP重傳。
圖1：HTTP總體流量圖
圖2：TCP丟失報文片段圖
圖3：TCP 重復(fù)ACK
從這張圖可以看到：整體的HTTP流量，TCP重傳以及重復(fù)ACK的流量，這些事件發(fā)生的時間點(diǎn)，以及在整體流量中所占的比例。
?數(shù)據(jù)包丟失和延遲的TCP序列號場景：我們可以在下面的圖中看到若干峰值和下降，表示TCP傳輸有問題。
圖4：數(shù)據(jù)包丟失和延遲的TCP序列號場景
與正常TCP報文比較：
這張圖可以看到TCP序列號相當(dāng)穩(wěn)定地增加，表示傳輸平穩(wěn)，沒有過多重傳或丟包。
?對比視頻會議在網(wǎng)絡(luò)卡頓與流暢時的IO圖表實(shí)例場景：
https://zhiliao.h3c.com/Theme/details/104284
5. 總結(jié)
如果只是簡單的排查網(wǎng)絡(luò)問題，只需要使用wireshark中簡單的添加過濾規(guī)則，通過觀察抓取到的數(shù)據(jù)包就可以達(dá)到定位問題的目的，其實(shí)這幾個進(jìn)階的功能，無論是專家模式、還是IO圖表，底層其實(shí)還是需要配置規(guī)則，亦或者是通過wireshark的內(nèi)置規(guī)則做了一個集成。針對一些場景，比如觀測網(wǎng)絡(luò)是否擁塞，可以通過IO圖表直觀的進(jìn)行判斷,,,,,以上。
作者：京東科技 宋慧超
來源：京東云開發(fā)者社區(qū) 轉(zhuǎn)載請注明來源
本文標(biāo)題：聊聊wireshark的進(jìn)階使用功能
標(biāo)題來源：http://fisionsoft.com.cn/article/djjgoeg.html
