Understanding TCP Sequence, Acknowledgment, and Length Numbers — The “Book Page” Analogy

TCP is the foundation of reliable communication on the internet. Understanding how sequence numbers, acknowledgment numbers, payload lengths, and next sequence numbers work is crucial for network engineers, developers, and anyone analyzing TCP traffic. Let’s break it down in a simple yet detailed way.

 1️⃣ Sequence Number (Seq) → “Letter Number”

Think of TCP as sending a long book, page by page, from the sender to the receiver.

• Each page (or even each byte) has a number. This number is called the Sequence Number (Seq).
• It uniquely identifies each byte in the TCP stream.
• Example:
• Your first page of the book is numbered 0.
• If you send 100 bytes, Seq starts at 0, the last byte has number 99, and the next byte will be 100.

📘 Analogy:
Seq = 0 → First page of the book.
Seq = 1 → Second page of the book.

 2️⃣ Acknowledgment Number (Ack) → “Received Up To”

When the receiver gets pages from the sender, it responds: “I got up to page 1. Please send me the next page starting from page 2.”

• That “next page I want” is the Acknowledgment Number (Ack).
• Ack always points to the next byte the receiver expects.
• Example:
• Sender sends bytes 0–99.
• Receiver sends Ack = 100 → “I got everything up to byte 99; please start from 100.”

📘 Analogy: Ack = 100 → Receiver has read all pages up to 99 and is requesting page 100 next.

3️⃣ Length (Len) → “Pages in This Segment”

Each TCP segment may carry some payload data.

• The Len field tells us how many bytes (or pages) are included in this segment.
• Example:
• Seq = 101, Len = 50 → This segment contains pages 101–150.

📘 Analogy: “Here are 50 pages starting from page 101.” 

4️⃣ Next Sequence Number (NextSeq) → “Next Page to Send”

After sending some data, the sender keeps track of what comes next.

• Formula depends on whether the segment has payload or control flags (SYN, FIN):
• No payload (SYN, FIN, pure ACK):
• SYN consumes 1 sequence number.
• FIN consumes 1 sequence number.
• Pure ACK consumes 0 sequence numbers.
• NextSeq = Seq + (1 if SYN/FIN else 0)
• With payload:
• NextSeq = Seq + TCP payload length
• Example:
• Seq = 0, SYN = 1 byte → NextSeq = 1
• Seq = 1, Payload = 446 → NextSeq = 447

📘 Analogy: “I’ve sent up to page 446; the next one I send will be page 447.” 

5️⃣ Rules for Next Sequence Number 

Scenario	Formula	Example
SYN only	NextSeq = Seq + 1	Seq = 0 → NextSeq = 1
FIN only	NextSeq = Seq + 1	Seq = 1000 → NextSeq = 1001
Pure ACK	NextSeq = Seq	Seq = 1 → NextSeq = 1
With payload	NextSeq = Seq + Len	Seq = 1, Len = 446 → NextSeq = 447

 📘 Tip:

• NextSeq always points to the first byte of the next segment you will send.
• Ack always points to the first byte the receiver expects next.
• This system ensures reliable, ordered delivery, even if packets arrive out of order or are retransmitted.

Actual vs. Relative Sequence and Acknowledgment Numbers 

Wireshark subtracts each side’s Initial Sequence Number (ISN) from every subsequent packet’s Seq or Ack, so that both start at 0 or 1 instead of large random values. 

What Are Actual Sequence Numbers?

• TCP sequence and acknowledgment numbers are 32-bit integers (0 to 4,294,967,295).
• They represent the absolute byte offsets in the data stream.
• Each side chooses a random Initial Sequence Number (ISN) when the connection starts (for security and uniqueness). 
• Example : Client chooses ISN = 1,253,421,000, Server chooses ISN = 4,001,560,000

What Are Relative Sequence / Ack Numbers?

• When you open a packet capture (e.g., Wireshark), it often shows relative numbers instead of the full 32-bit values — just to make your life easier.
• Relative numbering resets the “zero point” of the sequence space to the start of the conversation.
• So instead of huge random numbers like 1,253,421,000, Wireshark shows: Relative Seq = 0, Relative Ack = 0  and counts forward from there.

⚙️ Why Wireshark Does This

Imagine you’re following a TLS handshake with real sequence numbers like: 

