Understanding an HTTP or HTTPS conversation and the 3 way handshake in Wireshark

Home > Search
  by

When the client starts the application that will request resources from the server, the TCP connection must be established using the 3 way handshake.

HTTP

HTTPS


After the connection has been established, there can be anywhere from a few to hundreds of packets. If using HTTP, you should at least see a GET request from the client to the server, an ACK from the server to the client, and an OK from the server to the client.

 

If using HTTPS, there should be a TLSv1.2 packets to establish a secured, encrypted connection.

 


Next, there will usually be some sort of payload to transfer from the server to the client. HTTP Continuation packets are common, as these packets are segments of the payload.

For a deeper understanding of HTTP Continuation packets, refer to the article on Understanding HTTP Continuation or TCP segment of a reassembled PDU packets in Wireshark.


When the client application remains idle for some time, the client will send a Keep Alive ACK to the server. In this example, we see 2 TCP Keep-Alive packets, one from the client to the server and another from the server to the client. This is normal, and not suggestive of a problem. The client is simply asking the server to keep the TCP connection alive, and the server acknowledges (ACK) the request to keep the connection alive.


When the client closes the application, the TCP connection will be closed. The client will send a FIN ACK request packet to the server, the server will send a FIN ACK response packet to the client, and lastly the client with send an ACK packet to the server, and the TCP connection is closed.

HTTP

HTTPS



Add a Comment




We will never share your name or email with anyone. Enter your email if you would like to be notified when we respond to your comment.




Please enter in the box below so that we can be sure you are a human.




Comments