控制參數 參數說明

　　tcp_keepcnt關閉一個非活躍連接之前進行探測的最大次數，默認為 8 次

　　tcp_keepidle對一個連接進行有效性探測之前運行的最大非活躍時間間隔，默認值為 14400（即 2 個小時）

　　tcp_keepintvl兩個探測的時間間隔，默認值為 150 即 75 秒

　　我們來看一個具體的例子。在 testServer 端（AIX 主機）采用 tcp_keepidel=240（即 2 分鐘）：tcp_keepcnt=8：tcp_keepintvl=150（即 75 秒）的參數值；啟動 testServer 上的 tcpdump 查看網絡包的交互情況；從 testClient 端發起請求建立和 testServer 之間的一個 telnet 連接。在連接建立完成之后，拔出 testClient 端的網線并觀察服務器端的數據輸出（見清單 4）。

　　清單 4. telnet 連接在服務器端的 tcpdump 輸出

　　1 # tcpdump -i en1 host testServer.cn.ibm.com

　　2 04:51:51.379716 IP testClient.cn.ibm.com.telnet.40621 》

　　testServer.cn.ibm.com.telnet： S 4097149880:4097149880（0）

　　3 04:51:51.379755 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.40621： S 2543529892:2543529892（0） ack 4097149881

　　4 04:51:51.380609 IP testClient.cn.ibm.com.telnet.40621 》

　　testServer.cn.ibm.com.telnet： 。 ack 1

　　5 。。。

　　6 04:51:54.924058 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.40621： P 676:696（20） ack 87

　　7 04:51:54.924909 IP testClient.cn.ibm.com.telnet.40621 》

　　testServer.cn.ibm.com.telnet： 。 ack 696

　　8 04:53:54.550192 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.40621： 。 695:696（1） ack 86

　　9 04:55:09.550997 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.40621： 。 695:696（1） ack 86

　　10 04:56:24.552053 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.40621： 。 695:696（1） ack 86

　　11 04:57:39.552615 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.40621： 。 695:696（1） ack 86

　　12 04:58:54.553446 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.40621： 。 695:696（1） ack 86

　　13 05:00:09.554287 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.40621： 。 695:696（1） ack 86

　　14 05:01:24.555117 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.40621： 。 695:696（1） ack 86

　　15 05:02:39.555958 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.40621： 。 695:696（1） ack 86

　　16 05:03:54.557282 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.40621： 。 695:696（1） ack 86

　　17 05:05:09.559795 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.40621： R 696:696（0） ack 87

　　從清單 4 中可以看出，第 6 行的報文是本連接發送的最后數據，而第 7 行則是對第 6 行數據的確認。其后，該連接上沒有任何數據交互，從而使得該連接一直處于非活躍狀態。經過 2 分鐘（第 8 行數據報時間 04:53:54 和第 7 行數據報時間 04:51:54 之差，即 tcp_keepidle 的值）的非活躍時間后，第 8 行是服務器端發起第一個保活探測數據報。由于服務器端沒有收到客戶端關于探測報文的相應，因此再經過 tcp_keepintvl 的時間間隔（75 秒）之后，第 9 行顯示服務器端再次發起保活探測數據報。服務器端持續發送了 tcp_keepcnt 個探測報文（上面結果顯示，在 AIX 上是持續發送 tcp_keepcnt+1 個探測報文）之后，仍然沒有收到來自客戶端的任何回應，所以服務器在第 17 行向客戶端發送復位報文同時在服務器端關閉了該連接。

　　需要注意的是，保活探測雖然通過發送 TCP 探測報文，但探測報文不會對正常的 TCP 連接產生任何影響。從清單 4 可以看出，第 8 行發送數據的 TCP 報文序號為 695 起始的 1Byte 數據，而該數據在第 6 行已經發送并被客戶端確認。對于正常狀態的連接，客戶端在收到探測報文之后將返回一個第 7 行所示的 ACK 報文并借此向服務器端表明連接工作正常。

　　接下來，我們將通過一個實際的 TCP 斷連的例子來分析上述機制對 TCP 連接保持的影響，并針對需要長時間保持 TCP 連接的應用提出兩種可選的解決方案。

　　AIX 上的 TCP 斷連及數據分析

　　圖 3. 出現 TCP 斷連的網絡拓撲結構示意圖

　　所有服務器主機均劃為一個局域網，并處于防火墻 B 之后。由于工作需要，來自工作區局域網的主機 testClient 需和服務器局域網內的 testServer 上的數據庫使用 TCP/IP 建立一個連接，testClient 上的上層應用將通過該連接對 testServer 上的數據庫進行相應操作。

　　在實際測試中，我們發現，在 testClient 和 testServer 均工作正常的情況下，testClient 上的客戶端在事先沒有收到任何異常信息的情況下，所持有的連接會出現非預期的斷連現象（在試圖通過連接進行數據庫操作時，會被告知 connection is reset by foreign host 的錯誤）。

　　由于該現象不斷出現，并且網絡內的中間節點（路由器和交換機等）均工作正常，因此可以排除物理因素（如掉電、宕機等）的可能。為了便于分析斷連原因，我們首先查看了 testServer 機器上的默認保活設置：