Seq=2,613,481,777, Ack=3,904,331,020

Hard to see what’s happening, right? 

Wireshark “normalizes” them:

Relative Seq = 0
Relative Ack = 0

so that all later packets show how far each side advanced in bytes. 

📘 Example — Real vs Relative Numbers

Let’s look at a simple 3-way handshake: 

Step	Direction	Actual Seq	Actual Ack	Relative Seq	Relative Ack	Notes
1️⃣	Client → Server (SYN)	1,253,421,000	—	0	—	Client starts
2️⃣	Server → Client (SYN+ACK)	4,001,560,000	1,253,421,001	0	1	Each side starts counting from its own zero
3️⃣	Client → Server (ACK)	1,253,421,001	4,001,560,001	1	1	Connection established

 Now, when client sends 100 bytes of data:

Step	Actual Seq	Actual Ack	Relative Seq	Relative Ack
PSH →	1,253,421,001	4,001,560,001	1	1
NextSeq	1,253,421,101	—	101	—

📊 How to Toggle This in Wireshark

• Relative Numbers (default ON): shows easy-to-read 0-based numbers.
• Actual Numbers: shows real 32-bit sequence numbers chosen by TCP stack.

To toggle: Wireshark → Preferences → Protocols → TCP → Uncheck “Relative sequence numbers and window scaling”

🔍 Visual Example

[Relative View]
Client SYN: Seq=0
Server SYN,ACK: Seq=0, Ack=1
Client ACK: Seq=1, Ack=1
Data: Seq=1, Len=500
Ack: Ack=501

[Actual View]
Client SYN: Seq=1,253,421,000
Server SYN,ACK: Seq=4,001,560,000, Ack=1,253,421,001
Client ACK: Seq=1,253,421,001, Ack=4,001,560,001
Data: Seq=1,253,421,001, Len=500
Ack: Ack=1,253,421,501
 

Item	Relative Seq/Ack	Actual Seq/Ack
Purpose	Easier to read	True 32-bit TCP number
Start value	Always 0	Random (per TCP peer)
Used by	Packet analyzers (Wireshark)	TCP stack / OS kernel
Toggle	Edit → Preferences → TCP → Relative Seq Numbers	N/A
Good for	Readability, teaching	Deep debug, TCP reuse issues
Formula	Rel = Actual - ISN	Actual = ISN + Rel

 Understanding “Relative” vs “Actual” Sequence/Ack Numbers

Field	Meaning	Example (from your trace)
Actual Sequence Number	The real 32-bit TCP sequence number as transmitted in the TCP header (ranges 0–4,294,967,295).	421639144
Relative Sequence Number	Wireshark’s normalized view: it subtracts the first sequence number of the flow, so it starts at 1 (or 0) for readability.	1
Next Sequence Number	The next expected byte number after sending this segment. Formula: Seq + TCP Segment Len.	447 (means bytes 1–446 were sent)
Actual Acknowledgment Number	The real TCP acknowledgment number from the packet, i.e., the next byte the sender expects to receive.	3775721000
Relative Acknowledgment Number	Wireshark subtracts the initial acknowledgment base (the peer’s first Seq) to make it start at 1 (or 0).	1

 

 

 Client and Server exchange books, client send Book1 to Server and Server Send Book2 to client.

1️⃣ SYN (Client → Server) [Seq=0, Ack=0, Len=0, NextSeq=1] 

• Seq=0 → Client sends Book1 Start (page 0) – just a cover page, no data.
• NextSeq=1 → “I’ve sent up to page 0; my next real page will be page 1.” [Rules for Next Sequence Number : SYN/FIN consumes 1 sequence number.]
• Ack=0 → “I haven’t received any of your pages yet.”

2️⃣ SYN+ACK (Server → Client)  [Seq=0, Ack=1,Len=0,NextSeq=1]

• Seq=0 → Server sends its Book2 Start (page 0).
• Ack=1 → “I received your page 0 (Book1 Start). Next, I expect your page 1.”  [Rules for Next Sequence Number : SYN/FIN consumes 1 sequence number.]
• NextSeq=1 → “My next real page will be page 1.”

3️⃣ ACK (Client → Server)  [Seq=1, Ack=1,Len=0, NextSeq=1]

