Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 24

TCP Handshake & Teardown Analysis with Packet Diagrams

Recommended resources

Welcome back! In our last lesson, we traced the journey of a web request through the TCP/IP model, establishing a foundational understanding of how different network layers collaborate. You learned that the Transport Layer is responsible for reliable, process-to-process communication, with TCP being the workhorse protocol for this task.

Today, we will zoom in on the mechanics of that reliability. This lesson will dissect the complete lifecycle of a TCP connection, from its birth to its closure. We'll analyze the famous three-way handshake used for connection establishment and the corresponding four-way handshake for termination. By the end of our session, you'll be able to interpret a packet diagram of these processes, understanding the role of each packet and the state transitions that occur on both the client and server.

The Problem: Establishing a Reliable Conversation

Before two parties can have a meaningful conversation, they need to agree that they are both ready to talk and listen. In networking, this is even more critical. TCP's promise of reliability requires that both the client and server synchronize their state before any application data is exchanged.

Specifically, they need to agree on the starting sequence numbers. As we've learned, TCP is a bi-directional protocol. This means that data flows in both directions simultaneously, and each side needs to track the bytes it sends and receives independently. The purpose of the connection establishment phase is for each side to choose a random Initial Sequence Number (ISN) and communicate it to the other.

The video below from Practical Networking explains this concept very clearly.

TCP - 12 simple ideas to explain the Transmission Control Protocol

This video provides a fantastic conceptual breakdown of TCP's core ideas. We'll focus on why the handshake is necessary in the first place.

First, watch the segment on bi-directional communication to understand that each party maintains its own sequence and acknowledgment numbers. Then, watch the next segment explaining the core purpose of the handshake: exchanging these initial sequence numbers (ISNs).

The Three-Way Handshake: SYN, SYN-ACK, ACK

With the "why" established, let's look at the "how". TCP uses a three-step process to reliably exchange ISNs and move both client and server into an ESTABLISHED state.

This diagram shows the complete TCP connection lifecycle. We will first focus on part 1, "Establishment (Three-Way Handshake)".

Let's break down the three steps, referring to the "Client" and "Server" in the diagram above:

  1. SYN (Synchronize): The client initiates the connection by sending a TCP segment with the SYN flag set. This packet contains the client's chosen Initial Sequence Number, let's call it ISN_C (in the diagram, seq=1000). The client is essentially saying, "I want to connect. My starting sequence number is 1000." At this point, the client enters the SYN_SENT state.

  2. SYN-ACK (Synchronize-Acknowledge): The server, which has been in a LISTEN state on a specific port, receives the SYN packet. It allocates resources for the new connection and responds with a TCP segment that has both the SYN and ACK flags set.

    • The SYN part contains the server's own chosen Initial Sequence Number, ISN_S (in the diagram, seq=5000).
    • The ACK part acknowledges the client's SYN. The acknowledgment number is set to ISN_C + 1 (in the diagram, ack=1001). This +1 is crucial; it confirms the server received the client's specific SYN packet.
      The server now enters the SYN_RECD state.

  3. ACK (Acknowledge): The client receives the server's SYN-ACK. It now knows the server's ISN. To complete the handshake, the client sends a final segment with the ACK flag set. The acknowledgment number is ISN_S + 1 (in the diagram, ack=5001), confirming receipt of the server's SYN. Upon sending this packet, the client moves to the ESTABLISHED state. When the server receives this final ACK, it also moves to ESTABLISHED.

The connection is now open, and both sides can begin exchanging application data.

The following reading provides another clear, step-by-step description of this process.

TCP Internals Step-by-Step for Engineers - Part 1

This article from Codeburst provides a concise explanation of the handshake with a simple diagram.

Please read the section titled Three-Way Handshake. Pay attention to how it describes the exchange of sequence numbers x and y.

A key detail is that SYN packets consume one sequence number, even though they carry no data. This is sometimes called a "phantom byte." It ensures that the acknowledgment number changes, preventing ambiguity.

TCP - 12 simple ideas to explain the Transmission Control Protocol

Let's return to the Practical Networking video for a detailed walkthrough of the handshake.

