最近遇到了android 在慢網絡下面請求服務器報
java.net.SocketException: recvfrom failed: ECONNRESET (Connection reset by peer) java.net.SocketTimeoutException: failed to connect to mobile2.itanzi.com/120.27.142.146 (port 80) after 15000ms java.net.SocketTimeoutException: timeout java.net.UnknownHostException: Unable to resolve host "mobile2.itanzi.com": No address associated with hostname
而ios 不存在這個問題，一直沒有搞懂什么原因，總以為是android 的原因
netstat -an |grep 'ESTABLISHED' |grep 'tcp' |wc -l 243
一個 tcp_tw_recycle ，為了支持高並發，開啟了這個，也就是tcp請求回收，如果開了這個，那在默認60s內同一個ip包過來是會被回收的，而游戲網絡很多都是經過多層代理網絡的，代理網絡過來的數據包的時間肯定是小於這個請求時間的，那么服務器就會認為他是無效的連接，就會拒絕連接，所以才會出現TCP包重傳，基於實踐是檢查理論的唯一標准，那就試着改吧
vim /etc/sysctl.conf net.ipv4.tcp_tw_reuse = 0 net.ipv4.tcp_tw_recycle = 0
網上查了一下：
tcp_tw_reuse、tcp_tw_recycle 使用場景及注意事項
linux TIME_WAIT 相關參數:
net.ipv4.tcp_tw_reuse = 0 表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接，默認為0，表示關閉 net.ipv4.tcp_tw_recycle = 0 表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉 net.ipv4.tcp_fin_timeout = 60 表示如果套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間（可改為30，一般來說FIN-WAIT-2的連接也極少）
注意：
- 不像Windows 可以修改注冊表修改2MSL 的值，linux 是沒有辦法修改MSL的，tcp_fin_timeout 不是2MSL 而是Fin-WAIT-2狀態.
- tcp_tw_reuse 和SO_REUSEADDR 是兩個完全不同的東西
1. tw_reuse，tw_recycle 必須在客戶端和服務端timestamps 開啟時才管用（默認打開）
2. tw_reuse 只對客戶端起作用，開啟后客戶端在1s內回收
3. tw_recycle 對客戶端和服務器同時起作用，開啟后在 3.5*RTO 內回收，RTO 200ms~ 120s 具體時間視網絡狀況。
內網狀況比tw_reuse 稍快，公網尤其移動網絡大多要比tw_reuse 慢，優點就是能夠回收服務端的TIME_WAIT數量
對於客戶端
1. 作為客戶端因為有端口65535問題，TIME_OUT過多直接影響處理能力，打開tw_reuse 即可解決，不建議同時打開tw_recycle，幫助不大。
2. tw_reuse 幫助客戶端1s完成連接回收，基本可實現單機6w/s請求，需要再高就增加IP數量吧。
3. 如果內網壓測場景，且客戶端不需要接收連接，同時tw_recycle 會有一點點好處。
4. 業務上也可以設計由服務端主動關閉連接
對於服務端
1. 打開tw_reuse無效
2. 線上環境 tw_recycle 不要打開
服務器處於NAT 負載后，或者客戶端處於NAT后（這是一定的事情，基本公司家庭網絡都走NAT）；
公網服務打開就可能造成部分連接失敗，內網的話到時可以視情況打開；
像我所在公司對外服務都放在負載后面，負載會把timestamp 都給清空，好吧，就算你打開也不起作用。
3. 服務器TIME_WAIT 高怎么辦
不像客戶端有端口限制，處理大量TIME_WAIT Linux已經優化很好了，每個處於TIME_WAIT 狀態下連接內存消耗很少，
而且也能通過tcp_max_tw_buckets = 262144 配置最大上限，現代機器一般也不缺這點內存。
下面像我們一台每秒峰值1w請求的http 短連接服務，長期處於tw_buckets 溢出狀態，
tw_socket_TCP 占用70M, 因為業務簡單服務占用CPU 200% 運行很穩定。