Layer 4: The Transport Layer

Reliability and Multiplexing

Layer 3 delivers a packet to the right computer. But a modern computer runs dozens of applications simultaneously — a web browser, an SSH client, a Slack app, a database. Layer 4 answers the question: which application gets this data?

Layer 4: The Transport Layer

Layer 4 provides two critical functions: multiplexing (routing data to the correct application using port numbers) and reliability (optionally guaranteeing delivery, ordering, and error checking).

• Unit: Segment (TCP) or Datagram (UDP)
• Address: Port number (0–65535)
• Protocols: TCP (Transmission Control Protocol), UDP (User Datagram Protocol)

Port numbers as application addresses:

Your IP address identifies your building. The port number identifies the specific apartment (application) inside that building. When a web server receives a packet destined for port 80, it knows to hand that data to the HTTP server process, not the SSH daemon or the database.

Well-known port assignments (defined by IANA):

A connection at Layer 4 is identified by a 4-tuple: (Source IP, Source Port, Destination IP, Destination Port). This is how a server handles thousands of simultaneous connections — each client uses a different ephemeral source port (randomly assigned from the range 49152–65535), making every connection unique even if they all go to the same destination IP and port.

TCP vs. UDP — the fundamental trade-off:

TCP and UDP represent two different philosophies about reliability:

TCP (Transmission Control Protocol) establishes a connection before sending data using a three-way handshake:
1. Client sends SYN (synchronize)
2. Server responds SYN-ACK (synchronize-acknowledge)
3. Client sends ACK (acknowledge)

After the handshake, TCP guarantees: every segment is acknowledged, lost segments are retransmitted, segments are reassembled in order, and flow control prevents overwhelming the receiver. This reliability has a cost: latency and overhead.

UDP (User Datagram Protocol) sends data with no handshake, no acknowledgment, no ordering, and no retransmission. It's "fire and forget." This makes it faster and lower-latency, but the application must handle any reliability it needs.

Why UDP for video streaming? A dropped frame in a video call is better displayed as a brief glitch than paused while the network retransmits it. Retransmitting old video data would make the stream fall behind real-time. UDP lets the application decide: skip the lost packet and keep playing.

Senior depth — TCP connection states and TIME_WAIT: After a TCP connection closes, the socket doesn't immediately disappear. It enters a TIME_WAIT state for 2× MSL (Maximum Segment Lifetime, typically 60 seconds) to ensure any delayed packets from the old connection don't corrupt a new connection on the same port. On high-traffic servers, thousands of sockets in TIME_WAIT can exhaust the ephemeral port range, causing new connection failures. This is diagnosed with ss -s or netstat -an | grep TIME_WAIT | wc -l. The fix is tuning net.ipv4.tcp_tw_reuse or increasing the ephemeral port range — not blindly setting tcp_tw_recycle (which breaks NAT and was removed in Linux kernel 4.12).