Transmission Control Protocol (TCP) is a network communications protocol that governs communications on the transport layer of networked devices. It accounts for the majority of common internet data transfer (R) and comes with many attractive features like Reliable Data Protocol (RDP).
TCP was outlined in the 1981 RFC703 (R) and has been updated considerably over time to include many new features, extensions, and considerations for evolved networking needs (R). Things like Slow Start, Congestion Avoidance, Reliable Data Protocol, and the TCP Three-Way Handshake are all parts of TCP that make it the go-to choice for networked applications around the world.
TCP is considered a reliable transport protocol not only because it establishes a connection before sending data but also because the receipt of data is acknowledged. Put simply; TCP allows senders to ensure the data will be received and, if any data corruption or loss occurs, which parts of the data to re-transmit.
- Client-Server Model
- TCP Sockets
- Three-Way Handshake
- Sequence Numbers
- Header Format
TCP is a connection-based protocol facilitating the communication between two, and only two, network end systems. TCP does not support multicasting (one end system communicating with many over the same connection) and relies on point-to-point connections. One end system can service many requests but each is addressed individually.
Network communications ultimately take place between different host end systems. The host initiating the connection is termed the client process whereas the other accepting host is termed the server process. Ultimately, both the TCP client and TCP server processes are host systems but there are some subtle distinctions between the two that make separating them practically.
Client – creates a socket and is (generally) automatically assigned a port by the transport layer protocol. This socket is then instructed to connect to a remote host on a given port. For example:
www.example.com:80 would connect to
port 80 at the remote host
www.example.com. Note: a domain name service would resolve
www.example.com into a numerical IP address before an actual connection request is sent.
Server – creates a socket on an explicitly defined port, generally selected from a list of well-known ports in accord with expected connection protocols. For example, a web server might open a socket on
port 80 to listen for incoming HTTP requests. Another difference in server sockets is that after creation they enter a listen to a state where all they do is listen for incoming client connection requests.
Sockets are software implementations of connections between network hosts. They facilitate the transmission of data packets from the application layer to the transport layer, and across the network. Sockets are created with the following four fields:
source_ip source_port destination_ip destination_port
Depending on which transport-layer protocol is being used (TCP vs. UDP) the source_ip and source_port fields may not be immediately encapsulated in transport layer datagrams. In such cases, as is common in UDP, application-layer implementation is required to address return packets to the client. For example, this is done in java via the following:
// Create buffer to receive data byte buffer = new byte; // Create Server Socket on Port 12345 DatagramSocket socket = new DatagramSocket(12345); // Create new DatagramPacket object, receive socket data DatagramPacket packet = new DatagramPacket(buffer, buffer.length); socket.receive(packet); // Get sender information from received packet InetAddress address = packet.getAddress(); int port = packet.getPort();
As odd as it may seem to include UDP-oriented code in an article about TCP, the last two lines of the above code illustrate how a UDP server application would access sender information in preparation for a response. In TCP, this information is available directly from the packet header provided by the transport layer.
In UDP, a new socket has to be created for every transmission, in which return information from the previously-received transmission is used. That means UDP requires a new connection for every network transmission. This shortcoming is one of the main reasons TCP has become the predominant means of globally networked communication.
Packets (a.k.a Datagrams)
The original outline of Internet Protocol made by RFC791 for DARPA outlined the need for network-transported data to be fragmented (R). This key consideration for IP protocol was summarized as follows:
Fragmentation of an internet datagram is necessary when it originates in a local net that allows a large packet size and must traverse a local net that limits packets to a smaller size to reach its destination.
This “fragmentation” protocol relies on sending and receiving applications to disassemble and reassemble amounts of data that exceed the maximum amount of single-part transferrable data.
These fragmented groupings are called datagrams and require additional data to be transferred to ensure proper order and completeness upon receipt and re-assembly. This is where headers come into play.
[alert type=red ]Note: The term “datagram” is synonymous with “packet.” However, in practice, datagram is commonly used in the context of UDP protocols whereas packet is more common in discussion related to TCP.[/alert]
TCP Header Format
The TCP header consists of several unique parts that each work in concert to support the concept of reliable data transfer built into TCP. Some fields bear more importance, such as the port declarations, sequence number, and checksum, while other such as the PSH flag, padding, and urgent pointer is more dynamic and not necessarily vital to every transmission.
The following parts make up the TCP packet header:
- Source Port (16 Bits)
- Destination Port – 16bits
- Sequence Number (32 – Bits)
- The sequence number
- Acknowledgment Number – 32 bits
- Data Offset – 4 Bits
- Reserved – 6 Bits
- Control Bits – 6 Bits (1-bit each) a.k.a flag field
- URG – Urgent Pointer
- ACK – Acknowledgement
- PSH – Push Function
- RST – Connection Reset
- SYN – Synchronize Sequence Numbers
- FIN – Indicates no more sender data
- Window – 16 bits
- Checksum – 16 bits
- Urgent Pointer – 16 bits
- Options – Variable – ends on an 8-bit boundary
- Padding – Variable – used to finish the line to a 32-bit boundary
- Data – Variable
TCP Segment Flags
Flags are single-bit values used to indicate true/false status of certain fields. These values are used to instruct. Defined in RFC793 (R).
SYN – Indicates a synchronization request, used in the first step of the TCP 3-way handshake to establish a connection between two network end systems. Carried by the first packet from the sender and the first response packet by the receiver.
ACK – Indicates a response is in the Acknowledgement of a successfully-received data segment. Used in the second and third steps of the TCP 3-way handshake for the server to acknowledge the request and the sender to acknowledge the receiver’s message.
PSH – Push flag indicating whether a segment of data should be pushed to the receiver’s application layer immediately. Has a direct relationship with the receiver buffer such that, when indicated, the buffer is returned even if not full. Likewise, the sender’s transport layer immediately a segment marked PSH to the network layer.
URG – Urgent flag indicating the urgent field data is to be processed before other data and forwarded to the application layer immediately. The receiver will be notified when all urgent data has been received. The URG field differs from PSH in that it breaks data sequence.
RST – Reset flag indicating that a host is not prepared to handle a received packet and for the sender to not retransmit. Could happen if a sender transmitted a packet to an incorrect port.
FIN – This flag is set by either sender or receiver to indicate the end of data segment transmission. The FIN bit starts a tw0-stage process in which the FIN initiate waits for an ACK from the recipient, and followup FIN, and then returns a final ACK.
Note: The URG, PSH, and urgent pointer TCP header fields aren’t commonly used
TCP Sequence Numbers
A core underpinning of TCP’s RDP service is the ability to keep track of which packets have been delivered, which packets need to be retransmitted, and which are next in line. TCP uses a combination of Acknowledgements and sequence numbers to accomplish this.
Sequence numbers correspond to individual bytes in transmission, rather than segments. For example, in the illustration below, a file containing 3,000 bytes of data is transmitted with a Maximum Segment Size (MSS) of 1,000 bytes. TCP protocol will construct three 1,000-byte segments from this data.
Sequence numbers found in TCP headers will correspond to the first byte within a segment, not the first segment. Sequence numbers are byte-offset pairs such that
SEQ-N = N * MSS. In the example above, the following sequence numbers have been calculated:
SEQ0 = 0 * 1000 = 0 SEQ1 = 1 * 1000 = 1000 SEQ2 = 2 * 1000 = 2000
TCP acknowledges receipt on a byte-level such that, still considering the illustration above, Host A could receive bytes 0-499, not receive bytes 500-999, and then receive bytes 1000-1999 and 2000-2999 successfully. When this happens, TCP correctly detects data loss and takes measures to recover that loss.
Cumulative Sequence Acknowledgement
After receiving the above packets, with bytes 500-999 missing, the subsequence transmission from the receiving host would have an ACK of 500. This indicates that everything up to this SEQ number has been received. This illustrates the cumulative acknowledgment attribute of TCP protocol.
TCP RFCs do not specify how to handle segments that have been received after missing data. In many cases, the use of a buffer to temporarily hold that data until retransmission of previous data may be used. Ultimately, such consideration is left to application-level implementations.
Initial Sequence Number Assignment
The first step of client-side TCP transmission involves the SYN bit being set to one, indicating that no application data is being transmitted, and a random value chosen for the initial sequence number. Basically, this is the initiating host’s way of saying “I’m going to start counting sequences from this number.”
Careful consideration must be given to how initial sequence numbers are chosen. Using predictive numbering schemes leaves TCP transmissions open to vulnerabilities. RFC6528 formerly noted shortcomings in previous attempts at initial sequence number generation, and outlined the following algorithm for a more secure generation (R):
ISN = M + F(local-ip, localport, remote-ip, remoteport, secretkey)
In the equation above, M is a timer that is incremented every 4 microseconds, and F is a pseudorandom generator function where the secret key is generating using the MD5 hashing algorithm. RFC6528 notes that the initial sequence number is no more secure than the
secret_key and still vulnerable if outside attackers should be aware of said key.
Remote Host SEQ Acknowledgement
After the initial SYN request containing the randomly-generated SEQ number, TCP protocol dictates that the remote (receiving) host replies with an ACK and an initial server sequence number, equivalent to the initial client SEQ + 1. This response is referred to as the SYN_ACK segment and precipitates buffer and resource allocation on the server-side in anticipation of client connection and data transmission.
Reliable Data Protocol (RDP) – 3.4
The attractiveness of TCP for many network Applications can be found in it’s Reliable Data Protocol (RDP). This part of the TCP specification provides application-level support to ensure the reliable transfer of data between networked machines.
Persistent vs. Non-Persistent HTTP Protocols
TCP/IP protocol is the underpinning of modern HTTP protocols. As such, it can facilitate application-level directives such as persistent vs. non-persistent HTTP connections.
TCP represents an evolution in HTTP protocol that allows persistent connections. These types of data interchanges are essential to the modern Internet experience and help reduce wait times between HTTP requests.
With this support comes a complex system of accountancy to provide data validation, reliable transport, and retransmissions when needed. Sequences such as the TCP 3-Way Handshake have become almost infamous in their characterization of this HTTP protocol—they remain essential to TCP’s underpinnings nonetheless.
Another essential facet of TCP transmissions is the header in which data is encapsulated. The diagram presented here illustrates the relative size, in bits, of each part of the TCP header. This feature is used to support the transmission routing, data acknowledgment and validation, and passing to the application layer.