how a TCP connection actually starts and ends

every time you load a website, your computer and a server perform a tiny little ritual before sending a single byte of real data. three packets, nobody talks about it, and it's called the 3-way handshake. here's what's actually in those packets.

the handshake: SYN, SYN-ACK, ACK

TCP is what's called a connection-oriented protocol , both sides need to agree on some things before talking: the starting sequence numbers, window sizes, etc. the handshake is how they do it.

1. SYN > client: "hey, i want to talk. here's my starting sequence number" (SYN=1)
2. SYN-ACK > server: "ok got it, let's talk. here's mine too" (SYN=1, ACK=1)
3. ACK > client: "cool, confirmed" (ACK=1)

those sequence numbers are the whole point , they let each side know if packets arrive out of order or go missing, which is what makes TCP "reliable."

the ending: FIN, or the polite door slam
closing a connection is also a ritual, it just has four steps instead of three because each direction closes separately:

FIN > one side: "i'm done sending"
ACK > other side: "ok"
FIN > other side: "me too, done"
ACK > "ok, bye"
and sometimes there's no politeness at all: a RST packet means "this connection doesn't exist / something went wrong, drop everything." if you've ever seen "connection reset by peer," that was a RST.

watch it yourself with tcpdump
this is the part that makes it click. open two terminals:

# terminal 1: sniff port 80 traffic (needs sudo)
sudo tcpdump -i any -n 'tcp port 80'

# terminal 2: make a quick HTTP request
curl -nv http://example.com > /dev/null

you will see something like that :

IP 192.168.1.15.54321 > 93.184.216.34.80: Flags [S], ...
IP 93.184.216.34.80 > 192.168.1.15.54321: Flags [S.], ...
IP 192.168.1.15.54321 > 93.184.216.34.80: Flags [.], ...

tcpdump shows flags as tiny letters: S = SYN, S. = SYN-ACK, . = ACK, F = FIN, R = RST. so [S] [S.] [.] is literally the handshake, printed on your screen, milliseconds after it happened.

for testing with wireshark: capture on any interface, filter with tcp.flags.syn == 1, load a page, and watch the handshake packets light up. you can even right-click a packet → "Follow TCP Stream" to see the entire conversation from SYN to FIN.

why SYN makes sense of SYN flood attacks

this handshake is also why the classic SYN flood attack works: a client sends a SYN, the server replies SYN-ACK and reserves memory waiting for the final ACK that never comes. do that thousands of times with spoofed IPs and the server runs out of space for real connections. the ritual is the attack surface.