Mastering TCP Packet Analysis with Wireshark: A Guide to Understanding HTTPS Data Flows and Network Anomalies

Introduction

Overview

In this article, Wireshark is used for TCP packet analysis of a specific HTTPS request.

Objective

Understand TCP packets through practical packet capture analysis.

Preparations

I installed Wireshark version 2.2.6 on my machine, randomly located a TCP connection, and followed the stream.

/>2018228104429-1 />2018228104751-2201822817932-29

Transmission

Establishing Connection

• No58: 10.60.45.187:17932 (hereafter referred to as the client) sent a SYN request to 131.25.61.68:443 (hereafter referred to as the server), with seq=0, ack=0.
• No79: The server sent a SYN+ACK to the client, with seq=0, ack=1.
• No81: The client received the server’s SYN+ACK and responded with an ACK, with seq=1, ack=1. Since the captured TCP uses the HTTPS protocol, authentication is required first for the connection, as illustrated below.

  

  20182281194-4

Handshake

• No84: The client initiated a handshake with the server, but specific packet analysis is not detailed here.

  

  201822811650-3 The total SSL length is 239 bytes (including ContentType of 1 byte, Version of 2 bytes, Length of 2 bytes, plus 234 bytes for the handshake protocol length).

2018228112520-52018228112523-62018228112526-7

• No103: After receiving the client’s handshake request, the server responded with an ACK packet, indicating seq=1, ack=1. This packet is a special TCP Window Update, where the server informs the client of sufficient buffer size (8192) to receive the client’s data normally. If a TCP Window Full packet appears, it indicates the buffer is full, and the client will stop sending until a TCP Window Update is received. (Window value indicates the sliding window, allowing multiple packets to be acknowledged by a single ACK packet.)
• No104: The server initiated a handshake with the client. As the server needs to return certificate and algorithm information, the packet might exceed 1460 bytes, resulting in fragmentation (No136 indicates the total packet size is 5984KB, split into 5 packets). The current server’s seq=1, ack=240 (current packet size is 1460, No84 indicates a client packet size of 239.)

  

  201822811397-8
• No105: The server sent handshake data to the client, marked as TCP Previous segment not captured, indicating possible packet disorder or loss. This packet’s seq=2921, while No104’s next packet seq should be 1461; the packet between No104 and No105 (seq=1461) might be lost or out of order.

  

  2018228114447-9
• No106: The server sent handshake data to the client, with seq=4381. Since No105’s next packet’s seq matches this one, these packets were transmitted in order. The next packet’s seq is 5841.

  

  2018228115030-10
• No108: The client sent an ACK to the server with ack=1461, confirming the receipt of No104.

  

  201822816532-23
• No118: The server sent an ACK packet to the client, marked as TCP Out-Of-Order, due to packet loss in No105, and TCP retransmitted all packets before No104, effectively retransmitting No104 itself.

  

  201822812016-12
• No119: The client sent an ACK to the server, marked as TCP Dup ACK 108#1, indicating a retransmitted ACK packet caused by No118. Since No118 sent an out-of-order packet from the server, but the client confirmed receipt of No104 in No108, the client retransmitted No108 to inform the server it received No104; hence, this packet is discarded by the server.
• No123 and No124: The server sent handshake data to the client, marked as TCP Retransmission, with seq values 1461 and 2921, respectively. As the server considered these packets sent (seq=1461 was unsent, as inferred from No105; seq=2921 was sent but lacked a response ACK from the client), the server retransmitted them due to the prolonged absence of the client’s ACK.

  

  201822812398-13
• No127: The client sent an ACK to the server. seq=240, ack=5841, indicating all packets before seq=5841 were received.
• No132: The server sent handshake data to the client, marked as TCP Spurious Retransmission, indicating the packet was previously sent. The seq is 1461, corresponding to the retransmitted No123. Despite the client’s ACK indicating receipt of all packets before seq=5841, the server might not have received this ACK.

  

  2018228135613-14
• No133: The client sent an ACK to the server. seq=240, ack=5841. The packet is marked as TCP Dup ACK 127#1. Although the client returned ack=5841 in No127, the server still retransmitted previously sent packets in No132, leading the client to suspect the server didn’t receive No127, prompting a retransmission of this ACK. This packet is discarded by the server as it was already received.
• No136: The server sent the final handshake packet to the client. seq=5841. Next packet seq=5985, summarizing the contents and information of the 5 fragmented packets.

  

  201822814102-16

  

  2018228141317-17
• No140: The client sent an ACK to the server. seq=240, ack=5985.

  

  2018228141727-18

Key Generation

• No141: The client generated a key pair and sent it to the server after receiving the server’s handshake request. Since all packets from No103 were server-to-client transmissions, the client’s seq remained 240.

  

  2018228141948-19
• No147: The server retransmitted No136 to the client. Since the client had already confirmed receiving all packets before seq=5985 in No140, this packet resulted in a spurious retransmission.
• No148: The client sent an ACK to the server. This packet was marked as TCP Dup ACK 140#1 due to the server’s spurious retransmission in No147, prompting the client to resend No140.
• No152: The server sent a packet to the client marked as Change Cipher Spec, Encrypted Handshake Message, indicating encryption of handshake information.
• No153: The client sent an ACK to the server, acknowledging the receipt of No152.

Data Transmission

• No154-No159: The client sent data to the server.
• No166 and No167: The server sent 2 ACK packets to the client.
• No170: The server sent data to the client.
• No171: The client sent an ACK to the server, confirming receipt of No170.
• No178: The server sent further data to the client, constituting the remaining data fragmented from No170.
• No179: The client sent an ACK to the server, seq=8331, ack=8770, confirming receipt of No178.

  

  2018228144225-21 No152 to No179 were normally transmitted packets, thus no detailed analysis is provided here.

Connection Disconnection

• No180: After the client completed receiving data from the server, it disconnected, sending a FIN packet and entering the FIN_WAIT_1 state.

2018228161043-24

Theoretically, the server closes the HTTP connection actively after sending data, but packet capture reveals the client was first to send a FIN+ACK packet, suggesting packet loss or delay of the server’s FIN+ACK.

2018228164349-28

• No187: The server sent a FIN+PSH+ACK to the client, seq=7552, ack=8331. This packet not only carried a FIN to close the connection but also contained a PSH flag, indicating No178 was dispatched, but the server didn’t receive (or received late) the client’s ACK packets from No179 and No180 (potentially due to network handling issues).
• No188: As No187 was marked as TCP Out-Of-Order, the client responded by retransmitting No179, assuming disordered packets from the server.

  

  2018228162321-25
• No189: The server acknowledged the client’s FIN and received No188, sending back an ACK, updating seq to the latest 8770, transitioning the client to the FIN_WAIT_2 state.

201822816264-26

• No198: The server sent a RST to the client to reset the connection, potentially due to network issues between No179 and No187 causing connection anomalies, prompting the server to issue a RST to reset the connection.

Conclusion

The analyzed packets above suggest multiple occurrences of network anomalies or fluctuations, including disorder, retransmission, spurious retransmission, and connection reset of TCP packets.

If there are errors in the analysis, please correct them.