正文

tcp協(xié)議怎么抓包

發(fā)布時(shí)間：2023-03-19 01:41:14 稿源：創(chuàng)意嶺閱讀： 63 問大家

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于tcp協(xié)議怎么抓包的問題，以下是小編對(duì)此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個(gè)非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計(jì)劃、工作報(bào)告、論文、代碼、作文、做題和對(duì)話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁(yè)版、PC客戶端

官網(wǎng)：https://ai.de1919.com

本文目錄:

1、本地進(jìn)程間通過tcp通信，Wireshark 可以抓包么？
2、tcpdump抓包工具
3、詳解 TCP（上）
4、求大神解答 TCP過程分析 Wireshark 抓包分析

tcp協(xié)議怎么抓包

一、本地進(jìn)程間通過tcp通信，Wireshark 可以抓包么？

其實(shí)可以的，在WindowsXp下我嘗試過，設(shè)置本地IP的靜態(tài)路由至網(wǎng)關(guān)，可以使用Wireshark抓包。

這樣設(shè)置你訪問本地地址，報(bào)文就要到網(wǎng)關(guān)那里走一個(gè)回路。

二、tcpdump抓包工具

tcpdump和ethereal可以用來獲取和分析網(wǎng)絡(luò)通訊活動(dòng)，他們都是使用libpcap庫(kù)來捕獲網(wǎng)絡(luò)封包的。

在混雜模式下他們可以監(jiān)控網(wǎng)絡(luò)適配器的所有通訊活動(dòng)并捕獲網(wǎng)卡所接收的所有幀。

要想設(shè)置網(wǎng)絡(luò)接口為混雜模式并執(zhí)行這些命令來捕獲所有的網(wǎng)絡(luò)封包，需要具有超級(jí)用戶的權(quán)限。

你可以使用這些工具來探究網(wǎng)絡(luò)相關(guān)問題。你可以發(fā)現(xiàn)TCP/IP重發(fā)、窗口大小的縮放、名字解析的問題、網(wǎng)絡(luò)配置錯(cuò)誤等。

注意這些工具只能監(jiān)控網(wǎng)絡(luò)適配器所接收到的幀，并不能監(jiān)控到整個(gè)網(wǎng)絡(luò)的通訊情況。

三、詳解 TCP（上）

讓我們來看看這張圖

首先來了解每個(gè)部分的意義

其他部分解釋在這里：

為什么建鏈接要 3 次握手，斷鏈接需要 4 次揮手？

另有一些需要注意的地方：

Again，使用tcp_tw_reuse和tcp_tw_recycle來解決TIME_WAIT的問題是非常非常危險(xiǎn)的，因?yàn)檫@兩個(gè)參數(shù)違反了TCP協(xié)議（RFC 1122）

SeqNum 的增加是和傳輸?shù)淖止?jié)數(shù)相關(guān)的 。上圖中，三次握手后，來了兩個(gè) Len:1440 的包，而第二個(gè)包的 SeqNum 就成了 1441。然后第一個(gè) ACK 回的是 1441，表示第一個(gè) 1440 收到了。

注意：如果你用 Wireshark 抓包程序看 3 次握手，你會(huì)發(fā)現(xiàn) SeqNum 總是為 0，不是這樣的，Wireshark 為了顯示更友好，使用了 Relative SeqNum ——相對(duì)序號(hào)，你只要在右鍵菜單中的 protocol preference 中取消掉就可以看到“Absolute SeqNum”了

TCP 要保證所有的數(shù)據(jù)包都可以到達(dá)，所以，必需要有重傳機(jī)制。

比如：發(fā)送端發(fā)了 1,2,3,4,5 五個(gè)包，接收端收到了 1,2 于是返回 ack 3，然后收到了 4（3 沒收到）。此時(shí)的 TCP 會(huì)怎么辦？因?yàn)檎缜懊嫠f的， SeqNum 和 Ack 是以字節(jié)數(shù)為單位，所以 ack 的時(shí)候，不能跳著確認(rèn)，只能確認(rèn)最大的連續(xù)收到的包 ，不然，發(fā)送端就以為之前的都收到了。

有這樣一個(gè)簡(jiǎn)單的辦法：不回 ack，死等 3。當(dāng)發(fā)送方發(fā)現(xiàn)收不到 3 的 ack 超時(shí)后，會(huì)重傳 3。一旦接收方收到 3 后，會(huì) ack 回 4——意味著 3 和 4 都收到了。

但是這樣有個(gè)非常大的 BUG，不回 ACK 那收到的 4,5 也不告訴發(fā)送方，這樣發(fā)送方很有可能會(huì)認(rèn)為 4,5 也沒有到。導(dǎo)致 4,5 的重傳

于是，TCP引入了一種叫 Fast Retransmit 的算法， 不以時(shí)間驅(qū)動(dòng)，而以數(shù)據(jù)驅(qū)動(dòng)重傳 。也就是說，如果，包沒有連續(xù)到達(dá)，就 ack 最后那個(gè)可能被丟了的包，如果發(fā)送方連續(xù)收到 3 次相同的ack，就重傳。Fast Retransmit 的好處是不用等 timeout 了再重傳。

比如說：

我收到了 3 沒收到 2，返回 ack2

我又收到了 4 但還是沒收到 2，返回 ack2

但是 TMD 我又收到了 5 就是沒收到 2，還是返回 ack2

