回來查了一下，發(fā)現(xiàn)自己的理解是錯的，“TCP segment of a reassembled PDU”指的不是IP層的分片，IP分片在wireshark里用“Fragmented IP protocol”來標識。詳細查了一下，發(fā)現(xiàn)“TCP segment of a reassembled PDU”指TCP層收到上層大塊報文后分解成段后發(fā)出去。于是有個疑問，TCP層完全可以把大段報文丟給IP層，讓IP層完成分段，為什么要在TCP層分呢？ 其實這個是由TCP的MSS(Maximum Segment Size，最大報文段長度)決定的，TCP在發(fā)起連接的第一個報文的TCP頭里通過MSS這個可選項告知對方本端能夠接收的最大報文（當然，這個大小是TCP凈荷的大?。?，以太網(wǎng)上這個值一般設(shè)置成1460，因為1460Byte凈荷+20Byte TCP頭+20Byte IP頭 ＝ 1500字節(jié)，正好符合鏈路層最大報文的要求。
至于收到一個報文后如何確定它是一個"TCP segment"？如果有幾個報文的ACK序號都一樣，并且這些報文的Sequence Number都不一樣，并且后一個Sequence Number為前一個Sequence Number加上前一個報文大小再加上1的話，肯定是TCP segment了，對于沒有ACK標志時，則無法判斷。
既然收到的TCP報文都是180Byte的segment，那么應(yīng)該是協(xié)商的時候PC端告知了MSS為180Byte，至于為什么這樣，只能等抓包后確認是MSS的問題再排查了。另外，有一種情況也可能導致這個問題：被測系統(tǒng)因為MTU為220Byte而設(shè)置MSS為180Byte，但是這種情況現(xiàn)在可以排除，因為前面講過，已經(jīng)查詢過MTU值為1500。
今天利用windows查找功能對網(wǎng)絡(luò)上的一個共享文件夾里的內(nèi)容進行查找，發(fā)現(xiàn)查找網(wǎng)絡(luò)文件時流量巨大。好奇用wireshark抓包發(fā)現(xiàn)wireshark Info欄里有很多“TCP segment of a reassembled PDU”提示信息。不解百度了一下發(fā)現(xiàn)大家都在詢問這個問題網(wǎng)上并沒有很好的解答。想到“TCP segment of a reassembled PDU”只是wireshark的提示信息，那么在sniffer pro里會給出什么樣的提示呢，用sniffer打開同樣的trace 發(fā)現(xiàn)里面提示“Continuation of missing frame”和"Continuation of frame xx"現(xiàn)在大概知道“TCP segment of a reassembled PDU”是什么意思，其實主機響應(yīng)一個查詢或者命令時如果要回應(yīng)很多數(shù)據(jù)（信息）而這些數(shù)據(jù)超出了TCP的最大MSS時，主機會通過發(fā)送多個數(shù)據(jù)包來傳送這些數(shù)據(jù)（注意：這些包并未被分片）。對wireshark來說這些對相應(yīng)同一個查詢命令的數(shù)據(jù)包被標記了“TCP segment of a reassembled PDU”
問題，wireshark如何識別多個數(shù)據(jù)包是對同一個查詢數(shù)據(jù)包的響應(yīng)? wireshark是根據(jù)sequence number來識別，這些數(shù)據(jù)包ACK number是相同的，當然number的數(shù)值與查詢數(shù)據(jù)包中的next sequence number也是一樣的。
CIFS/SMB協(xié)議對待文件查詢效率多么的低下！對待一個文件名的查詢要用兩個幀長1514字節(jié)和一個1294字節(jié)的幀長來響應(yīng)。
關(guān)于TCP/UDP與IP最大報文長度的區(qū)別請見此文
http://blog.163.com/hlz_2599/blog/static/142378474201341601129121/
本文來自CSDN博客，轉(zhuǎn)載請標明出處：http://blog.csdn.net/rossini23/archive/2010/03/28/5424850.aspx
聯(lián)系客服
