tcp連接異常情況處理

1、1TCP連接中可能出現(xiàn)的異常斷開(kāi)情況假設(shè)存在這樣一種情況：在兩個(gè)不同的主機(jī)Machine1、Machine2系統(tǒng)上分別運(yùn)行兩個(gè)應(yīng)用程序Application1、Application2，在Application1與Application2的進(jìn)程中存在一個(gè)TCP鏈接TCPLink。它們的實(shí)際傳輸取決于物理鏈路的溝通PhysiLink。圖一：TCP通信情況模擬圖1.1程序進(jìn)程異常如果TCPLink異常而Application1正常，TCPL

2、ink會(huì)被關(guān)掉并且告訴Application２，Application２也就關(guān)閉了該異常的TCPLink。這種情況會(huì)在TCPLink異常后的一次Socket調(diào)用中通過(guò)返回值(CC)或者異常代碼(C#)得知。因此在做程序開(kāi)發(fā)的時(shí)候比較容易處理。1.2物理鏈路異常如果出現(xiàn)Machine1或者M(jìn)achine2任何一個(gè)系統(tǒng)死機(jī)：假設(shè)Machine1系統(tǒng)異常此時(shí)Machine2無(wú)法知道此TCP連接的失效，并一直認(rèn)為連接正常。如果網(wǎng)絡(luò)硬件故障（如網(wǎng)

3、線拔掉、交換機(jī)斷電）：Machine1與Machine2都無(wú)法知道此TCP連接的失效，并一直認(rèn)為連接正常。以上這兩種情況在編程時(shí)會(huì)變的非常糟糕，因?yàn)門CP連接將一直被認(rèn)為有效，所有對(duì)此TCPSocket的調(diào)用都會(huì)正確返回，這顯然是錯(cuò)誤的。并且這種錯(cuò)誤情況通常會(huì)持續(xù)很久。2異常斷開(kāi)情況影響分析對(duì)于程序進(jìn)程異常，由于Socket調(diào)用中可以得到返回值。因此在做程序開(kāi)發(fā)的時(shí)候比較容易處理。對(duì)于物理鏈路異常，如果Machine1系統(tǒng)異常，如果Ap

4、plication2是FTP之類的服務(wù)器程序倒也無(wú)妨（一個(gè)連接存在時(shí)間比較長(zhǎng)對(duì)它沒(méi)有多大影響），如果是需要實(shí)時(shí)知道連接用戶狀態(tài)的即時(shí)通訊類服務(wù)器或者Application2是客戶端則就會(huì)產(chǎn)生一系列的問(wèn)題了。如果Machine1與Machine2都異常，Application1和Application2都會(huì)一直等下去，兩端需要進(jìn)行相似的處理。3異常斷開(kāi)情況的判斷與處理對(duì)于這種情況在MSDN里面是這樣處理的，原文如下：如果您需要確定連接的當(dāng)

5、前狀態(tài)，請(qǐng)進(jìn)行非阻止、零字節(jié)的Send調(diào)用。如果該調(diào)用成功返回或引發(fā)WAEWOULDBLOCK錯(cuò)誤代碼(10035)，則該套接字仍然處于連接狀態(tài)；計(jì)算機(jī)中對(duì)應(yīng)的網(wǎng)絡(luò)接口卡。它們一起處理傳輸媒介(如網(wǎng)線)的物理接口細(xì)節(jié)。網(wǎng)絡(luò)層，處理分組在網(wǎng)絡(luò)中的活動(dòng)。運(yùn)輸層主，要為兩臺(tái)主機(jī)上的應(yīng)用程序提供端到端的通信。在TCPIP協(xié)議族中，有兩個(gè)互不相同的傳輸協(xié)議：TCP和UDP。TCP為兩臺(tái)主機(jī)提供高可靠性的數(shù)據(jù)通信。它所做的工作包括把應(yīng)用程序交給它的

