4 way handshake

 TCP 4-Way Handshake

Introduction

There is a certain reason why we call TCP a reliable connection. When a client needs to send some data to the server, before that, they need to decide what parameters they need to work with, for example, MSS and window scale. 

Similarly, when they need to close the connection, they both can't close directly; they need to tell that data transfer is finished, and we can close the established connection. In this blog, we will talk more about it.

Why is a 4-Way Handshake Required?

• TCP allows simultaneous data flow in both directions
• One side may finish sending data earlier than the other
• Each direction must be closed separately

Before we explain the process, keep in mind that Connection Termination can be initiated by any of the devices, it can be the client or the server. In our case, we are taking an example where the client is closing a connection.

States of 4 way handshake 

• ESTABLISHED: Connection is established, and data transfer is still going on.
• FIN_WAIT_1: Fin was sent by the client node to close the connection and is waiting for the server to respond with the ACK.
• FIN_WAIT_2: Acknowledgement was received from the server, and the client is now waiting for the FIN FLAG from the server.
• CLOSE_WAIT: This indicates that the server node has received a termination request FIN flag from the Client node but has not yet closed its own side of the connection.
• TIME_WAIT: Client is waiting for any other data that has not forwarded yet.

The process.

•  Firstly, the client will send a FIN flag to tell the server that data transfer is completed, and we can close this connection. At this moment, the Client node or device will be waiting for the ACK from the server node or device, and this wait time is known as FIN-WAIT-1.
Client ── FIN ──> Server


•  After receiving a FIN flag from the Client node, the Server will now move to close wait, and this indicates that the server node has received a termination request FIN flag from the Client node but has not yet closed its own side of the connection.
  
  
• A packet will be sent with the ACK flag set from the server node, and the Client node, which was waiting for the ACK, will now move to FIN-WAIT-2 and will wait for the FIN flag from the server node.
• Client  <─ ACK ──  Server
• Client  <─ FIN ──  Server
  
  
•  After receiving the FIN flag from the server node, the Client node will start a timer, which is known as the TIME WAIT timer, and during this timer device will wait, so if there is any packet that is still not received, it can be forwarded, and once this timer expires, the connection will be closed gracefully.
• Client  ── ACK ──>  Server

Wireshark Packet capture 

In this picture above, you can see that a FIN-ACK is forwarded by the client and then some application data is forwarded before closing the connection.

]

Here you can see the FIN and ACK flag is set to 1 to indicate that we are closing the connection.

Useful Command for 4-Way handshake

There are some useful Wireshark commands that you can to filter the traffic for the connection termination.

Show All TCP Traffic: tcp

Show Only Connection Termination Packets: tcp.flags.fin == 1

Show FIN and ACK Together: tcp.flags.fin == 1 || tcp.flags.ack == 1

Show Only FIN, ACK, FIN-ACK, ACK: (tcp.flags.fin == 1) || (tcp.flags.ack == 1 && tcp.len == 0)

 Client-Side Close Only: tcp.flags.fin == 1 && ip.src == <client_ip>

 Server-Side Close Only: tcp.flags.fin == 1 && ip.src == <server_ip>

Show Graceful vs Abrupt Close :  tcp.flags.fin == 1 || tcp.flags.reset == 1

 Show Only Pure ACKs  : tcp.flags.ack == 1 && tcp.flags.fin == 0 && tcp.len == 0

Detect CLOSE_WAIT Scenario : tcp.flags.fin == 1 || tcp.flags.push == 1

I hope you learned something today. If you want a blog or you have any suggesation how I can improve, let me know by adding a comment.