|  首頁  |  資訊  |  評測  |  活動  |  學院  |  訪談  |  專題  |  雜志  |  產服  |  
您現在的位置:硅谷網> 學院> 論文>

長期使人困惑的問題:TCP連接中斷的實時檢測

2013-12-24 11:30 作者:程 偉 來源:硅谷網-《硅谷》雜志 HV: 編輯: 【搜索試試
  目前TCP/IP已經成為網絡的主導技術。通過對TCP底層實現的分析,對TCP/IP編程中一個長期使人困惑的問題----網絡連接中斷的實時檢測—進行深入的分析,并提出相應的解決方案。
  
  0引言
  作為現代網絡的主導技術,TCP/IP編程看起來非常簡單,但在經歷了最初的高效率后,往往會在細節面前停滯不前,這常常是因為對TCP協議底層細節的缺乏了解所導致的。
  TCP是面向連接協議,而UDP是無連接協議,許多初學者發現可以沒有任何數據流通過一個空閑的TCP連接,如果TCP連接的雙方都沒有向對方發送數據,則在兩個TCP模塊之間不交換任何信息。這意味著可以啟動一個客戶與服務器建立一個連接,然后離去數小時至數個星期連接依然保持。中間路由器可以崩潰和重啟,電話線可以被掛斷再連通,只要兩端的主機沒有被重啟,則連接依然保持建立。
  因此,初次接觸TCP/IP協議組的程序員感到很迷惑:TCP中并沒有可以在其他網絡協議中發現的連接階段的輪詢,甚至發現TCP不給應用程序提供既時的網絡連接中斷的通知。一些程序員據此斷定TCP不適用于一般的應用程序到應用程序的通信。TCP為什么不提供通知呢?
  1原理分析
  TCP通常被稱為可靠的協議,即“TCP保證發送數據的傳輸”,這通常會產生誤解:TCP不會出錯。事實是只要雙方保持連接,TCP就能保證數據的正確傳輸,但是當連接中斷時,就會產生問題,原因有3個:1)永久的或暫時的網絡紊亂;2)對等方應用程序崩潰;3)對等方主機崩潰,當出現以上問題時,會使雙方應用程序不能互相通信,而其中一個應用程序卻不能立刻意識到。發送數據給對等方的應用程序可能在知道TCP在放棄重發之前才會發現連接中斷,。如果應用程序沒有發送數據,可能永遠不會發現網絡已經中斷。例如應用程序可能是一個正在等待對等方發出下一個請求的服務器,因為客戶端不能和服務器通信,下一個請求永遠不會到達,甚至客戶端的TCP放棄并撤銷連接,導致客戶端中斷,服務器也沒有意識到這一點。
  其他的通信協議如SNA和X.25,當連接中斷時會給應用程序提供通知。比如簡單的直接點對點專有鏈接復雜的任何協議都必須使用一種輪詢協議來連續地測試對等方是否存在。輪詢-選擇協議可能會采用顯式地發送“你有要發送給我的任何數據嗎?”諸如此類的消息的形式,或者它們會采用后臺靜態幀的形式來檢測虛擬線路是否仍然存在。每一個輪詢消息都會消耗網絡資源,而這些資源本來可以用于“有效負載”數據的傳輸。
  對可獲得的網絡帶寬的消耗是TCP不提供網絡中斷立即通知的一個原因。因為大多數的應用程序不需要即時的通知,所以沒有必要以降低帶寬的代價來提供這個功能。需要以一種及時的方式知道對等方不可到達的應用程序可以實現它們自己的機制來發現網絡中斷,如后面介紹的那樣。
  TCP/IP設計中使用的一個基本原則是終端對終端參數[Saltzerelal.1984],該參數應用到網絡上時可以表述為所有的智能應當盡可能地接近連接的終端點,而網絡本身應當相對沒有智能。這就是為什么TCP自己處理錯誤控制而不是依靠網絡來提供它的原因。當這個原則應用到監控對等應用程序之間的連接時,應用程序應當提供它自己需要的功能,而不是不管應用程序是否需要這個功能都由下層提供。
  TCP不提供及時連接中斷通知的最重要的原因是:網絡突然中斷時仍可以維持通訊的能力。TCP最早是美國國防部發起的一項研究的成果,它要求提供一個遇到戰爭或自然災害引起的網絡中斷時仍然可以維持計算機之間可靠的通信的網絡協議。通常網絡紊亂是暫時的,路由器也可能找到連接的另一條路徑。通過允許連接的暫時中斷,甚至在終端應用程序意識到中斷之前TCP就已經處理好了紊亂。
  2解決方案
  2.1方案一:使用TCPKeep-alive機制
  人們希望知道連接是否中斷了,因此許多TCP的具體實現提供了一個稱作Keep-alive的機制用于檢測死連接,但是它并不經常用于應用程序。如果應用程序啟用Keep-alive機制時,TCP就會在連接已經空閑了一段時間間隔后發送一個特殊的段給對等方。如果對等方主機可到達而且對等方應用程序仍然運行,對等方TCP就會響應一個ACK應答。在這種情況下,TCP發送Keep-alive重置空閑時間為零,并且應用程序不會收到消息交換的任何通知。
  如果對等方主機可以到達但是對等方應用程序沒有運行,對等方TCP就響應RST消息,發送Keep-alive消息的TCP撤銷連接并返回ECONNRESET錯誤給應用程序。這通常是對等方主機崩潰后重起的結果,因為如果僅僅是對等方應用程序中斷或崩潰了,對等方TCP可能已經發送FIN消息了。
  如果對等方主機沒有響應ACK或RST消息,發送Keep-alive消息的TCP繼續發送Keep-alive探詢消息,直到它認為對等方不可到達或已經崩潰了。這時它就撤銷連接并通知應用程序ETIMEDOUT錯誤,如果路由器已經返回主機或網絡不可到底的ICMP消息的話,就返回EHOSTUNREACH或ENERUNREACH錯誤。
  通過Keep-alive機制,TCP提供了協議層面的網絡中斷通知功能,但這種機制有很多問題以至于很少用于應用程序。
  首先,Keep-alive并不是TCP規范中的一部分,長期以來,是否在TCP中提供Keep-alive機制一直是有爭論的話題,因此,Keep-alive不是所有的TCP實現都提供,而且實現細節也有所不同。
  需要即時通知網絡中斷的應用程序使用Keep-alive功能的第二個問題是和時間間隔有關的。RFC1122[Braden1989]認為,如果TCP實現了Keep-alive,保活間隔必須是可配置的,但是其默認值必須不小于兩個小時,之后它才能發送Keep-alive探詢消息。那么因為對等方的ACK消息并不是可靠地遞交,它必須在放棄連接之前重復發送探詢消息。4.4BSD具體實現在撤銷連接之前以75秒的時間間隔發送9個探詢消息。
  這意味著BSD派生的具體實現,大約需要2小時11分鐘15秒才能發現連接已經中斷了。這個時間值只有在我們認識Keep-alive是用于釋放被死連接占有的資源時才有意義。例如,當客戶端連接到服務器而客戶端主機崩潰時就有可能發生這樣的連接。如果沒有Keep-alive機制,服務器就會永遠等待客戶端的下一個請求,這是因為它永遠沒有接收到FIN消息。(因為基于PC系統的用戶僅僅是關閉計算機和modem而不是正確地關閉應用程序,所以這種情況正越來越普遍。)
  由于2小時的時間對于實時檢測幾乎沒有意義,因此一些具體實現允許改變一個或兩個時間間隔值,但因為保活間隔時間是系統級的變量,這些值的改變影響系統上所有的TCP連接,這是Keep-alive作為一個連接監控機制沒有實際使用的主要原因:默認的時間段太長了,如果改變了默認值,它們就失去了清除長時間死連接這一最初的意義。
  Keep-alive的另一個問題是它們不僅僅檢測死連接,同時也撤銷它們。這有可能是應用程序所希望的,但是也有可能不是應用程序所希望的。
  2.2方案二:使用heartbeat檢測
  第二種方案是在應用層來實現對連接中斷的檢測,其基本思想是象Keep-alive一樣,定時向對等方發送探針,由于是在應用層實現,可以根據應用程序靈活掌握探測時間。實際上,邊界網關協議BGP就是通過定期發送Keep-alive報文給其鄰站來檢測TCP連接對端的鏈路或主機失敗,兩個報文之間的時間間隔建議值為30秒。這種在應用層實現的對連接中斷的檢測通常稱為“heartbeat檢測”。
  以上算法原則盡管是在TCP上討論,但一樣適用于UDP。這種方案的最大優點在于提供了最大的靈活性。
  2.3方案三:利用TCP-KEEPALIVE套接字選項
  第三種方案是使用新的POSIX1003.1g套接字選項TCP-KEEPALIVE,它允許在每一個連接的基礎上指定超時時間間隔,但是它沒有廣泛地實現,因此應用中使用的不多。在Linuxkernel2.4之后的TCP實現中,可以這樣設置socket的探針間隔:
  #ifdefTCP_KEEPALIVE
  intsecs=120;/*2minutes*/
  setsockopt(s,IPPROTO_TCP,TCP_KEEPALIVE,&secs,sizeof(secs));
  #endif
  這種方案的缺點是,由于TCP-KEEPALIVE套接字選項是比較新的POSIX特性,不是所有TCP實現都給予支持,因此存在移植性問題;同時,由于是在傳輸層進行探測,靈活性不如在應用層的實現。
  3總結
  綜上所述,對于TCP連接中斷的檢測,原理上都是通過定時向對等方發送探針數據來進行檢測,不同方案的區別在于實現于不同層次,應用中可以根據需要進行不同的選擇,關鍵在于對TCP連接的原理要透徹理解。(注:本文版權歸作者本人和硅谷雜志所有,禁止他人未經授權轉載)
