Layer 4 of the OSI model, the transport layer, is the model's great hinge: below it sit the layers that move data between machines (physical, data link, network); above it, those that think in terms of applications (session, presentation, application). The transport layer joins the two worlds: it takes the "best-effort delivery between machines" that layer 3 offers and turns it into communication between processes, optionally reliable and ordered. In module 2 (lesson 02-04) you already studied its two star protocols — TCP with its three-way handshake, sequences and ACKs, and UDP — along with ports and netstat; we won't repeat any of that. Here we will analyze layer 4 as a layer: which services OSI defines for it, what "end to end" really means, how flow control and congestion control differ, and how a layer 4 problem gets diagnosed in practice.

1. The transport layer's role within the model
2. End to end: the key difference from layer 3
3. Service 1: multiplexing by ports
4. Service 2: segmentation and reassembly
5. Service 3: reliability — two service classes as a design decision
6. Service 4: flow control and congestion control
7. Layer 4 diagnosis: closed port vs downed host

Layer 4's OSI contract:

• What it receives from above (layers 5-7): a data stream from an application that wants to talk to a specific process on another machine.
• What service it offers: communication between processes (not just between machines), with the level of guarantees contracted: from "reliable, ordered, controlled delivery" to "loose sends with no promises".
• What it uses from below (layer 3): packet delivery between machines, best effort — packets can get lost, duplicated or arrive out of order.
• Its PDU: the segment (or datagram in the connectionless service). Its addresses: the ports.

A helpful image: layer 3 is the postal service that carries letters to the right building; layer 4 is the building's front desk, which distributes each letter to the right department and, if the service includes it, confirms receipt, chases up lost letters and reorders the ones that arrived jumbled.

Unlike layers 1-3, layer 4 has no network devices of its own: it lives in the operating system of the endpoints. The TCP managing Marta's connection to the intranet is operating system code on her PC and on the server; the routers and switches in between never even look at it (with nuances: firewalls and other security equipment do inspect ports, which is why they are called "layer 4" devices — we will come back to this in the diagnosis).

"End to end" is the concept that defines this layer, and it deserves precision, because layer 3 also delivers "end to end" in a certain sense. The difference:

This design has a name — the end-to-end principle — and it is one of the most influential architecture decisions in the history of networking: the network's interior stays simple (routers only route), and the intelligence sits at the edges (the endpoints' operating systems execute the guarantees). Practical consequence: no matter how many routers, tunnels and carriers separate Jon's PC from the Valencia server, the TCP conversation is a private affair between those two machines; the VPN and the routers merely carry their packets without understanding the dialogue. It is lesson 03-01's "peer dialogue" in its purest form.

The first service answers this question: a packet arrives at server 192.168.10.10, which simultaneously runs the intranet web server, the file service and a maintenance SSH session — which of the three is this data for? The IP alone doesn't say: it identifies the machine, not the program.

The answer is multiplexing by ports: layer 4 labels each segment with a source port and a destination port, so that many conversations from different applications can share the same network connection without mixing (that is multiplexing), and the receiver can demultiplex: deliver each segment to the process listening on its destination port.