Watch the section that breaks down the four events within the three-way handshake, followed by the detailed explanation of how the sequence and acknowledgment numbers appear in the TCP headers, including the concept of the "phantom byte".

The Four-Way Handshake: Graceful Connection Teardown

Closing a connection is as important as opening one. Since a TCP connection is full-duplex, each side must be closed independently. This results in a four-step process, which allows one side to finish sending data while the other might still have data in transit.

Let's refer back to our diagram, focusing on part 3, "Termination (Four-Way Handshake)".

This diagram shows the complete TCP connection lifecycle. We will now focus on part 3, "Termination (Four-Way Handshake)".

  1. FIN (Finish): The client decides to close the connection. It sends a TCP segment with the FIN flag set (and its current sequence number, Seq X). This signifies, "I have no more data to send." The client enters the FIN_WAIT_1 state.

  2. ACK: The server receives the FIN and sends an acknowledgment packet (ACK, Seq Y, Ack X+1). The server's application is notified that the client wants to close the connection. The server enters the CLOSE_WAIT state. At this point, the connection is half-closed: the client will no longer send data, but the server can still send data to the client. When the client receives this ACK, it enters the FIN_WAIT_2 state.

  3. FIN: Once the server has also finished sending all its data, its application signals to close the connection. The server then sends its own FIN packet (FIN, Ack (X+1), Seq Y). The server now moves to the LAST_ACK state, waiting for the final acknowledgment.

  4. ACK: The client receives the server's FIN and sends a final ACK packet (ACK, Seq (X+1), Ack (Y+1)). Upon sending this, the client enters the TIME_WAIT state. This is a safety mechanism to ensure the final ACK is received and to handle any delayed packets from the old connection. After a timeout period (typically 2 * Maximum Segment Lifetime), the client connection is fully CLOSED. When the server receives this final ACK, it immediately moves to the CLOSED state.

The following text provides a formal description of the TCP state machine and the closing sequence.

12: TCP Transport

This resource from Engineering LibreTexts offers a more formal, in-depth look at the states involved in connection management.

First, quickly review the state diagram to get a visual map of all the states we've discussed (e.g., LISTEN, ESTABLISHED, FIN_WAIT_1). Then, read the subsection Closing a connection. This part details the active vs. passive close paths and explains why the server might not send its FIN immediately.

Abrupt Termination: The RST Packet

While the FIN handshake is the "polite" way to end a conversation, TCP also has an abrupt, "ungraceful" method: the RST (Reset) packet.

A RST packet immediately terminates the connection. The receiving side is notified of an error, and both sides discard any buffered data and release all resources for the connection. There is no acknowledgment; the connection is simply gone.

This is used in situations like:

  • An attempt to connect to a port where no process is listening.
  • A fatal protocol error or mismatched sequence numbers.
  • An application explicitly requesting an abort of the connection.

TCP - 12 simple ideas to explain the Transmission Control Protocol

The Practical Networking video concludes by contrasting the graceful and ungraceful closing methods.

First, watch the brief introduction to the two closing methods. Then, skip to the final idea and watch the explanation of the ungraceful reset mechanism.

Conclusion

Today we've demystified the process of TCP connection management. You've seen how the intricate dance of SYN, FIN, and ACK packets ensures that a reliable, ordered stream of communication can be established and terminated gracefully between two endpoints on the internet.

Key Takeaways:

  • The three-way handshake (SYN, SYN-ACK, ACK) is essential for both client and server to synchronize their Initial Sequence Numbers (ISNs) before data transfer begins.
  • The four-way handshake (FIN, ACK, FIN, ACK) provides a graceful shutdown, allowing each direction of a full-duplex connection to terminate independently. This creates a "half-closed" state.
  • The TCP state machine (LISTEN, ESTABLISHED, FIN_WAIT, TIME_WAIT, etc.) provides a formal model for the lifecycle of a connection.
  • FIN packets, like SYN packets, consume a sequence number to enable reliable acknowledgment.
  • A RST packet provides an immediate, ungraceful termination for error conditions.

In our next lesson, we will broaden our view of the Transport Layer by comparing TCP with its main counterpart, UDP. We will explore the characteristics that make UDP different and analyze scenarios where its low-overhead, "best-effort" delivery is more suitable than TCP's guaranteed reliability.