TCP 連接的保持并不需要任何額外的操作，但在實(shí)際應(yīng)用中，要長(zhǎng)時(shí)間保持一個(gè) TCP 連接則會(huì)受到諸多因素的影響。本文介紹了幾種常見的導(dǎo)致 TCP 連接斷連的原因，并在此基礎(chǔ)上，以 AIX 系統(tǒng)上 TCP 連接的異常斷連為例，借助相應(yīng)的網(wǎng)絡(luò)分析工具，逐步揭開 AIX 上 TCP 斷連的原因，并給出兩種可行的解決方案。<!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --><!--END RESERVED FOR FUTURE USE INCLUDE FILES-->
在官方的正式文檔中，TCP/IP 協(xié)議簇也稱為國(guó)際互聯(lián)網(wǎng)協(xié)議簇。TCP/IP 協(xié)議簇是目前使用最為廣泛的全球互聯(lián)網(wǎng)技術(shù)，其分層結(jié)構(gòu)如圖 1 所示：
圖 1. TCP/IP 協(xié)議簇分層結(jié)構(gòu)
如圖 1 所示，數(shù)據(jù)鏈路層主要負(fù)責(zé)處理傳輸媒介等眾多的物理接口細(xì)節(jié)；網(wǎng)絡(luò)層負(fù)責(zé)處理數(shù)據(jù)分組在網(wǎng)絡(luò)中的活動(dòng)，包括上層數(shù)據(jù)報(bào)文的分割、選路 phost2008-08-21T00:00:00 等；傳輸層則負(fù)責(zé)為兩臺(tái)主機(jī)提供端到端的通信；應(yīng)用層將負(fù)責(zé)處理應(yīng)用程序的特定細(xì)節(jié)。其中，IP 協(xié)議是網(wǎng)絡(luò)層的核心協(xié)議，用來提供不可靠、無連接的數(shù)據(jù)傳遞服務(wù)；而 TCP 協(xié)議則處于傳輸層，其基于不可靠無連接的 IP 協(xié)議能夠?yàn)閮膳_(tái)主機(jī)提供面向連接的、可靠的通信。UDP?
由于 TCP 是面向連接的協(xié)議，因此在兩臺(tái)主機(jī)通信之前，需要首先建立起一條連接。下面我們將簡(jiǎn)要介紹 TCP 連接的建立以及通信雙方是如何保持已建立的 TCP 連接的。
一個(gè) TCP 連接的建立需要通過著名的“三次握手”來完成。下面的例子將直觀給出一個(gè) TCP 連接的建立過程。
在本文的下述描述中，客戶端主機(jī)均為 testClient.cn.ibm.com(Linux)，服務(wù)器主機(jī)均為 testServer.cn.ibm.com(AIX)。在 testClient 主機(jī)的一終端上執(zhí)行 tcpdump –i eth0 host testServer 命令，啟動(dòng) tcpdump 監(jiān)聽網(wǎng)絡(luò)數(shù)據(jù)（其中，eth0 是客戶主機(jī)與外部網(wǎng)絡(luò)進(jìn)行通信所使用的網(wǎng)卡）；與此同時(shí)，在客戶主機(jī)的另一個(gè)終端上執(zhí)行下述命令： (root@testClient /)>telnet testServer。此時(shí)客戶主機(jī)上 tcpdump 的輸出如清單 1 所示。
清單 1. 創(chuàng)建一個(gè) TCP 連接的三次握手
# tcpdump –S -i en0 host testServer
|
注意：我們刪除了 tcpdump 輸出結(jié)果中的部分無關(guān)信息。為了便于理解，我們將上述輸出轉(zhuǎn)換為實(shí)際序列圖 2。
圖 2. TCP 建立創(chuàng)建三次握手的實(shí)際序列
從圖 2 中我們可以清楚地看到，在 testClient 與 testServer 之間建立連接時(shí)，要經(jīng)過以下三次握手過程：
- testClient 向 testServer 主動(dòng)發(fā)送握手協(xié)議，報(bào)文序列號(hào)為 3392458353，大小為 1 個(gè)字節(jié)。
- testServer 向 testClient 主動(dòng)發(fā)送握手協(xié)議，報(bào)文序列號(hào)為 881279296，大小為 1 個(gè)字節(jié)；同時(shí)返回 ACK 3392458354，作為對(duì) testClient 發(fā)來的 3392458354 包的應(yīng)答。
- testClient 向 testServer 返回 ACK 881279297，作為對(duì) testServer 發(fā)來的 881279296 包的應(yīng)答。
一個(gè) TCP 連接在完成上述的三次握手之后便建立完畢；此后，連接的兩端即可進(jìn)行信息的相互傳遞。因此，TCP 連接可以認(rèn)為是以兩端 IP 地址和端口進(jìn)行標(biāo)識(shí)的一個(gè)通信信道，而 TCP 連接的建立就是向通信雙方進(jìn)行上述通信信道注冊(cè)的過程。TCP 連接一旦建立，只要通信雙方之間的中間結(jié)點(diǎn)（包括網(wǎng)關(guān)和交換機(jī)、路由器等網(wǎng)絡(luò)設(shè)備）工作正常，那么在通信雙方中的任何一方主動(dòng)關(guān)閉連接之前，TCP 連接都將被一直保持下去。
TCP 連接的這種特性，使得一個(gè)長(zhǎng)期不交換任何信息的空閑連接可以長(zhǎng)期保持?jǐn)?shù)小時(shí)、數(shù)天甚至數(shù)月。中間路由器可以崩潰、重啟，網(wǎng)線可以被掛斷再連通，只要兩端的主機(jī)沒有被重啟，TCP 連接就可以被一直保持下來。
|
|
理想狀態(tài)下，一個(gè) TCP 連接可以被長(zhǎng)期保持。然而，在實(shí)際應(yīng)用中，客戶端或服務(wù)器端上維持的一個(gè)看似正常的 TCP 連接可能已經(jīng)斷連。TCP 連接主要受到兩個(gè)方面的影響而導(dǎo)致斷連：網(wǎng)絡(luò)中間節(jié)點(diǎn)和客戶端 / 服務(wù)器節(jié)點(diǎn)參與通信的兩方節(jié)點(diǎn)？
在實(shí)際網(wǎng)絡(luò)應(yīng)用中，兩個(gè)主機(jī)之間的通信往往需要穿越多個(gè)中間節(jié)點(diǎn)，例如路由器、網(wǎng)關(guān)、防火墻等。因此，兩個(gè)主機(jī)之間 TCP 連接的保持同樣會(huì)受到中間節(jié)點(diǎn)的影響，尤其是會(huì)受到防火墻（軟件或硬件防火墻）的限制。防火墻是一種裝置，有多種不同的實(shí)現(xiàn)方式（軟件實(shí)現(xiàn)、硬件設(shè)備實(shí)現(xiàn)或是軟硬件相結(jié)合實(shí)現(xiàn)），它需要依據(jù)一系列規(guī)則對(duì)進(jìn)出的信息流進(jìn)行掃描，并允許安全（符合規(guī)則）的信息交互、阻止不安全（違反規(guī)則）的信息交互。防火墻的工作特性決定了要維護(hù)一個(gè)網(wǎng)絡(luò)連接就需要耗費(fèi)較多的資源，并且企業(yè)防火墻常常位于企業(yè)網(wǎng)絡(luò)的出入口，長(zhǎng)時(shí)間維護(hù)非活躍的 TCP 連接必將導(dǎo)致網(wǎng)絡(luò)性能的下降。因此，大部分防火墻默認(rèn)會(huì)關(guān)閉長(zhǎng)時(shí)間處于非活躍狀態(tài)的連接而導(dǎo)致 TCP 連接斷連。類似的，如果中間節(jié)點(diǎn)異常導(dǎo)致來自客戶端關(guān)閉連接的請(qǐng)求無法傳遞到服務(wù)器端，也將導(dǎo)致服務(wù)器端的相應(yīng)連接發(fā)生斷連。
另一方面，對(duì)于一個(gè) TCP 連接兩端的主機(jī)而言，創(chuàng)建 TCP 連接需要耗費(fèi)一定的系統(tǒng)資源。如果不再使用某個(gè)連接，那么我們總是希望進(jìn)行通信的兩個(gè)主機(jī)能夠主動(dòng)關(guān)閉相應(yīng)的連接，以便釋放所占用的系統(tǒng)資源。然而，如果由于客戶端出現(xiàn)異常 ( 例如崩潰或異常重啟 ) 而導(dǎo)致連接未能正常關(guān)閉，這將導(dǎo)致服務(wù)器端的連接斷連。
無論是客戶端節(jié)點(diǎn)或是服務(wù)器端節(jié)點(diǎn)，斷連的 TCP 連接已經(jīng)不能傳遞任何信息，因此，維護(hù)大量斷連的 TCP 連接將導(dǎo)致系統(tǒng)資源的浪費(fèi)。這種系統(tǒng)資源的浪費(fèi)可能并不會(huì)對(duì)客戶端節(jié)點(diǎn)帶來太大問題；然而，對(duì)于服務(wù)器主機(jī)而言，這可能會(huì)導(dǎo)致系統(tǒng)資源（尤指內(nèi)存資源和 socket 資源）被耗盡而拒絕為新的用戶請(qǐng)求提供服務(wù)。因此在實(shí)際應(yīng)用中，服務(wù)器端需要采取相應(yīng)的方法來探測(cè) TCP 連接是否已經(jīng)斷連。
|
|
|
探測(cè) TCP 連接是否斷連或是工作正常的原理比較簡(jiǎn)單：定期向連接的遠(yuǎn)程通信節(jié)點(diǎn)發(fā)送一定格式的信息并等待遠(yuǎn)程通信節(jié)點(diǎn)的反饋，如果在規(guī)定時(shí)間內(nèi)收到來自遠(yuǎn)程節(jié)點(diǎn)的正確的反饋信息，那么該連接就是正常的，否則該連接已經(jīng)斷連。依據(jù)該原理，目前常用的探測(cè)方法有以下三種。
應(yīng)用程序本身附帶探測(cè)其自身建立的 TCP 連接的功能。這種方法具有極大的靈活性，可以依據(jù)應(yīng)用本身的特點(diǎn)選擇相應(yīng)的探測(cè)機(jī)制和功能實(shí)現(xiàn)。然而，實(shí)際應(yīng)用中，大部分應(yīng)用程序均沒有附帶自我探測(cè)的功能。
此種方法就是在服務(wù)節(jié)點(diǎn)上安裝相應(yīng)的第三方應(yīng)用程序來探測(cè)該節(jié)點(diǎn)上所有的 TCP 連接是否正?；蚴且呀?jīng)斷連。該方法最大的不足就是需要所有支持探測(cè)的客戶端能夠識(shí)別來自該探測(cè)應(yīng)用的數(shù)據(jù)報(bào)文，因此，實(shí)際應(yīng)用中比較少見。
最常用的探測(cè)方法就是采用 TCP 協(xié)議層提供的保活探測(cè)功能即 TCP 連接?；疃〞r(shí)器。盡管該功能并不是 RFC 規(guī)范的一部分，但是幾乎所有的類 Unix 系統(tǒng)均實(shí)現(xiàn)了該功能，所以使得該探測(cè)方法被廣泛使用。
接下來的部分，我們將重點(diǎn)討論來自 TCP 協(xié)議層的?；钐綔y(cè)方法。
|
|
|
類 Unix 系統(tǒng)上的 TCP 連接保活定時(shí)器
TCP 連接的?；疃〞r(shí)器可以在應(yīng)用層實(shí)現(xiàn)，也可以在 TCP 中提供。這個(gè)問題存在爭(zhēng)議，因此 TCP 連接的保活探測(cè)并不是 TCP 規(guī)范中的一部分。但為了方便，幾乎所有類 Unix 系統(tǒng)均在 TCP 中提供了相應(yīng)的功能。
清單 2. 常見 Unix 系統(tǒng)上的?；疃〞r(shí)器
操作系統(tǒng) 保活定時(shí)器
| AIX |
# no -a | grep keep
tcp_keepcnt = 8 tcp_keepidle = 14400 tcp_keepintvl = 150 |
| Linux |
# sysctl -A | grep keep
net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_time = 7200 |
| FreeBSD |
#sysctl -A | grep net.inet.tcp
net.inet.tcp.keepidle=… net.inet.tcp.keepintvl=… |
不同系統(tǒng)上的各參數(shù)的時(shí)間單位不盡相同。在 AIX 上，tcp_keeidle/tcp_keepinit/tcp_keepintvl 的時(shí)間單位是 0.5 秒；而在 Linux 上，net.ipv4.tcp_keepalive_intvl 和 net.ipv4.tcp_keepalive_time 的時(shí)間單位則為秒。并且，上述參數(shù)僅對(duì)運(yùn)行在其上的服務(wù)器應(yīng)用連接有效。
注：在 Solaris 上可通過“ndd /dev/tcp /?”命令顯示上述類似參數(shù)信息，而在 HP Unix 上則可通過 nettune 或 ndd 命令進(jìn)行查詢。
由于所有類 Unix 系統(tǒng)上均支持這種功能，因此，在接下來的部分中我們將基于 AIX 系統(tǒng)具體講述上述參數(shù)的意義和作用機(jī)制。
|
|
|
AIX 中的 TCP 連接?；钐綔y(cè)機(jī)制及原理
正如清單 2 中列出的一樣，AIX 上的?；钐綔y(cè)機(jī)制由 4 個(gè)參數(shù)來控制，其具體意義見清單 3：
清單 3. AIX 上的?；疃〞r(shí)器控制參數(shù)
控制參數(shù) 參數(shù)說明
| tcp_keepcnt | 關(guān)閉一個(gè)非活躍連接之前進(jìn)行探測(cè)的最大次數(shù)，默認(rèn)為 8 次 |
| tcp_keepidle | 對(duì)一個(gè)連接進(jìn)行有效性探測(cè)之前運(yùn)行的最大非活躍時(shí)間間隔，默認(rèn)值為 14400（即 2 個(gè)小時(shí)） |
| tcp_keepintvl | 兩個(gè)探測(cè)的時(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ā)起請(qǐng)求建立和 testServer 之間的一個(gè) telnet 連接。在連接建立完成之后，拔出 testClient 端的網(wǎng)線并觀察服務(wù)器端的數(shù)據(jù)輸出（見清單 4）。
清單 4. telnet 連接在服務(wù)器端的 tcpdump 輸出
1 # tcpdump -i en1 host testServer.cn.ibm.com
|
從清單 4 中可以看出，第 6 行的報(bào)文是本連接發(fā)送的最后數(shù)據(jù)，而第 7 行則是對(duì)第 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è)?；钐綔y(cè)數(shù)據(jù)報(bào)。由于服務(wù)器端沒有收到客戶端關(guān)于探測(cè)報(bào)文的相應(yīng)，因此再經(jīng)過 tcp_keepintvl 的時(shí)間間隔（75 秒）之后，第 9 行顯示服務(wù)器端再次發(fā)起保活探測(cè)數(shù)據(jù)報(bào)。服務(wù)器端持續(xù)發(fā)送了 tcp_keepcnt 個(gè)探測(cè)報(bào)文（上面結(jié)果顯示，在 AIX 上是持續(xù)發(fā)送 tcp_keepcnt+1 個(gè)探測(cè)報(bào)文）之后，仍然沒有收到來自客戶端的任何回應(yīng)，所以服務(wù)器在第 17 行向客戶端發(fā)送復(fù)位報(bào)文同時(shí)在服務(wù)器端關(guān)閉了該連接。
需要注意的是，保活探測(cè)雖然通過發(fā)送 TCP 探測(cè)報(bào)文，但探測(cè)報(bào)文不會(huì)對(duì)正常的 TCP 連接產(chǎn)生任何影響。從清單 4 可以看出，第 8 行發(fā)送數(shù)據(jù)的 TCP 報(bào)文序號(hào)為 695 起始的 1Byte 數(shù)據(jù)，而該數(shù)據(jù)在第 6 行已經(jīng)發(fā)送并被客戶端確認(rèn)。對(duì)于正常狀態(tài)的連接，客戶端在收到探測(cè)報(bào)文之后將返回一個(gè)第 7 行所示的 ACK 報(bào)文并借此向服務(wù)器端表明連接工作正常。
接下來，我們將通過一個(gè)實(shí)際的 TCP 斷連的例子來分析上述機(jī)制對(duì) TCP 連接保持的影響，并針對(duì)需要長(zhǎng)時(shí)間保持 TCP 連接的應(yīng)用提出兩種可選的解決方案。
|
|
|
圖 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ù)庫(kù)使用 TCP/IP 建立一個(gè)連接，testClient 上的上層應(yīng)用將通過該連接對(duì) testServer 上的數(shù)據(jù)庫(kù)進(jìn)行相應(yīng)操作。
在實(shí)際測(cè)試中，我們發(fā)現(xiàn)，在 testClient 和 testServer 均工作正常的情況下，testClient 上的客戶端在事先沒有收到任何異常信息的情況下，所持有的連接會(huì)出現(xiàn)非預(yù)期的斷連現(xiàn)象（在試圖通過連接進(jìn)行數(shù)據(jù)庫(kù)操作時(shí)，會(huì)被告知 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)?；钤O(shè)置：
# no -a | grep keep
|
testServer 上的 tcp_keepidle 為 14400，即 2 個(gè)小時(shí)。既然中間節(jié)點(diǎn)工作正常，為什么?；顧C(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 >
|
清單 6. 客戶端的 tcpdump 數(shù)據(jù)輸出
1 # tcpdump -e -i eth0 host testServer.cn.ibm.com
|
從清單 5 中可以看出，在該連接處于非活躍狀態(tài)的時(shí)間達(dá)到 tcp_keepidle 設(shè)定的 2 小時(shí)時(shí)，服務(wù)器主機(jī)發(fā)出了第一個(gè)連接保活的探測(cè)報(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è)探測(cè)報(bào)文之后就立刻向 testServer 發(fā)送了一個(gè)復(fù)位報(bào)文。
上述分析說明，在連接傳遞完最后一個(gè)交互數(shù)據(jù)之后到服務(wù)器端發(fā)送第一個(gè)?；钐綔y(cè)之間，該連接已經(jīng)被防火墻 B 終止；在此之后，基于該連接的任何報(bào)文傳遞在試圖穿過防火墻的時(shí)候均會(huì)被防火墻丟棄并發(fā)送復(fù)位報(bào)文。
|
|
|
針對(duì)上述 TCP 斷連現(xiàn)象，有兩種常用的解決方案可供選擇：
方案 1、延長(zhǎng)防火墻終止非活躍的 TCP 連接的時(shí)間。例如，針對(duì)上述案例，可以調(diào)節(jié)防火墻設(shè)置，將時(shí)間設(shè)置為大于服務(wù)器端設(shè)定的 2 小時(shí)。
方案 2、縮短服務(wù)器端的 TCP 連接?；顣r(shí)間。縮短該時(shí)間的目的是為了在連接被防火墻終止之前發(fā)送保活探測(cè)報(bào)文，既可以探測(cè)客戶端狀態(tài)，又可以使連接變?yōu)榛钴S狀態(tài)。
對(duì)于第一種方案而言，延長(zhǎng) TCP 連接的保持時(shí)間可能會(huì)導(dǎo)致防火墻性能的降低，尤其是在維持大量長(zhǎng)時(shí)間處于非活躍狀態(tài)的連接的情況下更是如此；而對(duì)于第二種方案，如果縮短服務(wù)器端的 TCP 連接?；顣r(shí)間，意味著會(huì)增加網(wǎng)絡(luò)中的數(shù)據(jù)報(bào)文數(shù)而占用額外的網(wǎng)絡(luò)帶寬。因此，兩種方案各有利弊，需要依據(jù)不同的實(shí)際應(yīng)用情況進(jìn)行選擇。
|
|
|
本文介紹了 TCP 連接的建立和保持的相關(guān)概念以及影響 TCP 連接保持的常見因素。給出了常見的類 Unix 系統(tǒng)上 TCP 連接保活探測(cè)的相關(guān)配置參數(shù)，并基于 AIX 借助 tcpdump 工具分析了一個(gè)實(shí)際的 TCP 斷連的案例。最后，針對(duì) TCP 斷連的情況給出了兩種可行的解決方案。
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號(hào)聯(lián)系： 360901061
您的支持是博主寫作最大的動(dòng)力，如果您喜歡我的文章，感覺我的文章對(duì)您有幫助，請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長(zhǎng)非常感激您！手機(jī)微信長(zhǎng)按不能支付解決辦法：請(qǐng)將微信支付二維碼保存到相冊(cè)，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對(duì)您有幫助就好】元
