An Overview of the Transmission Control Protocol

Posted by Jarren Long at 2016-11-25 11:45:54

The Transmission Control Protocol (TCP for short) was published in January of 1980 as the first protocol designed to work with the Internet Protocol (IP) defined in RFC 791 (later STD 5) for packet-switched networks. It is not uncommon to see TCP and IP mentioned synonymously, as they are designed to work side-by-side within a network. The Transmission Control Protocol was developed by a team of engineers at the Information Sciences Institute from the University of Southern California for the Defense Advanced Research Projects Agency (DARPA) in response to their need for a data transmission protocol that would ensure network reliability and availability. In September of 1981, the 8th and final version of TCP was published as RFC 793, which later became known as STD 7. While TCP has had a few extensions added over the years, the protocol has remained essentially unchanged since it was first published as STD 7.

The Transmission Control Protocol was designed to operate at Layer 4 in the OSI network model, right on top of IP at Layer 3. As its name may indicate, TCP is designed for controlling data transmissions between devices connected to an IP network. While IP is responsible for delivering data from one node to another in a generic fashion, TCP is responsible for making sure that the data that IP has to send is properly broken into packets, sent in the right order, and received without error on the other side of the connection. TCP accomplishes this by providing an array of control and validation mechanisms for network devices to use to ensure that data is transmitted correctly from device to device as efficiently as possible.

By using TCP with IP, network engineers are able to implement a connection oriented protocol, meaning that once a connection is opened to a remote network device, it will remain open until both the client and the server have finished sending data, and agree to close. What does this mean for the average user? While the average user will not ever know about TCP and what it does, every user would understand how important it is if it was unavailable. TCP provides the core reliability and quality of service features available over packet switched networks. Most of these features are not available in other publicly available Transport-layer specifications, which are generally much more susceptible to lost and corrupt data during transmissions.

Losing transmitted data en route is a relatively common occurrence in most networks, especially when the data has to travel through multiple devices or across great distances. When using TCP, the sending and receiving devices have access to specific features of the TCP protocol that allow for lost and corrupt data packets to be detected, and later retransmitted to correct the problem. While the specifics of the flow and congestion control mechanisms are beyond the scope of this document, it should be noted that the culmination of mechanisms and algorithms lend themselves to "error-free delivery." From an application and user's point of view, this means that 100% of the data sent across a network will be delivered to its destination.

Anyone who has ever attempted to read RFC 793 will tell you two things: The reading is hard, and the protocol is easy. "Request for Comments" documents are publicly available for use and download, and are maintained by the Internet Engineering Task Force (IETF), the governing agency for higher-lever protocols and specifications that are not defined by the Institute of Electrical and Electronic Engineers (IEEE), which handles lower/physical level specifications. The simplicity of the TCP protocol's data structure can be hard to decipher from the 85-page RFC, however it can be summarized as a single data structure (known as a "TCP Header") as represented below (written in C):


// This header goes inside of an IP header (which contains the
// source and destination IP address, along with a few other fields.)

typedef struct {
  unsigned short src_port;  // Source port, 16 bits
  unsigned short dest_port; // Destination port, 16 bits
  unsigned long seq_num;    // Sequence #, 32 bits
  unsigned long ack_num;    // Acknowledgment #, 32 bits
  unsigned short flags;     // 4 Data offset bits, 6 reserved bits,
  /* and the following 6 flag bits (in order):
  Bit 0 - Means that the "urg_ptr" field below is used
  Bit 1- Means that the "ack_num" field above is used in this packet
  Bit 2 - Triggers the Push function
  Bit 3 - Reset the connection
  Bit 4   "Sync" (SYN) - Synchronize sequence numbers
  Bit 5 - "Finish" (FIN), means that the sender is out of data to send
  */
  unsigned short window;    // The size of the transmission window
  unsigned short checksum;  // The packet's checksum
  unsigned short urg_ptr;   // This packet is Urgent!!! (Shouldn't use)
  unsigned short[] opts;    // Header Options
  unsigned short[] pad;     // Padding
  // The packet's actual data would come next
} TCP_HEADER_;

Each field represents a piece of information that the Transmission Control Protocol requires to operate properly while sending and receiving data. These fields are described as follows:

