This might seem weird, but I’m a little confused, and I’d like an explanation, and perhaps an of the whole process of TCP data transfer from when there is a stream of data that needs to be sent.
I’m currently reading TCP documentation (RFC 9293), and in [Section 3.4](https://www.rfc-editor.org/rfc/rfc9293.html#name-sequence-numbers) it says:
>A fundamental notion in the design is that **every octet of data sent over a TCP connection has a sequence number**
So far, so good. In [Section 3.7](https://www.rfc-editor.org/rfc/rfc9293.html#name-segmentation) it says:
>The term “segmentation” refers to the activity TCP performs when ingesting a stream of bytes from a sending application and packetizing that stream of bytes into TCP segments.
The section later states that the segment’s size varies, but cannot exceed the [maximum segment size](https://www.rfc-editor.org/rfc/rfc9293.html#name-maximum-segment-size-option). I was confused and wondered if the segments are the octets, so I googled which is which. [RFC 879](https://www.ietf.org/rfc/rfc0879.txt) states that:
>The rule must match the default case. If the TCP Maximum Segment Size option is not transmitted then the data sender is allowed to send IP datagrams of maximum size (576) with a minimum IP header (20) and a minimum TCP header (20) and thereby be able to stuff **536 octets** of data into **each TCP segment**.
Meaning that octets go into segments, and given that octets have sequence numbers, then each segment would have multiple sequence numbers for each octet they send. However, googling “do TCP segments have sequential numbers” gives me:
>**At offset 32 into the TCP header is the sequence number**. The sequence number is a counter used to keep track of every byte sent outward by a host. If a TCP packet contains 1400 bytes of data, then the sequence number will be increased by 1400 after the packet is transmitted.
By [IBM](https://www.ibm.com/docs/en/zos-basic-skills?topic=4-transmission-control-protocol-tcp), meaning that the segments themselves also have their own sequence numbers?
My current understanding of the whole process is this:
1. A stream of data needs to be sent
2. TCP divides them into octets
3. TCP then packages them into segments
4. Segments get sequence numbers
5. Segments are sent sequentially.
Is my understanding correct? Please write an if possible.
In: 1
“Octet” is basically another word for “byte”. It literally means “8 thingies that are related”. When a large amount of data is sent through the TCP/IP stack, it is indeed chopped up into segments of appropriate size. There isn’t much “division into octets” because that’s how the driver *gets* the data: usually as an array of bytes in the memory, straight from the OS or whatever program.
> every octet of data sent over a TCP connection has a sequence number
Taken literally, that would be stupid and double the size of the message for no purpose. The sequence number is a feature of one whole TCP segment, and marks the number of the first byte it contains. The rest of the bytes in the packet follow sequentially, so there is no need to explicitly attach a number to each, the sequence number and the length together identify exactly where the chunk of data in question should go when reassembling the message. There is no such thing as a partial packet loss, if something is fucky with the packet the entire thing is requested to be re-sent.
Latest Answers