TCP Handshake Explained: How the Three-Way Handshake Works

Quick Answer

The TCP three-way handshake establishes a connection through three messages: SYN, SYN-ACK and ACK. The endpoints exchange initial sequence numbers and acknowledge each other’s synchronization request before proceeding with ordinary data exchange in the basic model. MDN’s TCP handshake overview describes this sequence.

A completed handshake establishes transport connection state. It does not establish that a website, API or proxy request will succeed.

Five distinctions help interpret the result:

• TCP Handshake ≠ TLS Handshake
• TCP Connection Established ≠ Application Request Successful
• Port Reachable ≠ Application Healthy
• Handshake Latency ≠ Total Application Latency
• Packet Sent ≠ Packet Acknowledged

Understanding the handshake therefore involves two questions: what did the endpoints exchange, and what can the available observations actually prove?

Key Takeaways

• SYN, SYN-ACK and ACK perform different roles in connection establishment.
• The client and server maintain their own connection state.
• A client-side observation does not automatically establish what the server received.
• TCP connectivity, TLS negotiation and HTTP responses are separate diagnostic checkpoints.
• Missing responses can have several explanations; they do not identify a firewall or closed port by themselves.
• A connection to a proxy says nothing conclusive about the proxy’s connection to its destination.
• HTTP/3 uses a different transport setup and does not perform the traditional TCP handshake.

How Does the Three-Way Handshake Work?

In the standard client-server model, the client actively opens a connection and the server listens for incoming connections. SYN begins synchronization, SYN-ACK combines the server’s synchronization request with an acknowledgment, and the final ACK acknowledges the server’s request.

The example below assumes no loss and no data in the handshake segments. The symbols x and y represent independently selected initial sequence numbers, or ISNs.

SYN requests sequence synchronization. ACK marks the acknowledgment field as meaningful. SYN-ACK is one segment with both flags set, not two separate messages.

In step 2, the server acknowledges the client’s SYN while supplying its own ISN. In step 3, the client acknowledges the server’s SYN. Microsoft’s connection-establishment example illustrates these flags and fields in a documented capture.

The table above is a conceptual example, not a Mango packet capture.

Why Does TCP Need Three Steps?

Both endpoints must exchange initial sequence numbers and receive acknowledgment of their own SYN. The server combines its acknowledgment and SYN into the second message; the third message confirms receipt of the server’s SYN.

The exchange also helps prevent an old duplicate connection attempt from being mistaken for a valid new connection. The purpose extends beyond checking whether two machines can exchange packets. RFC 9293, §3.4.1 explains this rationale.

What Do Sequence and Acknowledgment Numbers Mean?

Sequence numbers track positions in TCP’s byte stream. The acknowledgment number identifies the next expected position.

A SYN consumes one sequence-space position, making synchronization itself acknowledgeable. That explains x + 1 and y + 1 in the table. An ACK without data consumes no sequence space. RFC 9293, §3.4 defines these rules.

The practical distinction is between the Seq field, which describes the sender’s sequence position, and the Ack field, which describes progress in receiving the other direction.

When Do the Endpoints Enter ESTABLISHED?

The client and server reach ESTABLISHED at different moments in the ordinary exchange.

These are connection-state transitions, not application-health checks. RFC 9293, §3.5 specifies the exchange.

The server-side progression describes the connection being created. It should not be read as the listening service abandoning its ability to accept other clients. Implementations distinguish listening context from incoming connection state, as discussed in RFC 4987, §2.

What Does a Successful TCP Handshake Prove?

A completed TCP handshake establishes transport connection state between the participating TCP endpoints under the observed conditions.

The phrase “participating TCP endpoints” matters. An endpoint might be a proxy or frontend rather than the application’s backend.

The phrase “observed conditions” matters too. A result applies to the connection and evidence being examined; it is not a permanent guarantee.

These limits follow from separating transport setup from the functions of TLS and HTTP. A successful earlier stage does not establish the outcome of a later one.

Viewpoint Changes the Conclusion

