計算機網絡自學筆記:TCP

如果你在學習這門課程,僅僅為了理解網絡工作原理,那麼只要瞭解TCP是可靠傳輸,數據傳輸丟失時會重傳就可以了。如果你還要參加研究生考試或者公司面試等,那麼下面內容很有可能成為考查的知識點,主要的重點是序號/確認號的編碼、超時定時器的設置、可靠傳輸和連接的管理。

1 TCP連接

TCP面向連接,在一個應用進程開始向另一個應用進程發送數據之前,這兩個進程必須先相互"握手",即它們必須相互發送某些預備報文段,以建立連接。連接的實質是雙方都初始化與連接相關的發送/接收緩衝區,以及許多TCP狀態變量。

這種"連接"不是一條如電話網絡中端到端的電路,因為它們的狀態完全保留在兩個端系統中。

TCP連接提供的是全雙工服務,應用層數據就可在從進程B流向進程A的同時,也從進程A流向進程B。

TCP連接也總是點對點的,即在單個發送方與單個接收方之間建立連接。

一個客戶機進程向服務器進程發送數據時,客戶機進程通過套接字傳遞數據流。

客戶機操作系統中運行的TCP軟件模塊首先將這些數據放到該連接的發送緩存裡,然後會不時地從發送緩存裡取出一塊數據發送。

TCP可從緩存中取出並放入報文段中發送的數據量受限於最大報文段長MSS,通常由最大鏈路層幀長度來決定(也就是底層的通信鏈路決定)。例如一個鏈路層幀的最大長度1500字節,除去數據報頭部長度20字節,TCP報文段的頭部長度20字節,MSS為1460字節。

報文段被往下傳給網絡層,網絡層將其封裝在網絡層IP數據報中。然後這些數據報被髮送到網絡中。

當TCP在另一端接收到一個報文段後,該報文段的數據就被放人該連接的接收緩存中。應用程序從接收緩存中讀取數據流(注意是應用程序來讀,不是操作系統推送)。

TCP連接的每一端都有各自的發送緩存和接收緩存。

因此TCP連接的組成包括:主機上的緩存、控制變量和與一個進程連接的套接字變量名,以及另一臺主機上的一套緩存、控制變量和與一個進程連接的套接字。

在這兩臺主機之間的路由器、交換機中,沒有為該連接分配任何緩存和控制變量。

2報文段結構TCP報文段由首部字段和一個數據字段組成。數據字段包含有應用層數據。由於MSS限制了報文段數據字段的最大長度。當TCP發送一個大文件時,TCP通常是將文件劃分成長度為MSS的若干塊。TCP報文段的結構。

首部包括源端口號和目的端口號,它用於多路複用/多路分解來自或送至上層應用的數據。另外,TCP首部也包括校驗和字段。報文段首部還包含下列字段:32比特的序號字段和32比特的確認號字段。這些字段被TCP發送方和接收方用來實現可靠數據傳輸服務。16比特的接收窗口字段,該字段用於流量控制。該字段用於指示接收方能夠接受的字節數量。4比特的首部長度字段,該字段指示以32比特的字為單位的TCP首部長度。一般TCP首部的長度就是20字節。

可選與變長的選項字段,該字段用於當發送方與接收方協商最大報文段長度,或在高速網絡環境下用作窗口調節因子時使用。標誌字段ACK比特用於指示確認字段中的ACK值的有效性,即該報文段包括一個對已被成功接收報文段的確認。SYN和FIN比特用於連接建立和拆除。PSH、URG和緊急指針字段通常沒有使用。

•序號和確認號TCP報文段首部兩個最重要的字段是序號字段和確認號字段。TCP把數據看成一個無結構的但是有序的字節流。TCP序號是建立在傳送的字節流之上,而不是建立在傳送的報文段的序列之上。

一個報文段的序號是該報文段首字節在字節流中的編號。例如,假設主機A上的一個進程想通過一條TCP連接向主機B上的一個進程發送一個數據流。主機A中的TCP將對數據流中的每一個字節進行編號。假定數據流由一個包含4500字節的文件組成(可以理解為應用程序調用send函數傳遞過來的數據長度),MSS為1000字節(鏈路層一次能夠傳輸的字節數),如果主機決定數據流的首字節編號是7。TCP模塊將為該數據流構建5個報文段(也就是分5個IP數據報)。第一個報文段的序號被賦為7;第二個報文段的序號被賦為1007,第三個報文段的序號被賦為2007,以此類推。前面4個報文段的長度是1000,最後一個是500。

