在我的 Linux 机器上，我使用ncecho 服务器与我的 Android 设备上运行的回显服务器进行通信。我使用 echo 服务器nc将文本发送到 Android 设备的 65303 端口。输入 test1 后，镜像服务器会发回相同的文本。这就是为什么你总是看到两次相同的文本。
nc 192.168.1.24 -p 65303
test1
test1
test2
test2
这里是我的设备的更多详细信息：
Mx Linux MX-19.4_x64 patito feo May 31 2020, Kernel: 4.19.0-20-amd64 x86_64
Samsung Galaxy A8 (2018) SM-A530F, Kernel: 4.4.111-22928167
Android App "Echo Server" from Shufai Studio
android 设备通过 WiFi 连接到我的 WiFi 路由器，但我的 Linux 机器只有到同一 WiFi 路由器的以太网链路。我的 Linux 机器中的 WiFi 已关闭。两个设备都在同一个 C 网络 192.168.1.0/24 中。然后我关闭 WiFi 路由器的 WiFi，进入 test3 并观察WireShark我的 Linux 机器的 eth0 网络设备的通信。大约 60 秒后，我再次打开 WiFi。我可以看到6TCP 重新传输发生在前一个 TCP 段之后的这些时间：
0.437 s
0.416 s
0.832 s
1.664 s
3.392 s
106.496 s
有三件事令我惊讶：
前三次传输发生在不到一秒的时间内。这不符合 RFC 6298 的规定，该规范在第 2.4 章中规定：
每当计算 RTO 时，如果它小于 1 秒，则应将 RTO 四舍五入为 1 秒。
每次重传的时间都应该翻倍，但第二次重传的情况并非如此。这不符合 RFC 6298 的规定，RFC 6298 在第 5.5 章中规定：
主机必须设置 RTO <- RTO * 2（“退出计时器”）。
看来第 6 次重传被延迟了，并在我再次打开 WiFi 后发送。不知何故，我的 Linux 机器正在等待连接再次可用。但我不知道这是怎么做到的！eth0-network-device 始终处于开启状态，并且不知道 WiFi 路由器和 Android 设备之间的 WiFi 链接已关闭 60 秒。
再次查看后，WireShark我发现我的 Linux 设备正在发送 ARP 请求，询问 Android 设备的 MAC 地址。
Address Resolution Protocol (request)
Hardware type: Ethernet (1)
Protocol type: IPv4 (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (1)
Sender MAC address: HewlettP_2d:65:2c (e4:11:5b:2d:65:2c)
Sender IP address: 192.168.1.242
Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Target IP address: 192.168.1.24
这似乎是 Linux 机器用来判断是否可以通过网络访问 Android 设备的一种方式。一旦目标地址不再可用，00:00:00_00:00:00Android 设备就会再次上线。这种行为有记录吗？有人对此有更多了解吗？
答案1
TCP 驱动程序不会盲目遵循 RFC 6298，毕竟该版本是 2011 年发布的，在网络达到目前更快的速度之前。有很多科学论文都提到了如何改进高速网络的算法，但我无法确定您的驱动程序遵循的是哪一种。
然而，所有当前操作系统都包含经过调整和优化的算法，其参数通常可以由机器管理员进一步修改。
例如，在 Windows 中存在以下注册表参数 TcpTimedWaitDelay 定义为：
未确认的数据被重新传输多少次（3 推荐，5 为默认值）
您所看到的是类似的行为：
- 进行了两次传输，第二次传输耗时 0.416 秒
- 尝试了三次重传，每次加倍：0.832 秒、1.664 秒、3.392 秒
- 在这三次传输失败之后，TCP 驱动程序放弃了该算法并转向另一种方法，这次涉及 ARP。
这没什么好惊讶的。如果自 2011 年以来的 11 年里没有尝试改进该算法，那我会更惊讶。