Suppose a client-side capture shows SYN, SYN-ACK and an outgoing ACK.

The capture supports the statement that the client observed the response and sent its final acknowledgment. It does not, by itself, prove that the server received and processed that ACK.

A more precise report would say:

The client-side capture shows the expected handshake exchange, including an outgoing final ACK. Server-side completion has not been independently observed.

That wording preserves useful evidence without claiming more visibility than the capture provides.

The same discipline applies to a monitoring result labeled “connected.” Before interpreting it, identify which endpoint was tested and what event the monitoring system counts as success.

Why Can a TCP Handshake Fail?

A handshake can remain incomplete because an expected message is not delivered, is not accepted, or cannot be processed before the attempt ends. The observed symptom narrows the investigation but usually does not establish one unique cause.

This matrix lists possibilities, not automatic diagnoses.

No SYN-ACK does not uniquely mean firewall filtering. No response does not uniquely mean a closed port. Different forward and reverse routes are also not inherently a fault; the question is whether communication works in both directions.

Retransmission and Timeout

TCP uses a retransmission timer for outstanding segments. When the expected acknowledgment does not arrive, retransmission can occur. RFC 6298 specifies the retransmission-timeout framework.

There is no single retry count or total connection timeout that accurately describes every environment. Operating systems, application deadlines and intermediate devices can affect when an attempt ends.

For example, Linux’s TCP documentation exposes separate controls for SYN retries and behavior under connection-queue pressure. Those are implementation details, not universal defaults for TCP.

What Does RST Mean?

RST signals a reset; its meaning depends on the connection state and surrounding exchange. TCP’s reset rules are specified in RFC 9293, §3.5.2.

A closed port is one possible context. A reset alone should not be treated as proof of that diagnosis.

How Long Does a TCP Handshake Take?

For a new ordinary connection without loss, TCP setup introduces roughly one network round trip before the client can send ordinary application data in the basic model. That is not the same as the time until the server receives a request or the application returns a response.

TCP Fast Open, RFC 7413, describes an extension that permits earlier data exchange under its rules. Its existence is one reason to avoid saying that application data can never accompany connection establishment.

Several boundaries matter when interpreting timing:

• Retransmissions can extend setup.
• TLS negotiation and application processing add separate work.
• Reusing an existing connection avoids another TCP handshake for that connection.
• Measurements depend on their start event, end event and observation point.

For example, measuring from the client’s outgoing SYN to its incoming SYN-ACK answers a narrower question than measuring until a complete API response arrives.

Handshake latency is one component of an interaction, not a substitute for total application latency.

What Is the Difference Between a TCP Handshake and a TLS Handshake?

TCP establishes transport connection state. TLS negotiates cryptographic protection and authentication parameters. Completing TCP setup does not establish that TLS negotiation or certificate validation will succeed.

For an ordinary new HTTPS connection over TCP, the basic conceptual sequence is:

TCP Established ≠ TLS Success ≠ HTTP/Application Success

TLS 1.3, RFC 8446, defines the security negotiation. The table is a basic model for HTTPS over TCP, not a universal sequence for every web connection.

Does HTTP/3 Use a TCP Handshake?

No. HTTP/3 uses QUIC over UDP, so its transport setup does not include the traditional TCP three-way handshake. QUIC integrates TLS into its own connection-establishment process. This relationship is defined by RFC 9114, RFC 9000 and RFC 9001.

That difference does not establish a universal speed advantage for every connection or workload.

Is a TCP Handshake the Same as an HTTP Request?

No. TCP connection establishment and HTTP request processing are separate events. A TCP handshake does not contain an HTTP method, establish an HTTP status code or determine whether an application accepts a request.

An established connection can be followed by an authentication challenge, a rejected request or a server error. A connection might also be established before any HTTP request is sent.

HTTP defines its own request and response semantics, including status codes. Those semantics are specified in RFC 9110.

For automation, the useful question is therefore more specific than “Did the connection work?”