All of this (well-known ports, the client's ephemeral ports, the concept of a socket) you worked through in 02-04; the OSI nuance we add is the service's name: layer 4 multiplexes the communications of every application over the machine's single network stack, and that is the deep reason ports exist.

Applications think in their own terms: "send this 8 MB report to Bilbao". Layer 3 thinks in packets that fit the path's frames. Someone must mediate:

• Segmentation (sender): layer 4 slices the application's stream into appropriately sized segments and numbers them.
• Reassembly (receiver): the other end's layer 4 uses that numbering to put the segments back in order — layer 3 may have delivered them shuffled — and reconstruct the original stream before handing it to the application.

The result is one of the model's most elegant abstractions: Marta's application writes and reads a continuous stream of data, as if there were a direct pipe to the server, completely unaware that underneath everything traveled chopped up, perhaps out of order and perhaps retransmitted. The specific mechanics by which TCP numbers things (sequence numbers and ACKs) you already saw in 02-04. Note the contrast with layer 3's fragmentation (previous lesson): segmentation is the well-done, planned slicing at the source by layer 4; fragmentation is the emergency patch when a packet doesn't fit — a well-tuned layer 4 segments at a size that avoids fragmenting.

OSI states that the transport layer may offer different classes of service, and reality confirms it: there are two philosophies, which you already know embodied in TCP and UDP.

• Connection-oriented, reliable service (TCP): before sending data, a connection is established (02-04's handshake); every piece of data is acknowledged; what's lost is retransmitted; everything is delivered in order and without duplicates; when done, the connection is closed in an orderly way.
• Connectionless, best-effort service (UDP): each datagram is launched independently, with no prior connection, no acknowledgments and no promises. Whatever layer 3 loses stays lost.

What we add here is the design decision perspective: choosing a service class is a trade-off between guarantees and cost, and the one who chooses is each application's designer:

The lost-data row hides the counterintuitive key: for a video call, reliability is counterproductive — retransmitting an audio fragment from half a second ago would force a wait for a sound nobody cares about anymore; better to lose it and carry on with the current voice. There is no "good" class and "bad" class: there is a service suited to each need, and that is why layer 4 offers both.

Two services that often get confused because both mean "slowing the sender down". The difference lies in who is being protected:

• Flow control: protects the receiver. If the server sends data faster than Marta's PC can process it, Marta's receive memory overflows. Flow control is the mechanism by which the receiver tells the sender how much it can accept, and the sender adjusts. It is the receive window you saw in TCP (02-04): an agreement between the two endpoints.

• Congestion control: protects the network. Even if both endpoints are lightning fast, the path between them may not be: if senders inject more traffic than an intermediate link can carry, router queues fill up and start dropping packets — congestion. Congestion control is the mechanism by which the sender deduces the network's state (losses and delays are its thermometer) and moderates its pace: it starts cautiously, speeds up while everything arrives cleanly, and brakes as soon as it detects losses.

Both mechanisms operate at the same time and the sender obeys the more restrictive of the two. And both are pure end-to-end: the routers in the middle request nothing — at most, they drop, and that drop is the signal. That billions of TCP connections self-regulate this way, with no central coordinator, is the reason the Internet doesn't collapse; the specific algorithms are advanced material, but this is the principle.

Today we add the fourth rung to layer-based diagnosis, with the question that characterizes it: "the machine responds, but does the service respond?". The star distinction is closed port vs downed host, because they look different and mean opposite things.

The case: server 192.168.10.10 hosts the intranet (port 443). Ana can't open it. Two checks:

The three possible outcomes of the connection attempt, and what each means:

The diagnostic logic combines both tests:

• Ping answers + port refused → a layer 4/7 problem on the server: the intranet process is down. Don't touch the network: restart or inspect the service. This is our case: the web server had stopped after an update; the machine, perfectly alive.
• Ping answers + port silent (timeout) → host alive but something is dropping the connection: almost always a firewall (on the server or along the path). Silence, as opposed to refusal, is the firewall's typical footprint.
• Ping unanswered + port silent → probably a downed or unreachable host: go back to layers 1-3 (link? routes? machine powered off?). (With the caveat that some firewalls also block ping: that is why the two tests are weighed together, not each on its own.)

Notice the conceptual leap from layer 3 diagnosis: ping asks "are you there, machine?"; the port connection asks "are you there, program?". They are different questions at different layers, and the difference between "they refuse me" and "they ignore me" is worth an entire diagnosis. The specific tools for this (port scanners, netstat in depth, captures) arrive in module 6.

• Concluding "the server is down" because the website won't load. Distinguish machine and service: if ping answers, the host lives and the problem belongs to the service (layers 4-7). Opposite diagnoses, opposite solutions.
• Confusing flow control and congestion control. Flow = protects the receiver, requested by the receiver. Congestion = protects the network, inferred by the sender. In a technical interview, this distinction gets asked word for word.
• Believing UDP is "worse" or that "TCP is always better". They are service classes for different needs; reliability has a cost that sometimes (voice, live video) is worse than the loss itself.
• Forgetting that firewalls act at layer 4. A firewall that drops silently produces timeouts that get mistaken for a downed host. Faced with a timeout and a healthy ping, think "firewall" before "broken network".
• Thinking routers participate in TCP. They don't: the guarantees are the two endpoints' business. If there are massive retransmissions, the network is losing packets (look for it below: congestion, or layer 1-2 errors like the CRCs from lesson 03-03), but the one retransmitting is the endpoint.
• Tip: memorize the trio of outcomes — it connects / they refuse me / they ignore me — and how to read it. It is the entire layer 4 diagnosis in three phrases.

Exercise 1. Classify each mechanism as multiplexing, segmentation/reassembly, reliability, flow control or congestion control: (a) the server slows its send rate because Marta's PC announces that its receive memory is almost full; (b) Jon's PC delivers the data from port 443 to the browser and the data from port 22 to the terminal; (c) TCP resends a segment for which no acknowledgment arrived; (d) the nightly backup's sender eases off after detecting losses on the VPN link; (e) the 8 MB report is sliced into numbered segments.

Exercise 2. The developers who maintain Meridiano's intranet add a real-time internal notices module: every few seconds, each PC receives the updated state of the notices (the latest state replaces the previous one; a lost state doesn't matter because the next one arrives right away). Which transport service class fits best and why? Cite two costs of the connection-oriented service that this case does not amortize.

Exercise 3. From Bilbao, Jon tests against the Valencia server: ping 192.168.10.10 answers fine, but the connection to port 443 stays silent until it times out. Ana, from Valencia, connects to 443 without trouble. (a) What does Jon's ping rule out? (b) Why is the timeout (rather than a refusal) a key clue? (c) Formulate the most likely hypothesis knowing that Ana does connect from the local network.

Solution 1. (a) Flow control (the receiver explicitly asks for restraint). (b) Multiplexing — strictly, demultiplexing: distributing by destination port. (c) Reliability (retransmission of what wasn't acknowledged). (d) Congestion control (the sender infers the network's state from losses and moderates itself). (e) Segmentation with numbering for later reassembly.

Solution 2. The connectionless, best-effort service (UDP) fits: the data is periodic, small, replaceable and freshness-sensitive — retransmitting an old state is useless because the next one is already on its way. Costs of the connection-oriented service that aren't amortized: (1) the handshake and maintaining a connection per PC for tiny, spaced-out messages; (2) the retransmissions and ordering waits: after a loss, TCP would halt delivery until recovering data that is already obsolete, adding exactly the latency this case wants to avoid. (The ACKs and bigger headers for so little payload are also a cost.)

Solution 3. (a) The healthy ping rules out layer 1-3 problems between Jon and the server: there is a round-trip path through the VPN and the host is alive. (b) Because a refusal would have meant "host alive, nobody listening on 443" (service stopped); the silence means the connection attempts never get answered at all: something drops them along the way or at the destination — the typical signature of a firewall. (c) Most likely hypothesis: a firewall (on the server or on the routers/VPN) allows ICMP and local traffic, but blocks or doesn't allow port 443 from the Bilbao network (192.168.20.0/24); since Ana connects from Valencia's local network, the service itself works — the filter discriminates by source. Natural next step: review the firewall rules on the server and on the routers regarding inter-site traffic.

The transport layer turns layer 3's best-effort delivery between machines into communication between processes, with four services you can now name: multiplexing by ports, segmentation and reassembly giving applications the illusion of a continuous stream, reliability as a design decision with two service classes (the eternal TCP/UDP choice from 02-04, now understood as a guarantees-versus-cost trade), and the double brake of flow control (protects the receiver) and congestion control (protects the network). All of it executed only at the endpoints: the end-to-end principle that keeps the network's interior simple. And in diagnosis, you gained the layer 4 question — does the machine respond, or does the service respond? — with its trio of answers: it connects, they refuse me, they ignore me. This completes the four "plumbing layers", the ones module 2 had already introduced protocol by protocol. Starting next lesson we enter new territory: the upper layers that module 2 treated as a single block. The first is the most slippery of the seven, the one almost no protocol implements separately and which is nevertheless everywhere: the session layer.