linux - 是什么导致在 linux 内核中发送这些重复的 TCP ACK

Question

我在 Android 设备(linux 3.4.39)上用 tcpdump 捕获了这些数据包，这些数据包在 HTTP GET 流中:

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

客户端是我的设备。

是什么导致客户端发送这些重复的 TCP ACK？

更新:
为什么客户端在收到后续 TCP 数据包(#3)后发送先前的 DUP ACK(#4)？

谢谢。

Answer 1

What causes these duplicate TCP ACKs be sent by client?

接收方(客户端) 发送 ACK# 作为它期望来自 发送方(服务器)的下一个 SEQ#/。

在您的示例中，服务器发送:

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

client 收到它，然后通过放置 ACK = 12617 请求带有 SEQ# 12517+100 = 12617 的数据包

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

如果数据包带有SEQ# 12617:

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

丢失且未被receiver接收，则receiver将发送一个duplicate ACK，这是对的指示>sender 重新发送数据包(表示数据包已经丢失)。

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

因为带有SEQ#12617 的数据包似乎在 channel 中丢失了，客户端 没有收到这些数据包。因此，重复的 ACK 12617 指示 server 重新传输它。

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

它不能是不同的线程，因为线程根据收到的SEQ#生成ACKS#。所以，它不能是两个不同的线程。即使是，一个人也必须等待另一个人的信息(同步)。