這個(gè)時(shí)候，不用等 timeout 的發(fā)送方就知道了 2 怕是掉了。于是會(huì)重新發(fā) 2。然后我接收到了我就返回 ack6

**快速重傳只解決了一個(gè)問題：不再需要等 timeout 就可以重新傳包了。那重傳多少呢？我知道 4 丟了，那要不要重傳 5,6,7 呢？ **

所以就有了另一個(gè)更好的辦法： Selective Acknowledgment （SACK） 。這種方式需要在 TCP 頭里加一個(gè) SACK 的東西，ACK 還是 Fast Retransmit 的 ACK，SACK 則是匯報(bào)收到的數(shù)據(jù)碎版。參看下圖：

這樣，在發(fā)送端就可以根據(jù)回傳的 SACK 知道哪些數(shù)據(jù)到了，哪些數(shù)據(jù)沒有到。于是就優(yōu)化了 Fast Retransmit 的算法。當(dāng)然，這個(gè)協(xié)議需要兩邊都支持。在 Linux下，可以通過 tcp_sack 參數(shù)打開這個(gè)功能（Linux 2.4后默認(rèn)打開）。

這里還需要注意一個(gè)問題—— 接收方 Reneging，所謂 Reneging 的意思就是接收方有權(quán)把已經(jīng)報(bào)給發(fā)送端 SACK 里的數(shù)據(jù)給丟了 。這樣干是不被鼓勵(lì)的，因?yàn)檫@個(gè)事會(huì)把問題復(fù)雜化了，但是，接收方這么做可能會(huì)有些極端情況，比如要把內(nèi)存給別的更重要的東西。所以，發(fā)送方也不能完全依賴 SACK，還是要依賴 ACK，并維護(hù) Time-Out，如果后續(xù)的 ACK 沒有增長(zhǎng)，那么還是要把 SACK 的東西重傳，另外，接收端這邊永遠(yuǎn)不能把 SACK 的包標(biāo)記為 Ack。

注意：SACK 會(huì)消費(fèi)發(fā)送方的資源，試想，如果一個(gè)攻擊者給數(shù)據(jù)發(fā)送方發(fā)一堆 SACK 的選項(xiàng)， 這會(huì)導(dǎo)致發(fā)送方開始要重傳甚至遍歷已經(jīng)發(fā)出的數(shù)據(jù)，這會(huì)消耗很多發(fā)送端的資源。 詳細(xì)的東西請(qǐng)參看《 TCP SACK的性能權(quán)衡》

Duplicate SACK 又稱 D-SACK， 其主要使用了 SACK 來告訴發(fā)送方有哪些數(shù)據(jù)被重復(fù)接收了 。

D-SACK 使用了 SACK 的第一個(gè)段來做標(biāo)志

下面的示例中，丟了兩個(gè) ACK，所以，發(fā)送端重傳了第一個(gè)數(shù)據(jù)包（3000-3499），于是接收端發(fā)現(xiàn)重復(fù)收到，于是回了一個(gè)SACK=3000-3500，因?yàn)?ACK 都到了 4000 意味著收到了 4000 之前的所有數(shù)據(jù)，所以這個(gè) SACK 就是 D-SACK——旨在告訴發(fā)送端我收到了重復(fù)的數(shù)據(jù)，而且我們的發(fā)送端還知道，數(shù)據(jù)包沒有丟，丟的是 ACK 包。

下面的示例中，網(wǎng)絡(luò)包（1000-1499）被網(wǎng)絡(luò)給延誤了，導(dǎo)致發(fā)送方?jīng)]有收到 ACK，而后面到達(dá)的三個(gè)包觸發(fā)了“Fast Retransmit算法”，所以重傳，但重傳時(shí)，被延誤的包又到了，所以，回了一個(gè)SACK=1000-1500，因?yàn)?ACK 已到了3000，所以，這個(gè) SACK 是D-SACK——標(biāo)識(shí)收到了重復(fù)的包。

這個(gè)案例下，發(fā)送端知道之前因?yàn)椤癋ast Retransmit算法”觸發(fā)的重傳不是因?yàn)榘l(fā)出去的包丟了，也不是因?yàn)榛貞?yīng)的 ACK 包丟了，而是因?yàn)榫W(wǎng)絡(luò)延時(shí)了。

可見，引入了D-SACK，有這么幾個(gè)好處：

知道這些東西可以很好得幫助TCP了解網(wǎng)絡(luò)情況，從而可以更好的做網(wǎng)絡(luò)上的流控。Linux 下的 tcp_dsack 參數(shù)用于開啟這個(gè)功能（Linux 2.4后默認(rèn)打開）

陳皓大神講的真的非常非常好，我仔仔細(xì)細(xì)把這篇文章過了一遍。

四、求大神解答 TCP過程分析 Wireshark 抓包分析

（1）TCPClient向TCPServer發(fā)送連接請(qǐng)求SYN

（2）TCPServer收到連接請(qǐng)求后反饋SYN+ACK

（3）TCPClient收到SYN+ACK后反饋ACK，三次握手完成，連接建立

（4）TCPClient向TCPServer發(fā)送100字節(jié)的數(shù)據(jù)

（5）TCPServer收到（4）后確認(rèn)并發(fā)送78字節(jié)的數(shù)據(jù)，即捎帶確認(rèn)

（6）TCPClient收到（5）后，發(fā)送ACK進(jìn)行確認(rèn)

（7）TCPClient發(fā)送100字節(jié)的數(shù)據(jù)