確認號要比序號難理解一些。前面講過,TCP是全雙工的,因此主機A在向主機B發送數據的同時,也可能接收來自主機B的數據。從主機B到達的每個報文段中的序號字段包含了從B流向A的數據的起始位置。

因此主機B填充進報文段的確認號是主機B期望從主機A收到的下一報文段首字節的序號。

假設主機B已收到了來自主機A編號為7-1006的所有字節,同時假設它要發送一個報文段給主機A。主機B等待主機A的數據流中字節1007及後續所有字節。所以,主機B會在它發往主機A的報文段的確認號字段中填上1007。

再舉一個例子,假設主機B已收到一個來自主機A的包含字節7-1006的報文段,以及另一個包含字節2007-3006的報文段。由於某種原因,主機A還沒有收到字節1007-2006的報文段。

在這個例子中,主機A為了重組主機B的數據流,仍在等待字節1007。因此,A在收到包含字節2007-3006的報文段時,將會又一次在確認號字段中包含1007。因為TCP只確認數據流中至第一個丟失報文段之前的字節數據,所以TCP被稱為是採用累積確認。

TCP的實現有兩個基本的選擇:

1接收方立即丟棄失序報文段;

2接收方保留失序的字節,並等待缺少的字節以填補該間隔。

一條TCP連接的雙方均可隨機地選擇初始序號。這樣做可以減少將那些仍在網絡中的來自兩臺主機之間先前連接的報文段,誤認為是新建連接所產生的有效報文段的可能性。

•例子telnet

Telnet由是一個用於遠程登錄的應用層協議。它運行在TCP之上,被設計成可在任意一對主機之間工作。

假設主機A發起一個與主機B的Telnet會話。因為是主機A發起該會話,因此主機A被標記為客戶機,主機B被標記為服務器。用戶鍵入的每個字符(在客戶機端)都會被髮送至遠程主機。遠程主機收到後會複製一個相同的字符發回客戶機,並顯示在Telnet用戶的屏幕上。這種"回顯"用於確保由用戶發送的字符已經被遠程主機收到並處理。因此,在從用戶擊鍵到字符顯示在用戶屏幕上之間的這段時間內,每個字符在網絡中傳輸了兩次。

現在假設用戶輸入了一個字符"C",假設客戶機和服務器的起始序號分別是42和79。前面講過,一個報文段的序號就是該報文段數據字段首字節的序號。因此,客戶機發送的第一個報文段的序號為42,服務器發送的第一個報文段的序號為79。前面講過,確認號就是主機期待的數據的下一個字節序號。在TCP連接建立後但沒有發送任何數據之前,客戶機等待字節79,而服務器等待字節42。

計算機網絡自學筆記:TCP

如圖所示,共發了3個報文段。第一個報文段是由客戶機發往服務器,其數據字段裡包含一字節的字符"C"的ASCII碼,其序號字段裡是42。另外,由於客戶機還沒有接收到來自服務器的任何數據,因此該報文段中的確認號字段裡是79。

第二個報文段是由服務器發往客戶機。它有兩個目的:第一個目的是為服務器所收到的數據提供確認。服務器通過在確認號字段中填入43,告訴客戶機它已經成功地收到字節42及以前的所有字節,現在正等待著字節43的出現。第二個目的是回顯字符"C"。因此,在第二個報文段的數據字段裡填入的是字符"C"的ASCII碼,第二個報文段的序號為79,它是該TCP連接上從服務器到客戶機的數據流的起始序號,也是服務器要發送的第一個字節的數據。

這裡客戶機到服務器的數據的確認被裝載在一個服務器到客戶機的數據的報文段中,這種確認被稱為是捎帶確認.

第三個報文段是從客戶機發往服務器的。它的唯一目的是確認已從服務器收到的數據。

3往返時延的估計與超時TCP如同前面所講的rdt協議一樣,採用超時/重傳機制來處理報文段的丟失問題。最重要的一個問題就是超時間隔長度的設置。顯然,超時間隔必須大於TCP連接的往返時延RTT,即從一個報文段發出到收到其確認時。否則會造成不必要的重傳。

•估計往返時延

TCP估計發送方與接收方之間的往返時延是通過採集報文段的樣本RTT來實現的,就是從某報文段被髮出到對該報文段的確認被收到之間的時間長度。

