The Internet: Under the Hood, Part 4

Part 2 of this series took a look at the Link layer of the TCP/ IP model and Part 3 explored the Internet layer. This post will discuss the Transport layer and its two most prevalent protocols: TCP & UDP. This where things start to get really interesting for the web developer as these two protocols present critical engineering trade-offs.

With the ethernet and IP protocols now built into our networking mental model, we know how data is transmitted between hosts on different networks. But given that a host is likely running multiple process at any given time, how does the host know what to do with the message? Protocols at the Transport layer address this question by providing end-points for the communication needs of specific applications.

Wait, What's the Apartment Number???

Imagine for a second that you've written a letter (I know, bear with me) to your friend Andy who lives in an apartment in New York City. You know that Andy's street address is 217 West 57th Street, New York, NY. This towering skyscraper happens to be the tallest residential building in the world. How exactly is your letter going to navigate 98 stories and 179 units to ultimately find its way to Andy? The answer is simple: append the apartment number to the address on your letter!

With this example in mind, we can introduce the concept of a port which is simply an identifier for a specific process running on a host. A port, when combined with an IP address, can be thought of as a communication end-point, much like a street address combined with an apartment number is the end-point of a letter's journey. So, when an IP packet arrives at a host, a connection between hosts is established. Then, the transport protocol takes over and through the use of ports creates a connection between applications.

Tying this new information back into our mental model of PDUs and encapsulation, the source and destination port numbers are included in the Protocol Data Units (PDU) for the transport layer. The name, and exact structure, of these PDUs varies according to the Transport protocol used, but what they have in common is that they include these two pieces of information.

Use TCP for Serious Matters

The Transmission Control Protocol, or TCP, is the first of the two Transport layer protocols we'll look at today. TCP is a connection-oriented protocol which effectively creates a dedicated virtual connection for communication between a specific process running on one host and a specific process running on another host.

The PDU created by TCP is known as a segment. Some of the metadata included in the segment header includes:

• Checksum: this provides the error-detection aspect of TCP reliability, similar to the checksum provided by IP
• Sequence and Acknowledgement numbers: used together to provide for the other elements of TCP reliability such as in-order delivery, handling of data loss and handling duplication
• Window size: used in the flow control and congestion avoidance mechanisms (see below)

TCP uses the Sequence (SYN) and Acknowledgment (ACK) metadata in what's known as the three-way-handshake to establish its dedicated connection, a simplified version of which goes something like this:

1. Sender sends SYN segment to receiver
2. Receiver receives SYN segment, responds with SYN & ACK segments
3. Sender receives SYN, ACK segments, responds with ACK segment
4. Receiver receives ACK segment, connection is now established

Upon sending the ACK, the sender can immediately start sending application data. The receiver must wait until it has received the ACK before it can send any data back to the sender. One of the main reasons for this process is to synchronise (SYN) the sequence numbers that will be used during the connection.

The advantage of having a dedicated connection is that it allows for the implementation of more robust rules for managing things such as the order of messages, acknowledgements that messages had been received, retransmission of messages that weren't received, etc. In this way, TCP provides the abstraction of reliable network communication on top of an unreliable channel.

The reliability features of TCP are not without downside however as the mechanisms to implement them involve a lot of overhead as well as the issue of head-of-line-blocking. TCP tries to mitigate this overhead cost by using flow control and congestion avoidance to optimize performance, however if speed is of utmost importance in an application, another Transport layer protocol, UDP, might be the better choice.

UDP = All Gas No Brakes

Like TCP, the User Datagram Protocol (UDP) encapsulates the PDU from the Application layer and includes information about the source and destination ports in the header to facilitate app-to-app communication. The PDU produced by UDP is known as a datagram.

In contrast to TCP, UDP is a connection-less protocol and is often described in terms of the absence of the reliability features that constitute the TCP protocol. Notably, UDP does not:

• provide a guarantee of message delivery
• provide a guarantee of message delivery order
• provide built-in flow control or congestion avoidance mechanisms
• provide connection state tracking

By discarding the built-in reliability features of TCP, UDP provides a platform that prioritizes speed and flexibility. UDP is often used by video conferencing apps and multiplayer video games at the transport layer because users most often prefer a slightly lower quality experience (think glitches or an imperfectly rendered picture) as long as lag (think frozen frame) is kept to a minimum.

Note that UDP is often used as a 'base' template whereby software engineers can pick and choose which reliability features they need and then implement them on top of the UDP protocol.

Wrapping Up

At this point we have discussed the Link, Internet and Transport layers of the TCP/ IP networking model, which means we have a good mental model of how messages are transported over the internet to communication end-points. The last thing we need to understand is how to structure these messages. That's for the next post on HTTP. Thanks for reading!