• Ack=1 → Client says: “I got your Book2 Start (page 0). I’m ready for your next pages.”
• NextSeq=1 → “I still haven’t sent new data yet; my next page will be 1.  This ACK has no data, so NextSeq remains 1. ”

4️⃣ Client Hello (Client → Server)  [Seq=1, Ack=1, Len=446, NextSeq=447 ]

• Seq=1,Len=446 → Client sends pages 1–446 (TLS ClientHello).
• NextSeq=447 → “I’ve sent up to page 446; next page will be 447.”
• Ack=1 → “I’ve received your pages up to 0 (Book2 Start). Waiting for your next page (1).”

5️⃣ ACK (Server → Client) [Seq=1, Ack=447, Len=0, NextSeq=1]

• Ack=447 → Server acknowledges: “I received your pages 1–446. Next I expect page 447.”
• NextSeq=1 → “I still haven’t sent new data yet; my next page will be 1.”  This ACK has no data, so NextSeq remains 1. 

6️⃣ Server Hello + CCS + AppData (Server → Client) [Seq=1, Ack=447, Len=2760, NextSeq=2761]

• Seq=1,Len=2760  → Server sends pages 1–2760 (TLS ServerHello and early encrypted data).
• NextSeq=2761 → “I’ve sent up to page 2760; my next will be 2761.”
• Ack=447 → “I received everything you sent up to page 446. Next I expect page 447.”

7️⃣ PSH+ACK (Server → Client) [Seq=2761, Ack=447, Len=1336, NextSeq=4097]

• Seq=2761,Len=1336 → Server continues sending more data: pages 2761–4096.
• NextSeq=4097 → “I’ve now sent up to page 4096; next one will be 4097.”
• Ack=447 → “Still expecting your next page (447), haven’t received anything new from you.”

8️⃣ TLS App Data (Server → Client) [Seq=4097, Ack=447, Len=480, NextSeq=4577]

• Seq=4097, Len=480 →  Server continues sending more data: pages 4097–4576.
• NextSeq=4577 → “I’ve now sent up to page 4576; next one will be 4577.”
• Ack=447 → “Still expecting your next page (447), haven’t received anything new from you.”

9️⃣ ACKs (Client → Server) [Seq=447, Ack=2761,Len=0, NextSeq=447]
       ACKs (Client → Server) [Seq=447, Ack=4097, Len=0, NextSeq=447]

• Client acknowledges server data:
• First Ack=2761 → received up to page 2760, expecting 2761.
• Second Ack=4097 → received up to page 4096, expecting 4097.
• NextSeq=447 → “I still haven’t sent new data yet; my next page will be 447.  This ACK has no data,  ”Seq does not advance because no client data is sent".

🔟 Change Cipher Spec (Client → Server) [Seq=447, Ack=4097,Len=6, NextSeq=453]

• Seq=447,Len=6 → Client sends CCS message (6 bytes)i,e  pages 447–452
• NextSeq=453 →  “I’ve sent up to page 452; next page will be 453 after CCS.”
• Ack=4097 → “I received everything you sent up to page 4096. Next I expect page 4097.” 

1️⃣1️⃣ TLS App Data (Client → Server) [Seq=453, Ack=4577, Len=1380, NextSeq=1833]

• Seq=453, Len=1380  → Client sends encrypted application data 453–1832 (page numbers).
• NextSeq=1833 → next byte/page to send.
• Ack=4577 → received server pages up to 4576.

1️⃣2️⃣ ACK (Server → Client) [Seq=4577, Ack=1833, Len=0, NextSeq=4577]

• Ack=1833→ Server acknowledges: “I received your pages 453–1832. Next I expect page 1833.”
• NextSeq=4577 → “I still haven’t sent new data yet; my next page will be 4577.  This ACK has no data,  ”NextSeq unchanged (no server data sent here).".

1️⃣3️⃣ TLS App Data (Server → Client) [Seq=4577, Ack=1833, Len=319, NextSeq=4896]
             TLS App Data (Server → Client) [Seq=4896, Ack=1833, Len=319, NextSeq=5215]

• Seq=4577,Len=319 → Server continues sending pages 4577–4895
• Seq=4896,Len=319 → Server continues sending more data : pages 4896–5214
• NextSeq=5215→ “I’ve now sent up to page 5214; next one will be 5215."
• Ack=1833→ “Still expecting your next page (1833 ), haven’t received anything new from you.”

1️⃣4️⃣ TLS App Data (Client → Server) [Seq=1833, Ack=4577, Len=508, NextSeq=2341]

• Seq=1833,Len=508→ Client sends pages 1833–2340(TLS encrypted App Data).
• NextSeq=2341→ “I’ve now sent up to page 2340; next one will be 2341."
• Ack=4577 →“I received everything you sent up to page 4576. Next I expect page 4577 .”

1️⃣5️⃣  ACK (Client→ Server) [Seq=2341, Ack=5215, Len=0, NextSeq=2341]

• Ack=5215→ Client acknowledges: “I received your pages up to 5214. Next I expect page 5215.”
• NextSeq=2341→ “I still haven’t sent new data yet; my next page will be 2341.  This ACK has no data,  ”NextSeq unchanged (no server data sent here)."

1️⃣6️⃣  ACK (Server → Client) [Seq=5215, Ack=2341, Len=0, NextSeq=5215]

• Ack=2341→ Server acknowledges: “I received your pages up to 2340. Next I expect page 2341.”
• NextSeq=5215→ “I still haven’t sent new data yet; my next page will be 5215.  This ACK has no data,  ”NextSeq unchanged (no server data sent here).".

1️⃣7️⃣ TLS App Data (Server → Client) [Seq=5215, Ack=2341, Len=2090, NextSeq=7305]

• Seq=5215,Len=2090 → Client sends pages 5215–7304(TLS encrypted App Data). 
• NextSeq=7305→ “I’ve now sent up to page 7304; next one will be 7305."
• Ack=2341→ “Still expecting your next page (2341), haven’t received anything new from you.”

1️⃣8️⃣ ACK (Client → Server) [Seq=2341, Ack=7305, Len=0, NextSeq=2341]

• Client acknowledges server data i,e  received up to page 7304, expecting 7305.
• NextSeq=2341→ “I still haven’t sent new data yet; my next page will be 2341.  This ACK has no data,  ”NextSeq unchanged (no client data sent here)."

1️⃣9️⃣ TLS App Data (Server → Client) [Seq=7305, Ack=2341, Len=24, NextSeq=7329]

• Seq=7305,Len=24→ Server sends pages 7305–7328(TLS encrypted App Data). 
• NextSeq=7329→ “I’ve now sent up to page 7328; next one will be 7329."
• Ack=2341→ “Still expecting your next page (2341), haven’t received anything new from you.”

2️⃣0️⃣  FIN+ACK (Server→ Client) [Seq=7329, Ack=2341, Len=0, NextSeq=7330]

• Seq=7329, Server initiates connection close. Now I am sending my last page just a cover page of my book, no data.
• NextSeq=7330 → “Now I am sending my last page i,e 7329 page no.; if further communication require then my next page will be start from 7330." [SYN/FIN consumes 1 sequence number.]
• Ack=2341 → “Still expecting your next page (2341), haven’t received anything new from you.”

2️⃣1️⃣ Retransmission FIN+ACK  (Server → Client) [Seq=7329, Ack=2341, Len=0, NextSeq=7330]

• Retransmission previous connection close packets i,e #20.
• NextSeq=7330 → “Now I am sending my last page i,e 7329 page no.; if further communication require then my next page will be start from 7330." 
• Ack=2341 → “Still expecting your next page (2341), haven’t received anything new from you.”

2️⃣2️⃣ Final ACK (Client→ Server ) [Seq=2341, Ack=7330, Len=0, NextSeq=2341]

• Ack=7330→ Client acknowledges server data i,e “I’ve received your pages up to 7329(i,e up Book2 last cover page). If require i can wait for your next page start from 7330.
• NextSeq=2341→ “I still haven’t sent new data yet; my next page will be 2341.  This ACK has no data,  ”NextSeq unchanged (no client data sent here)."

2️⃣ 3️⃣ FIN+ACK (Client→ Server) [Seq=2341, Ack=7330, Len=0, NextSeq=2342]

• Seq=2341, Client initiates connection close. Now I am sending my last page just a cover page of my book, no data.
• NextSeq=2342→ “Now I am sending my last page i,e 2341 page no.; if further communication require then my next page will be start from 2342." [SYN/FIN consumes 1 sequence number.]
• Ack=7330→ “I’ve received your pages up to 7329 (i,e up Book2 last cover page). If require i can wait for your next page start from 7330.”

