控制參數(shù) 參數(shù)說明

　　tcp_keepcnt關(guān)閉一個(gè)非活躍連接之前進(jìn)行探測的最大次數(shù)，默認(rèn)為 8 次

　　tcp_keepidle對一個(gè)連接進(jìn)行有效性探測之前運(yùn)行的最大非活躍時(shí)間間隔，默認(rèn)值為 14400（即 2 個(gè)小時(shí)）

　　tcp_keepintvl兩個(gè)探測的時(shí)間間隔，默認(rèn)值為 150 即 75 秒

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

　　清單 4. telnet 連接在服務(wù)器端的 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 行的報(bào)文是本連接發(fā)送的最后數(shù)據(jù)，而第 7 行則是對第 6 行數(shù)據(jù)的確認(rèn)。其后，該連接上沒有任何數(shù)據(jù)交互，從而使得該連接一直處于非活躍狀態(tài)。經(jīng)過 2 分鐘（第 8 行數(shù)據(jù)報(bào)時(shí)間 04:53:54 和第 7 行數(shù)據(jù)報(bào)時(shí)間 04:51:54 之差，即 tcp_keepidle 的值）的非活躍時(shí)間后，第 8 行是服務(wù)器端發(fā)起第一個(gè)保活探測數(shù)據(jù)報(bào)。由于服務(wù)器端沒有收到客戶端關(guān)于探測報(bào)文的相應(yīng)，因此再經(jīng)過 tcp_keepintvl 的時(shí)間間隔（75 秒）之后，第 9 行顯示服務(wù)器端再次發(fā)起保活探測數(shù)據(jù)報(bào)。服務(wù)器端持續(xù)發(fā)送了 tcp_keepcnt 個(gè)探測報(bào)文（上面結(jié)果顯示，在 AIX 上是持續(xù)發(fā)送 tcp_keepcnt+1 個(gè)探測報(bào)文）之后，仍然沒有收到來自客戶端的任何回應(yīng)，所以服務(wù)器在第 17 行向客戶端發(fā)送復(fù)位報(bào)文同時(shí)在服務(wù)器端關(guān)閉了該連接。

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

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

　　AIX 上的 TCP 斷連及數(shù)據(jù)分析

　　圖 3. 出現(xiàn) TCP 斷連的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)示意圖

　　所有服務(wù)器主機(jī)均劃為一個(gè)局域網(wǎng)，并處于防火墻 B 之后。由于工作需要，來自工作區(qū)局域網(wǎng)的主機(jī) testClient 需和服務(wù)器局域網(wǎng)內(nèi)的 testServer 上的數(shù)據(jù)庫使用 TCP/IP 建立一個(gè)連接，testClient 上的上層應(yīng)用將通過該連接對 testServer 上的數(shù)據(jù)庫進(jìn)行相應(yīng)操作。

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

　　由于該現(xiàn)象不斷出現(xiàn)，并且網(wǎng)絡(luò)內(nèi)的中間節(jié)點(diǎn)（路由器和交換機(jī)等）均工作正常，因此可以排除物理因素（如掉電、宕機(jī)等）的可能。為了便于分析斷連原因，我們首先查看了 testServer 機(jī)器上的默認(rèn)保活設(shè)置：

　　# no -a | grep keep

　　tcp_keepcnt = 8

　　tcp_keepidle = 14400

　　tcp_keepintvl = 150

　　testServer 上的 tcp_keepidle 為 14400，即 2 個(gè)小時(shí)。既然中間節(jié)點(diǎn)工作正常，為什么保活機(jī)制沒有其作用呢？為了進(jìn)行分析，我們采用 tcpdump 工具捕獲 testClient 和 testServer 上的報(bào)文信息，見清單 5 和清單 6 所示。

　　清單 5. 服務(wù)器端的 tcpdump 數(shù)據(jù)輸出

　　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 數(shù)據(jù)輸出

　　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 中可以看出，在該連接處于非活躍狀態(tài)的時(shí)間達(dá)到 tcp_keepidle 設(shè)定的 2 小時(shí)時(shí)，服務(wù)器主機(jī)發(fā)出了第一個(gè)連接保活的探測報(bào)文（清單 5 中的第 7 行）。緊接著，服務(wù)器主機(jī)就收到了來自 testClient 的連接復(fù)位報(bào)文（清單 5 中的第 8 行）。之后，服務(wù)器便關(guān)閉了該連接（可以通過 netstat –ni 來查看）。然而，從清單 6 的 tcpdump 數(shù)據(jù)可以看出， testClient 端并未發(fā)送任何報(bào)文。那么，是誰向 testServer 發(fā)送了復(fù)位報(bào)文呢？

　　為了查看上述復(fù)位報(bào)文的發(fā)送者，同樣采用上述 tcpdump 命令再次捕獲服務(wù)器端和防火墻 B 的報(bào)文信息（注意：通常需要捕獲防火墻主機(jī)上網(wǎng)絡(luò)數(shù)據(jù)的出口網(wǎng)卡和入口網(wǎng)卡數(shù)據(jù)），結(jié)果顯示，防火墻 B 在收到來自 testServer 的第一個(gè)探測報(bào)文之后就立刻向 testServer 發(fā)送了一個(gè)復(fù)位報(bào)文。

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

　　兩種常用的解決方案

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

　　方案 1、延長防火墻終止非活躍的 TCP 連接的時(shí)間。例如，針對上述案例，可以調(diào)節(jié)防火墻設(shè)置，將時(shí)間設(shè)置為大于服務(wù)器端設(shè)定的 2 小時(shí)。

　　方案 2、縮短服務(wù)器端的 TCP 連接保活時(shí)間。縮短該時(shí)間的目的是為了在連接被防火墻終止之前發(fā)送保活探測報(bào)文，既可以探測客戶端狀態(tài)，又可以使連接變?yōu)榛钴S狀態(tài)。

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

　　總結(jié)

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