Field Description
Source Port The port that the TCP packet is originating from (i.e. 80=HTTP, 21=FTP ).
Destination Port The port that the TCP packet is destined to on the remote device.
Sequence Number The sequence number of this data packet. If the SYN flag is set, the sequence number is the initial sequence number, which can be predetermined or (preferably) randomly generated and agreed upon.
Acknowledge Number If the "ack_num" flag in the TCPHEADER is set, then this field is the next sequence number the sender is expecting to receive. Once a connection is opened, this is always sent.
Data Offset This field represents the size of the TCP packet's header, not including the size of the data it contains. This also represents the position in the data stream where the packet's data starts.
Reserved The TCP specification initially left 6 bits as reserved and unused, to be allocated later for extensions/customization of the TCP protocol.
Control Flags See comments in TCPHEADER structure above
Window Size The number of bytes the sender can accept (defaults to 1,460 bytes).
Packet Checksum STD 7 initially defined the checksum to be a 16-bit value that was calculated for every TCP packet by adding up all of the bytes and taking the ones-complement of the sum (a binary bit transformation operation). RFC 1146 later extended TCP to also allow for the use of 8-bit and 16-bit Fletcher's algorithm for calculating checksums.
Urgent Pointer The urgent pointer is a 16-bit value that references data in the TCP packet that has been deemed "urgent", in lesser words. It has been noted that this field is often incorrectly implemented and/or broken, and is rarely used.
Options TCP allows a variety of options to be transmitted at the end of the TCP header (before the packet data). These options are stored in a Tuple (a data structure that represents a value's type, length, and value).
Padding At the end of the TCP header, there is a block of padding bits that is used to add extra data to the header so that it is "aligned on an octet boundary," meaning that the size of the packet's header is a multiple of 8 bits.

The Transmission Control Protocol puts one (or more) of these headers on every scrap of data it receives from higher layers in the network stack before sending it down to the IP stack for distribution to the next hop device. Using these headers, the Transmission Control Protocol knows everything it needs to reassemble the data when the client receives it. Of course, the TCP client and server must first perform a few steps to open a connection between them. First, both the client and server will need to open up an Internet Socket in either passive or active mode. A socket is a mechanism for binding an application to a specific data stream associated with a network interface card, represented as an IP address and port number. Whichever device is playing the role of the server will be required to open their socket in passive mode, which tells the system to open the socket and wait for incoming connections. Conversely, the client device will need to open their socket in active mode and point the destination to the server device's IP after the server has opened its socket. At this time, the physical connection will be established, and TCP will negotiate the connection.

The Transmission Control Protocol uses a Three-Way Handshake exchange to initiate every new connection. When a client connects to the server's socket, the first packet it sends will have the SYN flag set, which will signal the server to synchronize sequence numbers with the client. When the synchronization is complete, the connection has been established and is ready for use. As TCP is a connection-oriented protocol, both the client and server may send and receive data at any time, however TCP leaves the communication synchronization for higher level drivers to manage. Regardless of which device is transmitting, both devices will follow the same basic process.

When data is sent from an application to the socket, the TCP driver will check the data for a variety of metrics, including size, options, and checksums. If the data is too large to fit inside of a single TCP header (which is often the case), the protocol will use its built-in data fragmentation techniques to distribute the data across multiple headers, updating the sequence numbers accordingly. Once the packets have been constructed from the data passed in, they are sent to the IP driver, where they are routed throughout the network. When the data reaches the destination device, the sending process will be reversed to decode the packets back into the original data that was sent. In the event that some data was lost or corrupt, the protocol will request the missing packets again, where they will be re-inserted into the received data stream upon successful arrival.

This process continues back and forth between the client and server for the lifetime of the TCP session. When both the client and server have decided that they have no more data to send, the connection termination process is initiated. This process uses the same Three-Way Handshake as the connection establishment, but sets the FIN (Finish) flag rather than the SYN (Sync) flag to denote the end of the connection. Once the server and the client have both acknowledged the Finish flag, the sockets can be closed and the communication session is complete.

While there are dozens more pages that could be written on the inner workings of the protocol, it detracts from the core point of TCP: simplicity. When the Transmission Control Protocol was drafted in the early 1980's, system resources were very limited, so the protocol was designed to be both small and simple, yet powerfully attractive for its reliable connection and scalability across an enormous collection of devices of all varieties. Today, TCP (along with IP) has become a "must-have" technology for every device wanting to connect to a public network, and is used as the de-facto backbone of the Internet as we know it.

While the Transmission Control Protocol is an excellent choice for almost every application, there are still a few instances when it may not be the most appropriate choice for the data being sent. Network devices that are required to send large amounts of data over short distances tend to run quite a bit slower over a TCP connection than a UDP (User Datagram Protocol) connection, which does not provide reliability or guaranteed delivery to reduce the protocol header's size, increasing usable bandwidth. Network game and FTP servers are excellent examples of devices that often benefit from using alternative protocols for data transmission.

Even the most popular underlying protocols in the world contain flaws, and TCP is no different. Since its inception in the 1980's, the Transmission Control Protocol has been susceptible to a variety of attack techniques that exploit flaws in the protocol's design, generally known as Denial of Service (DoS) attacks, thus named because the aftermath of the attacks is a denial of the target's services to legitimate network users. These attacks usually require that the aggressor has some knowledge about the target network, including legitimate IP addresses, and a rough idea of the network's design. By using a collection of tools and utilities, an attacker could craft malicious TCP packets and inject them into a real data connection to masquerade as a legitimate network device, either to interrupt services or gain access to a private network. While many solutions and workarounds have been proposed and implemented to reduce the commonality of these vulnerabilities, the problem is deeply integrated into the core structure of the protocol, and will therefore always be a threat.

To conclude, we have learned that the Transmission Control Protocol, albeit imperfect, is one of the essential components of a reliable packet switched Internet Protocol network. The simplicity of its design lends itself to its speed and efficiency by minimizing the excess overhead associated with other transport layer protocols, and the robustness of the protocol's features ensures it provides a consistent, reliable user experience across networks of any size. After nearly 25 years of faithful public service, the Transmission Control Protocol has stood the test of time as one of the true core components of the Internet as we know it, and is expected to be widely implemented and used for decades to come.

Bibliography:

Braden, R. and V. Jacobson. "RFC 1072." IETF Data Tracker. IETF, Oct 1988. Web. 28 Oct 2012. http://datatracker.ietf.org/doc/rfc1072/?include_text=1.

Gilbert, Howard. "Introduction To TCP/IP." PC Lube and Tune. Yale University, 02 1995. Web. 28 Oct 2012. http://www.yale.edu/pclt/COMM/TCPIP.HTM.

"Internet Protocol Suite." Internet Protocol Suite. 2012. http://en.wikipedia.org/wiki/Internet_protocol_suite.

Kessler, Gary. "An Overview of TCP/IP Protocols and the Internet." Gary Kessler Associates. N.p., 09 2010. Web. 28 Oct 2012. http://www.garykessler.net/library/tcpip.html.

Partridge, A. and J. Zweig. "RFC 1146." IETF Data Tracker. IETF, Mar 1990 Web. 28 Oct 2012. http://datatracker.ietf.org/doc/rfc1146/?include_text=1.

Parziale, Lydia. TCP/IP Tutorial and Technical Overview. 8th ed. IBM Corp., 2006. 149-170. eBook. http://www.redbooks.ibm.com/redbooks/pdfs/gg243376.pdf.

Postel, Jon, ed. "RFC 793." IETF Data Tracker. IETF, Sept 1981. Web. 28 Oct 2012. http://datatracker.ietf.org/doc/rfc793/?include_text=1.

Rouse, Margaret. "TCP." Search Networking. N.p., 01 2006. Web. 28 Oct 2012. http://searchnetworking.techtarget.com/definition/TCP.

Rouse, Margaret. "TCP/IP." Search Networking. N.p., 01 2008. Web. 28 Oct 2012. http://searchnetworking.techtarget.com/definition/TCP-IP.

"TCP/IP Suite." Protocols.com. N.p.. Web. 28 Oct 2012. <http://www.protocols.com/pbook/tcpip2.htm

"Transmission Control Protocol." Wikipedia. 2012. http://en.wikipedia.org/wiki/Transmission_Control_Protocol.