TCP segment of a reassembled PDU
TCP segment of a reassembled PDU 其實主機響應一個查詢或者命令時，如果要回應很多數據（信息），而這些數據超出了TCP的最大MSS時，主機通過發送多個數據包來傳送這些數據（注意：這些包並未被分片）。
【背景知識】
MTU 最大傳輸單元
MSS
【分析過程】
先說說MTU（最大傳輸單元），這個MTU實際上和鏈路層協議有着密切的關系。EthnernetII幀的結構：DMAC+SMAC+Type+Data+CRC。由於以太網傳輸電氣方面的限制，每個以太網幀都有最小64bytes和最大1518bytes。對於小於或者大於這個限制的以太網幀我們都視為錯誤的數據幀，一般的以太網轉發設備會丟棄這些數據幀。（注：小於64bytes的數據幀一般是由於以太網沖突產生的“碎片”或者線路干擾或者壞的以太網接口產生的，對於大於1518bytes的數據幀我們一般稱為Giant幀，這種一般是線路干擾或者壞的以太網接口產生）
由於以太網EthernetII最大的數據幀是1518bytes，刨去以太網幀的幀頭（DMAC（6bytes）+SMAC（6bytes）+Type（2bytes））14bytes和幀尾CRC校驗部分4bytes（這個有時候大家把它叫做FCS），那么剩余承載上層協議的地方就是DATA域，最大就只有1500Bytes，這個值我們就把它稱為MTU。這個就是網絡層協議非常關心的地方，因為網絡層協議比如IP協議會根據這個值來決定是否把上層傳下來的數據進行分片。
當兩台遠程PC互聯的時候，它們的數據需要穿過很多的路由器和各種網絡媒介才能到達對端，網絡中不同媒介的MTU各不相同，就好比一長段的水管，由不同粗細的水管組成（MTU不同），通過這段水管最大水量就要由中間最細的水管決定。
對於網絡層的上層協議而言（以TCP/IP協議族為例）它們對水管粗細不在意它們認為這個是網絡層的事情。網絡層IP協議會檢查每個從上層協議下來的數據包的大小，並根據本機MTU的大小決定是否作“分片”處理。分片的最大壞處就是降低了傳輸性能，本來一次可以搞定的事情，分成多次搞定，所以網絡層更高一層（就是傳輸層）的實現中往往會對此加以注意。有些高層因為某些原因就會要求我這個面包不能切片，我要完整地面包，所以會在IP數據包包頭里面加上一 個標簽：DF（DonotFragment）。這樣當這個IP數據包在一大段網絡（水管里面）傳輸的時候，如果遇到MTU小於IP數據包的情況，轉發設備 就會根據要求丟棄這個數據包。然后返回一個錯誤信息給發送者。這樣往往會造成某些通訊上的問題，不過幸運的是大部分網絡鏈路都是MTU1500或者大於 1500。
對於UDP協議而言，這個協議本身是無連接的協議，對數據包的到達順序以及是否正確到達不甚關心，所以一般UDP應用對分片沒有特殊要求。
對於TCP協議而言就不一樣了，這個協議是面向連接的協議，對於TCP協議而言它非常在意數據包的到達順序以及是否傳輸中有錯誤發生。所以有些TCP應用對分片有要求---不能分片（DF）。
MSS最大傳輸大小的縮寫，是TCP協議里面的一個概念。
MSS 就是TCP數據包每次能夠傳輸的最大數據分段。為了達到最佳的傳輸效能TCP協議在建立連接的時候通常要協商雙方的MSS值，這個值TCP協議在實現的時 候往往用MTU值代替（需要減去IP數據包包頭的大小20Bytes和TCP數據段的包頭20Bytes）所以往往MSS為1460。通訊雙方會根據雙方 提供的MSS值得最小值確定為這次連接的最大MSS值。
我們回過頭來看前言里面的那個問題，我們試想一下，如 果我們在中間路由器上把每次TCP連接的最大MSS進行調整這樣使得通過PPPoE鏈路的最大MSS值加上數據包頭包尾不會超過PPPoE的MTU大小 1492這樣就不會造成無法通訊的問題.所以上面的問題可以通過iptcp adjust-mss 1452來解決。
當然問題也可以通過修改PC機的MTU來解決。
上周在公司里遇到一個問題，用wireshark抓系統給網管上報的數據發現里面有好多報文被標識為“TCP segment of a reassembled PDU”，並且每一段報文都是180Byte，當時看到這樣的標識，覺得是IP報文分片，以為系統的接口MTU值為設置小了，通過命令查詢發現是 1500，沒有被重設過，當時有點想不通。
回來查了一下，發現自己的理解是錯的，“TCP segment of a reassembled PDU”指的不是IP層的分片，IP分片在wireshark里用“Fragmented IP protocol”來標識。詳細查了一下，發現“TCP segment of a reassembled PDU”指TCP層收到上層大塊報文后分解成段后發出去。於是有個疑問，TCP層完全可以把大段報文丟給IP層，讓IP層完成分段，為什么要在TCP層分呢？ 其實這個是由TCP的MSS(Maximum Segment Size，最大報文段長度)決定的，TCP在發起連接的第一個報文的TCP頭里通過MSS這個可選項告知對方本端能夠接收的最大報文（當然，這個大小是 TCP凈荷的大小），以太網上這個值一般設置成1460，因為1460Byte凈荷+20Byte TCP頭+20Byte IP頭 ＝ 1500字節，正好符合鏈路層最大報文的要求。
至於收到一個報文后如何確定它是一個"TCP segment"？如果有幾個報文的ACK序號都一樣，並且這些報文的Sequence Number都不一樣，並且后一個Sequence Number為前一個Sequence Number加上前一個報文大小再加上1的話，肯定是TCP segment了，對於沒有ACK標志時，則無法判斷。
既然收到的TCP報文都是180Byte的segment，那么應該是協商的時候PC端告知了MSS為180Byte，至於為什么這樣，只能等抓包后確認是MSS的問題再排查了。另外，有一種情況也可能導致這個問題：被測系統因為MTU為220Byte而設置MSS為180Byte，但是這種情況現在可以排除，因為前面講過，已經查詢過MTU值為1500。
今天利用windows查找功能對網絡上的一個共享文件夾里的內容進行查找，發現查找網絡文件時流量巨大。好奇用wireshark抓包發現 wireshark Info欄里有很多“TCP segment of a reassembled PDU”提示信息。不解百度了一下發現大家都在詢問這個問題網上並沒有很好的解答。想到“TCP segment of a reassembled PDU”只是wireshark的提示信息，那么在sniffer pro里會給出什么樣的提示呢，用sniffer打開同樣的trace 發現里面提示“Continuation of missing frame”和"Continuation of frame xx"現在大概知道“TCP segment of a reassembled PDU”是什么意思，其實主機響應一個查詢或者命令時如果要回應很多數據（信息）而這些數據超出了TCP的最大MSS時，主機會通過發送多個數據包來傳送這些數據（注意：這些包並未被分片）。對wireshark來說這些對相應同一個查詢命令的數據包被標記了“TCP segment of a reassembled PDU”
問題，wireshark如何識別多個數據包是對同一個查詢數據包的響應? wireshark是根據sequence number來識別，這些數據包ACK number是相同的，當然number的數值與查詢數據包中的next sequence number也是一樣的。
CIFS/SMB協議對待文件查詢效率多么的低下！對待一個文件名的查詢要用兩個幀長1514字節和一個1294字節的幀長來響應。
關於TCP/UDP與IP最大報文長度的區別請見此文
http://blog.163.com/hlz_2599/blog/static/142378474201341601129121/
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/rossini23/archive/2010/03/28/5424850.aspx