血淋淋教训，生产环境不要乱修改net.ipv4.tcp_tw_recycle

今天公司app大量的出现无法访问网络，各路排查才发现是因为当时优化了内核快速回收time_wait参数导致

网上的帖子，大多都写开启net.ipv4.tcp_tw_recycle这个开关，可以快速回收处于TIME_WAIT状态的socket（针对Server端而言）。
而实际上，这个开关，需要net.ipv4.tcp_timestamps（默认开启的）这个开关开启才有效果。
更不为提到却很重要的一个信息是：当tcp_tw_recycle开启时（tcp_timestamps同时开启，快速回收socket的效果达到），对于位于NAT设备后面的Client来说，是一场灾难——会导到NAT设备后面的Client连接Server不稳定（有的Client能连接server，有的Client不能连接server）。也就是说，tcp_tw_recycle这个功能，是为“内部网络”（网络环境自己可控——不存在NAT的情况）设计的，对于公网，不宜使用。

我们在一些高并发的 WebServer上，为了端口能够快速回收，打开了 tcp_tw_reccycle ，而在关闭 tcp_tw_reccycle 的时候，kernal 是不会检查对端机器的包的时间戳的；打开了 tcp_tw_reccycle 了，就会检查时间戳，很不幸移动的cmwap发来的包的时间戳是乱跳的，所以我方的就把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据，不是新的请求”，于是丢掉不回包，造成大量丢包。