Week 6: TCP I -- Handshake and Connection Mechanics

TCP guarantees that bytes arrive in order and without corruption. It does this by numbering every byte it sends and requiring the receiver to acknowledge what it has received. This week you trace the three-way handshake and the connection teardown through actual packet captures, following the sequence and acknowledgment arithmetic.

Theme

When you open https://virtuscyberacademy.org in a browser, the first thing that happens (after DNS resolves the IP address) is a TCP three-way handshake: SYN, SYN-ACK, ACK. Three packets, a few milliseconds, and then your browser and the server share a connection with agreed-on initial sequence numbers. Everything after that -- the TLS handshake, the HTTP request, the response -- rides on the TCP stream that was established in those three packets. This week you trace all three in a capture.

Reading (~60 minutes)

1. Stevens TCP/IP Illustrated Ch 18 ("TCP Connection Establishment and Termination"): the three-way handshake; active and passive open; FIN and RST teardown
2. Stevens TCP/IP Illustrated Ch 17 ("TCP: The Transmission Control Protocol -- Preliminary") -- §17.1-17.3: the TCP header; sequence numbers; port numbers
3. Optional: Kurose & Ross Ch 3 §3.5 (Connection-Oriented Transport: TCP): the handshake from a higher-level perspective

Lecture outline (~2 hours)

Section 1: The TCP header

The TCP header is 20 bytes minimum:

TCP flag bits:

Display filters: tcp.flags.syn == 1, tcp.flags.ack == 1, tcp.flags.fin == 1, tcp.flags.rst == 1.

Section 2: Sequence numbers

• The sequence number identifies the position of the first data byte in this segment within the overall byte stream
• The initial sequence number (ISN) is chosen randomly at connection setup (for security reasons)
• The acknowledgment number says: "I have received everything up to byte N; send me byte N+1 next"
• SYN and FIN each consume one sequence number, even though they carry no data
• Example arithmetic (from fundamentals-tcp-3way.pcap):
  • Client SYN: SEQ = 0xa1b2c3d4 (ISN), ACK = 0 (not valid yet)
  • Server SYN-ACK: SEQ = 0x55667788 (server's ISN), ACK = 0xa1b2c3d5 (client's ISN + 1)
  • Client ACK: SEQ = 0xa1b2c3d5 (ISN + 1), ACK = 0x55667789 (server's ISN + 1)

Section 3: The three-way handshake

1. SYN: Client sends a segment with SYN flag set, its chosen ISN (initial sequence number), and its MSS (Maximum Segment Size) in the options. ACK flag is NOT set.
2. SYN-ACK: Server responds with both SYN and ACK set. Its own ISN, and an ACK number = client's ISN + 1 (acknowledging the SYN). Server also sends its MSS.
3. ACK: Client sends ACK with ACK number = server's ISN + 1. No data yet. Connection is established.

Figure 6.1. The TCP three-way handshake from the worked example in Section 2. The numbered annotations on the arrows (1, 2, 3) match the numbered paragraphs above. The sequence numbers shown are the ones you will see in fundamentals-tcp-3way.pcap when you load it in Wireshark for Lab 6.1.

After the handshake, both sides have:

• An agreed starting sequence number for each direction
• An agreed MSS (maximum size of one segment) for each direction
• A connection state (ESTABLISHED) in their TCP state machine

Section 4: Connection teardown

FIN/ACK sequence (graceful close):

1. Side A sends FIN-ACK: "I am done sending data."
2. Side B sends ACK: "I received your FIN." (Side B can still send data.)
3. Side B sends FIN-ACK: "I am also done sending data."
4. Side A sends ACK: "I received your FIN." Connection is closed.

The FIN consumes one sequence number on each side.

RST (reset):

• RST immediately aborts the connection with no graceful close
• Common causes: receiving a packet for a port with no listener; firewall dropping connections; one side crashing
• In a capture: RST packets appear where a FIN/ACK sequence would be expected, or in the middle of a connection

Section 5: TCP state machine

TCP connections go through a series of states:

CLOSED -> LISTEN (server waiting for connections)
LISTEN -> SYN_RECEIVED (server received SYN)
SYN_RECEIVED -> ESTABLISHED (server sent SYN-ACK, received ACK)
ESTABLISHED -> FIN_WAIT_1 (sent FIN)
FIN_WAIT_1 -> FIN_WAIT_2 (received ACK of FIN)
FIN_WAIT_2 -> TIME_WAIT (received FIN; sent ACK)
TIME_WAIT -> CLOSED (waited 2x MSL for delayed packets)

A key state: TIME_WAIT. After sending the final ACK, the closing side waits 2x Maximum Segment Lifetime (typically 60-120 seconds) before fully closing. This prevents delayed packets from a previous connection being interpreted as data in a new connection on the same port pair.

ss -tn state time-wait (Linux) lists connections in TIME_WAIT. Large numbers can indicate a high-volume server closing many connections rapidly.

Labs (~90 minutes)

Lab 6-1: TCP Three-Way Handshake (labs/lab-6-1-tcp-3way.md) Lab 6-2: TCP Connection Teardown (labs/lab-6-2-tcp-state.md)

Tier-1 companion: TCP Handshake Replay Workout (worksheets/net-101/lab-tcp-handshake-replay.md)

• Drive the pcap-tools replay panel through fundamentals-tcp-3way.pcap with predict-then-verify discipline on flag sets, state pairs, and SEQ / ACK arithmetic
• ~60 minutes; recommended primer before Lab 6-1 (same fixture; today is the annotated walk, Lab 6-1 is the unaided fill-in)
• Tutor-integrated via the tcp-3way-replay-context.md overlay; ask the academy tutor for hints if a step gets stuck

Independent practice (~7 hours)

1. Read Stevens Ch 17-18 in full; work through the sequence-number arithmetic examples
2. Load fundamentals-tcp-3way.pcap in pcap-tools. For each of the three packets: write down the SEQ, ACK, window, flags, and MSS option. Verify the arithmetic: ACK in packet 2 = SEQ in packet 1 + 1.
3. Load fundamentals-http-get.pcap. Identify: the three-way handshake packets; the HTTP GET request packet; the HTTP 200 OK response packets; the FIN-ACK teardown sequence. For each stage, write the TCP flag combination you see.
4. Apply the display filter tcp.flags == 0x002 to any capture. What does this filter find? (Look up what the hex value 0x002 means for TCP flags.)
5. Look up the SYN_COOKIES technique. What problem does it solve? Where in the TCP handshake does it matter?

Reflection prompts (~30 minutes)

1. TCP sequence numbers are chosen randomly at connection setup (not starting at 0). Why? What attack would be possible if ISNs were predictable?
2. The three-way handshake involves 3 packets. A two-way handshake (SYN, SYN-ACK, then data immediately) is sometimes proposed. What problem does the third packet (ACK) solve?
3. The TIME_WAIT state lasts 60-120 seconds. This can be a problem for high-volume servers that close many connections quickly. What is the practical symptom of too many TIME_WAIT connections?
4. RST immediately terminates a connection. What is the difference between a firewall that responds to blocked traffic with RST vs one that silently drops the packet?
5. TCP was designed in 1974. The Internet in 1974 was a research network with a few dozen nodes. Which aspects of TCP's design turned out to scale unexpectedly well, and which have caused problems as the network grew to billions of nodes?

What comes next

Week 7 goes deeper into TCP: sliding windows, flow control, congestion control, and what happens inside a real TCP stream when the network gets congested. You will open a longer capture and trace window-size changes across many packets.