Section 6: Transport Protocols

The Big Picture: Two Ways to Send a Message

IP (Section 2) can carry a packet from one computer to another. But IP makes no promises. A packet can be lost, copied, delayed or arrive out of order. IP is like dropping letters in a postbox: usually they arrive, but nobody guarantees it.

On top of IP sit two transport protocols. They make the delivery useful for programs. They are two different "postal services":

Both also add port numbers, so the data reaches the right program on the PC (Section 7). The transport layer is where the segment or datagram of Section 1.5 is made.

6.1 TCP (Reliable, Connection-Oriented)

What it is: TCP (Transmission Control Protocol) gives programs a reliable, ordered stream of bytes. "Reliable" means every byte arrives, or the program is told it failed. "Ordered" means bytes arrive in the order they were sent. "Connection-oriented" means the two ends first set up a connection and later close it.

How TCP keeps its promises:

How data and ACKs flow:

 SENDER                                                  RECEIVER

 segment: bytes 1-1000     ───────────────────────────►
 segment: bytes 1001-2000  ───────────X (lost on the way)
 segment: bytes 2001-3000  ───────────────────────────►
                           ◄─────── ACK 1001 ("got up to 1000, send 1001 next")
                           ◄─────── ACK 1001 (still waiting for 1001)
 (no ACK for 1001 in time, so send it again)
 segment: bytes 1001-2000  ───────────────────────────►
                           ◄─────── ACK 3001 ("got everything up to 3000")

The TCP header is added to the data (Section 1.5). The fields you should know:

The cost of reliability. TCP costs extra messages (the handshake, the ACKs) and, when something is lost, waiting. This is a good trade for things where every byte matters.

Used for: web pages (HTTP and HTTPS), email, file transfer, remote login (SSH, RDP), file sharing (SMB) and most things where correctness beats speed.

6.2 UDP (Unreliable, Connectionless, Fast)

What it is: UDP (User Datagram Protocol) is the postcard. The program hands UDP a message, UDP adds a tiny header, and IP sends it. That's all. There is no handshake, no acknowledgement, no retransmission and no ordering.

The UDP header is only 8 bytes:

┌─────────────┬─────────────┬──────────┬──────────┐
│ Source port │  Dest port  │  Length  │ Checksum │
│  (2 bytes)  │  (2 bytes)  │ (2 bytes)│ (2 bytes)│
└─────────────┴─────────────┴──────────┴──────────┘

Compare this with TCP's header, which is at least 20 bytes plus the extra messages for the connection.

Why use something that can lose data?

• When late data is useless data. In a voice call, a word that arrives two seconds late is worse than a tiny gap. The program just skips it and carries on. Waiting for a resend would make the call stutter.
• When the message is tiny. A DNS question (Section 4) fits in one datagram. A handshake would cost more than the question itself.
• When the program wants control. Some programs build their own reliability on top of UDP. A modern example is QUIC, the protocol behind newer web traffic (HTTP/3), which adds its own reliability and encryption on top of UDP.

If UDP loses something, who cares? The program. A DNS client simply asks again if no answer arrives. A game keeps playing with the newest update.

UDP and broadcast. Because UDP has no connection, it can send to a whole network at once. DHCP (Section 5) uses this for its first message.

6.3 The TCP Three-Way Handshake

What it is: Before sending data, TCP sets up a connection with three messages. The aim is that both sides agree they are talking, and agree on the starting sequence numbers.

 CLIENT (your browser)                                   SERVER (web server)
 (port 50123)                                            (port 443)

 1. SYN       "I want to connect. My first sequence number is 1000."
              ─────────────────────────────────────────────────────────►

 2. SYN-ACK   "OK, I hear you (I expect 1001). My first number is 5000."
              ◄─────────────────────────────────────────────────────────

 3. ACK       "Got it (I expect 5001). Connection open."
              ─────────────────────────────────────────────────────────►

 Now data can flow in both directions.

(The numbers in the picture are examples. Real starting numbers are chosen unpredictably, which makes the connection harder to hijack.)

What if the server has no program listening on that port? It answers the SYN with a RST ("reset"). Your program then reports "connection refused". If nobody answers at all (for example, a firewall silently drops it), the SYN is repeated a few times and then the program reports a timeout. These two failures look different, and that difference helps when troubleshooting (see Section 10).

Closing a connection. Each side sends a FIN (finish) and the other answers with an ACK. Often this takes four messages, since each direction is closed separately.

What you can see on your own PC: In netstat -ano (Section 7), a TCP connection has a State column:

Test a TCP connection safely (read-only):

Test-NetConnection example.com -Port 443

This command tries the TCP handshake to port 443 of example.com and reports TcpTestSucceeded : True when it works. Use it only on your own devices or public sites.

Summary