也就是說TCP為一個已發送的但目前尚未被確認的報文段估計sampleRTT,從而產生一個接近每個RTT的採樣值。但是,TCP不會為重傳的報文段計算RTT。

為了估計一個典型的RTT,採取了某種對RTT取平均值的辦法。TCP據下列公式來更新

EstimatedRTT=(1-)*EstimatedRTT+*SampleRTT即估計RTT的新值是由以前估計的RTT值與sampleRTT新值加權組合而成的。

參考值是a=0.125,因此是一個加權平均值。顯然這個加權平均對最新樣本賦予的權值

要大於對老樣本賦予的權值。因為越新的樣本能更好地反映出網絡當前的擁塞情況。從統計學觀點來講,這種平均被稱為指數加權移動平均

除了估算RTT外,還需要測量RTT的變化,RTT偏差的程度,因為直接使用平均值設置計時器會有問題(太靈敏)。

DevRTT=(1-β)*DevRTT+β*|SampleRTT-EstimatedRTT|RTT偏差也使用了指數加權移動平均。B取值0.25.•設置和管理重傳超時間隔假設已經得到了估計RTT值和RTT偏差值,那麼TCP超時間隔應該用什麼值呢?TCP將超時間隔設置成大於等於估計RTT值和4倍的RTT偏差值,否則將造成不必要的重傳。但是超時間隔也不應該比估計RTT值大太多,否則當報文段丟失時,TCP不能很快地重傳該報文段,從而將給上層應用帶來很大的數據傳輸時延。因此,要求將超時間隔設為估計RTT值加上一定餘量。當估計RTT值波動較大時,這個餘最應該大些;當波動比較小時,這個餘量應該小些。因此使用4倍的偏差值來設置重傳時間。

TimeoutInterval=EstimatedRTT+4*DevRTT

4可信數據傳輸

因特網的網絡層服務是不可靠的。IP不保證數據報的交付,不保證數據報的按序交付,也不保證數據報中數據的完整性。

TCP在IP不可靠的盡力而為服務基礎上建立了一種可靠數據傳輸服務。

TCP提供可靠數據傳輸的方法涉及前面學過的許多原理。TCP採用流水線協議、累計確認。TCP推薦的定時器管理過程使用單一的重傳定時器,即使有多個已發送但還未被確認的報文段也一樣。重傳由超時和多個ACK觸發。

在TCP發送方有3種與發送和重傳有關的主要事件:從上層應用程序接收數據,定時器超時和收到確認ACK。

從上層應用程序接收數據。一旦這個事件發生,TCP就從應用程序接收數據,將數據封裝在一個報文段中,並將該報文段交給IP。注意到每一個報文段都包含一個序號,這個序號就是該報文段第一個數據字節的字節流編號。如果定時器還沒有計時,則當報文段被傳給IP時,TCP就啟動一個該定時器。

第二個事件是超時。TCP通過重傳引起超時的報文段來響應超時事件。然後TCP重啟定時器。

第三個事件是一個來自接收方的確認報文段(ACK)。當該事件發生時,TCP將ACK的值y與變量SendBase(發送窗口的基地址)進行比較。TCP狀態變量SendBase是最早未被確認的字節的序號。就是指接收方已正確按序接收到數據的最後一個字節的序號。TCP採用累積確認,所以y確認了字節編號在y之前的所有字節都已經收到。如果Y>SendBase,則該ACK是在確認一個或多個先前未被確認的報文段。因此發送方更新其SendBase變量,相當於發送窗口向前移動。

另外,如果當前有未被確認的報文段,TCP還要重新啟動定時器。

快速重傳

超時觸發重傳存在的另一個問題是超時週期可能相對較長。當一個報文段丟失時,這種長超時週期迫使發送方等待很長時間才重傳丟失的分組,因而增加了端到端時延。所以通常發送方可在超時事件發生之前通過觀察冗餘ACK來檢測丟包情況。

冗餘ACK就是接收方再次確認某個報文段的ACK,而發送方先前已經收到對該報文段的確認。

當TCP接收方收到一個序號比所期望的序號大的報文段時,它認為檢測到了數據流中的一個間隔,即有報文段丟失。這個間隔可能是由於在網絡中報文段丟失或重新排序造成的。因為TCP使用累計確認,所以接收方不向發送方發回否定確認,而是對最後一個正確接收報文段進行重複確認(即產生一個冗餘ACK)

如果TCP發送方接收到對相同報文段的3個冗餘ACK.它就認為跟在這個已被確認過3次的報文段之後的報文段已經丟失。一旦收到3個冗餘ACK,TCP就執行快速重傳

