1

There might be something simple that I'm missing, but I just can't understand how related TCP segments are identified.

So let's say I want to send 2000 bytes using TCP with an MSS of 1500 bytes. I just do a send operation, and TCP segments each operation into two packets of 1500 bytes and 500 bytes. How does the reassembly mechanism know that these two packets are supposed to be reassembled, and not just two different packets of sizes 1500 and 500? If I'm not mistaken, all flags and sequence numbers will be exactly the same.

Does TCP actually differentiate between these two cases, or does this just depend on the receiving application saying how many bytes it wants to receive?

Edit: It seems the question is not very clear, so I'll try to clarify it more.

If I wrote an application that looks something like:

send (2000)

and another application that looks like:

send (1500)
send (500)

and trace the TCP packets using something like Wireshark, in both cases I will see two packets from the same source to the same destination, and they would both have the same data length. The first packet will have a relative sequence number of 1, and the second packet will have a relative sequence number of 1501.

My question is: Looking at the traces of the two TCP packets, is there something that can identify which application I used? How does the receiving side know whether these two packets are related to each other and need to be reassembled?

Improve this question
3
  • TCP can only send MSS-sized segments with MSS = MTU - IP header size - TCP header size.
    – Zac67 ♦
    Apr 13 at 14:20
  • 1
    @Zac67 I edited the question to use MSS instead of MTU
    – Etchy
    Apr 13 at 15:12
  • small addendum to Zac's answer: (1) socket is identified by a 5 tuple <src ip, src port, dst ip, dst port, proto>, proto for TCP is always TCP. Packets are first attributed to sockets based on these values, then reassembly happens. (2) first 1024 ports are well known ports, so if those ports are present, you know what type of application it likely is (not the exact application though).
    – Effie
    Apr 13 at 19:30

2 Answers 2

Reset to default
1

Does TCP actually differentiate between these two cases, or does this just depend on the receiving application saying how many bytes it wants to receive?

There are no two cases. Each socket connection uses it's own, unambiguous sequence numbering (per direction). There's nothing to guess or interpret.

Looking at the traces of the two TCP packets, is there something that can identify which application I used?

No, generally not. TCP provides arbitrary-length streams/pipes for use by an application. It has no notion of that application however.

The application may identify itself on the application layer (e.g. a web browser by the user-agent header) but protocols above the transport layer are off topic here.

How does the receiving side know whether these two packets are related to each other and need to be reassembled?

Since TCP provides its base service as a stream socket, it sends both cases in the same way (assuming there's no/very little pause between the 1500 and 500 byte chunks): it fills a segment up to the maximum segment size and then passes it to IP for host-level transport.

With an MSS of e.g. 1200 bytes, it sends a single chunk of 2000 bytes as two segments of 1200 and 800 bytes. Two chunks of 1500 and 500 bytes sent directly following each other are sent in the exact same way.

Additionally, TCP mostly hides the data segmentation from the application - any data is passed on as a data stream. The application cannot rely on pauses that may or may not occur within the stream to mean anything. Instead, it's the application-layer protocol's task to make sense of the streamed data - with dedicated, secondary TCP channels (e.g. FTP), headers and offsets (e.g. HTTP), XML-style encapsulation or by any other means.

Improve this answer
2

If I'm not mistaken, all flags and sequence numbers will be exactly the same.

You are mistaken. TCP is a stream-oriented protocol, and an application sends an arbitrary amount of data, and TCP segments it with unique information in the header of each segment. For example:

The sequence number of the first data octet in this segment (except when the SYN flag is set). If SYN is set, the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1.

In your example of 2000 octets being divided into two segments, each segment will have a sequence number for the segment it is, not the sequence number of only the first segment.

Refer to the current TCP definition, RFC 9293, Transmission Control Protocol (TCP).

Improve this answer
10
  • That's actually what I meant. So whether I do "send 2000" or "send 1500 bytes, then send 500 bytes", in both cases the sequence number of the first one will be ISN+1 and the second one will be ISN+1501, is that correct? If yes, then how to do you differentiate between both cases?
    – Etchy
    Apr 13 at 14:20
  • @Etchy Any socket connection (same source&destination IPs, same source&destination ports) uses unique sequence numbering per direction. Duplication sequence numbers are regarded as duplicate received segments or, when completely outside the window, cause the connection to be reset.
    – Zac67 ♦
    Apr 13 at 14:25
  • @Zac67 I am not talking about duplicate sequence numbers. I am talking about differentiating between two separate cases
    – Etchy
    Apr 13 at 14:43
  • 1
    @Etchy, I think you are missing the part about the initial sequence number being a random 32-bit number. You cannot have two connections using the same source and destination IP and TCP addresses (the connection identifier), and unlikely that two connections would share starting sequence numbers
    – Ron Maupin ♦
    Apr 13 at 14:52
  • 1
    @Etchy, An application gets a port number, and no other application can use that port number. Even the same application creating a second connection must use a different port number for the second connection.
    – Ron Maupin ♦
    Apr 13 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.