可靠傳輸之TCP協議

首先,我們來看一下TCP報文段結構,梳理一下關鍵字含義:

這裏寫圖片描述
傳輸層最常用的兩種協議:UDP和TCP。它們最基本的責任是將兩個端系統間IP的交付服務擴展爲運行在端系統上的兩個進程之間的交付服務。在這裏我只對提供可靠傳輸的TCP做介紹。

在討論圖中的TCP報文段之前,我先介紹一下TCP提供的服務:

(1) TCP提供可靠數據傳輸。通過使用流量控制、序號、確認和定時器,TCP確保正確地、按序地將數據從發送進程交付給接收進程。這樣,TCP就將兩個端系統間的不可靠IP服務轉換成了一種進程間的可靠數據傳輸服務。
(2)TCP提供擁塞控制,防止過多數據注入到網絡中,使網絡中的路由器或鏈路不致過載。

多路分解:當報文段到達主機時,運輸層檢查報文段中的目的端口號,並將其定位到相應的套接字。然後報文段中的數據通過套接字進入其所連接的進程。

多路複用:在源主機中,從不同的套接字接收數據塊,併爲每個數據塊封上頭部信息生成報文段,然後將報文段傳遞到網絡層。

TCP是面向連接運輸協議,即在一個應用進程可以開始向另一個進程發送數據之前,這兩個進程之間必須建立一條可靠的連接。TCP用一個四元組(源IP地址、源端口號、目的IP地址、目的端口號)標識一個連接。

下面我們來研究一下TCP報文段結構,以幫助理解後面要介紹的內容:

目的端口號(16比特):標識目的主機的一個socket。
源端口號(16比特):標識源主機的一個socket。
序號(32比特):TCP隱式地對TCP報文段 數據部分 的每一個字節編號。TCP報文段首部的序號值是其數據部分第一個字節的編號。
確認號(32比特):接收主機的確認號是期望從發送主機接收的下一個字節的編號。
首部長度(4比特):表示報文段的首部長度,以32比特的字爲單位,例如首部長度最大值爲154比特)則首部爲60字節。
接收窗口(rwnd):一個變量,接收方的報文段中包含該變量值 用於告知發送方自己還有多少可用的緩存空間。

TCP在IP不可靠的盡力而爲服務之上創建了一種可靠數據傳輸服務。TCP的可靠傳輸確保一個進程從其緩存中讀出的數據流是無損壞、無間隔、非冗餘和按序的數據流;即該字節流與連接的另一端系統發送出的字節流是完全相同。

我們以解釋概念的形式 來討論TCP解決數據傳輸中一些常見問題的方式:

注意,我們現在假設主機A用於發送數據,主機B用於接收數據。

定時器

堅持定時器:

假設主機B的接收緩衝區已經存滿,使得rwnd爲0。在將rwnd=0告訴主機A以後,假設主機B沒有任何數據要發送給主機A。或者當主機B更新了rwnd後,有報文段發給主機A,但是這個報文段丟失了。這樣,主機A就不可能知道主機B的接收緩衝區已經有新空間了,即主機A被阻塞而不能再發任何數據。爲了解決這兩個個問題,當主機A收到的報文段中rwnd(也叫接收窗口也叫通告窗口)爲0時,就設置它的堅持定時器。如果該定時器時間到,主機A還沒有收到任何報文段提示rwnd已經不等於0了的話,主機A就發送包含一個字節數據的窗口探查(就是上次發送數據的下一個字節報文段)。如過主機B的rwnd還是爲0就返回一個rwnd爲0的ACK,但是這個ACK並沒有確認剛剛收到的一個字節數據,而是確認的這個字節以前的所有數據。所以這個字節還是被持續重傳。使用堅持定時器的特點就是,TCP從不放棄發送 窗口探查。這些探查每隔60秒發送一次,這個過程持續到 或者接收窗口不爲0或者應用進程使用的連接被終止。

流量控制與擁塞控制

流量控制:

一條TCP連接每一側主機都爲該連接設置了接收緩存。當該TCP連接收到正確、按序的字節後,它就將數據放入接收緩存。相關聯的應用進程會從該緩存中讀取數據,但不必是數據一到達就立即讀取。如果應用程序讀取數據相對緩慢,而發送方發送得太多太快,發送的數據就會很容易地使該連接的接收緩存溢出。
爲了解決這個問題,TCP爲它的應用程序提供了流量控制服務以消除發送方使接收方緩存溢出的可能性。TCP通過讓發送方維護一個稱爲接收窗口的變量(就是上面TCP報文段的接收窗口)來提供流量控制。通俗地說,接收窗口用於給發送方一個指示:該接收方還有多少可用緩存空間。具體實現就是在接收方在給發送方發送一個報文段(確認報文段、主動發送的數據)時,報文段頭部信息的接收窗口 用於通知 該連接中接收方 剩餘緩存區的大小。