即在該報文段的定時器過期之前重傳丟失的報文段。

5流量控制

前面講過,一條TCP連接雙方的主機都為該連接設置了接收緩存。當該TCP連接收到正確、按序的字節後,它就將數據放入接收緩存。相關聯的應用進程會從該緩存中讀取數據,但沒必要數據剛一到達就立即讀取。事實上,接收方應用也許正忙於其他任務,甚至要過很長時間後才去讀取該數據。如果應用程序讀取數據時相當緩慢,而發送方發送數據太多、太快,會很容易使這個連接的接收緩存溢出。

TCP為應用程序提供了流量控制服務以消除發送方導致接收方緩存溢出的可能性。因此,可以說流量控制是一個速度匹配服務,即發送方的發送速率與接收方應用程序的讀速率相匹配。

前面提到過,TCP發送方也可能因為IP網絡的擁塞而被限制,這種形式的發送方的控制被稱為擁塞控制(congestioncontrol)。

TCP通過讓接收方維護一個稱為接收窗口的變量來提供流量控制。接收窗口用於告訴發送方,該接收方還有多少可用的緩存空間。因為TCP是全雙工通信,在連接兩端的發送方都各自維護一個接收窗口變量。

主機把當前的空閒接收緩存大小值放入它發給對方主機的報文段接收窗口字段中,通知對方它在該連接的緩存中還有多少可用空間。

6 TCP連接管理客戶機中的TCP會用以下方式與服務器建立一條TCP連接:

第一步:客戶機端首先向服務器發送一個SNY比特被置為1報文段。該報文段中不包含應用層數據,這個特殊報文段被稱為SYN報文段。另外,客戶機會選擇一個起始序號,並將其放置到報文段的序號字段中。為了避免某些安全性攻擊,這裡一般隨機選擇序號。

第二步:一旦包含TCP報文段的用戶數據報到達服務器主機,服務器會從該數據報中提取出TCPSYN報文段,為該TCP連接分配TCP緩存和控制變量,並向客戶機TCP發送允許連接的報文段。這個允許連接的報文段還是不包含應用層數據。但是,在報文段的首部卻包含3個重要的信息。

首先,SYN比特被置為1。其次,該TCP報文段首部的確認號字段被置為客戶端序號+1最後,服務器選擇自己的初始序號,並將其放置到TCP報文段首部的序號字段中。

這個允許連接的報文段實際上表明瞭:"我收到了你要求建立連接的、帶有初始序號的分組。我同意建立該連接,我自己的初始序號是XX"。這個同意連接的報文段通常被稱為SYN+ACK報文段。

第三步:在收到SYN+ACK報文段後,客戶機也要給該連接分配緩存和控制變量。客戶機主機還會向服務器發送另外一個報文段,這個報文段對服務器允許連接的報文段進行了確認。因為連接已經建立了,所以該ACK比特被置為1,稱為ACK報文段,可以攜帶數據。

一旦以上3步完成,客戶機和服務器就可以相互發送含有數據的報文段了。

為了建立連接,在兩臺主機之間發送了3個分組,這種連接建立過程通常被稱為三次握手(SNY、SYN+ACK、ACK,ACK報文段可以攜帶數據)。這個過程發生在客戶機connect()服務器,服務器accept()客戶連接的階段。

假設客戶機應用程序決定要關閉該連接。(注意,服務器也能選擇關閉該連接)客戶機發送一個FIN比特被置為1的TCP報文段,並進人FINWAIT1狀態。當處在FINWAIT1狀態時,客戶機TCP等待一個來自服務器的帶有ACK確認信息的TCP報文段。當它收到該報文段時,客戶機TCP進入FINWAIT2狀態。當處在FINWAIT2狀態時,客戶機等待來自服務器的FIN比特被置為1的另一個報文段,

收到該報文段後,客戶機TCP對服務器的報文段進行ACK確認,並進入TIME_WAIT狀態。TIME_WAIT狀態使得TCP客戶機重傳最終確認報文,以防該ACK丟失。在TIME_WAIT狀態中所消耗的時間是與具體實現有關的,一般是30秒或更多時間。

經過等待後,連接正式關閉,客戶機端所有與連接有關的資源將被釋放。因此TCP連接的關閉需要客戶端和服務器端互相交換連接關閉的FIN、ACK置位報文段。


分享到:


相關文章: