The previous lesson left IP packets arriving at the right machine, but with an open question: inside that machine, which program does the data go to? The Valencia server hosts the file service, an internal website and a few other things; on Marta's PC, a browser with ten tabs, the email client and a video call all live side by side. The transport protocols solve exactly that: end-to-end communication between applications, not between machines. And they add something more: since IP is "best effort" and can lose, duplicate or reorder packets, the transport layer is where you decide how much reliability each communication needs. Its two stars embody the two possible answers: TCP, which guarantees everything in exchange for extra work, and UDP, which guarantees almost nothing in exchange for speed. In this lesson you will understand ports and sockets, the famous three-way handshake, sequence numbers and ACKs, flow control, when to choose each protocol, and how to spy on your own connections with netstat.

1. The transport's mission: application to application
2. Ports: each application's office number
3. Sockets: the full address of a conversation
4. TCP: reliability as a service
5. The three-way handshake: opening the connection
6. Sequence numbers, ACKs and retransmissions
7. Flow control and connection teardown
8. UDP: speed as a service
9. TCP vs UDP: comparison table and Meridiano cases
10. netstat: a first look at your connections

Let's recap the stack's division of labor with the postal analogy we've been using: the data link delivers within the neighborhood, IP carries the envelope between cities to the right building... and the transport is the building's concierge: it receives the mail and takes it up to the exact office it is addressed to. One building (one machine, one IP) has many offices (applications), and without a concierge the envelope would sit in the lobby.

Transport protocols provide two services:

• Multiplexing by ports: letting many applications on the same machine use the network at once without getting mixed up, identifying each one with a port number.
• Delivery control (optional): on top of IP's "no guarantees" service, adding — if the application needs it — guaranteed, in-order, duplicate-free delivery (TCP), or adding nothing at all and staying featherweight (UDP).

You already know their data units from the encapsulation in 02-01: segments (TCP) and datagrams (UDP) travel inside IP packets, and the Protocol field of the IP header (6 = TCP, 17 = UDP) hands them to the right transport protocol.

A port is a 16-bit number (0 to 65535) that identifies a communication endpoint within a machine. Every segment carries a source port and a destination port in its header, just as the IP packet carries source and destination IPs.

Ports are organized into three ranges:

The well-known ports are the Internet's implicit "phone book": a web server listens on 80 (HTTP) or 443 (HTTPS), DNS on 53, outgoing mail on 25... We will cover them protocol by protocol in lesson 02-05; for now the idea is enough: a client that wants a service calls that service's standard port. The client, for its part, uses as its source whichever ephemeral port its operating system assigns on the fly.

The combination IP + transport protocol + port is called a socket, and it is the complete address of one communication endpoint: 192.168.10.10:443 unambiguously identifies "the application listening on TCP port 443 of machine 192.168.10.10". A connection is identified by the pair of sockets at its two ends:

If the term rings a bell from programming, that's no coincidence: the sockets of programming languages (the API a program uses to open connections) are precisely the doorway into the transport protocols we are studying. When your code calls connect() on an IP and port, it is asking the operating system for exactly what comes in the next section.

TCP (Transmission Control Protocol) is the connection-oriented, reliable transport protocol. On top of IP's best effort, it guarantees applications four things:

1. Complete delivery: whatever gets lost is retransmitted.
2. Ordering: data reaches the application in the order it was sent, even if the packets arrive out of order.
3. No duplicates: if something arrives twice (from a superfluous retransmission), the copy is discarded.
4. Flow control: the sender never overwhelms the receiver.

The application using TCP sees something wonderfully simple: a continuous stream of bytes that goes in one end and comes out intact at the other, like a pipe. All the complexity (slicing into segments, numbering, acknowledging, retransmitting, reordering) stays hidden. That is why TCP is the choice for everything that cannot tolerate losing a single byte: web pages, file transfers, email... At Meridiano, when a consultant saves a 40 MB proposal on the server, every one of those millions of bytes arrives exact and in order thanks to TCP.

The price: TCP needs to establish a connection before sending data, acknowledge everything in transit, and keep state at both ends. Let's look at those pieces.

Before the first byte of data, client and server perform the three-way handshake, the exact equivalent of the "Hello? — Hi, it's Ana — Go ahead, Ana" of the phone call from lesson 02-01:

• SYN (synchronize): the client asks to open a connection and announces its initial sequence number.
• SYN-ACK: the server accepts, announces its own and confirms the client's.
• ACK (acknowledgement): the client confirms. From this moment on, both sides know the other is there, is listening, and which numbers they will use to count the bytes.