6、數(shù)據(jù)分成合適的小塊交給下面的網(wǎng)絡(luò)層，確認(rèn)接收到的分組，設(shè)置發(fā)送最后確認(rèn)分組的超時(shí)時(shí)鐘等。由于運(yùn)輸層提供了高可靠性的端到端的通信，因此應(yīng)用層可以忽略所有這些細(xì)節(jié)。應(yīng)用層，負(fù)責(zé)處理特定的應(yīng)用程序細(xì)節(jié)。關(guān)鍵點(diǎn)：應(yīng)用程序位于應(yīng)用層，TCP協(xié)議在運(yùn)輸層，在數(shù)據(jù)流從運(yùn)輸層傳遞到鏈路層的過(guò)程中，TCP協(xié)議本身的底層實(shí)現(xiàn)正是我們要利用的所在。TCP協(xié)議在實(shí)現(xiàn)的時(shí)候?yàn)槊織l連接建立了七個(gè)定時(shí)器。按照它們?cè)谝粭l連接生存期內(nèi)出現(xiàn)的次序，分別為：connecti

7、onestablishmenttimer(連接建立定時(shí)器)、retransmissiontimer(重傳定時(shí)器)、delayedACKtimer(延遲ACK定時(shí)器)、persisttimer(持續(xù)定時(shí)器)、keepalivetimer(保活定時(shí)器)、FIN_WAIT_2timer、TIME_WAITtimer。4.2KeepAliveTimer（?；疃〞r(shí)器）在《TCPIP協(xié)議詳解卷2：實(shí)現(xiàn)》中，這樣描述KeepAliveTmer：Kee

8、pAliveTmer在應(yīng)用進(jìn)程選取了Socket的SO_KEEPALIVE選項(xiàng)時(shí)生效。如果連接的連續(xù)空閑時(shí)間超過(guò)2小時(shí)，?；疃〞r(shí)器超時(shí)，向?qū)Χ税l(fā)送連接探測(cè)報(bào)文段，強(qiáng)迫對(duì)端響應(yīng)。如果收到了期待的響應(yīng)，TCP可確定對(duì)端主機(jī)工作正常，在該連接再次空閑超過(guò)2小時(shí)之前，TCP不會(huì)再進(jìn)行保活測(cè)試。如果收到的是其他響應(yīng)，TCP可確定對(duì)端主機(jī)已重啟。如果連續(xù)若干次?；顪y(cè)試都未收到響應(yīng)，TCP就假定對(duì)端主機(jī)已崩潰，盡管它無(wú)法區(qū)分是主機(jī)故障(例如，系統(tǒng)崩潰

9、而尚未重啟)，還是連接故障(例如，中間的路由器發(fā)生故障或電話線斷了)。4.3KeepAliveTimer工作機(jī)理分析123455.15.25.35.3.1?；疃〞r(shí)器在2小時(shí)空閑后超時(shí)收到一個(gè)報(bào)文段后，將復(fù)位連接的保活定時(shí)器，重設(shè)為2小時(shí)，并清零連接的空閑計(jì)數(shù)器。如果保活定時(shí)器超時(shí)(收到最后一個(gè)報(bào)文段2小時(shí)后)，并且置位了Socket的保活選項(xiàng)，則TCP將向?qū)Χ税l(fā)送連接探測(cè)報(bào)文段。如果定時(shí)器超時(shí)，且未置位Socket的?；钸x項(xiàng)，則TCP將

10、只復(fù)位定時(shí)器，重設(shè)為2小時(shí)，不向?qū)Χ税l(fā)送連接探測(cè)報(bào)文段。當(dāng)然，如果應(yīng)用進(jìn)程調(diào)用了close，即使連接已空閑了2小時(shí)，TCP也不會(huì)發(fā)送連接探測(cè)報(bào)文段。5.3.2進(jìn)行?；顪y(cè)試當(dāng)保活定時(shí)器發(fā)送連接探測(cè)報(bào)文后，如果對(duì)端無(wú)響應(yīng)，TCP最多以75秒的間隔發(fā)送9個(gè)連接探測(cè)報(bào)文段。TCP在確認(rèn)連接已死亡之前必須發(fā)送多個(gè)連接探測(cè)報(bào)文段的一個(gè)原因是，對(duì)端的響應(yīng)很可能是不帶數(shù)據(jù)的純ACK報(bào)文段，TCP無(wú)法保證此類報(bào)文段的可靠傳輸，因此，連接探測(cè)報(bào)文段的響應(yīng)有