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

2019年8月4日 276次阅读

我在
Android设备上使用tcpdump捕获了这些数据包(linux 3.4.39),这些数据包在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

客户端是我的设备.

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

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

谢谢.

最佳答案

What causes these duplicate TCP ACKs be sent by client?

接收方(客户端)发送ACK#作为它期望从发送方(服务器)接下来的SEQ#.

在您的示例中,服务器已发送：

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

客户端接收它然后通过放置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

如果丢失并且没有被接收器接收,则接收器将发送重复的ACK,这是发送器重新发送分组的指示(指示分组已丢失).

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的数据包似乎在通道中丢失,所以客户端没有接收到这些数据包.因此,重复的ACK 12617指示服务器重新发送它.

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

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

点赞