擁塞控制:

很多人容易把流量控制和擁塞控制搞混,其實它們是針對完全不同的原因採取的措施。

MSS:TCP可從發送緩存中取出並放入報文段的數據量受限於最大報文段長度。MSS一般根據MTU確定。
路徑MTU:是指能從源到目的地的所有鏈路上發送的最大鏈路層幀。
注意, MSS是指在報文段裏應用層數據的最大長度而不是指包括TCP首部的TCP報文段的最大長度。

在實踐中,分組丟失一般是當網絡變得擁塞時由於路由器緩存溢出引起的。分組重傳因此作爲網絡擁塞的徵兆來對待。但是卻無法處理導致網絡擁塞的原因,因爲有太多的源想以過高的速率發送數據。爲了處理網絡擁塞原因,需要一些機制以在面臨網絡擁塞時遏制發送方。
擁塞網絡的代價:
1.當分組的到達速率接近鏈容量時,分組經歷巨大的排隊時延。
2.發送方在遇到大時延時所進行的不必要重傳會引起路由器利用其鏈路寬帶來轉發不必要的分組副本。
3.當一個分組沿一條路徑被丟棄時,每個上游路由器用於轉發該分組到丟失該分組而使用的傳輸容量最終被浪費掉了。

快速重傳:

超時觸發重傳存在的問題之一是超時週期可能相對較長。當一個報文段丟失時,這種長超時週期迫使發送方延遲重傳丟失的分組。因而增加了端到端時延。
解決辦法:發送方可在超時事件發生之前通過注意冗餘ACK來較好地檢測到丟包情況。一旦TCP發送方收到3個冗餘ACK,TCP就執行快速重傳,即在該報文段的定時器過期之前重傳丟失的報文段。

那我們現在來看一下,爲什麼接收方要發送冗餘ACK:當TCP接收方收到一個序號大於下一個所期望的、按序的報文段,它檢測到了數據流中的一個間隔,這就是說有報文段丟失。這個間隔可能是由於在網絡中報文段丟失或重新排序造成的。因爲TCP不能向發送方發回一個顯示的否定確認(報文頭部信息沒有,也沒有這個變量)。所以它只對已經接收到的最後一個按序字節進行重複確認,即產生冗餘ACK。

慢啓動:

擁塞窗口:擁塞窗口表示爲cwnd,它對一個TCP發送方能向網絡中發送流量的速率進行了限制。特別是,在一個發送方未被確認的窗口的數據量不會超過cwnd(擁塞窗口)和rwnd(接收窗口)中的最小值。(擁塞窗口和接收窗口是在TCP建立時給連接分配的變量)

當一條TCP連接開始時,並不知道網絡中能接收的數據大小是多少。所以需要向網絡中一點一點發數據探測。cwnd的值通常設置爲一個MSS,如果MSS=500字節且RTT=200ms,則得到的初始發送速率大約只有20kbps。由於對TCP發送方而言,可用寬帶可能比MSS/RTT大得多,TCP發送方希望迅速找到可用寬帶的數量。因此,在慢啓動的狀態,cwnd的值以一個MSS開始並且每當傳輸的報文段首次被確認就增加一個MSS,併發送出兩個最大長度的報文段。這兩個報文段被確認,則發送方對每個確認報文段擁塞窗口增加一個MSS,使得擁塞窗口變爲4個MSS,並一直這樣下去。這一過程每過一個RTT,發送速率就翻番。因此,TCP發送速率起始慢,但在啓動階段以指數增長。

那麼,什麼時候結束這種指數增長呢?
(1)如果存在一個由超時指示的丟包事件(即擁塞),TCP發送方將cwnd設置爲1並重新開始慢啓動過程。並且將慢啓動閥門置爲擁塞窗口的一半。
(2)慢啓動閥門兒有個初始值,當cwnd等於慢啓動閥門兒時,結束慢啓動並且TCP轉移到擁塞避免模式。慢啓動閥門兒就是網絡最優值。
(3)如果檢測到三個冗餘的ACK,這時TCP執行快速重傳,並進入快恢復狀態。

擁塞避免:

當進入擁塞避免狀態時,在每個RTT只將cwnd的值增加一個MSS(線性增長)。一種通用的方法是,例如,我在一個RTT內發送10個報文段。則我每收到一個報文段的ACK,就把我的cwnd增加(1/10)個MSS,當我10個報文段的ACK都收到時也就增加了一個MSS。

快速恢復:

相比於超時指示的丟包,一個由三個冗餘ACK標識的丟包事件 反應應當不那麼劇烈。
當進入快速恢復狀態時,TCP發送方不將cwnd設置爲1,而是設置爲cwnd/2 + 3。
然後就如擁塞避免狀態。如果出現超時事件,快速恢復在執行如同慢啓動相同的動作。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章