我有一个客户端/服务器程序，我可以从服务器向客户端发送可变数量的数据包。 / proc / sys / net / ipv4 / tcp_retries2设置为默认值15，但是当我拔下以太网电缆时，服务器只发送7或8（它变化）重新发送才放弃，然后是连续的ARP谁拥有请求..
对我提出的一个建议是TCP在7-8次重新传输后停止的原因是该路由的ARP表条目在服务器达到适当的重试次数之前到期。我试图通过更改来解决这个问题/ ipv4 / route / cg_timeout为1500（从300），但程序行为没有明显的差异..
如果有人能说清楚或提供其他解释，我们将不胜感激。
答案 0 :(得分：1)
也许ARP表中的条目即将到期，当再次发送ARP请求时，无响应超时？你运行arp -a了吗？ 也许设置gc_timeout是不够的，你还需要设置gc_stale_time？我在这篇文章中读到了关于它是如何工作的一个很好的解释。这家伙正试图做几乎与你正在尝试的相反的事情。 Configuring ARP age timeout
还有另一个要调查的主题。也许你还应该改变tcp_retries1？ 是否可以更改重传超时（RTO）？
我还查看了内核文档，文件ip-sysctl.txt，我得到了：
tcp_retries1 - INTEGER 该值会影响TCP决定的时间 由于未确认的RTO重传，出现问题， 并将此怀疑报告给网络层。 有关更多详细信息，请参阅tcp_retries2。 RFC 1122建议至少重传3次，即 默认值。
tcp_retries2 - INTEGER 此值会影响活动TCP连接的超时， 当RTO重传仍然未被确认时。 给定值N，后面是假设的TCP连接 使用TCP_RTO_MIN的初始RTO进行指数退避 在第（N + 1）次RTO中杀死连接之前重传N次。 默认值15产生假设超时924.6 秒，是有效超时的下限。 TCP将在超过的第一个RTO有效超时 假设超时。 RFC 1122建议超时至少100秒， 它对应的值至少为8。
在其他线程中，我读到了有关套接字选项TCP_USER_TIMEOUT的内容。我从来没有使用它，但它可能是一个简单的解决方案。 Application control of TCP retransmission on Linux
我希望其中一个选项有所帮助。