CODEWITHSUNDEEP
linuxtcp
HM.Yang
HM.Yang

Reputation: 185

What causes these duplicate TCP ACKs be sent in linux kernel

I captured these packets with tcpdump on Android device(linux 3.4.39), these packets are in a HTTP GET Stream:

1 385.447794 Server -> Client: SEQ 12517, LEN 100
2 385.498345 Client -> Server: SEQ 3086, LEN 0, ACK 12617
3 385.497836 Server -> Client: SEQ 12617, LEN 1348
4 385.498644 Client -> Server: [DUP ACK] SEQ 3086, LEN 0, ACK 12617
5 385.498735 Server -> Client: SEQ 13965, LEN 619
6 385.498978 Client -> Server: [Dup ACK] SEQ 3086, LEN 0, ACK 12617
7 385.718843 Server -> Client: [Retrans] SEQ 13965, LEN 619
8 385.719280 Client -> Server: [DUP ACK] SEQ 3086, LEN 0, ACK 12617
9 385.733230 Server -> Client: [Retrans] SEQ 12617, LEN 1348
10 385.733602 Client -> Server: SEQ 3086, LEN 0, ACK 14584
11 385.909921 Server -> Client: [Retrans] SEQ 12617, LEN 1348
12 385.910449 Client -> Server: [DUP ACK][Window Upd.] SEQ 3086, LEN 0, ACK 14584
13 388.031541 Client -> Server: SEQ 832, LEN 0, ACK 4192, FIN
14 388.031681 Client -> Server: SEQ 3086, LEN 0, ACK 14584, FIN

Client is my device.

What causes these duplicate TCP ACKs be sent by client?

UPDATE:
Why client send previous DUP ACK(#4) after receiving subsequent TCP packet(#3)?

Thanks.

Upvotes: 4

Views: 9033

Answers (1)

brokenfoot
brokenfoot

Reputation: 11649

What causes these duplicate TCP ACKs be sent by client?

The receiver (client) sends the ACK# as the SEQ# it expects next from the sender (server).

In your example, Server sent:

1 385.447794 Server -> Client: SEQ 12517, LEN 100

the client receives it and then asks for the packet with SEQ# 12517+100 = 12617 by placing ACK = 12617

2 385.498345 Client -> Server: SEQ 3086, LEN 0, ACK 12617

If the packet with SEQ# 12617: 

3 385.497836 Server -> Client: SEQ 12617, LEN 1348

is lost and is not received by the receiver, then the receiver will send a duplicate ACK which is an indication to the sender to re-transmit the packet (indicating the packet has been lost).

4 385.498644 Client -> Server: [DUP ACK] SEQ 3086, LEN 0, ACK 12617

Why client send previous DUP ACK(#4) after receiving subsequent TCP packet(#3)?

Because the packets with SEQ#12617 seem to be lost in the channel, the client is not receiving those packets. Hence, the duplicate ACK 12617 to indicate the server to re-transmit it.

I want to know if Linux kernel reading packet and sending ACK be processing in different thread?

It can not be different threads since the thread generates the ACKS# on the basis of the SEQ# it has received. So, it cannot be two different threads. And even if they were, one will have to wait for the information from the other (synchronized).

Upvotes: 2

Related Questions