Mastering TCP Header Analysis with Wireshark: Step-by-Step Guide to Packet Capture and Three-way Handshake

Packet Capture Process

Used Wireshark for packet capturing, demonstrating the packet capture with the two most common commands: curl and ping. Start capturing.

Code Language: javascriptCopy

## First, visit my own website’s homepage curl https://zengzhiqin.kuaizhan.com ## Then, check my own website's address ping https://zengzhiqin.kuaizhan.com

Wireshark filters based on the address obtained from the ping command to capture packets from the above two commands, primarily including TCP (HTTPS is based on the TCP protocol) and ICMP (the ping command is based on the ICMP protocol) packets, as shown in the figure below:

Packet Capture Analysis

TCP Header Analysis

Contents of the TCP header correspond one-to-one

TCP Header

Brief analysis of header contents:

1. Source and Destination Ports

Packets navigate through the transport layer, reaching machines and numerous applications. For example, if Alice is flirting with Bob via WeChat, and Bob is using both QQ and WeChat, it’s the port numbers distinguishing the services. Therefore, QQ and WeChat ports are different, ensuring messages reach the correct application.

1. Sequence Number and Acknowledgment Number

During data segmentation, sequence numbers ensure reassembly in the correct order, with acknowledgments ensuring data integrity.

• The figure shows analysis of five consecutive request packet sequence numbers and acknowledgment numbers for sequence analysis:

Analysis is as follows:

Sequence numbers determine the position of transmitted content and track which byte has been reached. The receiver uses sequence numbers to reassemble data. Relative sequence numbers and acknowledgments simplify random numbering.

Next sequence number = Previous request’s sequence number + Data length

• Request-response process is as follows

Request-response

Acknowledgment confirms which packet’s sequence it is responding to, hence Ack = Request packet’s Seq + Data length. Through sequence, acknowledgment numbers, and data length, packet completeness is checked.

1. Data Offset

Specifies header length. Besides the 20-byte fixed length, options have variable length, so offset indicates header length position.

1. Reserved

This 6-bit binary is unused

1. Flags

Connection request packet’s flags

Flags Explanation

Notes: Upper case denotes flags like ACK; lower case for acknowledgment numbers like Ack.

1. Window

TCP is reliable. It has receive/send buffers (called windows), employing sliding window technique for reliable transmission. (Details elaborated in the next article about reliable transmission and congestion control)

1. Checksum

Ensures correctness and completeness of TCP header and data upon arrival.

1. Urgent Pointer

If URG is set, this field is checked as an extra instruction telling the CPU where to start reading data in this urgent packet. Interjecting queues the original order, prioritizing specific team members urgently needing handling, documenting them separately first.

1. Options

Specifies maximum datagram size and supports selective acknowledgment.

1. Padding

Options and padding total 40 bytes. Padding covers any deficit to reach total capacity.

TCP Three-Way Handshake

Bob as client, Lin Pinru as server

Three-step handshake establishes a marriage

Handshake Process:

(Client) Bob: Pinru, you’re so beautifulThe client initiates request, setting SYN in the header to 1 indicating intent to connect, sending a random sequence number x. Bob enters SYN_SENT state awaiting love;

SYN Packet: SYN=1, ACK=0, Seq=x

(Server) Pinru: Bob, you’re handsomeThe server acknowledges with SYN+ACK, randomly generating sequence number y, indicating response to Bob’s x+1 sequence number. Pinru enters SYN_RCVD willing waiting state

SYN+ACK Packet: SYN=1, ACK=1, Seq=y, Ack=x+1

(Client) Bob: Pinru, let’s marryThe client confirms connection post server reply, sets ACK, indicating acknowledgment, Ack=y+1, confirming server's packet. Seq=x+1. Bob receives response, enters ESTABLISHED marriage state, Pinru also agrees.

ACK Packet: ACK=1, Seq=x+1, Ack=y+1

Summary:

No data is transmitted pre-connection, yet SYN and ACK states incur a sequence number. Hence sequence numbers increment by 1 pre-connection and increase by data length post-connection.

• Ack=Seq + Data length;
• Seq = Previous sequence number + Data length;
• Next Seq = Previous response’s Ack

Insight:Leveraging Wireshark’s analysis tools by accessing Statistic > Follow Graph provides a visual of the handshake, termination, and sequence numbers:

TCP

TCP Four-Way Termination

image

The sequence number and acknowledgment number analysis during four-way termination resemble handshake analysis, hence showing Bob.

Four-Way Termination

(Client) Bob: You’re not exciting enough

(Server) Pinru: Isn’t my wardrobe appealing?

(Server) Pinru: Fine, enjoy my clothes. I’m diving in the sea

(Client) Bob: You love the sea, I once loved you

This termination process should be reviewed via figure, detailing too much. Focus on states, sequence, and acknowledgment numbers.

Common Interview Questions

Why is the handshake three times, but the termination four times?

Reason for Three-Way Handshake:

Usually, if the client initiates a request and the server responds, it signifies a well-functioning network capable of data transmission. Why the third packet then?

Initially, an unsuccessful connection request prompts the client to persistently retry, causing multiple requests.

The Tale of Bob and Pinru

Bob as client A, Saruman as client B, Pinru as server

1. Imagine Bob, pre-proposal, detours to the US for roses, then Saruman exits jail and directly proposes to Pinru. Pinru accepts Saruman’s proposal awaiting a sea date;
2. Bob arrives, Pinru finds him handsome, remains unmarried and accepts Bob’s proposal too, awaiting another sea date;
3. Consider all men worldwide proposing once to Pinru—she’s inundated.The key is determining authenticity. This warrant’s third confirmation, solidifying the marriage, dismissing others.

With only two attempts, confirmed response misconceived as connection. Without three’s confirmation, two notable issues arise:

• First, stale connections persist as network latency causes repeated client requests. Eventually, outdated requests establish unnecessary connections, consuming resources. Post third handshake confirmation, the server establishes connection, discarding stale ones.

• Second, missing acknowledgment cycles deadlock, as shown below.

Reason for Four-Way Termination

Ending ties isn’t easy, urban life affirms.

The server may still have data pending post-closure request, continuing transmission before notifying closure, then, client closes.

Why does the TIME_WAIT state need to last 2MSL (Maximum Segment Lifetime) before returning to the CLOSE state?

MSL defines a segment’s maximum network survival duration. 2MSL doubles MSL for maximum transit time of request-response.

The network’s unreliability means missing ACK risks sustained FIN from the server in client’s absence, causing closure issues. Hence, 2MSL waits reassure no incoming FIN, allowing safe closure.

Feels like scripting, recalling Pinru’s wardrobe. Appreciate decipherable writing? `Like` or `Your Thoughts` for encouragement. Thanks for reading~

Coming Next:

Implementing TCP Traffic Control and Congestion Management