【對“長期使人困惑的問題:TCP連接中斷的實時檢測”發布評論】

版權及免責聲明:
① 本網站部分投稿來源于“網友”,涉及投資、理財、消費等內容,請親們反復甄別,切勿輕信。本網站部分由贊助商提供的內容屬于【廣告】性質,僅供閱讀,不構成具體實施建議,請謹慎對待。據此操作,風險自擔。
② 內容來源注明“硅谷網”及其相關稱謂的文字、圖片和音視頻,版權均屬本網站所有,任何媒體、網站或個人需經本網站許可方可復制或轉載,并在使用時必須注明來源【硅谷網】或對應來源,違者本網站將依法追究責任。
③ 注明來源為各大報紙、雜志、網站及其他媒體的文章,文章原作者享有著作權,本網站轉載其他媒體稿件是為傳播更多的信息,并不代表贊同其觀點和對其真實性負責,本網站不承擔此類稿件侵權行為的連帶責任。
④ 本網站不對非自身發布內容的真實性、合法性、準確性作擔保。若硅谷網因為自身和轉載內容,涉及到侵權、違法等問題,請有關單位或個人速與本網站取得聯系(聯系電話:01057255600),我們將第一時間核實處理。
廣告
相關
頭條
硅谷網解密:4G網絡中的微波傳輸解決方案 硅谷網解密:4G網絡中的微波傳輸解決方案
在2013年12月4日,工信部向中國移動、中國聯通、中國電信頒發TD-LTE(4G)經營許可之后……
·硅谷網解密:4G網絡中的微波傳輸解決方案
·創意產業的批量化規律 工業造型方法論之加減
·《硅谷》雜志:淺談電信運營商開展IPTV業務
·《硅谷》雜志:新型桌面搜索關鍵技術的研究與
·硅谷雜志:基于時間技術的搜索引擎排名算法
圖文
佳惠安抗菌噴劑敷料殺(抑)菌臨床檢驗結論
佳惠安抗菌噴劑敷料殺(抑)菌臨床檢驗結論
利用重力勢能做功發電介紹和勢能輸出系統介紹
利用重力勢能做功發電介紹和勢能輸出系統介
佳惠安抗菌噴劑敷料殺(抑)菌臨床檢驗結論
佳惠安抗菌噴劑敷料殺(抑)菌臨床檢驗結論
利用重力勢能做功發電介紹和勢能輸出系統介紹
利用重力勢能做功發電介紹和勢能輸出系統介
最新
·佳惠安抗菌噴劑敷料殺(抑)菌臨床檢驗結論
·利用重力勢能做功發電介紹和勢能輸出系統介紹
·李磊:新時代下電網調度自動化技術的發展分析
·提升企業競爭力以及企業人力資源管理優化思考
·《硅谷》雜志:采油分層測靜壓工藝技術淺究
熱點
·判斷連續時間系統的線性非時變性和因果性
·3DMAX+Vary室內漫游動畫制作的技法淺析
·長期使人困惑的問題:TCP連接中斷的實時檢測
·佳惠安抗菌噴劑敷料殺(抑)菌臨床檢驗結論
·關于汽輪機油系統失火原因分析及防范措施的一
舊聞
·硅谷雜志:視頻會議系統建設應用分析
·顏海宙:談談工業鍋爐節能運行的優化措施
·硅谷雜志:無線通信技術在調度通信中的應用
·《科技與生活》雜志:鋼鐵廠廠址的選擇
·硅谷雜志:化工生產過程中的DCS監控系統的應
廣告
硅谷影像
佳惠安抗菌噴劑敷料殺(抑)菌臨床檢驗結論
佳惠安抗菌噴劑敷料殺(抑)菌臨床檢驗結論
利用重力勢能做功發電介紹和勢能輸出系統介紹
利用重力勢能做功發電介紹和勢能輸出系統介紹
公關負責人離職背后:危機公關案例分析
公關負責人離職背后:危機公關案例分析
硅谷網解密:4G網絡中的微波傳輸解決方案
硅谷網解密:4G網絡中的微波傳輸解決方案
使用Autoit腳本在虛擬內存盤設置考試模擬系統
使用Autoit腳本在虛擬內存盤設置考試模擬系統
探秘開灤集團設備租賃管理系統的設計和實現
探秘開灤集團設備租賃管理系統的設計和實現
關于我們·About | 聯系我們·contact | 加入我們·Join | 關注我們·Invest | Site Map | Tags | RSS Map
電腦版·PC版 移動版·MD版 網站熱線:(+86)010-57255600
Copyright © 2007-2020 硅谷網. 版權所有. All Rights Reserved. <京ICP備12003855號-2>
福建36选7新中奖规则 益升网 佳永配资-配资头条—正规实盘股票配资平台提供资讯及在线配资服务 黑龙江体彩6 1开奖结果今天 贵州茅台股票行情分析 双彩网开奖查询 股票配资平台出不了金怎么办 大为配资 体彩湖南幸运赛车开奖结果 内蒙十一选五走势图59 时时彩软件哪个比较好 江西11选五5奖金 山西体彩十一选五软件 永隆配资 河北福彩排列七开奖 普通人如何理财让钱生钱 免费三肖必中特