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).
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.
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.
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.
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.
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.
Figure 1 – TCP Header Model
Source: https://www.lifewire.com/tcp-headers-and-udp-headers-explained-817970
Figure 2 – IP Packet with TCP Header and HTTP Payload
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.
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.
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.
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:
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.
Figure 4 – TCP Pseudo Header
Source: http://www.tcpipguide.com/free/t_TCPChecksumCalculationandtheTCPPseudoHeader-2.htm
Figure 5 – TCP Pseudo Header
Source: http://www.tcpipguide.com/free/t_TCPChecksumCalculationandtheTCPPseudoHeader-2.htm
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.
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.
Figure 6 – Constructed IP Packet with Missing TCP checksum
>>> packet.show2()
Figure 7 – Constructed IP Packet with Computed TCP checksum 0xeb23
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.