wireshark抓包出现“TCP segment of a reassembled PDU”的解释

为什么大家看到这个以后总是会往MSS，TSO上联系呢？也许第一个解释这个的人是个高手，而且以MSS/MTU/TSO的观点解释了这个问题，还有一种可能就是TSO等技术让人觉得太牛逼，毕竟是底层硬件机制吧，抓包机制又是作用于网卡层面的，所以很自然会觉得TSO会有关联。
        事实上，这个跟TSO没有关系！跟MSS有一定的关系但不是全部因果关系，在阐述“TCP segment of a reassembled PDU”之前，先把TSO理清再说。当有人问题“这个包会不会被TSO分段”这类问题时，只要看该TCP数据包的长度，拿它跟MTU比较，如果数据长度更长，则就是TSO。
        那么，“TCP segment of a reassembled PDU”究竟是什么呢？答案是，这要向上看，这个跟应用层有关，而与底层关系不大！我用Wireshark的抓包例子来解释这个问题。首先看一个抓包，我们以网络测试工具baidu为例，抓取一个访问其服务器https://14.215.177.38/的一个HTTPS连接的包：

网上很多人在解释这个“TCP segment of a reassembled PDU”的时候(基本都是转载)，都说什么“ACK了同一笔数据就会是reassembled PDU”，“同一个GET请求的response”云云...但是很显然，上述我抓包的截图中，402到405号包都有ACK了同一个序列号，但是为什么只有一个“TCP segment of a reassembled PDU”呢？？在没有标识reassembled PDU的数据包中，另外标识了TLSv1.2的协议原语。此时，我来做一个动作，按下“Ctrl-Shift-E”组合键，事实上就是点击“分析”菜单，进入“已启用的协议”界面：

反选SSL协议，不再识别SSL协议之后，我们再看402到405号数据包：

没有了“TCP segment of a reassembled PDU”这些，除了没有这些“修饰语”之外，其它的协议层面的数据完全和之前识别SSL协议的时候相符合。我们的结论是，关掉了对SSL协议的识别，就没有了reassembled PDU的修饰，这恰恰是因为SSL协议让Wireshark知道403号包是一个reassembled PDU！如果你不知道这是个SSL协议，你就无法判断出这是不是一个reassembled PDU！
        是的，这就是原因。接下来，为什么SSL协议就能识别这是一个reassembled PDU呢？这就要看你对SSL协议是否理解了，起码我是懂的，在握手阶段，Server Hello和Server的Certificate是背靠背发送的，也就是说它们是连着发给Client的，一个Server Hello，外加一个证书，一起发给Client，接下来就是不那么根本但很显然的事情了，如果这些包的总和足够小或者链路的MTU足够大，能够一次性发送过去的话，那当然好，如果不能，很显然要拆成几个分段发送了，如果中间的那个分段不能被SSL协议的原语识别，那么就会被标识成reassembled PDU，这就是为什么404，405号数据包都是连续发送的，但是却未被识别为reassembled PDU，因为SSL协议知道它们是Certificate消息和Server Key Exchange消息。

        现在明白了吗？我特意没有用HTTP协议去解释这个而是选择了用SSL协议，目的就是想让大家明白，并不是针对同一个GET请求的同一笔回应会被标识为reassembled PDU！而是完全靠着应用层协议原语来识别协议消息。如果你的Wireshark被配置成不识别任何协议，比如不识别HTTP协议，SSL协议，那也就不会出现reassembled PDU了，因为Wireshark不知道到底是不是！实际上Wireshark支持你去自定义你自己的协议插件，你可以试一下，自己开发一个简单的协议，就算你的TCP数据段总和没有超过一个MSS，比如你的socket每发100字节就sleep 10秒，并且TCP socket没有设置Nagle算法，那么虽然每个段只有100字节，远没有到一个MSS，也会有reassembled PDU的标识！

        本质上来讲，reassembled PDU要向上看，而不是去考虑什么底层的MTU，TSO什么的。Wireshark根据它能识别的应用层协议，告诉你哪些数据是属于一个应用层消息的。就这么简单。
————————————————
版权声明：本文为CSDN博主「dog250」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/dog250/article/details/51809566