一場由tcp_timestamps 引發的無解追擊案

  案例描述：我們的合作客戶（國內知名電子支付企業）反應有四臺機器調用我們的接口服務，但是奇怪的是四臺中有兩臺是通的，有兩臺是不通的，不通的機器也是偶爾通偶爾不通，這個問題一直斷斷續續困擾了他們很久，剛開始我們認為是他們系統那里參數配置不對，就沒有給予太多關注，畢竟我們還有好多合作客戶，卻沒有問題；這個問題直到有一天，他們實在扛不住，實在找不出原因了，要求我們技術人員現場去幫他們排查，才開始了一場無解破解案。

  那天接手了這個問題后，開始一對一讓對方網絡技術人員配合聯合排查，分別從正常機器，不正常機器，出口網絡設備，我方接收機器同時抓包測試；從抓包現象來分析的確是有重傳現象，并且三臺機器中偶爾一臺通，另外兩臺就通不了；那天我們手工畫了雙方的 網絡拓撲圖，從中了解到一點 他們出去的時候做了S-NAT,并且在問題一開始他們試出了一個解決方法：再加一個外網ip 出來，四臺機器不共用一個外網ip 出來，而是兩個！這樣有兩臺機器正常了。還有兩臺依然不正常。有點怪異。

  中間的各種懷疑也不描述了，直到重看抓包，的確發現問題，對方在三次握手(這里就不做詳細解釋)的時候，發出syn包的時候，我方沒有syn+ack 確認，對方一直tcp 重傳，并且可以確認的是對方的syn 包的確到達我們了，是我們這邊沒有回復syn+ack！我們開始把注意力轉向我方的網絡情況。

三次握手過程截圖：

對方出口截圖：

我們的入口截圖：

從源端口26414看，的確是同一連接請求從對方出口已經發出，到了我們遲遲沒有syn+ack 回復，于是就有了不停的重傳請求，連接超時。

剛開始懷疑nginx問題，懷疑keepd 問題，懷疑centos 問題，甚至懷疑底層虛擬化kvm/esxi 問題，做過的無盡測試排查這里就不描述了。但是從單方面一直沒有突破，這個時候給了點希望，我方有臺esxi ubuntu 的機器確實很正常的，對方三臺機器都可以聯通，于是就開始對比我們這邊兩臺機器的內核配置參數 sysctl -a > sysctl.txt 導出對比。

通過對比主要懷疑了以下參數（具體作用大家可網上查閱）：

tcp_sack 

tcp_fack

tcp_syncookies

tcp_tw_recycle

tcp_retries1

tcp_timestamps

發現tcp_tw_recycle 這個參數二者是不一樣的，于是改成一樣。對方測試，恢復正常。再關掉，對方測試，重新異常。基本就鎖定了這個參數。

tcp_tw_recycle默認是關閉的，有不少服務器，為了提高性能，開啟了該選項，在一些高并發的 WebServer上，為了端口能夠快速回收，打開了net.ipv4.tcp_tw_recycle。為什么我這里打開了快速回收，對方的服務器就連接異常了呢，仔細對比抓包發現，問題漏出了端倪。

    對的，仔細看圖只要是異常的，沒有回復的syn 包，時間戳都是不對的，默認情況應該是遞增的，才會連接正常。再結合對方網絡是共用一個Ip做了S-NAT，問題原因找到了。

我方服務器打開了 tcp_tw_reccycle 了，就會檢查時間戳，很不幸對方發來的包的時間戳是亂跳的（截圖時間字段，準確來講對方發來的時間戳是滯后的，這樣的包我方肯定不會回復），所以服務器就把帶了“倒退”的時間戳的包當作是“recycle的tw連接的重傳數據，不是新的請求”，于是丟掉不回包，造成大量丟包。

##########################################################################################

疑問：為什么對方發來的時間戳是亂跳的？

  通過對比對方的配置sysctl -a 發現，對端開啟了tcp_timestamps，而且在我們tcp_tw_recycle被打開了話，會假設對端開啟了tcp_timestamps，然后會去比較時間戳，如果時間戳變大了，就可以重用。但是，如果對端是一個NAT網絡的話（如：一個公司只用一個IP出公網）或是對端的IP被另一臺重用了，這個事就復雜了。建鏈接的SYN可能就被直接丟掉了（你可能會看到connection time out的錯誤）（如果你想觀摩一下Linux的內核代碼，請參看源碼 tcp_timewait_state_process）。

看到這里問題似乎已經解決了，但是不是，這不是最優的解決方法。因為從目前來看，我們得出兩種解決方法：

1，我方關閉tcp_tw_recycle ,不開啟回收功能，也就不會檢查時間戳，這種包肯定會被響應了。

2.對方關閉tcp_timestamps， 這樣發來的報文就不帶時間戳。但是這兩種方法各有長短優劣。

##########################################################################################

1. 關閉tcp_tw_recycle ，好處：不能保證所有客戶都關閉了tcp_timestamps情況下，可以避免類似問題發生。短處：若負載量高的情況下，web_server 的time_wait 狀態量會直線飆升。官方建議是關閉該選項：

   
   

##########################################################################################

2.對方關閉tcp_timestamps.好處：問題迎刃而解 短處：查閱rfc 文檔，這個tcp 可選字段會造成一些影響。

##########################################################################################

最后顯示一個沒有timestamp可選字段的報文，實地測試通過，也是正常可用：

有timestamp可選字段的報文：

  至此，一場由tcp_timestamps 引發的無解追擊案結束了。從這里得出任何事情一定要實事求是，仔細抓包分析，仔細查閱文檔，用數據說話。不要整天猜測而不是去實地考察研究，這樣只會浪費更多的時間，當然，文章還有很多紕漏之處，畢竟牽扯的技術點太多，望包涵指正。