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ù)鏈路層主要負責處理傳輸媒介等眾多的物理接口細節(jié)；網(wǎng)絡(luò)層負責處理數(shù)據(jù)分組在網(wǎng)絡(luò)中的活動，包括上層數(shù)據(jù)報文的分割、選路 phost2008-08-21T00:00:00 等；傳輸層則負責為兩臺主機提供端到端的通信；應(yīng)用層將負責處理應(yīng)用程序的特定細節(jié)。其中，IP 協(xié)議是網(wǎng)絡(luò)層的核心協(xié)議，用來提供不可靠、無連接的數(shù)據(jù)傳遞服務(wù)；而 TCP 協(xié)議則處于傳輸層，其基于不可靠無連接的 IP 協(xié)議能夠為兩臺主機提供面向連接的、可靠的通信。UDP?
由于 TCP 是面向連接的協(xié)議，因此在兩臺主機通信之前，需要首先建立起一條連接。下面我們將簡要介紹 TCP 連接的建立以及通信雙方是如何保持已建立的 TCP 連接的。
TCP 連接的建立及保持
一個 TCP 連接的建立需要通過著名的“三次握手”來完成。下面的例子將直觀給出一個 TCP 連接的建立過程。
在本文的下述描述中，客戶端主機均為 testClient.cn.ibm.com(Linux)，服務(wù)器主機均為 testServer.cn.ibm.com(AIX)。在 testClient 主機的一終端上執(zhí)行 tcpdump –i eth0 host testServer 命令，啟動 tcpdump 監(jiān)聽網(wǎng)絡(luò)數(shù)據(jù)（其中，eth0 是客戶主機與外部網(wǎng)絡(luò)進行通信所使用的網(wǎng)卡）；與此同時，在客戶主機的另一個終端上執(zhí)行下述命令： (root@testClient /)>telnet testServer。此時客戶主機上 tcpdump 的輸出如清單 1 所示。
清單 1. 創(chuàng)建一個 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)換為實際序列圖 2。
圖 2. TCP 建立創(chuàng)建三次握手的實際序列?
?
從圖 2 中我們可以清楚地看到，在 testClient 與 testServer 之間建立連接時，要經(jīng)過以下三次握手過程：
- testClient 向 testServer 主動發(fā)送握手協(xié)議，報文序列號為 3392458353，大小為 1 個字節(jié)。
- testServer 向 testClient 主動發(fā)送握手協(xié)議，報文序列號為 881279296，大小為 1 個字節(jié)；同時返回 ACK 3392458354，作為對 testClient 發(fā)來的 3392458354 包的應(yīng)答。
- testClient 向 testServer 返回 ACK 881279297，作為對 testServer 發(fā)來的 881279296 包的應(yīng)答。
一個 TCP 連接在完成上述的三次握手之后便建立完畢；此后，連接的兩端即可進行信息的相互傳遞。因此，TCP 連接可以認為是以兩端 IP 地址和端口進行標識的一個通信信道，而 TCP 連接的建立就是向通信雙方進行上述通信信道注冊的過程。TCP 連接一旦建立，只要通信雙方之間的中間結(jié)點（包括網(wǎng)關(guān)和交換機、路由器等網(wǎng)絡(luò)設(shè)備）工作正常，那么在通信雙方中的任何一方主動關(guān)閉連接之前，TCP 連接都將被一直保持下去。
TCP 連接的這種特性，使得一個長期不交換任何信息的空閑連接可以長期保持數(shù)小時、數(shù)天甚至數(shù)月。中間路由器可以崩潰、重啟，網(wǎng)線可以被掛斷再連通，只要兩端的主機沒有被重啟，TCP 連接就可以被一直保持下來。
導(dǎo)致 TCP 連接斷連的因素
理想狀態(tài)下，一個 TCP 連接可以被長期保持。然而，在實際應(yīng)用中，客戶端或服務(wù)器端上維持的一個看似正常的 TCP 連接可能已經(jīng)斷連。TCP 連接主要受到兩個方面的影響而導(dǎo)致斷連：網(wǎng)絡(luò)中間節(jié)點和客戶端 / 服務(wù)器節(jié)點參與通信的兩方節(jié)點？
在實際網(wǎng)絡(luò)應(yīng)用中，兩個主機之間的通信往往需要穿越多個中間節(jié)點，例如路由器、網(wǎng)關(guān)、防火墻等。因此，兩個主機之間 TCP 連接的保持同樣會受到中間節(jié)點的影響，尤其是會受到防火墻（軟件或硬件防火墻）的限制。防火墻是一種裝置，有多種不同的實現(xiàn)方式（軟件實現(xiàn)、硬件設(shè)備實現(xiàn)或是軟硬件相結(jié)合實現(xiàn)），它需要依據(jù)一系列規(guī)則對進出的信息流進行掃描，并允許安全（符合規(guī)則）的信息交互、阻止不安全（違反規(guī)則）的信息交互。防火墻的工作特性決定了要維護一個網(wǎng)絡(luò)連接就需要耗費較多的資源，并且企業(yè)防火墻常常位于企業(yè)網(wǎng)絡(luò)的出入口，長時間維護非活躍的 TCP 連接必將導(dǎo)致網(wǎng)絡(luò)性能的下降。因此，大部分防火墻默認會關(guān)閉長時間處于非活躍狀態(tài)的連接而導(dǎo)致 TCP 連接斷連。類似的，如果中間節(jié)點異常導(dǎo)致來自客戶端關(guān)閉連接的請求無法傳遞到服務(wù)器端，也將導(dǎo)致服務(wù)器端的相應(yīng)連接發(fā)生斷連。
另一方面，對于一個 TCP 連接兩端的主機而言，創(chuàng)建 TCP 連接需要耗費一定的系統(tǒng)資源。如果不再使用某個連接，那么我們總是希望進行通信的兩個主機能夠主動關(guān)閉相應(yīng)的連接，以便釋放所占用的系統(tǒng)資源。然而，如果由于客戶端出現(xiàn)異常 ( 例如崩潰或異常重啟 ) 而導(dǎo)致連接未能正常關(guān)閉，這將導(dǎo)致服務(wù)器端的連接斷連。
無論是客戶端節(jié)點或是服務(wù)器端節(jié)點，斷連的 TCP 連接已經(jīng)不能傳遞任何信息，因此，維護大量斷連的 TCP 連接將導(dǎo)致系統(tǒng)資源的浪費。這種系統(tǒng)資源的浪費可能并不會對客戶端節(jié)點帶來太大問題；然而，對于服務(wù)器主機而言，這可能會導(dǎo)致系統(tǒng)資源（尤指內(nèi)存資源和 socket 資源）被耗盡而拒絕為新的用戶請求提供服務(wù)。因此在實際應(yīng)用中，服務(wù)器端需要采取相應(yīng)的方法來探測 TCP 連接是否已經(jīng)斷連。
探測 TCP 連接斷連的三種常用方法
探測 TCP 連接是否斷連或是工作正常的原理比較簡單：定期向連接的遠程通信節(jié)點發(fā)送一定格式的信息并等待遠程通信節(jié)點的反饋，如果在規(guī)定時間內(nèi)收到來自遠程節(jié)點的正確的反饋信息，那么該連接就是正常的，否則該連接已經(jīng)斷連。依據(jù)該原理，目前常用的探測方法有以下三種。
應(yīng)用程序的自我探測
應(yīng)用程序本身附帶探測其自身建立的 TCP 連接的功能。這種方法具有極大的靈活性，可以依據(jù)應(yīng)用本身的特點選擇相應(yīng)的探測機制和功能實現(xiàn)。然而，實際應(yīng)用中，大部分應(yīng)用程序均沒有附帶自我探測的功能。
第三方應(yīng)用程序的探測
此種方法就是在服務(wù)節(jié)點上安裝相應(yīng)的第三方應(yīng)用程序來探測該節(jié)點上所有的 TCP 連接是否正常或是已經(jīng)斷連。該方法最大的不足就是需要所有支持探測的客戶端能夠識別來自該探測應(yīng)用的數(shù)據(jù)報文，因此，實際應(yīng)用中比較少見。
TCP 協(xié)議層的保活探測
最常用的探測方法就是采用 TCP 協(xié)議層提供的保活探測功能即 TCP 連接保活定時器。盡管該功能并不是 RFC 規(guī)范的一部分，但是幾乎所有的類 Unix 系統(tǒng)均實現(xiàn)了該功能，所以使得該探測方法被廣泛使用。
接下來的部分，我們將重點討論來自 TCP 協(xié)議層的保活探測方法。
類 Unix 系統(tǒng)上的 TCP 連接保活定時器
TCP 連接的保活定時器可以在應(yīng)用層實現(xiàn)，也可以在 TCP 中提供。這個問題存在爭議，因此 TCP 連接的保活探測并不是 TCP 規(guī)范中的一部分。但為了方便，幾乎所有類 Unix 系統(tǒng)均在 TCP 中提供了相應(yīng)的功能。
清單 2. 常見 Unix 系統(tǒng)上的保活定時器?
| 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ù)的時間單位不盡相同。在 AIX 上，tcp_keeidle/tcp_keepinit/tcp_keepintvl 的時間單位是 0.5 秒；而在 Linux 上，net.ipv4.tcp_keepalive_intvl 和 net.ipv4.tcp_keepalive_time 的時間單位則為秒。并且，上述參數(shù)僅對運行在其上的服務(wù)器應(yīng)用連接有效。
注：在 Solaris 上可通過“ndd /dev/tcp \?”命令顯示上述類似參數(shù)信息，而在 HP Unix 上則可通過 nettune 或 ndd 命令進行查詢。
由于所有類 Unix 系統(tǒng)上均支持這種功能，因此，在接下來的部分中我們將基于 AIX 系統(tǒng)具體講述上述參數(shù)的意義和作用機制。
AIX 中的 TCP 連接保活探測機制及原理
正如清單 2 中列出的一樣，AIX 上的保活探測機制由 4 個參數(shù)來控制，其具體意義見清單 3：
清單 3. AIX 上的保活定時器控制參數(shù)?
| tcp_keepcnt | 關(guān)閉一個非活躍連接之前進行探測的最大次數(shù)，默認為 8 次 |
| tcp_keepidle | 對一個連接進行有效性探測之前運行的最大非活躍時間間隔，默認值為 14400（即 2 個小時） |
| tcp_keepintvl | 兩個探測的時間間隔，默認值為 150 即 75 秒 |
我們來看一個具體的例子。在 testServer 端（AIX 主機）采用 tcp_keepidel=240（即 2 分鐘）：tcp_keepcnt=8：tcp_keepintvl=150（即 75 秒）的參數(shù)值；啟動 testServer 上的 tcpdump 查看網(wǎng)絡(luò)包的交互情況；從 testClient 端發(fā)起請求建立和 testServer 之間的一個 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 行的報文是本連接發(fā)送的最后數(shù)據(jù)，而第 7 行則是對第 6 行數(shù)據(jù)的確認。其后，該連接上沒有任何數(shù)據(jù)交互，從而使得該連接一直處于非活躍狀態(tài)。經(jīng)過 2 分鐘（第 8 行數(shù)據(jù)報時間 04:53:54 和第 7 行數(shù)據(jù)報時間 04:51:54 之差，即 tcp_keepidle 的值）的非活躍時間后，第 8 行是服務(wù)器端發(fā)起第一個保活探測數(shù)據(jù)報。由于服務(wù)器端沒有收到客戶端關(guān)于探測報文的相應(yīng)，因此再經(jīng)過 tcp_keepintvl 的時間間隔（75 秒）之后，第 9 行顯示服務(wù)器端再次發(fā)起保活探測數(shù)據(jù)報。服務(wù)器端持續(xù)發(fā)送了 tcp_keepcnt 個探測報文（上面結(jié)果顯示，在 AIX 上是持續(xù)發(fā)送 tcp_keepcnt+1 個探測報文）之后，仍然沒有收到來自客戶端的任何回應(yīng)，所以服務(wù)器在第 17 行向客戶端發(fā)送復(fù)位報文同時在服務(wù)器端關(guān)閉了該連接。
需要注意的是，保活探測雖然通過發(fā)送 TCP 探測報文，但探測報文不會對正常的 TCP 連接產(chǎn)生任何影響。從清單 4 可以看出，第 8 行發(fā)送數(shù)據(jù)的 TCP 報文序號為 695 起始的 1Byte 數(shù)據(jù)，而該數(shù)據(jù)在第 6 行已經(jīng)發(fā)送并被客戶端確認。對于正常狀態(tài)的連接，客戶端在收到探測報文之后將返回一個第 7 行所示的 ACK 報文并借此向服務(wù)器端表明連接工作正常。
接下來，我們將通過一個實際的 TCP 斷連的例子來分析上述機制對 TCP 連接保持的影響，并針對需要長時間保持 TCP 連接的應(yīng)用提出兩種可選的解決方案。
AIX 上的 TCP 斷連及數(shù)據(jù)分析
圖 3. 出現(xiàn) TCP 斷連的網(wǎng)絡(luò)拓撲結(jié)構(gòu)示意圖?
?
所有服務(wù)器主機均劃為一個局域網(wǎng)，并處于防火墻 B 之后。由于工作需要，來自工作區(qū)局域網(wǎng)的主機 testClient 需和服務(wù)器局域網(wǎng)內(nèi)的 testServer 上的數(shù)據(jù)庫使用 TCP/IP 建立一個連接，testClient 上的上層應(yīng)用將通過該連接對 testServer 上的數(shù)據(jù)庫進行相應(yīng)操作。
在實際測試中，我們發(fā)現(xiàn)，在 testClient 和 testServer 均工作正常的情況下，testClient 上的客戶端在事先沒有收到任何異常信息的情況下，所持有的連接會出現(xiàn)非預(yù)期的斷連現(xiàn)象（在試圖通過連接進行數(shù)據(jù)庫操作時，會被告知 connection is reset by foreign host 的錯誤）。
由于該現(xiàn)象不斷出現(xiàn)，并且網(wǎng)絡(luò)內(nèi)的中間節(jié)點（路由器和交換機等）均工作正常，因此可以排除物理因素（如掉電、宕機等）的可能。為了便于分析斷連原因，我們首先查看了 testServer 機器上的默認保活設(shè)置：
| # no -a | grep keep tcp_keepcnt = 8tcp_keepidle = 14400 tcp_keepintvl = 150 |
testServer 上的 tcp_keepidle 為 14400，即 2 個小時。既然中間節(jié)點工作正常，為什么保活機制沒有其作用呢？為了進行分析，我們采用 tcpdump 工具捕獲 testClient 和 testServer 上的報文信息，見清單 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)的時間達到 tcp_keepidle 設(shè)定的 2 小時時，服務(wù)器主機發(fā)出了第一個連接保活的探測報文（清單 5 中的第 7 行）。緊接著，服務(wù)器主機就收到了來自 testClient 的連接復(fù)位報文（清單 5 中的第 8 行）。之后，服務(wù)器便關(guān)閉了該連接（可以通過 netstat –ni 來查看）。然而，從清單 6 的 tcpdump 數(shù)據(jù)可以看出， testClient 端并未發(fā)送任何報文。那么，是誰向 testServer 發(fā)送了復(fù)位報文呢？
為了查看上述復(fù)位報文的發(fā)送者，同樣采用上述 tcpdump 命令再次捕獲服務(wù)器端和防火墻 B 的報文信息（注意：通常需要捕獲防火墻主機上網(wǎng)絡(luò)數(shù)據(jù)的出口網(wǎng)卡和入口網(wǎng)卡數(shù)據(jù)），結(jié)果顯示，防火墻 B 在收到來自 testServer 的第一個探測報文之后就立刻向 testServer 發(fā)送了一個復(fù)位報文。
上述分析說明，在連接傳遞完最后一個交互數(shù)據(jù)之后到服務(wù)器端發(fā)送第一個保活探測之間，該連接已經(jīng)被防火墻 B 終止；在此之后，基于該連接的任何報文傳遞在試圖穿過防火墻的時候均會被防火墻丟棄并發(fā)送復(fù)位報文。
兩種常用的解決方案
針對上述 TCP 斷連現(xiàn)象，有兩種常用的解決方案可供選擇：
方案 1、延長防火墻終止非活躍的 TCP 連接的時間。例如，針對上述案例，可以調(diào)節(jié)防火墻設(shè)置，將時間設(shè)置為大于服務(wù)器端設(shè)定的 2 小時。
方案 2、縮短服務(wù)器端的 TCP 連接保活時間。縮短該時間的目的是為了在連接被防火墻終止之前發(fā)送保活探測報文，既可以探測客戶端狀態(tài)，又可以使連接變?yōu)榛钴S狀態(tài)。
對于第一種方案而言，延長 TCP 連接的保持時間可能會導(dǎo)致防火墻性能的降低，尤其是在維持大量長時間處于非活躍狀態(tài)的連接的情況下更是如此；而對于第二種方案，如果縮短服務(wù)器端的 TCP 連接保活時間，意味著會增加網(wǎng)絡(luò)中的數(shù)據(jù)報文數(shù)而占用額外的網(wǎng)絡(luò)帶寬。因此，兩種方案各有利弊，需要依據(jù)不同的實際應(yīng)用情況進行選擇。
總結(jié)
本文介紹了 TCP 連接的建立和保持的相關(guān)概念以及影響 TCP 連接保持的常見因素。給出了常見的類 Unix 系統(tǒng)上 TCP 連接保活探測的相關(guān)配置參數(shù)，并基于 AIX 借助 tcpdump 工具分析了一個實際的 TCP 斷連的案例。最后，針對 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 程序在不同級別上采用的不同方式來向您講述了如何設(shè)計好 TCP/IP 應(yīng)用程序的通信模式以及需要注意的相關(guān)問題。?
- 為 TCP 的重新傳輸實現(xiàn)更低的計時器粒度?: 在本文中，將研究如何通過使用 AIX TCP 快速計時器使重新傳輸計時器實現(xiàn)更低的粒度，并了解使用更低的計時器粒度的其他優(yōu)點。?
- 了解 TCP 系統(tǒng)調(diào)用序列?: 在本文中，將回顧和學(xué)習關(guān)于 TCP 調(diào)用序列的詳細信息，其中包括對 FreeBSD 的引用，以及在用戶級進行系統(tǒng)調(diào)用后在 TCP 堆棧中發(fā)生的重要函數(shù)調(diào)用。?
- AIX and UNIX 專區(qū)?：developerWorks 的“AIX and UNIX 專區(qū)”提供了大量與 AIX 系統(tǒng)管理的所有方面相關(guān)的信息，您可以利用它們來擴展自己的 UNIX 技能。
- AIX and UNIX 新手入門?：訪問“AIX and UNIX 新手入門”頁面可了解更多關(guān)于 AIX 和 UNIX 的內(nèi)容。
- AIX and UNIX 專題匯總?：AIX and UNIX 專區(qū)已經(jīng)為您推出了很多的技術(shù)專題，為您總結(jié)了很多熱門的知識點。我們在后面還會繼續(xù)推出很多相關(guān)的熱門專題給您，為了方便您的訪問，我們在這里為你把本專區(qū)的所有專題進行匯總，讓您更方便的找到你需要的內(nèi)容。
- 獲取?本專區(qū)的 RSS Feed。（了解關(guān)于?RSS?的更多信息。）
總結(jié)
以上是生活随笔為你收集整理的TCP 连接断连问题剖析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Chrome Extension in
- 下一篇： 一个APP“感知”北京门头沟的城市智慧