The main job of the transport layer is to provide end-to-end communication between applications running on different devices. It takes data from an application on one machine, delivers it to the correct application on another machine, and handles everything in between: breaking data into manageable pieces, making sure those pieces arrive intact, and controlling how fast data flows so neither the network nor the receiving device gets overwhelmed.
The transport layer sits at Layer 4 in the OSI networking model, acting as a bridge between the applications you interact with (like your browser or email client) and the lower-level network infrastructure that physically moves data across cables and wireless signals.
Directing Data to the Right Application
Your computer runs dozens of networked applications at once. You might have a browser open, a video call running, and a file downloading, all sharing the same internet connection. The transport layer uses port numbers to keep all of this traffic sorted. Each application creates a “socket,” which is essentially a doorway to the network, and each socket gets a unique port number on the system.
When outgoing data leaves your machine, the transport layer reads the port number from the socket, attaches it to a header, and passes the data down to the network layer. This process is called multiplexing. When data arrives from the network, the transport layer reads the port number in the header, identifies which application should receive it, and forwards the data to the right socket. That reverse process is called demultiplexing. Without this mechanism, your computer would have no way of knowing whether an incoming packet belongs to your browser tab or your video call.
Breaking Data Into Segments
Applications often need to send chunks of data far too large to travel across a network in one piece. The transport layer splits this data into smaller units called segments, each tagged with a sequence number so the receiving side knows the original order. When the segments arrive at the destination, the transport layer reassembles them back into the complete original data, even if individual segments took different paths or arrived out of sequence.
This segmentation also makes error recovery much more efficient. If one small segment gets lost or corrupted, only that segment needs to be resent, not the entire data stream.
Ensuring Reliable Delivery
Networks are unreliable by nature. Packets get dropped, corrupted, or delivered out of order. The transport layer can compensate for all of this, depending on which protocol is in use.
Reliability works through a few cooperating mechanisms. First, the sender attaches a checksum to each segment. This checksum is a small value calculated from the segment’s contents. The receiver runs the same calculation on the data it receives and compares the result. If the numbers don’t match, the segment was corrupted in transit. Checksums are a detection tool, not a correction tool. They catch most errors, though not every possible bit flip.
Second, the receiver sends back acknowledgements (ACKs) confirming which segments arrived successfully. If the sender doesn’t receive an acknowledgement within a set time window, it assumes the segment was lost and retransmits it. This back-and-forth ensures that no data silently disappears.
Controlling the Flow of Data
If a fast server blasts data at a slow device, the receiving device’s memory buffer fills up and incoming data gets dropped. Flow control prevents this. The receiver tells the sender exactly how much free buffer space it has available, and the sender limits its transmissions to stay within that window. As the receiver processes data and frees up space, it advertises a larger window, and the sender speeds up. This happens continuously throughout a connection.
Congestion control is a related but distinct concern. Instead of protecting the receiver, it protects the network itself. When too many devices push too much data through the same links, the network gets congested and packets start getting dropped. The transport layer detects signs of congestion (like lost packets or rising delays) and dials back the sending rate. The two most widely used congestion control algorithms today are CUBIC, which uses a mathematical growth function to ramp up speed aggressively in high-bandwidth networks, and BBR, developed by Google, which estimates the network’s actual available bandwidth and adjusts accordingly rather than waiting for packet loss as a signal.
The sender’s actual transmission rate at any moment is whichever limit is smaller: the receiver’s advertised window or the congestion control window. This ensures data flows as fast as possible without overwhelming either the receiver or the network.
TCP vs. UDP: Two Approaches
The transport layer offers two main protocols that take very different approaches to the job.
TCP (Transmission Control Protocol) is connection-oriented. Before any data flows, the two devices perform a three-way handshake to establish a connection, which adds at least one round-trip of latency before the first byte of real data is sent. In exchange, TCP provides reliable, ordered delivery with acknowledgements, retransmission of lost packets, flow control, and congestion control. Its header is 20 to 60 bytes, reflecting all the extra information it tracks. TCP is what your browser uses to load web pages and what your email client uses to send messages.
UDP (User Datagram Protocol) is connectionless. There’s no handshake, no acknowledgements, no retransmission, and no guaranteed order. Its header is a fixed 8 bytes, keeping overhead minimal. UDP is faster precisely because it skips all of those reliability mechanisms. It’s the protocol behind live video calls, online gaming, and DNS lookups, where speed matters more than perfecting every single packet. A dropped frame in a video call is barely noticeable, but waiting for a retransmission would create a visible lag.
Neither protocol is universally better. They represent a fundamental trade-off at the transport layer: reliability and order on one side, speed and simplicity on the other. The choice depends entirely on what the application needs.
How Connection Setup Affects Speed
TCP’s three-way handshake means the transport layer adds measurable latency before a connection can carry data. Under normal conditions, this costs one round-trip time between the two devices. For a server 35 milliseconds away, that’s 70 milliseconds just to set up the connection. If a packet is lost during the handshake, the default retry timeout starts at three seconds, and each subsequent retry doubles the wait. On a lossy network, connection setup alone can take several seconds.
This latency is one reason modern web protocols have been designed to minimize the number of new connections needed, and why UDP-based alternatives have gained traction for time-sensitive applications. The transport layer’s reliability guarantees are powerful, but they come at a real cost in time.