Ask which event succeeded: TCP setup, TLS negotiation, proxy authentication, HTTP exchange or the required application operation.

How Do TCP Handshakes Relate to Proxies?

A proxy can participate in separate transport connections with the client and destination. Success on the client-facing connection does not establish success on the destination-facing connection.

HTTP CONNECT requests tunnel establishment after the initial connection to the proxy. SOCKS CONNECT similarly includes a proxy request and reply beyond the initial TCP connection. See HTTP CONNECT and SOCKS5, RFC 1928.

This is a conceptual model. It does not mean every proxy architecture creates exactly two new TCP connections for every request, or that transport boundaries always match TLS boundaries.

For errors beyond basic connection establishment, continue with Proxy Errors Explained.

Practical Examples

The following scenarios are conceptual examples, not measured packet captures.

Example 1: The Final ACK Is Visible Only at the Client

A capture records the expected SYN, SYN-ACK and outgoing ACK. No server-side capture or connection-state observation is available.

The defensible conclusion is that the client observed and sent the expected messages. The evidence does not independently establish receipt of the final ACK at the server.

The missing observation should remain explicit in the report.

Example 2: TCP Works, but HTTPS Does Not

A client establishes TCP connectivity to an HTTPS endpoint. The subsequent TLS attempt fails certificate validation.

The transport result and security result differ. Reporting this simply as “the port is closed” would discard the evidence that TCP connectivity succeeded.

The next relevant evidence comes from the TLS error and validation context.

Example 3: The Proxy Is Reachable, but the Request Is Rejected

A client connects to an HTTP proxy. The proxy returns an authentication challenge instead of establishing the requested tunnel.

The client-facing TCP connection worked. Proxy authentication did not complete successfully, and the destination connection cannot be inferred from that first success.

Example 4: The Connection Is Fast, but the Application Is Slow

TCP setup completes promptly, but the application takes much longer to produce its response.

The observations describe two different intervals. A fast setup does not exclude slow application processing or delays in an application dependency.

Identify the Connection and the Evidence First

Before interpreting a connectivity result, record:

1. Which endpoint and port were tested.
2. Where the observation was made.
3. Which event counted as success.
4. Whether the next protocol or application stage was tested separately.

Mango’s Port Scanner provides a way to check port accessibility. Treat its result as evidence about the check performed, not as certificate validation, authentication verification or a complete application-health assessment.

The useful diagnostic habit is to match each conclusion to the layer actually observed.

Final Thoughts

The value of understanding a TCP handshake extends beyond recognizing three messages. It helps separate connection establishment from the outcomes that follow.

A useful diagnosis identifies the participating endpoints, the observation point and the event that actually succeeded. That prevents a reachable proxy from being mistaken for a reachable destination, or an established TCP connection from being mistaken for a healthy application.

Glossary

Frequently asked questions

Here we answered the most frequently asked questions.

Ask a question

What are the three messages in a TCP handshake?

The standard exchange is SYN from the client, SYN-ACK from the server and ACK from the client.

Why is SYN-ACK one message?

The server combines its own synchronization request with acknowledgment of the client’s SYN.

Does seeing the final ACK prove that the server received it?

An outgoing ACK in a client-side capture proves only that the capture observed it leaving that point. Server-side receipt or processing requires corresponding evidence.

Does a TCP timeout prove that a firewall blocked the connection?

No. Loss, routing problems, an unavailable endpoint, resource limitations and other conditions can produce similar symptoms.

Does an open port mean the application is healthy?

No. Port accessibility does not establish that the required application operation, authentication or backend dependency works.

Does every HTTP request require a new TCP handshake?

No. HTTP can reuse an existing connection. A request on an already established connection does not require a fresh TCP handshake. HTTP/3 uses QUIC instead of TCP.

Can TCP succeed while TLS fails?

Yes. Transport connectivity can succeed while later TLS negotiation or certificate validation fails.

Can a proxy connection succeed while the destination request fails?

Yes. The client-facing proxy connection, proxy negotiation, destination-facing connection and application request can have different outcomes.