TCP服務端收到syn但是不回複syn ack問題分析

TCP服務端收到syn但是不回複syn ack問題分析

TCP服務端收到syn但是不回複syn ack問題分析
——lvyilong316

最近在分析客戶的一個問題時遇到了一種奇怪的情況，客戶在服務端開啟了某個連接埠，但是在用戶端telnet確一直不通。通過在服務端抓包發現，用戶端的syn分節已經到達，但是服務端並沒有應答。查看了一下當前串連數，發現串連數也不大，所以排除是串連隊列滿造成的。後來忽然想起了net.ipv4.tcp_tw_recycle選項可能引起這個問題，於是關閉了這個選項，問題果然得以解決。這裡分析一下原因。

有些伺服器（當然用戶端也可以）為了避免TIME_WAIT狀態佔用串連，希望能加快TIME_WAIT狀態的回收，通常將net.ipv4.tcp_tw_recycle選項開啟。當然這個選項的生效要依賴net.ipv4.tcp_timestamps選項的開啟。雖然開啟這個選項能夠加快TIME_WAIT串連的回收，但卻引入了另一個問題。我們先看下tcp_tw_recycle選項的工作機制：

當開啟了tcp_tw_recycle選項後，當串連進入TIME_WAIT狀態後，會記錄對應遠端主機最後到達分節的時間戳記。如果同樣的主機有新的分節到達，且時間戳記小於之前記錄的時間戳記，即視為無效，相應的資料包會被丟棄（rfc1323）。

Linux是否啟用這種行為取決於tcp_timestamps和tcp_tw_recycle，因為tcp_timestamps預設就是開啟的，所以當tcp_tw_recycle被開啟後，實際上這種行為就被啟用了。

現在很多公司都用LVS做負載平衡，通常是前面一台LVS，後面多台後端伺服器，這其實就是NAT，當請求到達LVS後，它修改地址資料後便轉寄給後端伺服器，但不會修改時間戳記資料，對於後端伺服器來說，請求的源地址就是LVS的地址，加上連接埠會複用，所以從後端伺服器的角度看，原本不同用戶端的請求經過LVS的轉寄，就可能會被認為是同一個串連，加之不同用戶端的時間可能不一致，所以就會出現時間戳記錯亂的現象，於是後面的資料包就被丟棄了，具體的表現通常是是用戶端明明發送的SYN，但服務端就是不響應ACK，還可以通過下面命令來確認資料包不斷被丟棄的現象：

shell> netstat -s | grep timestamp

... packets rejects in established connections because of timestamp

如果伺服器身處NAT環境，安全起見，通常要禁止tcp_tw_recycle，至於TIME_WAIT串連過多的問題，可以通過啟用tcp_tw_reuse來緩解（只對用戶端有作用）。

當然關閉tcp_timestamps選項也是可以避免這個問題的：

設定sysctl.conf裡面tcp_timestamps=0也可以只用命令sysctl -w net.ipv4.tcp_timestamps=0

但個人建議關閉tcp_tw_recycle選項，而不是timestamp；因為 在tcp timestamp關閉的條件下，開啟tcp_tw_recycle是不起作用的；而tcp timestamp可以獨立開啟並起作用。此外tcp timestamp還和其他選項起作用有關，如tcp_tw_reuse。