公司app大量的出現(xiàn)無法訪問網(wǎng)絡，各路排查才發(fā)現(xiàn)是因為當時優(yōu)化了內(nèi)核快速回收time_wait參數(shù)導致

網(wǎng)上的帖子，大多都寫開啟net.ipv4.tcp_tw_recycle這個開關，可以快速回收處于TIME_WAIT狀態(tài)的socket（針對Server端而言）。

而實際上，這個開關，需要net.ipv4.tcp_timestamps（默認開啟的）這個開關開啟才有效果。

更不為提到卻很重要的一個信息是：當tcp_tw_recycle開啟時（tcp_timestamps同時開啟，快速回收socket的效果達到），對于位于NAT設備后面的Client來說，是一場災難——會導到NAT設備后面的Client連接Server不穩(wěn)定（有的Client能連接server，有的Client不能連接server）。也就是說，tcp_tw_recycle這個功能，是為“內(nèi)部網(wǎng)絡”（網(wǎng)絡環(huán)境自己可控——不存在NAT的情況）設計的，對于公網(wǎng)，不宜使用。 

我們在一些高并發(fā)的 WebServer上，為了端口能夠快速回收，打開了 tcp_tw_reccycle ，而在關閉 tcp_tw_reccycle 的時候，kernal 是不會檢查對端機器的包的時間戳的；打開了 tcp_tw_reccycle 了，就會檢查時間戳，很不幸移動的cmwap發(fā)來的包的時間戳是亂跳的，所以我方的就把帶了“倒退”的時間戳的包當作是“recycle的tw連接的重傳數(shù)據(jù)，不是新的請求”，于是丟掉不回包，造成大量丟包。