　　# no -a | grep keep

　　tcp_keepcnt = 8

　　tcp_keepidle = 14400

　　tcp_keepintvl = 150

　　testServer 上的 tcp_keepidle 為 14400，即 2 個小時。既然中間節點工作正常，為什么保活機制沒有其作用呢？為了進行分析，我們采用 tcpdump 工具捕獲 testClient 和 testServer 上的報文信息，見清單 5 和清單 6 所示。

　　清單 5. 服務器端的 tcpdump 數據輸出

　　1 10:18:58.881950 IP testClient.cn.ibm.com.59098 》

　　testServer.cn.ibm.com.telnet： S 1182666808:1182666808（0） 。。。

　　2 10:18:58.882001 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.59098： S 3333341833:3333341833（0） ack 1182666809 。。。

　　3 10:18:58.882845 IP testClient.cn.ibm.com.59098 》

　　testServer.cn.ibm.com.telnet： 。 ack 1 。。。

　　4 。。。

　　5 10:19:03.165568 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.59098： P 1010:1032（22） ack 87 。。。

　　6 10:19:03.166457 IP testClient.cn.ibm.com.59098 》

　　testServer.cn.ibm.com.telnet： 。 ack 1032 。。。

　　7 12:19:05.445336 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.59098： 。 1031:1032（1） ack 86 。。。

　　8 12:19:05.445464 IP testClient.cn.ibm.com.59098 》

　　testServer.cn.ibm.com.telnet： R 86:87（1） ack 1031 。。。

　　清單 6. 客戶端的 tcpdump 數據輸出

　　1 # tcpdump -e -i eth0 host testServer.cn.ibm.com

　　2 10:18:55.800553 IP testClient.cn.ibm.com.59098 》

　　testServer.cn.ibm.com.telnet： S 1182666808:1182666808（0） 。。。

　　3 10:18:55.801778 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.59098： S 3333341833:3333341833（0） ack 1182666809 。。。

　　4 10:18:55.801799 IP testClient.cn.ibm.com.59098 》

　　testServer.cn.ibm.com.telnet： 。 ack 1 。。。

　　5 。。。

　　6 10:19:00.084662 IP testServer.cn.ibm.com.telnet 》

　　testClient.cn.ibm.com.59098： P 1010:1032（22） ack 87 。。。

　　7 10:19:00.084678 IP testClient.cn.ibm.com.59098 》

　　testServer.cn.ibm.com.telnet： 。 ack 1032 。。。

　　從清單 5 中可以看出，在該連接處于非活躍狀態的時間達到 tcp_keepidle 設定的 2 小時時，服務器主機發出了第一個連接保活的探測報文（清單 5 中的第 7 行）。緊接著，服務器主機就收到了來自 testClient 的連接復位報文（清單 5 中的第 8 行）。之后，服務器便關閉了該連接（可以通過 netstat –ni 來查看）。然而，從清單 6 的 tcpdump 數據可以看出， testClient 端并未發送任何報文。那么，是誰向 testServer 發送了復位報文呢？

　　為了查看上述復位報文的發送者，同樣采用上述 tcpdump 命令再次捕獲服務器端和防火墻 B 的報文信息（注意：通常需要捕獲防火墻主機上網絡數據的出口網卡和入口網卡數據），結果顯示，防火墻 B 在收到來自 testServer 的第一個探測報文之后就立刻向 testServer 發送了一個復位報文。

　　上述分析說明，在連接傳遞完最后一個交互數據之后到服務器端發送第一個保活探測之間，該連接已經被防火墻 B 終止；在此之后，基于該連接的任何報文傳遞在試圖穿過防火墻的時候均會被防火墻丟棄并發送復位報文。

　　兩種常用的解決方案

　　針對上述 TCP 斷連現象，有兩種常用的解決方案可供選擇：

　　方案 1、延長防火墻終止非活躍的 TCP 連接的時間。例如，針對上述案例，可以調節防火墻設置，將時間設置為大于服務器端設定的 2 小時。

　　方案 2、縮短服務器端的 TCP 連接保活時間。縮短該時間的目的是為了在連接被防火墻終止之前發送保活探測報文，既可以探測客戶端狀態，又可以使連接變為活躍狀態。

　　對于第一種方案而言，延長 TCP 連接的保持時間可能會導致防火墻性能的降低，尤其是在維持大量長時間處于非活躍狀態的連接的情況下更是如此；而對于第二種方案，如果縮短服務器端的 TCP 連接保活時間，意味著會增加網絡中的數據報文數而占用額外的網絡帶寬。因此，兩種方案各有利弊，需要依據不同的實際應用情況進行選擇。

　　總結

　　本文介紹了 TCP 連接的建立和保持的相關概念以及影響 TCP 連接保持的常見因素。給出了常見的類 Unix 系統上 TCP 連接保活探測的相關配置參數，并基于 AIX 借助 tcpdump 工具分析了一個實際的 TCP 斷連的案例。最后，針對 TCP 斷連的情況給出了兩種可行的解決方案。