Skip to content

🤝 02-01: TCP Fundamentals & the Three-Way Handshake

📌 What Makes TCP Different?

TCP (Transmission Control Protocol) is the workhorse transport-layer protocol behind the majority of internet traffic — web browsing (HTTP/HTTPS), email (SMTP), file transfer (FTP/SFTP), and more. Its defining characteristics are right there in the name and in how it behaves:

Property What It Means
Connection-oriented Two hosts must formally establish a connection before exchanging data (unlike UDP, which just starts sending)
Reliable Every byte sent is guaranteed to arrive, or the sender is told it didn't
Ordered Data arrives at the application in the exact order it was sent, even if individual packets took different paths and arrived out of order
Byte-stream oriented TCP treats the data as a continuous stream of bytes, not discrete messages — it decides how to chop that stream into segments

💡 Contrast this with 02-03: UDP & Connectionless Protocols, which throws all of these guarantees away in exchange for speed and simplicity.

Why "Connection-Oriented" Matters

Think of TCP like a phone call versus UDP being like sending postcards. Before you can talk on a phone call, both people have to pick up and confirm they can hear each other — that's the handshake. Once connected, you know if the line drops (connection reset), and you can ask the other person to repeat themselves if you didn't catch something (retransmission). Postcards, by contrast, just get dropped in a mailbox with no confirmation they were received, read, or even delivered in the order you wrote them.

🔄 The Three-Way Handshake

Before any actual application data flows, TCP establishes a connection using a 3-step exchange of specially flagged segments. This is called the three-way handshake, and it lets both sides agree on starting sequence numbers and confirm that both directions of communication actually work.

Sequence Diagram

   Client                                   Server
     |                                         |
     |  ------------ SYN (seq=X) ------------> |   Step 1: Client requests a connection
     |                                         |
     |  <-------- SYN-ACK (seq=Y, ack=X+1) --- |   Step 2: Server acknowledges and
     |                                         |           requests a connection back
     |  ------------ ACK (ack=Y+1) -----------> |   Step 3: Client acknowledges the server
     |                                         |
     |            [ Connection Established ]   |
     |                                         |
     |  <====== Application data flows ======> |

Step-by-Step Breakdown

  1. SYN (Synchronize): The client picks a random initial sequence number (ISN), let's call it X, and sends a segment with the SYN flag set and seq = X. This says: "I'd like to start a connection, and my byte stream will start counting from X."

  2. SYN-ACK (Synchronize-Acknowledge): The server responds with its own random ISN, Y, setting both the SYN and ACK flags: seq = Y, ack = X + 1. This says: "I got your request (acknowledged by X+1), and I'd also like to start my own byte stream counting from Y."

  3. ACK (Acknowledge): The client responds with just the ACK flag set: ack = Y + 1. This says: "Got it — I acknowledge your sequence number too." At this point, both sides have proven they can send and receive, and the connection is officially established.

💡 Why does the handshake need three steps, not two? Because the connection has to be confirmed in both directions. A 2-step handshake would only prove the client can reach the server — it wouldn't prove the server's reply can actually reach back to the client. The third step is the client's proof, delivered to the server, that the return path works too.

🔒 Why This Guarantees Reliable, Ordered Delivery

The handshake is just the beginning — the sequence numbers established here are what TCP uses for the rest of the connection's life to guarantee reliability:

  • Every byte sent gets a sequence number, letting the receiver detect missing or out-of-order data.
  • Every received byte range is confirmed with an acknowledgment number, letting the sender know what arrived safely and what needs to be retransmitted.
  • If an ACK doesn't arrive within an expected time window, the sender assumes the segment was lost and resends it.

The full mechanics of how these numbers actually increment during a live conversation — with a worked numeric example — are covered in 02-02: TCP Flags, Sequence & ACK Numbers.

🔚 Closing a Connection (Preview)

Just as opening a TCP connection requires a multi-step handshake, closing one gracefully also involves an exchange of FIN (finish) segments from each side — think of it as each side individually saying "I'm done sending" rather than one side abruptly hanging up. The security-relevant abrupt alternative — the RST (reset) flag, which tears down a connection immediately and without negotiation — is covered along with all the other flags in the next lesson.

⚠️ Security Relevance: Why the Handshake Is a Target

The handshake process itself is the foundation for one of the most famous denial-of-service techniques in networking history: SYN flooding. The core idea (covered in full in Module 04) is simple once you understand the handshake:

  • A server that receives a SYN must allocate memory to track a "half-open" connection while it waits for the final ACK.
  • If an attacker sends a flood of SYN segments — often with spoofed source IP addresses so the SYN-ACK goes nowhere and no ACK ever comes back — the server's table of half-open connections fills up.
  • Once full, the server can no longer accept legitimate new connections, achieving denial of service.

This attack is a perfect illustration of a recurring theme in this course: understanding the legitimate protocol in detail is what reveals exactly where it can be broken.

📌 Key Takeaways

  • TCP is connection-oriented, reliable, and ordered — it guarantees delivery and correct sequencing, unlike UDP.
  • The three-way handshake (SYN → SYN-ACK → ACK) establishes a connection and synchronizes starting sequence numbers in both directions.
  • Three steps are required (not two) because both directions of the connection must be independently proven to work.
  • Sequence and acknowledgment numbers established during the handshake are the mechanism TCP uses for reliability and ordering throughout the whole connection.
  • Closing a TCP connection normally uses FIN segments exchanged by each side; RST abruptly tears a connection down instead.
  • The handshake's requirement to allocate server-side state for half-open connections is exactly what SYN flooding attacks (Module 04) exploit.