Why three steps and not two? Because both ends need confirmation that their message got through: with the SYN-ACK the client knows the server heard it; with the final ACK the server knows the client heard its reply. With two steps, the server would open connections without knowing whether the client was still there.

If the destination port is closed (nobody listening), the server answers with an RST (reset) segment: TCP's "wrong number, nobody here by that name".

Once the connection is established, TCP numbers every byte it sends (the sequence numbers agreed in the handshake) and the receiver keeps confirming with ACKs up to which byte it has received everything correctly. This mechanism is the heart of reliability:

Watch the timing and semantics pieces working together:

• The receiver only acknowledges contiguous data: even though it received block 3001-4000, it keeps answering ack=2001 because the previous one is missing. Meanwhile it holds the early block so it can reorder later.
• The sender detects the loss in two ways: duplicate ACKs (the fast signal) or a timeout (if no ACK arrives within a calculated time, it retransmits). It is the "if no confirmation within X, resend" rule we used as a timing example in 02-01.
• The result: over a network that loses packets, the application receives 100% of the bytes, in order. Reliability isn't in the network: it is manufactured at the endpoints.

Flow control: what if the server receives faster than it can process (slow disk, heavy load)? In every ACK, the receiver announces its window: how many more bytes it is willing to accept right now. The sender never sends beyond the announced window; if it drops to 0, it stops and waits. It is the "slow down, I'm taking notes" of the phone conversation: the receiver sets the pace. (TCP also performs congestion control to avoid saturating the network in between — a fascinating topic beyond this introductory course.)

Teardown: when the application finishes, the connection is closed in an orderly way with an exchange of FIN segments and their ACKs, in which each end says goodbye separately ("I'm done sending" — "acknowledged"), because one side may finish before the other. The equivalent of "OK, talk soon" / "bye": nobody hangs up without warning. An abrupt close (an error, a killed process) is signaled with RST.

UDP (User Datagram Protocol) is the other answer: a connectionless, no-guarantees transport protocol, so simple that its header fits on one line:

UDP takes the application's data, slaps on ports and a checksum, and hands it to IP. Nothing more: no handshake, no sequence numbers, no ACKs, no retransmissions, no flow control. Each datagram is independent, like a postcard: it may arrive, get lost, be duplicated or overtake another, and nobody will tell you.

What is a protocol like that good for? For the cases where TCP's guarantees get in the way:

