TCP的流量控制

Love&Share發表於2021-01-04

一---導讀

   首先我們來看實際生活中這樣一個例項,大人喂小孩子吃飯,如果孩子嘴裡還有飯,孩子表示不想吃了,但大人還是繼續喂。喂多了。這樣就會給孩子留下一個完整的不愉快童年。

那麼在使用TCP協議的雙方端系統中,傳送方就像餵飯的大人,而接收方就是孩子,傳送方傳送的量應該由接收方來決定或者說來調節。

 

二---TCP流量控制(flow control)的產生原因以及控制手段

  讓傳送方不要太快,以免接收方接收不過來。滑動視窗就是控制手段。

  

上圖即為滑動視窗,圖示滑動視窗大小為400,滑動視窗由接收方調節。

 

三---例項說明

 

在看下圖之前,我們首先必須搞清楚這樣幾個專有名詞的含義

1---seq(順序;序號;初始序號;序列號;排列機):是TCP報文段首部中的序號欄位,取值為1則表示TCP報文段資料載荷的第一個位元組的序號為1,取值為101表示TCP報文段資料載荷的第一個位元組的序號為101;

2---DATA:表示TCP報文段;

3---ACK(Acknowledge character 接收字元):表示TCP報文段首部中的標識位,取值為1表示是一個確認報文段,為0表示報文中不包含確認資訊,忽略確認號欄位。

4---ack:表示TCP報文段中的確認號欄位,取值為x表示傳送方傳送的x部分的位元組已經確認收到;

5---rwnd(receive window):滑動視窗的英文名;滑動視窗也可理解為接收視窗。

 

四---死鎖的產生和解決

  思考這樣一個問題,當接收方傳送給傳送方的確認報文段丟失,而它一直傻傻的以為報文段成功被接收方接收,滿懷期待的等著接收方傳送新的報文段給它。然而另一邊,傳送方一直等待著接收方傳送的確認報文段,好繼續傳送新的報文段給接收方,然而確認報文段在路上的時候就走丟了。於是雙方陷入千年的等待。這就是死鎖(死鎖在計算機作業系統中也出現了這個概念,思想和計算機網路的大致相同)。這個時候就需要一個來解決問題的調節員。持續計時器就是這樣一個調解員,若超時了,傳送方傳送一個大小為1位元組的0視窗探測報文段。如果接收方回答為當前的接收視窗為0,則傳送方繼續等待,等待一會後,如果接收方的接收快取有了空閒,則傳送能接受多大的接收視窗(rwnd)給傳送方,傳送方按照接收方回答的值調整滑動視窗繼續去傳送報文段。

  朋友們可能會有這樣一個疑問,既然接收方的接收視窗都為0了,那就應該什麼都收不到才對,為什麼能收到傳送傳送的0視窗探測報文段並且返回確認呢? 這是因為TCP規定,即使接收視窗為0,接收方必須無條件的接收0視窗探測報文段,攜帶緊急資料的報文段,確認報文段。

  繼續思考這樣一個問題:如果0視窗檢測報文段丟失了,會出現什麼問題?還能打破死鎖的局面嗎?回答是肯定的,因為0視窗探測報文段本身帶有重傳計時器,如果重傳計時器超時,則重新傳送0視窗探測報文段

 

 

相關文章