1. 程式人生 > >TCP超時重傳機制

TCP超時重傳機制

TCP協議在能夠傳送資料之前就建立起了“連線”。要實現這個連線,啟動TCP連線的那一方首先將傳送一個SYN資料包。這只是一個不包含資料的資料包, 然後,開啟SYN標記。如果另一方同時在它收到SYN標記的埠通話,它將發回一個SYN+ACK:SYN和ACK標誌位都被開啟,並將ACK(確認)編 號欄位設定為剛收到的那個資料包的順序號欄位的值。接下來,連線發起方為了表示收到了這個SYN+ACK資訊,會向傳送方傳送一個最終的確認資訊(ACK 包)。這種SYN、SYN+ACK、ACK的步驟被稱為TCP連線建立時的“三次握手”。在這之後,連線就建立起來了。這個連線將一直保持活動狀態,直到 超時或者任何一方發出一個FIN(結束)訊號。
任何一方都可以關閉一個TCP連線,要求雙方傳送一個FIN訊號關閉自己的通訊頻道。一方可以在另 一方之前關閉,或者雙方同時關閉TCP連線。因此,當一方傳送一個FIN訊號時,另一方可傳送“FIN+ACK”,開始關閉自己一方的通訊並且確認收到了 第一個FIN訊號。傳送第一個FIN訊號的人接下來再發送一個“FIN+ACK”資訊,確認收到第二個FIN訊號。另一方就知道這個連線已經關閉了,並且 關閉了自己的連線。傳送第一個FIN的人沒有辦法收到最後一個ACK訊號的確認資訊。這時它會進入“TIME_WAIT”(等待時間)狀態並啟動一個定時 器,防止另一方沒有收到ACK資訊並且認為連線仍是開啟的。一般來說,這個狀態會持續1至2分鐘。
現在,我們來討論第一個問題。如果有人(假如一 個黑客)在你的Web伺服器上留下一個半開或者半關的連線,那就是一個壞訊息。每一個連線都要消耗記憶體,開啟數千個虛假的TCP連線可能導致伺服器癱瘓。 當然,你實際上不可能在不影響TCP正常工作的情況下調整TCP定時器。如果你聽說過TCP SYN 攻擊的話,那就是這個意思。為了防止出現這種情況,大多數

作業系統都要限制半開連線的數量。例如,Linux預設的限制一般是256個。
關於持續 流控制問題,現在我們就來討論這個問題。TCP中實現它的機制是TCP滑動視窗機制。TCP協議使用“重新發送與正向ACK”來保證資料傳輸的可靠性。發 送方將等待一段時間,如果沒有收到其傳送的資料包的ACK確認資訊,傳送方就要重新發送。順便說一下,TCP協議中有許多定時器。這只是其中一個定時器。 ACK的概念對於流控制是非常重要的,因為TCP滑動視窗協議使TCP的往復確認變得更有效率。如果TCP要傳送一個數據包並且等待每一個ACK確認信 息,它實際上就把資料吞吐量削減了一半。
理想的情況是,我們能夠一次傳送許多資料包,然後等待收到一個確認收到全部資料包的ACK資訊,而不用對 方發來更多的資料。但是,我們如何知道傳送了多少個數據包呢?TCP視窗尺寸可以控制在“已傳送但是沒有確認”的狀態下能夠容納多少個數據包。如果這個窗 口尺寸很大,我們不必等待ACK資訊就可以傳送大量的資料包。這實際上就是流控制。
接收方就是控制視窗大小的那一方。如果接收方將視窗大小設為 “0”,那麼,傳送方根本就不能傳送任何資料。如果這個視窗的尺寸是“1”,那麼,我們就回到了簡單的“傳送和等待ACK”的協議。如果最後的視窗尺寸是 “0”,傳送者將發出一個探測訊號以搞清這個視窗什麼時間再次開啟。如果傳送方從來沒有收到ACK資訊,它就一直不斷地重試,直到定時器過期。請記住,這 個視窗尺寸在TCP頭中是一個16位欄位。如果你要一個視窗尺寸(按位元組計算)大於16位可以表示的容量(2的16次方個位元組),還可以使用一個名為“窗 口縮放”的TCP協議選項。這個選項允許視窗尺寸乘以比例因子。如果沒有極大的視窗尺寸,TCP協議就就無法充分利用GB級別的高速連線。這也是我們需要 針對這些新的高速連線調整TCP引數的原因,
關於TCP流控制的問題,我們不能不提一下Nagle
演算法
。如果我們在一個telnet連線上使用一 個大的TCP視窗會發生什麼事情呢?你會輸入一個指令(例如敲了一個字母),然後一直等待迴應它卻遲遲不出現在終端回顯上。這對於實時通訊來說是一個大問 題。而且,telnet也會增加網路的阻塞度,因為一個位元組的資料(例如我們的一次擊鍵)需要40個位元組的包頭。於是RFC 896定義這個Nagle演算法,用以消除小的資料包。這個思路是我們應該在資料傳送之前給先把小資料集中起來然後一次性發送,以便提高效率。為了更有效 率,它還限定只允許存在一個未經確認的資料段,你在得到確認資訊之前不能傳送更多的資料。Telnet和互動SSH連線使用TCP_NODELAY套介面 選項啟用這個功能,這樣當你按下一個按鍵的時候,你能夠立即得到一個迴應。
當然,我們仍是忽略了有關TCP協議的許多事情。然而,通過這兩篇文章的瞭解,你應該能夠理解其它一些更專業的TCP著作。阻塞控制與流控制不同,本文沒有討論。如果你真的對了解TCP協議的全部工作原理感興趣,你可以詳細閱讀TCP RFC。
小結

TCP 協議非常善於解決流控制問題,因此非常適應於許多應用程式。TCP協議中的流控制的含義是:“在收到對傳送的資料的確認資訊這前,我可以傳送多少資料?” 這就是TCP視窗。學習阻塞控制的問題可以留作讀者的練習。需要指出的是,在TCP協議之下連線速度開始很慢,然後速度逐漸加快。這個做法並不總是最理想 的。

 

轉自http://blog.csdn.net/zhengchunhao/article/details/4425717