• Real-time traffic (voice, video calls): if a fragment of audio is lost, retransmitting it is pointless — it would arrive late, the conversation has already moved on. Better a 20 ms crackle than a 2-second pause waiting for retransmissions. The daily Valencia–Bilbao video call travels over UDP for exactly this reason.
• Short question-and-answer exchanges (DNS is the canonical example, we'll see it in 02-05): to send a 50-byte query, setting up and tearing down a TCP connection (3 opening segments + the close) would cost more than the entire query. With UDP: one question, one answer, done. If it gets lost, the application itself asks again.
• Broadcasts and discovery (DHCP, streaming to many destinations): TCP is point-to-point by nature; UDP can send to a broadcast.

The mental rule: with UDP, reliability (if needed) is the application's responsibility. Modern real-time applications add on top of UDP exactly the guarantees that suit them, and not one more.

And grounded in Grupo Meridiano's day-to-day:

Everything above can be seen on your own machine with netstat, available on Windows and Linux (on modern Linux its successor is ss, with nearly identical output). On Marta's PC, with the internal website open and the file uploading:

Reading it line by line, with this lesson's concepts:

• Each row is a TCP connection identified by its pair of sockets (local and remote address, each an IP:port).
• The local 528xx ports are ephemeral; the remote ones (443, 445) are well-known and give the service away: HTTPS and file sharing against the Valencia server, HTTPS against a server on the Internet.
• State ESTABLISHED: the three-way handshake completed and the connection is alive. Other states you will see: LISTEN (a server waiting for clients — add -a to see them), SYN_SENT (a half-done handshake: SYN sent with no reply, typical of a downed server or a firewall), TIME_WAIT (a freshly closed connection in its final courtesy phase — normal and short-lived).
• UDP "connections" don't show up as such (there is no connection to list); with netstat -an you will see its open ports marked as UDP, with no state.

netstat is the first tool that turns this lesson into something tangible; we will squeeze it, along with the rest of the utilities, in module 6.

• Confusing a port with something physical. Port 443 is not a socket on the wall: it is a number in the segment header. The switch's physical ports and transport ports share nothing but the name, and mixing them up marks you as a beginner.
• Believing UDP is "worse" or that "TCP is always better". They are tools for different problems: using TCP for a video call adds unacceptable delays; using UDP to transfer a file forces you to reinvent TCP by hand. A professional chooses by requirements, not by prestige.
• Forgetting that TCP's reliability ends at the TCP endpoint. TCP guarantees the bytes reach the receiving socket; if the application then mishandles them or the disk fails, that is no longer the network's problem. "The network is fine, your application isn't" is a sentence you will say many times.
• Ignoring netstat states when troubleshooting. A perpetual SYN_SENT says "nobody is answering the handshake" (service down or firewall); an ESTABLISHED says "the connection exists, look for the problem higher up". Telling them apart saves hours.
• Tip: memorize the 80/443 pair (HTTP/HTTPS) and 53 (DNS) right now. In the next lesson we'll add the rest of the well-known ports, and you will use them weekly throughout your career.

Exercise 1. Marta has two browser tabs open at the same time against https://intranet.grupomeridiano.example (which resolves to 192.168.10.10, port 443). Explain how it is possible that each tab's responses don't get mixed up, indicating which fields of which header make it possible, and write a plausible example of the two socket pairs.

Exercise 2. During a file upload from Bilbao to the Valencia server, the VPN loses a packet carrying the segment with seq=5001 (bytes 5001-6000). The sender had already sent bytes 6001-8000 as well. Describe the sequence of ACKs and retransmissions until everything is acknowledged, and explain what the server's application received in the meantime.

Exercise 3. The Valencia–Bilbao video call keeps stuttering and a colleague proposes "switching it to TCP, the reliable one". Explain in 3-4 sentences why the proposal would make the problem worse, and what this says about how to choose a transport protocol.

Solution 1: Both tabs share the local IP, the remote IP and the remote port (443), but the operating system assigns each connection a different ephemeral source port. The source port and destination port fields of the TCP header, combined with the IPs of the IP header, identify each connection uniquely, so every response segment is delivered to the right socket (and the right tab). Example: tab 1 = (192.168.10.21:52840) ↔ (192.168.10.10:443); tab 2 = (192.168.10.21:52841) ↔ (192.168.10.10:443).

Solution 2:

1. The server receives 6001-8000 but is missing 5001-6000: it holds the early data and answers ack=5001 (repeated) to every segment that arrives: duplicate ACKs.
2. The sender, on seeing duplicate ACKs (or when its timer runs out), retransmits the segment seq=5001.
3. On receiving it, the server now has contiguous data up to 8000 and answers ack=8001, acknowledging everything in one go.
4. In the meantime, the server's application received nothing from byte 5001 onward: TCP holds bytes 6001-8000 back until it can deliver the stream in order. The application never sees gaps or disorder; only a brief pause. That is TCP's contract.

Solution 3: The problem with a stuttering video call is latency and occasional losses, and TCP responds to losses with retransmissions and waiting: every lost audio packet would stall the stream until it was retransmitted (later data is held back to preserve ordering), turning millisecond micro-dropouts into multi-second freezes. The retransmitted stale audio is useless anyway: the conversation has moved on. That is why real time uses UDP and accepts small losses. The moral: you choose a transport protocol based on what the application can tolerate (losses or delays?), not on which one "guarantees more".

The transport completes the journey: we no longer deliver to machines, but to applications. We have seen that ports multiplex the network among all the programs on a machine (well-known for services, ephemeral for clients) and that a socket — IP + protocol + port — is the complete address of one endpoint. On top of IP's best effort, TCP manufactures end-to-end reliability: it opens with the three-way handshake (SYN, SYN-ACK, ACK), numbers every byte, confirms with ACKs, retransmits what is lost, reorders, paces itself with the receive window, and says goodbye with FIN; UDP, by contrast, offers bare, immediate datagrams, perfect for real time and short queries — and the Meridiano table (files and web over TCP; video calls, DNS and DHCP over UDP) sums up the selection criterion. With netstat we have watched our own connections live for the first time. All that remains is the top floor of the stack, the one that motivates all the others: the protocols with which applications do useful things — requesting web pages, translating names like grupomeridiano.example into IPs, moving mail and files, handing out addresses automatically. All of them, in the next lesson: Application Protocols.