【My Study Note】Dissection of a TCP Segment
Dissection of a TCP Segment
Just like how an Ethernet frame encapsulates an IP datagram, an IP datagram encapsulates a TCP segment. Remember that an Ethernet frame has a payload section which is really just the entire contents of an IP datagram.
Remember also that an IP datagram has a payload section and this is made up of what’s known as a TCP segment.
A TCP segment is made up of a TCP header and a data section. This data section, as you might guess, is just another payload area for where the application layer places its data.
A TCP header itself is split into lots of fields containing lots of information.
TCP Header
Source and Destination Port
The destination port is the port of the service the traffic is intended for.
A source port is a high-numbered port chosen from a special section of ports known as ephemeral ports.
WHy do we need Source Ports?
You know how a destination port, say port 80, is needed to make sure traffic reaches a web server running on a certain IP? Similarly, a source port is needed so that when the web server replies, the computer making the original request can send this data to the program that was actually requesting it.
It is in this way that when it web server responds to your requests to view a webpage that this response gets received by your web browser and not your word processor.
Sequence Number
This is a 32-bit number that’s used to keep track of where in a sequence of TCP segments this one is expected to be.
Lower on our protocol stack, there are limits to the total size of what we send across the wire. In Ethernet frame, it’s usually limited in size to 1,518 bytes, but we usually need to send way more data than that.
At the transport layer, TCP splits all of this data up into many segments. The sequence number in a header is used to keep track of which segment out of many this particular segment might be.
Acknowledgment Number
This is a lot like the sequence number. The acknowledgment number is the number of the next expected segment. In very simple language, a sequence number of one and an acknowledgement number of two could be read as this is segment one, expect segment two next.
Header Length
The data offset field is a four-bit number that communicates how long the TCP header for this segment is. This is so that the receiving network device understands where the actual data payload begins.
Control Flags
This is six bits and is reserved for the six TCP control flags.
Window
This is a 16-bit number known as the TCP window. A TCP window specifies the range of sequence numbers that might be sent before an acknowledgement is required.
TCP is a protocol that’s super reliant on acknowledgements. This is done in order to make sure that all expected data is actually being received and that the sending device doesn’t waste time sending data that isn’t being received.
CheckSum
This is a 16-bit checksum. It operates just like the checksum fields at the IP and Ethernet level.
Once all of this segment has been ingested by a recipient, the checksum is calculated across the entire segment and is compared with the checksum in the header to make sure that there was no data lost or corrupted along the way.
Urgent
The Urgent pointer field is used in conjunction with one of the TCP control flags to point out particular segments that might be more important than others.
This is a feature of TCP that hasn’t really ever seen adoption and you’ll probably never find it in modern networking. Even so, it’s important to know what all sections of the TCP header are.
Option
This is the options field. Like the urgent pointer field, this is rarely used in the real world, but it’s sometimes used for more complicated flow control protocols.
Padding
This is the padding which is just a sequence of zeros to ensure that the data payload section begins at the expected location.