记一次TCP连接异常故障解决
為什么80%的碼農(nóng)都做不了架構師？>>> ??
一.情況表現(xiàn)為
? ? 1.在公司內(nèi)網(wǎng)對站點的http訪問：
? ? ? ? linux主機出現(xiàn)故障：curl以及抓包分析，發(fā)現(xiàn)服務端不響應linux客戶端的請求，無法建立TCP連接，瀏覽器返回“無法連接到服務器”
? ? ? ? windows主機正常
? ? 2.http訪問質(zhì)量下降：
? ? ? ? 基調(diào)顯示，新架構上線后，訪問質(zhì)量下滑，主要表現(xiàn)為
? ? ? ? 2.1.訪問提示“無法連接到服務器”
? ? ? ? 2.2.僅少數(shù)人遇到這種故障，并且一天中不是每次訪問都會遇到，而是出現(xiàn)時好時壞的現(xiàn)象
二.處理過程
? ? 直接上google搜索關鍵字“服務器無法建立TCP連接”。
? ? 翻了幾頁后，發(fā)現(xiàn)這篇博文：“http://www.sunchis.com/html/os/linux/2012/0518/413.html”。
? ? 看了一下，和我們公司內(nèi)網(wǎng)的表現(xiàn)一模一樣，但各種問題（1為這方面基礎知識薄弱，2為沒有時間驗證此配置）
? ? 然后這種問題持續(xù)了n久…一直以為是內(nèi)部設備問題
? ? 后期搞不定了，大膽在線上啟用這個參數(shù)“net.ipv4.tcp_timestamps = 0”，做了下測試后，發(fā)現(xiàn)故障解除，原故障機每次訪問都正常了！
? ? 不過還是不明其中原理，只是大意了解，同樣處于NAT上網(wǎng)方式的用戶里（與別人共用出口IP地址），如果你的時間戳小于別人的，那么服務器不會響應你的TCP請求，要忽略此項，將net.ipv4.tcp_timestamps = 0（/etc/sysctl.conf）
三.總結
? ? 后期學習時，看見了一個更加詳細的博客，講的很詳細，也引入了新的問題：http://huoding.com/2012/01/19/142
? ? ====== 小抄 ======
? ? 其實，linux服務器原本對時間戳（timestamps）默認是不開啟的，Linux是否啟用這種行為取決于tcp_timestamps和tcp_tw_recycle，因為tcp_timestamps缺省就是開啟的，所以當tcp_tw_recycle被開啟后，實際上這種行為就被激活了。
? ? net.ipv4.tcp_tw_recycle又是啥呢，搜索了一下基本上是TIME_WAIT連接的回收參數(shù)
? ? 當 net.ipv4.tcp_timestamps 沒有設置（缺省為開啟），并且 net.ipv4.tcp_tw_recycle 也開啟時，這個坑爹的錯誤就出現(xiàn)了，但是注意，只表現(xiàn)在NAT網(wǎng)絡環(huán)境中。而且，大多數(shù)博客，以及一些大牛們，都有說過要開啟 net.ipv4.tcp_tw_recycle …
? ? ====== 小抄 ======
四.未完成的事項
? ? 上文 http://huoding.com/2012/01/19/142 中提到的：
? ? 1.（未驗證）關閉timestamps后，tw_recycle功能是失效的問題
? ? 2.（未驗證）新的解決TIME_WAIT連接過多的方法：net.ipv4.tcp_max_tw_buckets = 10000 設置一個最大值，不過壞處是系統(tǒng)日志會提示：TCP: time wait bucket table overflow
===============================================================
針對有些用戶能ping通我們的網(wǎng)站，但是連接時超時服務器沒有任何響應，懷疑問題處在了了http的三次握手環(huán)節(jié)，這是決定通過抓包進行分析：
1、有問題機器的截圖：
2、正常機器的截圖：
3、發(fā)現(xiàn)問題
從抓包數(shù)據(jù)發(fā)現(xiàn)，web服務器對出問題機器和正常機器系統(tǒng)的tcp syn包都返回ACK包，但存在問題發(fā)出的tcp syn包有時候響應，有時候不響應。不響應時，終端與web服務器之間的tcp連接無法正常建立，導致頁面不能打開。對比這兩種數(shù)據(jù)包，就在時間戳上有差異，存在問題的機器發(fā)出的tcp syn包帶有時間戳，因此懷疑時間戳問題導致的故障。
4、解決問題
既然懷疑是時間戳導致的，那我們就著手分析如果將出現(xiàn)問題的機器的時間戳去掉會不會解決問題。針對帶有時間戳的tcp syn包不響應的問題，查閱了相關資料得知產(chǎn)生問題的原因是出問題系統(tǒng)中的注冊表中有Tcp1323opts這個選項，會導致其在發(fā)包時加入時間戳，經(jīng)過nat之后，如果前面相同的端口被使用過，且時間戳大于這個鏈接發(fā)出的syn中的時間戳，服務器上就會忽略掉這個syn，不返會syn-ack消息，表現(xiàn)為用戶無法正常完成tcp3次握手，從而不能打開web頁面。在業(yè)務閑時，如果用戶nat的端口沒有被使用過時，就可以正常打開；業(yè)務忙時，nat端口重復使用的頻率高，很難分到?jīng)]有被使用的端口，從而產(chǎn)生這種問題。
目前看有兩種方法解決:
(1)????是在服務器上修改變量
首先我們先查看一下我們服務器net.ipv4.tcp_timestamps的默認值，如果該值為0測說名不是該問題導致，如果是1我們需要將該值設置為1。
查看默認值的方法：[root@localhost ~]# cat /proc/sys/net/ipv4/tcp_timestamps
修改該值的方法：vim /etc/sysctl.conf? 添加 net.ipv4.tcp_timestamps=0
（2）修改客戶端的注冊表Tcp1323Opts設置為0。
?
備注：
Tcp1323Opts
說明：該參數(shù)控制 RFC 1323 時間戳與窗口縮放選項。默認情況下，啟用時間戳與
窗口縮放，但是可以使用標志位進行控制。0 位控制窗口縮放，1 位控制時間戳。
值為0（禁用 RFC 1323 選項）
值為1（僅啟用窗口縮放）
值為2（僅啟用時間戳）
值為3（兩個選項均啟用）
?
net.ipv4.tcp_timestamps=0
說明：時間戳可以避免序列號的卷繞。一個1Gbps的鏈路肯定會遇到以前用過的序列號。時間戳能夠讓內(nèi)核接受這種“異常”的數(shù)據(jù)包。這里需要將其關掉。
值為0（禁用時間戳）
值為1（啟用時間戳）
?
只有客戶端和服務端都開啟時間戳的情況下，才會出現(xiàn)能ping通不能建立tcp三次握手的情況，所以做為提供服務的公司，不可能保證所有的用戶都關閉時間戳，這個功能，所以我們必須關閉時間戳，這樣才能給所用用戶提供正常的服務。
轉載于:https://my.oschina.net/tsh/blog/1335116
總結
以上是生活随笔為你收集整理的记一次TCP连接异常故障解决的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： javascript深拷贝和浅拷贝
- 下一篇： 大数据服务社会的一个有益实践