packet order in TCP packet fragmentation

Question

In TCP/IP, we have MSS and MTU when sending and receiving packets.

1. MTU is an IP layer concept, which is determined by the underlying hardware. It shows the maximum data size that an IP layer packet can contain during one transmission.
2. MSS is a TCP layer concept, which is limited by the MTU, showing that the TCP data stream will be fragmented into MSS-size packets.

Our protocol lies on top of TCP, and each protocol will define its own packet. One example is MySQL, which defines its packet size up to 2^24-1, that is around 16M. When the big enough protocol packet comes to TCP, it will be fragmented according to MSS.

Assume that a client needs to send DATA1 and DATA2 to server. DATA2 size is bigger than MSS, and DATA2 will be fragmented into DATA2_1, DATA2_2. As the packets will be handled by the IP layer, so the time that each packet arrives at server might not be the same as that when the client sends them.

So I think the sequence of packets' arriving might be the following:

1. DATA1 DATA2_1, DATA2_2
2. DATA1, DATA2_1, DATA2_2
3. DATA1, DATA2_2, DATA2_1

In the first case, the server receives DATA1 and DATA2_1 in one tcp packet and then another packet contains DATA2_2 arrives.

In the second case, the server receives DATA1, DATA2_1 and DATA2_2 in three packets.

In the third case, the server first receives DATA2_2 and then DATA2_1.

My question:

Is the third case possible?

If yes, it disobeys that TCP is a stream protocol, and stream protocol should be ordered. And even this does not break the stream rule, how to handle this scenario?

If no, how TCP makes the disordered packets into its original order?

Answer 1

It is possible to receive that sequence over the network, however the TCP implementation will hide that detail from your application and only feed the data to you in stream order. (In fact since fragmentation happens at the IP layer it won't even be shown to the TCP layer until the second part has arrived also)

The fact that received packets have to be held in a buffer even after receiving them in some cases like this is why you will see people referring to UDP as better for lower latency applications: you can receive datagrams out of order with UDP and it's up to your application to figure out how to deal with that possibility.

Answer 2

Is the third case possible.

Yes, of course.

If so, it disobeys that TCP is a stream protocol ...

No it doesn't.

Your cases concern arrival of IP packets into a host. TCP being a stream protocol is about delivery of data into an application.

The packet fragments get reassembled in the correct order by the IP layer, and the packets get reassembled into segments in the correct order by TCP, and the now correctly ordered data stream is delivered to the application.