Blog

TCP header, TCP header size, TCP checksum mechanism, TCP header structure, options, and format

The Mail Analogy: Understanding TCP Headers and Reliable Delivery

The internet seamlessly transfers data, but how does it ensure everything arrives correctly? The Internet Protocol (IP) plays a crucial role, acting like the clear address written on the outer envelope of a mail package. This address guides data packets towards their destination. However, just like a physical envelope needs more than just an address for guaranteed delivery, IP needs some extra help from another protocol – the Transmission Control Protocol (TCP).

Encapsulating Messages: More Than Just Addresses

Imagine you’re in Miami, sending a puzzle of the Golden Gate Bridge to your friend Bob in Palo Alto. You break the picture into puzzle blocks, putting them in separate envelopes. But to help Bob reconstruct the image, you label each envelope with specific instructions. These details, written on the inner envelopes, are crucial for Bob but not needed by the post offices. They represent the TCP header that Bob uses to assemble the pieces of the puzzle into an original image.

To ensure delivery, letters must be placed in an outer envelope with Bob’s address. When everything is ready, you can send the letters one by one to Bob.

Routers: Post Office Mail Sorting

When data is transported over the Internet, the data passes through routers, similar to post offices. Routers use IP addresses on the inner envelopes to route and forward packets efficiently. However, they don’t need to look inside TCP envelopes; they rely only on the IP address to route packets to Bob.

Delivery at the Doorstep: When TCP Takes Over

When the packets (letters) arrive at Bob, the TCP protocol steps in. Bob reads the IP addresses on the outer envelopes and checks that the letters are addressed to him. If so, he discards the inner envelope and reads the TCP envelopes to reconstruct the puzzle blocks into the original image.

Why TCP? Ensuring Order and Reliability

But what if some letters are missing or arrive in the wrong order? Using TCP data, Bob can determine exactly which pieces of the puzzle were lost during transmission and ask you to resend a particular block of the puzzle.

Additionally, Bob understands that if a letter arrives out of order, he has to assemble them in the correct order. This is where TCP excels. It serves as a reliable mail carrier, guaranteeing the timely delivery of messages, verifying that no pieces (lost packets) are missing, and thus allowing Bob to accurately reconstruct the image.

TCP Header Size and Structure

As illustrated in Figure 1, The entire TCP header can be either the minimum size of 20 bytes (without options) or can grow up to a maximum of 60 bytes when optional fields are included. Optional data fields, ranging from 0 bytes (no options) to up to 40 bytes in size, can be added to the header for extended functionalities.

  • Source Port (16 bits): Identifies the application on the sending machine initiating the communication.
  • Destination Port (16 bits): Identifies the application on the receiving machine intended for the data.
  • Sequence Number (32 bits): Tracks the order of bytes sent within a TCP connection, ensuring data arrives in the correct sequence.
  • Acknowledgment Number (32 bits): Used by the receiver to acknowledge received data and request the next sequence of bytes.
  • TCP Data offset or Header Length (4 bits): Indicates the length of the TCP header in 32-bit words (minimum 5 words or 20 Bytes, maximum 15 words or 60 Bytes). This directly affects the overall header size.
  • Reserved data (3 bits): Reserved data in TCP headers always has a value of zero.
  • Control Flags (up to 9 bits): These flags signal different actions like starting a connection, ending a connection, acknowledging data, indicating urgent data, or controlling the flow of information.
  • Window Size (16 bits): Specifies the amount of data (in bytes) the receiver is willing to accept without further acknowledgment. Built-in algorithms dynamically adjust the window size for optimal data transfer.
  • TCP Checksum (16 bits): Used for error detection in the header itself to ensure data integrity during transmission.
  • Urgent Pointer (16 bits): (Optional within the 20 bytes) Used to indicate if there is urgent data following the TCP header that needs immediate processing.
  • TCP optional data (0 to 40 bytes): Usages of optional TCP data include support for special acknowledgment and window scaling algorithms.
Figure 2 depicts a captured packet with a TCP header highlighted in a large red frame. The size of the TCP header is determined by the Header Length parameter, also known as Data Offset. In this example, the header size is 32 bytes, indicating 20 bytes for the “base” header and 12 bytes of optional data.

Figure 2 – IP Packet with TCP Header and HTTP Payload

The entire TCP segment, which includes both the header and the data it carries, is 160 bytes long. This segment length is calculated as the sum of the TCP header size (32 bytes) and the payload size (data):
TCP Header: 32 bytes
Payload (HTTP Data): 128 bytes

The IP header has a fixed size of 20 bytes. Therefore, the total size of the IP packet is the sum of the IP header, TCP header, and payload:

IP Header: 20 bytes
TCP Header: 32 bytes
Payload (HTTP Data): 128 bytes
Total IP Packet Size: 20 bytes + 32 bytes + 128 bytes = 180 bytes

Note: A TCP segment is a chunk of data transmitted over a network connection. It consists of two parts: a TCP header containing control information and a payload carrying the actual data from the application layer.

The payload in this specific TCP segment carries data from the upper layer, which is typically the application layer. In this case, the application layer protocol is HTTP, and the data represents an HTTP response with a status code of 304 (Not Modified).

An HTTP response with a 304 status code indicates that the requested resource has not been modified since the client last accessed it. This response allows the client to utilize the cached version of the resource instead of downloading it again, improving efficiency.

TCP Options: Tailoring Transmission for Enhanced Efficiency

