TCP Handshake & Packet Flow

Why three steps to say hello?

Two segments wouldn't be enough. TCP needs both sides to prove they can send and receive, and both sides need to pick and confirm a random initial sequence number so both ends can track exactly which bytes have been sent and received.

SYN proves the client can send and picks the client's initial sequence number.
SYN-ACK proves the server can send and receive (it acknowledges the client's SYN) and picks the server's own initial sequence number.
ACK proves the client can receive too, acknowledging the server's SYN. Only now do both sides know the round trip works in both directions.

ClientCLOSED ServerLISTEN

Packet log

Press "Next" to begin the handshake.

TCP flag glossary

Flag	Meaning
SYN	"Synchronize" — requests a new connection and proposes an initial sequence number.
ACK	Acknowledges data or a control flag was received; carries the "ack" number, which is always one more than the last byte received.
PSH	"Push" — tells the receiving OS to hand the data straight to the application instead of buffering it, used for interactive data.
FIN	"Finish" — sender has no more data to send and wants to close its side of the connection.
RST	"Reset" — abruptly aborts a connection, e.g. when a segment arrives for a port nothing is listening on. Not part of a normal handshake or teardown.
URG	"Urgent" — marks part of the segment as needing out-of-band priority handling. Rarely used in modern applications.

Common gotchas

SYN flood attacks abuse step 1: an attacker sends many SYNs and never completes the handshake, hoping to exhaust the server's half-open connection table. Defenses include SYN cookies. See the Network Attacks & Defenses page for an interactive version of this exact attack.
TIME_WAIT isn't a bug. The side that sends the last ACK of the teardown waits (often 30–120 seconds) before fully releasing the port, in case that ACK was lost and the FIN needs to be retransmitted. This is why a busy server can occasionally show many connections stuck in TIME_WAIT.
RST isn't part of a graceful close. An RST tears down a connection immediately with no acknowledgment and no guarantee that in-flight data was delivered — it's what you see when a connection is refused, killed abruptly, or a firewall blocks it and spoofs a reset.
Both sides can close independently. This page shows the client closing first, but either side can send the first FIN — the other side isn't required to close immediately after (it can keep sending data during the "half-closed" state before sending its own FIN).