最近發現公司的app在高峰期超時嚴重.用wifi網絡一直超時,但qq等卻正常.換成手機卡網絡正常.
起初以為是DNS解析問題.
后來抓包,發現DNS解析正常,可以得到正確的A記錄.
但tcp retransmission嚴重.
因為app內使用了友盟等第三方庫,他們的DNS,tcp握手均正常.
而我們的app卻tcp retransmission嚴重.
后來找到一篇文章,照着修改了服務器配置...超時少了.
下面是轉發文章內容
內網有一台APP服務器,接口是通過Nginx發布的。手機通過無線登陸APP，有時候提示連接超時。
無線路由器和APP服務器，是通過內網交換機連接的。應該不會超時啊，可能是路由器問題。
然后換了好幾個路由器，小米mini,華碩RT-AC87U,TP-LINK WVR1750G
咨詢廠商，測試了一下，當時超時的時候，訪問百度視頻什么的是正常的。路由器沒有問題，可能是服務器問題。因為服務器是pc機主機，配置比較差，后來換成DELL R620，還是同樣的問題。
因為公司周圍有30幾個無線，2.4G傳輸速度是450M,可能是無線干擾問題。
最后買了一個Nighthawk X6 R8000，2.4G傳輸速度是600M，發現還是有超時。
網上搜索資料nginx超時問題，優化了一些參數，發現還是有超時。
手機安裝（Ping & DNS）軟件，版本是2.3，用TCP Ping持續測試dts.xx.com，
大約1~2分鍾，提示connection timed out，超時會持續一分鍾。出現超時的時候，手機登陸APP，就會提示連接超時。
然后超時的時候，在服務器抓包
[root@localhost ~]#tcpdump -i eth0 -s0 -w a.cap
發現無線路由器向服務器發送了SYN請求包，但是沒有得到服務器回應。
出現TCP Retransmission(TCP 包重傳)
因為服務器開啟了tcp_tw_recycle(為了支持高並發)
tcp請求回收，如果開了這個，那在默認60s內同一個ip包過來是會被回收的
網絡過來的數據包的時間肯定是小於這個請求時間的，那么服務器就會認為他是無效的連接，就會拒絕連接，所以才會出現TCP包重傳。
所以才會出現上面的現象，超時持續一分鍾。
后來我把tcp_tw_recycle關了
vi /etc/sysctl.conf
設置為0，表示關閉
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_tw_recycle = 0
加載配置
[root@localhost ~]#sysctl -p
最后再次用TCP Ping測試，測試20分鍾，沒有出現連接超時。
APP刷新數據，也沒有出現超時。
哎，解決這個問題，之前都是靠瞎猜的。分析問題沒有層層刨析，搞了這么長時間，才搞定。
路由器只提供數據轉發功能，只要轉發了，它的任務就完成了。
應該是服務器問題，然后抓包，為什么服務器沒有回應?
為什么出現TCP Retransmission(TCP 包重傳)?
這樣問題就越來越接近真相了，就好解決了，就好像福爾摩斯一樣。
后來發現系統日志出現
Jun 19 11:13:45 127.0.0.1TCP: time wait bucket table overflow
那就只能增加net.ipv4.tcp_max_tw_buckets的值
net.ipv4.tcp_max_tw_buckets = 100000
加載配置
[root@localhost ~]#sysctl -p
再次觀察，就沒有了。
http://www.51itong.net/nginx-app-12760.html
---------------------
作者：james_1010
來源：CSDN
原文：https://blog.csdn.net/james_1010/article/details/50387659
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！