TCP 连接断连问题剖析
在官方的正式文檔中，TCP/IP 協(xié)議簇也稱為國際互聯(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ī)通信之前，需要首先建立起一條連接。下面我們將簡要介紹 TCP 連接的建立以及通信雙方是如何保持已建立的 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 1 14:02:38.384918 IP testClient.cn.ibm.com.43370 > testServer.cn.ibm.com.telnet: S 3392458353:3392458353(0) … 2 14:02:38.629578 IP testServer.cn.ibm.com.telnet > testClient.cn.ibm.com.43370: S 881279296:881279296(0) ack 3392458354 … 3 14:02:38.629592 IP testClient.cn.ibm.com.43370 > testServer.cn.ibm.com.telnet: . ack 881279297 … |
注意：我們刪除了 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)行上述通信信道注冊的過程。TCP 連接一旦建立，只要通信雙方之間的中間結(jié)點(diǎn)（包括網(wǎng)關(guān)和交換機(jī)、路由器等網(wǎng)絡(luò)設(shè)備）工作正常，那么在通信雙方中的任何一方主動(dòng)關(guān)閉連接之前，TCP 連接都將被一直保持下去。
TCP 連接的這種特性，使得一個(gè)長期不交換任何信息的空閑連接可以長期保持?jǐn)?shù)小時(shí)、數(shù)天甚至數(shù)月。中間路由器可以崩潰、重啟，網(wǎng)線可以被掛斷再連通，只要兩端的主機(jī)沒有被重啟，TCP 連接就可以被一直保持下來。
導(dǎo)致 TCP 連接斷連的因素
理想狀態(tài)下，一個(gè) TCP 連接可以被長期保持。然而，在實(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ò)的出入口，長時(shí)間維護(hù)非活躍的 TCP 連接必將導(dǎo)致網(wǎng)絡(luò)性能的下降。因此，大部分防火墻默認(rèn)會(huì)關(guān)閉長時(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)的方法來探測 TCP 連接是否已經(jīng)斷連。
探測 TCP 連接斷連的三種常用方法
探測 TCP 連接是否斷連或是工作正常的原理比較簡單：定期向連接的遠(yuǎn)程通信節(jié)點(diǎn)發(fā)送一定格式的信息并等待遠(yuǎn)程通信節(jié)點(diǎn)的反饋，如果在規(guī)定時(shí)間內(nèi)收到來自遠(yuǎn)程節(jié)點(diǎn)的正確的反饋信息，那么該連接就是正常的，否則該連接已經(jīng)斷連。依據(jù)該原理，目前常用的探測方法有以下三種。
應(yīng)用程序的自我探測
應(yīng)用程序本身附帶探測其自身建立的 TCP 連接的功能。這種方法具有極大的靈活性，可以依據(jù)應(yīng)用本身的特點(diǎn)選擇相應(yīng)的探測機(jī)制和功能實(shí)現(xiàn)。然而，實(shí)際應(yīng)用中，大部分應(yīng)用程序均沒有附帶自我探測的功能。
第三方應(yīng)用程序的探測
此種方法就是在服務(wù)節(jié)點(diǎn)上安裝相應(yīng)的第三方應(yīng)用程序來探測該節(jié)點(diǎn)上所有的 TCP 連接是否正常或是已經(jīng)斷連。該方法最大的不足就是需要所有支持探測的客戶端能夠識(shí)別來自該探測應(yīng)用的數(shù)據(jù)報(bào)文，因此，實(shí)際應(yīng)用中比較少見。
TCP 協(xié)議層的保活探測
最常用的探測方法就是采用 TCP 協(xié)議層提供的保活探測功能即 TCP 連接保活定時(shí)器。盡管該功能并不是 RFC 規(guī)范的一部分，但是幾乎所有的類 Unix 系統(tǒng)均實(shí)現(xiàn)了該功能，所以使得該探測方法被廣泛使用。
接下來的部分，我們將重點(diǎn)討論來自 TCP 協(xié)議層的保活探測方法。
類 Unix 系統(tǒng)上的 TCP 連接保活定時(shí)器
TCP 連接的保活定時(shí)器可以在應(yīng)用層實(shí)現(xiàn)，也可以在 TCP 中提供。這個(gè)問題存在爭議，因此 TCP 連接的保活探測并不是 TCP 規(guī)范中的一部分。但為了方便，幾乎所有類 Unix 系統(tǒng)均在 TCP 中提供了相應(yīng)的功能。
清單 2. 常見 Unix 系統(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 連接保活探測機(jī)制及原理
正如清單 2 中列出的一樣，AIX 上的保活探測機(jī)制由 4 個(gè)參數(shù)來控制，其具體意義見清單 3：
清單 3. AIX 上的保活定時(shí)器控制參數(shù)?
| tcp_keepcnt | 關(guān)閉一個(gè)非活躍連接之前進(jìn)行探測的最大次數(shù)，默認(rèn)為 8 次 |
| tcp_keepidle | 對(duì)一個(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ā)起請(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 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 行則是對(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è)保活探測數(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)文不會(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)的連接，客戶端在收到探測報(bào)文之后將返回一個(gè)第 7 行所示的 ACK 報(bào)文并借此向服務(wù)器端表明連接工作正常。
接下來，我們將通過一個(gè)實(shí)際的 TCP 斷連的例子來分析上述機(jī)制對(duì) TCP 連接保持的影響，并針對(duì)需要長時(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)用將通過該連接對(duì) testServer 上的數(shù)據(jù)庫進(jìn)行相應(yīng)操作。
在實(shí)際測試中，我們發(fā)現(xiàn)，在 testClient 和 testServer 均工作正常的情況下，testClient 上的客戶端在事先沒有收到任何異常信息的情況下，所持有的連接會(huì)出現(xiàn)非預(yù)期的斷連現(xiàn)象（在試圖通過連接進(jìn)行數(shù)據(jù)庫操作時(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)保活設(shè)置：
| # no -a | grep keep tcp_keepcnt = 8tcp_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í)候均會(huì)被防火墻丟棄并發(fā)送復(fù)位報(bào)文。
兩種常用的解決方案
針對(duì)上述 TCP 斷連現(xiàn)象，有兩種常用的解決方案可供選擇：
方案 1、延長防火墻終止非活躍的 TCP 連接的時(shí)間。例如，針對(duì)上述案例，可以調(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)。
對(duì)于第一種方案而言，延長 TCP 連接的保持時(shí)間可能會(huì)導(dǎo)致防火墻性能的降低，尤其是在維持大量長時(shí)間處于非活躍狀態(tài)的連接的情況下更是如此；而對(duì)于第二種方案，如果縮短服務(wù)器端的 TCP 連接保活時(shí)間，意味著會(huì)增加網(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 斷連的案例。最后，針對(duì) TCP 斷連的情況給出了兩種可行的解決方案。
參考資料
- AIX V5.3 中 IPv4 和 IPv6 的網(wǎng)絡(luò)接口操作?: 通過本文，您將了解更多關(guān)于套接字 I/O 控制 (ioctl) 命令的內(nèi)容，以及如何使用它們完成各種網(wǎng)絡(luò)相關(guān)的操作 . 操作系統(tǒng)為套接字、路由表、ARP 表、全局網(wǎng)絡(luò)參數(shù)和接口提供了相應(yīng)的控制操作方式。?
- TCP/IP 應(yīng)用程序的通信連接模式?: 本文的作者通過分析 TCP/IP 程序在不同級(jí)別上采用的不同方式來向您講述了如何設(shè)計(jì)好 TCP/IP 應(yīng)用程序的通信模式以及需要注意的相關(guān)問題。?
- 為 TCP 的重新傳輸實(shí)現(xiàn)更低的計(jì)時(shí)器粒度?: 在本文中，將研究如何通過使用 AIX TCP 快速計(jì)時(shí)器使重新傳輸計(jì)時(shí)器實(shí)現(xiàn)更低的粒度，并了解使用更低的計(jì)時(shí)器粒度的其他優(yōu)點(diǎn)。?
- 了解 TCP 系統(tǒng)調(diào)用序列?: 在本文中，將回顧和學(xué)習(xí)關(guān)于 TCP 調(diào)用序列的詳細(xì)信息，其中包括對(duì) FreeBSD 的引用，以及在用戶級(jí)進(jìn)行系統(tǒng)調(diào)用后在 TCP 堆棧中發(fā)生的重要函數(shù)調(diào)用。?
- AIX and UNIX 專區(qū)?：developerWorks 的“AIX and UNIX 專區(qū)”提供了大量與 AIX 系統(tǒng)管理的所有方面相關(guān)的信息，您可以利用它們來擴(kuò)展自己的 UNIX 技能。
- AIX and UNIX 新手入門?：訪問“AIX and UNIX 新手入門”頁面可了解更多關(guān)于 AIX 和 UNIX 的內(nèi)容。
- AIX and UNIX 專題匯總?：AIX and UNIX 專區(qū)已經(jīng)為您推出了很多的技術(shù)專題，為您總結(jié)了很多熱門的知識(shí)點(diǎn)。我們在后面還會(huì)繼續(xù)推出很多相關(guān)的熱門專題給您，為了方便您的訪問，我們在這里為你把本專區(qū)的所有專題進(jìn)行匯總，讓您更方便的找到你需要的內(nèi)容。
- 獲取?本專區(qū)的 RSS Feed。（了解關(guān)于?RSS?的更多信息。）
總結(jié)
以上是生活随笔為你收集整理的TCP 连接断连问题剖析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Chrome Extension in
- 下一篇： 一个APP“感知”北京门头沟的城市智慧