2️⃣4️⃣  Final ACK (Server→ Client) [Seq=7330, Ack=2342, Len=0, NextSeq=7330]

• Ack=2342→ Server acknowledges client data i,e “I’ve received your pages up to 2341(i,e up Book1 last cover page). If require i can wait for your next page start from 2342.
• NextSeq=7330→ “I still haven’t sent new data yet; my next page will be 7330.  This ACK has no data,  ”NextSeq unchanged (no client data sent here)."

Why This Matters

Understanding Seq, Ack, Len, and NextSeq is essential for:

• Debugging network issues
• Analyzing packet captures
• Optimizing TCP-based applications
• Understanding TLS handshakes and data flow 

Real-Time Example: TCP Sequence, Ack, and Length Importance in Local Port Reuse Collisions

When multiple client applications share the same network infrastructure and use NATed IP addresses, improper TCP session closure can create critical connection failures. Let’s explore this step by step. 

Understanding TCP Sequence, Acknowledgment, and Length numbers is not just theoretical. It’s essential in real-world scenarios like NATed clients, port reuse, and incomplete connection closures. Proper TCP state management ensures reliable connections, prevents collisions, and avoids failed transactions in high-throughput environments.

We captured a packet trace showing a client behind a NAT router attempting multiple TLS connections to a server on port 443. The trace illustrates how improper TCP closure and port reuse can cause connection failures. 

Port Reuse & Collision 

Frame	Seq	Ack	Len	Info
20101	0	0	0	Client SYN (reusing port 62240)
20102	1	202923802	0	Server responds with PSH,ACK (old sequence numbers)
20180	0	0	0	Client retransmits SYN
20181	1	202923802	0	Server sends Dup ACK

• Client port reused before server cleared old connection.
• Server interprets new SYN as part of old session.
• Result: connection failure, DUP ACKs, unexpected sequence numbers. 

Scenario Setup

• Environment:
• Multiple clients behind a NAT router.
• Client traffic is centralized through the router before reaching the server firewall.
• Applications on clients use dynamic local ports.
• Server: Apache HTTP Server with standard TCP stack.
• Key Problem:
• Local port collisions occur because clients fail to fully close previous TCP connections, and the router reuses the same source port for new connections. 

Step 1: Normal TCP Connection Lifecycle

• Client initiates connection → sends SYN (Seq = X) to server.
• Server responds → SYN+ACK (Seq = Y, Ack = X+1).
• Client sends ACK → completes handshake (Ack = Y+1).
• Data transfer occurs → Seq and Ack track bytes exchanged.
• Normal close → FIN/ACK from client → FIN/ACK from server → final ACK from client.
• Connection state is cleared on both sides.

Importance of Seq & Ack:

• Both sides know exactly which bytes were sent and received.
• NextSeq ensures no overlapping or missing data. 

Step 2: Improper Connection Closure

• Client application 1 closes connection partially:
• Sends FIN/ACK.
• Server responds with FIN/ACK.
• Client never sends final ACK for the server’s FIN.

Result:

• Server remains in LAST-ACK state for that connection.
• Retransmits FIN periodically, waiting for final ACK.
• Connection state is “half-closed”, still consuming the source port. 

Step 3: Local Port Reuse Collision

• NAT router reassigns the same local port for a new client application 2 connection.
• Client 2 sends a new SYN using the stale port.
• Server still tracks the old half-closed session for that port.

Observed Behavior in TCP Flow:

• Server does not promote the SYN to a new socket.
• Server replies using old sequence numbers ([PSH, ACK] from previous session).
• Client sees a connection failure because its SYN is interpreted as part of the old session. 

Step 4: Why Seq, Ack, and Length Matter

• Sequence Numbers (Seq):
• Identify the exact byte range for a connection.
• Stale Seq numbers from previous sessions cause confusion if ports are reused.
• Acknowledgment Numbers (Ack):
• Tell the sender which bytes were received.
• Old Ack values on the server make it ignore new SYNs, treating them as retransmissions of the old connection.
• Payload Length (Len):
• Defines the data span in each segment.
• If the server receives a SYN on a half-closed port, the length of retransmitted segments may overlap with old unacknowledged data, causing corruption or session collisions. 

 Step 5 : Observation:

• SYN never promoted to new connection.
• Server responds using old sequence numbers, causing failure.
• Packet traces show “TCP port reused / duplicate ACK”.

