TCP Three-Way Handshake Explained
TCP connects two endpoints and delivers an ordered stream of bytes. Its three-way handshake synchronizes sequence numbers before application data is exchanged.
Published by Protocol Explorer · Reviewed
How the TCP handshake works
The client sends a SYN with its initial sequence number. The server replies with SYN and ACK, acknowledging the client’s sequence number and offering its own. The client then acknowledges the server’s sequence number. Both endpoints can now exchange data.
Sequence numbers and acknowledgments
TCP numbers bytes in each direction. An acknowledgment identifies the next byte the receiver expects. If data is lost, TCP can retransmit it; acknowledgments and timers help the sender detect missing data. Applications receive an ordered byte stream, not the original packet boundaries.
Flow control and connection closure
The receive window tells the sender how much data the receiver is prepared to accept. Congestion control also limits the sender according to network conditions. Either endpoint can close its sending direction with FIN; a reset terminates a connection differently.
Read a TCP packet
Compare source and destination ports, sequence and acknowledgment numbers, flags and window size. Follow both directions of the exchange: an ACK is meaningful in relation to bytes sent by the other endpoint.
How TCP works after the handshake
After establishment, each endpoint can send bytes and acknowledge received bytes. TCP segments can carry data and acknowledgments together. The sequence space describes bytes, so a segment boundary is not necessarily an application-message boundary.
When loss is detected, a sender retransmits data according to its loss-recovery algorithm. Flow control protects the receiver from being overwhelmed, while congestion control responds to network conditions. These mechanisms interact but solve different problems.
Frequently asked questions
Is every TCP connection an HTTPS connection?
No. TCP is a transport protocol used by many applications. HTTPS over TCP adds TLS and HTTP; HTTP/3 instead uses QUIC over UDP.
Does a TCP acknowledgment prove the application processed the data?
No. A TCP acknowledgment indicates receipt by the remote TCP endpoint, not that an application has completed its work.
Follow an example step by step
- Identify the SYN and record the client initial sequence number.
- Match the server SYN-ACK to the client SYN, then find the client acknowledgment.
- Follow data segments and compare byte sequence ranges with subsequent acknowledgments.
Common interpretation mistake
A retransmitted sequence range can suggest loss, but a capture point and asymmetric routing can also affect what appears in a trace.
Key point to remember
TCP acknowledgments do not prove that the receiving application processed the data.
Try the interactive lesson
Open Protocol Explorer and select TCP to follow the exchange packet by packet. The TCP lesson is free and does not require an account. Pro is a one-time $4.99 purchase for the full library; an account is required to buy and restore it.
Open Protocol Explorer · Free and Pro access
Primary reference
RFC 9293: Transmission Control Protocol
Related protocol lessons
UDP · HTTP · HTTPS · How to read a packet