The options field is optional because it is not used in every packet. Instead, it is employed selectively, such as in SYN packets or during periods of network congestion. This selective use ensures that the options field does not introduce unnecessary overhead but remains available for specific scenarios where optimizations are beneficial.

The SYN packet sent from the client to the web browser is depicted in Figure 3. The parameter Maximum Segment size (MSS) in the optional field of the TCP header tells the server that the client is accepting a packet with MSS 1460 bytes in a single TCP segment. MSS does not include the TCP header or the IP header. it dictates the maximum size of the “data” part or payload of the packet.

Figure 3 – SYN Packet with Optional Field Maximum Segment Size

By utilizing the options field within the TCP header, TCP developers have been able to adapt and optimize the protocol to meet the evolving needs of the Internet without requiring a complete overhaul and universal deployment of new TCP versions.

TCP Checksum Mechanism

The TCP checksum, a built-in inspector within the TCP header, safeguards data integrity during network travel. This critical functionality is achieved through a specific calculation process:

  1. Creating the TCP Pseudo Header: Before calculating the TCP checksum, the sending host constructs a 12-byte TCP pseudo-header. This pseudo header includes fields from both the IP header and the TCP header. It typically includes the source IP address (4 bytes), destination IP address (4 bytes), 1-byte protocol number (indicating TCP), reserved byte (8 bits of zeroes), the TCP segment length (including TCP header and payload).

    The pseudo-header is formed to ensure that changes in the IP header or TCP header can be detected. Refer to Figure 4 for a visual representation of the pseudo-header.

  1. Checksum Calculation: The sending host then computes the checksum by combining the pseudo-header with the TCP header and the TCP data (payload). The actual checksum field in the TCP header is set to 0 during this calculation. Please refer to Figure 5 for a depiction of the TCP checksum calculation process.
  1. Inserting the Checksum: Once the checksum is calculated, it is placed into the Checksum field of the TCP header.
  1. Transmission: The TCP segment, including the TCP header with the checksum, is then sent to the destination host.
  1. Validation at the Receiver: Upon receiving the TCP segment, the receiving TCP software repeats the same process. It constructs the TCP pseudo-header using the information from the IP header and TCP header of the received segment. Then, it calculates the checksum by combining the pseudo-header with the TCP header and payload, setting the Checksum field in the TCP header to 0 during calculation.
  1. Comparison: If the calculated checksum at the receiver matches the checksum value placed in the TCP header by the sender, the segment is considered valid. However, if there’s a mismatch, indicating a potential error in transit, the segment is typically discarded.

By performing this checksum validation process, TCP ensures that errors introduced during transmission, such as data corruption or manipulation of headers, can be detected and discarded, thereby maintaining the integrity and reliability of data communication over the network.

Calculating TCP checksum with Scapy

Now that we comprehend the mechanism of calculating the TCP checksum, we can proceed to demonstrate how to recreate it and identify the fields from the IP header and TCP segment involved in this process. To accomplish this, we will leverage Scapy, an interactive packet manipulation library written in Python. Let’s consider the packet depicted in Figure 2 from the file cern-packet.zip, where the checksum is indicated as 0xeb23.

We will employ the following command to extract parameters from the IP and TCP headers along with the actual HTTP payload:

>>> from scapy.all import *

packet =  IP(proto="tcp", len=180, src="188.184.100.182", dst="192.168.88.223")/TCP(sport="http", dport=47566, seq=2381753352, ack=2093000791, dataofs=8, reserved=0, flags="PA", window=235, urgptr=0, options=[('NOP', None), ('NOP', None), ('Timestamp', (2697522340, 1682671698))])/'HTTP/1.1 304 Not Modified\r\nDate: Wed, 13 Mar 2024 07:56:28 GMT\r\nServer: Apache\r\nConnection: close\r\nETag: "286-4f1aadb3105c0"\r\n\r\n'

To confirm the absence of the TCP checksum in the packet, simply enter the following command:

>>> packet.show()

As shown in Figure 6, the checksum is missing from the TCP header because we constructed the packet without it. The receiving host would naturally discard this packet because the computed checksum would not match the checksum in the received TCP segment.

As shown in Figure 6, the checksum is missing from the TCP header because we constructed the packet without it. The receiving host would naturally discard this packet because the computed checksum would not match the checksum in the received TCP segment.

Figure 6 – Constructed IP Packet with Missing TCP checksum

To have Scapy compute the checksum for the packet and display only the TCP layer with the computed checksum, simply enter the following command:
>>> packet.show2()

Figure 7 – Constructed IP Packet with Computed TCP checksum 0xeb23

Conclusion

In this article we’ve delved into the inner workings of TCP headers, the guardians of reliable data transmission across the web. We explored the concept using the analogy of sending a puzzle, highlighting TCP’s role in ensuring all pieces arrive in the correct order and without errors.

The TCP header contains vital information for data delivery, like source/destination ports, sequence numbers, and control flags. Optional fields provide additional functionalities. TCP checksum mechanism is a built-in inspector that safeguards data by calculating a checksum over the header and payload, guaranteeing data arrives unaltered. TCP ensures data arrives in order and without errors by acknowledging received packets and requesting missing pieces.

While TCP provides a robust foundation, proactive network monitoring is essential for maintaining optimal performance and security. Noction Flow Analyzer (NFA) empowers network administrators to identify anomalies, optimize performance and troubleshoot issues. By leveraging NFA software, you can complement the strengths of TCP and ensure a healthy, reliable, and secure network environment.