the transport layer

Imagine the network layer can deliver a letter to a building (a host, named by its IP address), but the building has many residents — a web browser, an email program, three game windows — all sending and receiving at once. Something has to read the apartment number on each letter and hand it to the right resident, and stuff each outgoing letter into the building's mail chute. That job belongs to the transport layer. The layers below it move bytes between machines; the transport layer turns that host-to-host delivery into process-to-process communication that actual programs can use.

Concretely, the transport layer runs in the end systems (your laptop, a server), not in the routers in the middle. It takes a message from an application, labels it with a source port and a destination port so it can be steered to the right program on each end, optionally adds reliability and ordering, and hands the result down to the network layer as a segment. On the Internet there are two main transport protocols with opposite philosophies: UDP, a thin best-effort wrapper that just adds ports and a checksum, and TCP, which builds a reliable, in-order byte stream on top of the unreliable network using acknowledgments, sequence numbers, and retransmission.

Why it matters: this is the layer your programs actually speak to. When code opens a socket, sends an HTTP request, or streams video, it is using transport-layer services. A key idea here is the end-to-end principle — functions like reliability and ordering are placed in the end hosts, not baked into the network core, which is one reason the Internet could stay simple in the middle and grow so large. Note that the transport layer is about delivery and multiplexing, not secrecy: TCP by itself encrypts nothing; that is the job of TLS above it.