在我的 Linux 机器上，我nc用来与运行在我的 android 设备上的 echo 服务器进行通信。我用来nc向安卓设备的端口 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-network-device的通信。大约 60 年代后，我再次打开 WiFi。我可以看到在上一个 TCP 段之后的这些时间发生了6次 TCP 重新传输：
0.437 s
0.416 s
0.832 s
1.664 s
3.392 s
106.496 s
有 3 件事让我感到惊讶：
前三个传输发生在不到一秒的时间内。这不符合 RFC 6298，它在第 2.4 章中说：
每当计算 RTO 时，如果它小于 1 秒，则 RTO 应该向上舍入到 1 秒。
每次重传的时间应该加倍，而第二次重传的情况并非如此。这不符合 RFC 6298，它在第 5.5 章中指出：
主机必须设置 RTO <- RTO * 2（“退出计时器”）。
再次打开WiFi后，似乎第6次重传延迟并发送。不知何故，我的 Linux 机器正在等待连接再次可用。但我不知道这是怎么做到的！eth0 -network-device 始终处于打开状态，并且不知道 WiFi 路由器和 Android 设备之间的 WiFi 链接已关闭 60 秒。
再次查看后，WireShark我可以看到我的 Linux 设备正在发送请求 Android 设备 MAC 地址的 ARP 请求。
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:00是 android 设备再次在线。该行为是否记录在案？有人知道更多吗？
TCP 驱动程序不会盲目地遵守 RFC 6298，它毕竟可以追溯到 2011 年，在网络达到目前更快的速度之前。很多关于改进高速网络算法的科学论文都写了，但我无法说出你的驱动程序遵循的是哪一篇。
但是，所有当前的操作系统都包含经过调整和优化的算法，机器管理员通常可以进一步修改它们的参数。
例如，在 Windows 中存在注册表参数 TcpTimedWaitDelay 定义为：
您会看到类似的行为：
没有什么令人震惊的。如果自 2011 年以来的过去 11 年中没有尝试对这个算法进行改进，我会更加震惊。