"TCP segment of a reassembled PDU" in Wireshark

Last week in the company encountered a problem, with Wireshark capture system to the network management reported data found that there are many messages are identified as "TCP segment of a reassembled PDU", and each piece of the message is 180Byte, at that time to see such an identity, Think is the IP message Shard, thought the System interface MTU value for the setting is small, through the command query found is 1500, has not been reset, at that time a little thought.

Back to check, found that their understanding is wrong, "TCP segment of a reassembled PDU" refers to the IP layer is not a shard, IP shards in the Wireshark with "fragmented IP protocol" to identify. A detailed look, found that "TCP segment of a reassembled PDU" refers to the TCP layer after receiving the upper chunk of the packet decomposition into a paragraph after the issue. So there is a doubt that the TCP layer can completely send a large segment of the message to the IP layer, so that the IP layer to complete the segment, why the TCP layer is divided. In fact, this is determined by the TCP MSS (Maximum Segment size, the maximum message length), TCP in the TCP header of the first message that initiates the connection through the MSS this option to inform the other side of the maximum message can receive (of course, this size is the size of TCP payload), This value on Ethernet is generally set to 1460, because the 1460Byte net charge +20byte TCP header +20byte IP Header = 1500 bytes, exactly in line with the link layer maximum message requirements.

As to how to determine when a message is received, it is a "TCP segment". If there are several messages with the same ACK sequence, and the sequence number of these messages are different, and the latter sequence number is the previous sequence, plus the previous message size plus 1, it must be TCP segment , it is not possible to determine when there is no ACK flag.

    since received TCP messages are 180Byte segment, then should be negotiated when the PC side told the MSS for 180Byte, as for why this, can only wait to confirm after the packet after the MSS to check the problem. In addition, there is a situation can also cause this problem: the system is tested because the MTU is 220Byte and set MSS to 180Byte, but this situation can now be excluded, because previously said, has been queried the MTU value is 1500.