We network computers together, not just so they can send data to each other, but because we want programs running on those computers to be able to send data to each other. This is where the Transport and Application layers of our networking model come into play. In short, the Transport layer allows traffic to be directed to specific network applications. And the Application layer allows these applications to communicate in a way they understand.
The transport layer is responsible for lots of important functions of reliable computer networking. These include multiplexing and demultiplexing traffic, establishing long-running connections, and ensuring data integrity through error checking and data verification. The transport layer has the ability to multiplex and demultiplex, which sets this layer apart from all others. Multiplexing in the transport layer means that nodes on the network have the ability to direct traffic toward many different receiving services. Demultiplexing is the same concept, just at the receiving end, it's taking traffic that's all aimed at the same node and delivering it to the proper receiving service.
The transport layer handles multiplexing and demultiplexing through ports. A port is a 16-bit number that's used to direct traffic to specific services running on a networked computer. A server or service is a program running on a computer waiting to be asked for data. A client is another program that is requesting this data.
Different network services run while listening on specific ports for incoming requests. For example, the traditional port for HTTP or unencrypted web traffic is port 80. If we want to request the webpage from a web server running on a computer listening on IP 10.1.1.100, the traffic would be directed to port 80 on that computer. Ports are normally denoted with a colon after the IP address. So the full IP and port in this scenario could be described as 10.1.1.100:80. When written this way, it's known as a socket address or socket number.
The same device might also be running an FTP or file transfer protocol server. FTP is an older method used for transferring files from one computer to another, but you still see it in use today.
FTP traditionally listens on port 21, so if you wanted to establish a connection to an FTP server running on the same IP that our example webserver was running on, you direct traffic to 10.1.1.100 port 21. You might find yourself working in IT support at a small business. In these environments, a single server could host almost all of the applications needed to run a business. The same computer might host an internal website, the mail server for the company, a file server for sharing files, a print server for sharing network printers, pretty much anything. This is all possible because of multiplexing and demultiplexing, and the addition of ports to our addressing scheme.
Just like how an Ethernet frame encapsulates an IP datagram, an IP datagram encapsulates a TCP segment.
Remember that an Ethernet frame has a payload section which is really just the entire contents of an IP datagram. Remember also that an IP datagram has a payload section and this is made up of what's known as a TCP segment. A TCP segment is made up of a TCP header and a data section. As you might guess, this data section is just another payload area for where the application layer places its data. A TCP header itself is split into lots of fields containing lots of information.
First, we have the source port and the destination port fields. The destination port is the port of the service the traffic is intended for. A source port is a high numbered port chosen from a special section of ports known as ephemeral ports. A source port is required to keep lots of outgoing connections separate. You know how a destination port, say port 80, is needed to make sure traffic reaches a web server running on a certain IP? Similarly, a source port is needed so that when the web server replies, the computer making the original request can send this data to the program that was actually requesting it. In this way, when it web server responds to your requests to view a web page, this response gets received by your web browser and not your word processor.
Next up is a field known as the sequence number. This is a 32-bit number that's used to keep track of where in a sequence of TCP segments this one is expected to be. You might remember that lower on our protocol stack, there are limits to the total size of what we send across the wire. The Ethernet frame is usually limited in size to 1,518 bytes, but we usually need to send way more data than that. At the transport layer, TCP splits all of this data up into many segments. The sequence number in a header is used to keep track of which segment out of many this particular segment might be. The next field, the acknowledgment number, is a lot like the sequence number. The acknowledgment number is the number of the next expected segment. In very simple language, a sequence number of one and an acknowledgment number of two could be read as this is segment one, expect segment two next. The data offset field comes next. This field is a four-bit number that communicates how long the TCP header for this segment is. This is so that the receiving network device understands where the actual data payload begins. Then, we have six bits that are reserved for the six TCP control flags. The next field is a 16-bit number known as the TCP window. A TCP window specifies the range of sequence numbers that might be sent before an acknowledgment is required. As we'll cover in more detail soon, TCP is a protocol that's super reliant on acknowledgments. This is done in order to make sure that all expected data is actually being received and that the sending device doesn't waste time sending data that isn't being received. The next field is a 16-bit checksum. It operates just like the checksum fields at the IP and Ethernet levels. Once all of this segment has been ingested by a recipient, the checksum is calculated across the entire segment and compared with the checksum in the header to ensure no data is lost or corrupted along the way. The Urgent pointer field is used in conjunction with one of the TCP control flags to point out particular segments that might be more important than others. This is a feature of TCP that hasn't really ever seen adoption and you'll probably never find it in modern networking. Even so, it's important to know what all sections of the TCP header are. Next up, we have the options field. Like the urgent pointer field, this is rarely used in the real world, but it's sometimes used for more complicated flow control protocols. Finally, we have some padding which is just a sequence of zeros to ensure that the data payload section begins at the expected location.