Step 6: Root Cause Summary

• TCP Port Reuse & Stuck LAST-ACK
• Client initiated a close (FIN/ACK).
• Server replied FIN/ACK but did not receive final ACK.
• Server stayed in LAST-ACK state.
• NAT reused same source port for new connection.
• Server tried to continue old session → connection failure.
• Key Learning:
• Proper TCP session closure is critical when NAT and port reuse are involved.
• Monitoring Seq, Ack, and Len in packet traces helps identify half-closed or stuck connections. 

 Step 7: Best Practices

• Client Applications:
• Always complete TCP close handshake (ACK the server’s FIN).
• Avoid reusing sockets prematurely.
• Server Side:
• Configure TCP TIME_WAIT and FIN timeout appropriately.
• Monitor for unusual LAST-ACK states.
• Network/NAT Layer:
• Track port reuse and avoid assigning stale ports immediately.

Analysis & Takeaways

• Seq / NextSeq:
• Server continues with old Seq numbers (PSH, ACK 1 → 202923802), confusing client.
• Ack Numbers:
• Client expects fresh acknowledgment, server still expecting old FIN ACK → ACKed unseen segment.
• Len:
• Payload lengths indicate how far along in the “book pages” server and client are.
• Old data length + half-closed state blocks new connection promotion.
• Root Cause:
• Half-closed connections + NAT port reuse = server treats SYN as old session.
• Connection failure occurs without visible SYN in server socket table. 

        

 

📘 TCP Behavior Cheatsheet

 

State Transition Table

 

Client State	Trigger	Next State	Notes
CLOSED	—	SYN-SENT	Start connect()
SYN-SENT	SYN/ACK received	ESTABLISHED	3-way complete
ESTABLISHED	Send FIN	FIN-WAIT-1	Initiate close
FIN-WAIT-1	Receive ACK	FIN-WAIT-2	Peer acknowledged FIN
FIN-WAIT-2	Receive FIN	TIME-WAIT	Wait for 2MSL before reuse
CLOSE-WAIT	Application close()	LAST-ACK	Wait for final ACK
LAST-ACK	Receive ACK	CLOSED	Final ACK received
TIME-WAIT	Timeout expires	CLOSED	Port becomes reusable

 

Common TCP Flags Recap

 

Flag	Name	Consumes Seq?	Purpose
SYN	Synchronize	✅ +1	Start connection
ACK	Acknowledge	❌	Confirm data receipt
PSH	Push	❌	Deliver data immediately
FIN	Finish	✅ +1	End connection
RST	Reset	❌	Abort connection instantly

 

Common Anomalies & Diagnoses

 

#	Issue	Symptom	Likely Cause	Wireshark Notes
1️⃣	Duplicate ACKs	Same ACK repeated multiple times	Packet loss or out-of-order delivery	“Dup ACK #n”
2️⃣	Retransmission	Segment resent with same Seq range	Timeout or missing ACK	“TCP Retransmission”
3️⃣	Fast Retransmission	3 duplicate ACKs trigger resend	Loss detected early	“TCP Fast Retransmission”
4️⃣	Out-of-Order Segment	Seq lower than expected	Reordering in path	“TCP Out-of-Order”
5️⃣	ACKed Unseen Segment	ACK references bytes never sent	Port reuse, stale session	Seen in port collision cases
6️⃣	Port Reuse Collision	SYN not accepted, PSH seen instead	Old connection in LAST-ACK	Server treats SYN as old data
7️⃣	Zero Window	Receiver stops advancing ACKs	Buffer full	“TCP Zero Window”
8️⃣	Keep-Alive Probe	1-byte Seq=N−1 sent	Idle connection check	“TCP Keep-Alive”
9️⃣	Window Update	Sudden jump in window size	Buffer cleared	“TCP Window Update”
🔟	RST Flood / Abort	Immediate resets	App crash, timeout, or firewall drop	“TCP RST”

 

  

Lessons Learned

• Always ensure clean TCP closure: FIN → FIN/ACK → final ACK.
• NAT routers reusing local ports can trigger collisions if previous sessions are stuck.
• Understanding Seq, Ack, Len in traces is essential to diagnose these failures.
• Tools like Wireshark reveal retransmissions, DUP ACKs, and port reuse issues.