自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

Wireshark抓包,丟包分析?

安全 數(shù)據(jù)安全
毋庸置疑,對端收到了完整地文件,數(shù)據(jù)包時肯定傳輸?shù)搅藢Χ?。那為什么wireshark中的pcap包丟包了呢?

前言

我們都知道,一般流量分析設(shè)備都支持pcap回放離線分析的功能,但如果抓的pcap丟了包,會影響最終安全測試的效果。比如說競測現(xiàn)場需要提供pcap包測試惡意文件的檢測功能,如果pcap中丟包,可能會導致文件還原失敗,最終惡意文件檢測功能“實效”。

那問題來了,我們怎么識別pcap包是否有丟包呢?接下來,我們通過wireshark來查找pcap文件中的丟包線索。

完整?丟包?

思路1:透過現(xiàn)象看現(xiàn)象。

在真實的網(wǎng)絡(luò)分析場景中,特別是傳輸大文件時,經(jīng)常會發(fā)現(xiàn)這樣的現(xiàn)象:

大文件已經(jīng)傳輸?shù)搅藢Χ?,但是pcap中卻存在丟包。

這是為什么呢?網(wǎng)絡(luò)數(shù)據(jù)包真的有完整地傳輸給對端嗎?

毋庸置疑,對端收到了完整地文件,數(shù)據(jù)包時肯定傳輸?shù)搅藢Χ恕D菫槭裁磜ireshark中的pcap包丟包了呢?

我們還是來看看wireshark的抓包原理吧!

wireshark在Linux操作系統(tǒng)中,底層是基于libpcap進行抓包的,tcpdump底層也是基于libpcap的,關(guān)于tcpdump的底層的收包原因已經(jīng)在tcpdump能進行丟包分析嗎?一文中已經(jīng)分析過了網(wǎng)卡層面的流程和入口,這里就不再贅述了。

由此我們可明確一點:產(chǎn)生上述現(xiàn)象的原因,并不是網(wǎng)卡丟包,因為網(wǎng)卡層面的丟包肯定會影響文件數(shù)據(jù)的完整性,由此如果我們排除wireshark使用錯誤產(chǎn)生的丟包,還可能是在下面這個過程中丟的包:

通過deliver_skb來進入 packet_rcv階段 ,packet_rcv 把收到的skb放到當前的packet socket緩沖區(qū),應(yīng)用層調(diào)用recvfrom就可以將緩沖區(qū)中的數(shù)據(jù)包拷貝到應(yīng)用層,從而實現(xiàn)libpcap的收包,大致過程如圖1所示:

圖1:libpcap的收包過程

所以我們能夠得出wireshark丟包的原因可能是:

  • packet socket緩沖區(qū)已滿導致丟包;
  • 從緩沖區(qū)拷貝到應(yīng)用層中斷異常導致丟包。
  • 當然排除以上兩條,也有可能是多路徑網(wǎng)絡(luò)結(jié)構(gòu)允許屬于同一 TCP 會話的數(shù)據(jù)包通過不同的網(wǎng)絡(luò)接口,導致wireshark捕獲的數(shù)據(jù)包不全。

可是在我們?nèi)粘5牧髁糠治龉ぷ髦校鶗鶕?jù)對端有沒有完整地數(shù)據(jù)包來判斷我們用wireshark抓的數(shù)據(jù)包是否完整,這樣做可能會嚴重影響安全測試的工作效率。那有沒有能夠快速分析pcap包中是否丟包的方法呢?

答案是有,可以用wireshark的專家信息快速分析丟包的效果。

丟包線索

思路2:透過本質(zhì)看現(xiàn)象。

打開wireshark,在工具欄中點擊“分析->專家信息”,如圖1、圖2所示:

圖1:wireshark的專家信息位置

wireshark的專家信息中提供了錯誤、警告、注意、對話這4種信息,選中任意一條都能定位到具體的數(shù)據(jù)包。

圖2:wireshark的丟包警告1

圖3:wireshark的丟包警告2

那專家信息中的哪些信息提示了丟包的線索呢?

  • Acked segment that wasn't capture(common at capture start),如圖2所示:表示此數(shù)據(jù)包已經(jīng)ack了未捕獲的數(shù)據(jù)。 傳輸正常,接收方已經(jīng)確認,但 Wireshark 無法在捕獲的數(shù)據(jù)中找到某段數(shù)據(jù)包, 這通常發(fā)生在捕獲設(shè)備不夠快的時候,比如libpcap的接收緩沖區(qū)已滿,或者由緩沖區(qū)向應(yīng)用層拷貝的時候?qū)е碌膩G包。
  • TCP Previous segment not captured,如圖3所示:表示如果數(shù)據(jù)包 N 標有未捕獲的前一個段,則表示在捕獲中沒有來自同一 TCP 會話的數(shù)據(jù)包,其 [seq + 長度≠數(shù)據(jù)包 N 的 seq ]。最典型的原因是數(shù)據(jù)包丟失或延遲啟動捕獲,但也有可能是發(fā)送方的 TCP 堆棧有問題,或者是多路徑網(wǎng)絡(luò)結(jié)構(gòu)允許屬于同一 TCP 會話的數(shù)據(jù)包通過不同的網(wǎng)絡(luò)接口,導致數(shù)據(jù)包確實到達目的地,但沒被 Wireshark 捕獲到。

結(jié)論

  • 1句忠告:不能通過判斷數(shù)據(jù)包是否已被接收端收到來判斷pcap中是否丟包。
  • 1個小tip:pcap丟包可以通過wireshark的專家信息快速定位和判斷。
  • 4條經(jīng)驗:由wireshark產(chǎn)生的丟包可能有4種原因,

①packet socket的緩沖區(qū)已滿導致丟包;

②從緩沖區(qū)拷貝到應(yīng)用層中斷異常導致丟包;

③wireshark使用不當,延遲啟動捕獲導致丟包;

④也有可能是多路徑網(wǎng)絡(luò)結(jié)構(gòu)允許屬于同一 TCP 會話的數(shù)據(jù)包通過不同的網(wǎng)絡(luò)接口,導致wireshark捕獲的數(shù)據(jù)包不全。

責任編輯:武曉燕 來源: FreeBuf.COM
相關(guān)推薦

2013-02-27 10:39:41

網(wǎng)絡(luò)丟包故障

2019-03-26 04:47:28

iOSWireshark抓包

2020-10-13 16:02:03

HTTPS淺析與抓包分

2021-03-08 07:24:06

抓包網(wǎng)絡(luò)請求

2020-10-16 08:02:00

Android系統(tǒng)

2023-11-01 08:04:08

WiresharkTCP協(xié)議

2011-11-28 16:03:49

wireshark數(shù)據(jù)包

2025-02-08 10:54:02

2009-07-27 10:39:50

2017-05-26 10:54:31

網(wǎng)絡(luò)故障丟包網(wǎng)絡(luò)診斷

2020-09-03 15:32:08

Wireshark數(shù)據(jù)包分析

2022-05-26 16:51:07

網(wǎng)絡(luò)丟包網(wǎng)絡(luò)故障網(wǎng)絡(luò)

2023-11-01 10:36:19

2019-05-13 14:17:06

抓包Web安全漏洞

2021-07-12 06:23:38

抓包gRpcRPC 框架

2018-10-12 14:34:13

2021-07-15 09:57:39

Wireshark數(shù)據(jù)包長度

2017-08-22 11:30:15

LinuxWireshark過濾數(shù)據(jù)包

2011-01-04 09:25:40

延時模擬丟包模擬

2019-09-27 09:35:12

點贊
收藏

51CTO技術(shù)棧公眾號