Linux – What causes these duplicate TCP ACKs be sent in linux kernel

linuxtcp

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.

Best Answer

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).

Related Solutions

Linux – FIN omitted, FIN-ACK sent

The closing sequence can also be different and don't need to have FIN+ACK inside the same packet:

ACK just acknowledges the receipt of data (e.g. received everything up to given sequence number)
packets will be re-send until one receives an ACK for them
FIN just says that the side sending the FIN will not send any more data. It gives no information if it will still receive data.
like every other packet FIN will be re-send until the receipt is acknowledged

Protocols like HTTP support a one-sided shutdown, e.g. the client sends the request data followed by a FIN to notify the server, that it will not send anymore data. But it will still receive the data send by the server. The server will acknowledge the FIN like it did with all the data before. Once the server is done it will send its own FIN which the client ACKs. In this case you have

1. client: FIN  (will not send more) 
2. server: ACK (received the FIN)
.. server: sends more data..., client ACKs these data 
3. server: FIN (will not send more)
4. client: ACK (received the FIN)

Note that the packet you see in step#1 might have an ACK inside too. But this ACK just acknowledges data send before by the server. If the server has no more data to send it might close the connection also. In this case steps 2+3 can be merged, e.g. the server sends a FIN+ACK, where the ACK acknowledges the FIN received by the client.

If one side sends its FIN the connection is called half-closed. It is fully closed once both sides send their FIN and received the ACK for the FIN, no matter if they do this in 3 or 4 packets.

Best Answer

Related Solutions

Linux – FIN omitted, FIN-ACK sent

Related Topic