更改/ proc / sys / net / ipv4 / tcp_tw_reuse的值是否危险？

我们有一些生产系统，最近已将其转换为虚拟机。我们的应用程序经常访问MySQL数据库，并且它为每个查询创建一个连接，查询并断开该连接。

这不是查询的合适方法（我知道），但是我们有一些似乎无法解决的约束。无论如何，问题是这样的：当计算机是物理主机时，程序运行良好。转换为虚拟机后，我们注意到与数据库的间歇性连接问题。一次，TIME_WAIT中有24000多个套接字连接（在物理主机上，我看到的最多是17000个-不好，但不会引起问题）。

我希望这些连接能够被重用，这样我们就不会看到该连接问题，因此：

问题：

可以将tcp_tw_reuse的值设置为1吗？有哪些明显的危险？有什么理由我不应该这样做吗？

另外，是否还有其他方法可以获取系统（RHEL / CentOS），以防止许多连接进入TIME_WAIT或被重用？

最后，更改tcp_tw_recycle有什么用，对我有帮助吗？

提前谢谢！

您可以安全地减少停机时间，但是可能会遇到网络关闭不正确而导致丢包或抖动的问题。我不会在1秒开始调优，在15-30开始调优。

另外，您确实需要修复您的应用程序。

RFC 1185在3.2节中有很好的解释：

当关闭TCP连接时，在TIME-WAIT状态下2 * MSL的延迟会将套接字对占用4分钟（请参阅[Postel81]的3.5节。基于TCP的应用程序会关闭一个连接并打开一个新连接（例如，使用Stream模式的FTP数据传输连接）必须每次都选择一个新的套接字对。此延迟有两个不同的用途：

 (a)  Implement the full-duplex reliable close handshake of TCP. 

      The proper time to delay the final close step is not really 
      related to the MSL; it depends instead upon the RTO for the 
      FIN segments and therefore upon the RTT of the path.* 
      Although there is no formal upper-bound on RTT, common 
      network engineering practice makes an RTT greater than 1 
      minute very unlikely.  Thus, the 4 minute delay in TIME-WAIT 
      state works satisfactorily to provide a reliable full-duplex 
      TCP close.  Note again that this is independent of MSL 
      enforcement and network speed. 

      The TIME-WAIT state could cause an indirect performance 
      problem if an application needed to repeatedly close one 
      connection and open another at a very high frequency, since 
      the number of available TCP ports on a host is less than 
      2**16.  However, high network speeds are not the major 
      contributor to this problem; the RTT is the limiting factor 
      in how quickly connections can be opened and closed. 
      Therefore, this problem will no worse at high transfer 
      speeds. 

 (b)  Allow old duplicate segements to expire. 

      Suppose that a host keeps a cache of the last timestamp 
      received from each remote host.  This can be used to reject 
      old duplicate segments from earlier incarnations of the 

---

*注：可以说发送FIN的一方知道它需要多少可靠性，因此，它应该能够确定FIN接收者的TIME-WAIT延迟的长度。这可以通过在FIN段中使用适当的TCP选项来完成。

      connection, if the timestamp clock can be guaranteed to have 
      ticked at least once since the old conennection was open. 
      This requires that the TIME-WAIT delay plus the RTT together 
      must be at least one tick of the sender's timestamp clock. 

      Note that this is a variant on the mechanism proposed by 
      Garlick, Rom, and Postel (see the appendix), which required 
      each host to maintain connection records containing the 
      highest sequence numbers on every connection.  Using 
      timestamps instead, it is only necessary to keep one quantity 
      per remote host, regardless of the number of simultaneous 
      connections to that host.

这不能回答您的问题（并且已经晚了18个月），但是建议了另一种使旧应用程序重用端口的方法：

在系统上进行设置tcp_tw_reuse（或tcp_tw_recycle）的一种有用的替代方法是将共享库（使用LD_PRELOAD）插入到您的应用中；然后该库可以允许端口的重用。这使您的旧版应用程序允许端口重用，而无需在系统上的所有应用程序上强制执行此操作（无需修改应用程序），从而限制了调整的影响。例如，

    LD_PRELOAD=/opt/local/lib/libreuse.so ./legacy_app

该共享库应拦截该socket()调用，调用真实的socket（），并在返回的套接字上设置SO_REUSEADDR和/或SO_REUSEPORT。请参阅http://libkeepalive.sourceforge.net，以获取有关如何执行此操作的示例（这会打开keepalive，但打开SO_REUSEPORT却非常相似）。如果您的行为不当的旧版应用使用IPv6，请记住将第55行更改libkeepalive.c为

    if((domain == PF_INET) && (type == SOCK_STREAM)) {

至

    if(((domain == PF_INET) || (domain == PF_INET6)) && (type == SOCK_STREAM)) {

如果您遇到问题，请给我发送电子邮件，我将编写代码并将其发送给您。

我认为将此值更改为1很好。一种更合适的方法可能是使用以下命令：

[root@server]# sysctl -w net.ipv4.tcp_tw_reuse=1

据我所知，没有明显的危险，但是快速的Google搜索会产生此链接，该链接肯定tcp_tw_reuse是比更好的选择tcp_tw_recycle，但无论如何都应谨慎使用。

如果连接处于TIME WAIT状态，则无法重用。如果应用程序和MySQL之间的网络上没有数据包丢失，则可以降低超时时间。

但是，最好的解决方案是对数据库和连接池使用持久连接。