是什么导致在linux内核中发送这些重复的TCP ACKs？
我在Android设备(linux 3.4.39)上使用tcpdump捕获了这些数据包，这些数据包位于中：
1 385.447794服务器->客户端: SEQ 12517，LEN 100 2 385.498345客户端->服务器: SEQ 3086，LEN 0，ACK 12617 3 385.497836服务器->客户端: SEQ 12617，LEN 1348 4 385.498644客户端->服务器: DUP 3086，LEN 0，ACK 12617 5 385.498735服务器->客户端: SEQ 13965，LEN 619 6 385.498978客户端->服务器: Dup 3086，LEN 0，ACK 12617 7 385.718843服务器->客户端: Retrans 13965，LEN 619 8 385.719280客户端->服务器: DUP 3086，LEN 0，ACK 12617 9 385.733230服务器->客户端: Retrans 12617，LEN 1348 10 385.733602客户端->服务器: SEQ 3086，LEN 0，ACK 14584 11 385.909921服务器->客户端: Retrans 12617，LEN 1348 12 385.910449客户端->服务器: DUP 3086，LEN 0，ACK 14584 13 388.031541客户端->服务器: SEQ 832，LEN 0，ACK 4192，FIN 14 388.031681客户端->服务器: SEQ 3086，LEN 0，ACK 14584，FIN
客户是我的设备。
是什么导致客户端发送这些重复的TCP？
更新：
为什么客户端在接收后续的TCP数据包(#3)后发送先前的DUP (#4)？
谢谢。
回答 1
Stack Overflow用户
发布于 2014-04-11 02:00:42
是什么导致客户端发送这些重复的TCP？
receiver (client)将ACK#作为它希望从sender (server)获得的下一个SEQ#发送。
在您的示例中，服务器发送：
1 385.447794 Server -> Client: SEQ 12517, LEN 100client接收到它，然后通过放置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，该duplicate ACK是对sender的指示，以重新发送分组(指示数据包已经丢失)。
4 385.498644 Client -> Server: [DUP ACK] SEQ 3086, LEN 0, ACK 12617为什么客户端在接收后续的TCP数据包(#3)后发送先前的DUP (#4)？
因为带有SEQ#12617的数据包似乎在信道中丢失了，所以client没有接收到这些数据包。因此，重复的ACK 12617表示要重新传输它的server .
我想知道Linux内核读取包和发送ACK是否在不同的线程？中处理。
它不能是不同的线程，因为线程根据接收到的ACKS#生成SEQ#。所以，它不能是两个不同的线程。即使他们是，其中一个将不得不等待来自另一个(同步)的信息。
https://stackoverflow.com/questions/22957901
复制相似问题
腾讯云开发者
