所屬專業(yè)：視覺傳播設計與制作所屬課程：《廣告攝像》所屬單元：《產(chǎn)品短視頻的拍攝》

計算機網(wǎng)絡基礎第六章傳輸層與數(shù)據(jù)傳輸物聯(lián)網(wǎng)工程學院(信息安全學院)6.3TCP協(xié)議1.TCP協(xié)議報文2.TCP重傳機制3.TCP的傳輸連接管理TCP協(xié)議報文TCP/IP體系中面向連接的傳輸層協(xié)議，它提供全雙工的可靠交付的服務。一個TCP報文段分為首部和數(shù)據(jù)兩部分，如圖6-7所示。應當指出，TCP的全部功能都體現(xiàn)在它的首都的各字段。TCP報文段首都的前20個字節(jié)是固定的，后面有4N字節(jié)是根據(jù)需要而增加的選項（N必須是整數(shù)）。因此TCP首部的最小長度是20字節(jié)。TCP協(xié)議報文源端口和目的端口各占兩個字節(jié)是傳輸層與應用層的服務接口。用來將若干高層協(xié)議向下復用，也用來將傳輸層協(xié)議向上分用。TCP協(xié)議報文序號占4字節(jié)。TCP是面向數(shù)據(jù)流的，TCP傳送的報文可看成為連續(xù)的數(shù)據(jù)流，其中每一個字節(jié)都對應于一個序號。首部中的“序號”指的是本報文段所發(fā)送的數(shù)據(jù)中第一個字節(jié)的序號。TCP協(xié)議報文確認序號占4字節(jié)，是期望收到對方的下—個報文段的數(shù)據(jù)的第一個字節(jié)的序號，也就是期望收到的下—個報文段首部的字號字段的值。TCP協(xié)議報文數(shù)據(jù)偏移占4bit，它指出數(shù)據(jù)開始的地方離TCP報文段的起始處有多遠?！皵?shù)據(jù)偏移”的單位不是字節(jié)，而是32bit字（即4字節(jié)字）。由于4bit能表示的最大十進制數(shù)是15，因此數(shù)據(jù)偏移的最大值是60字節(jié)，這也是TCP首部的最大長度。TCP協(xié)議報文保留字段占6bit，保留為今后使用，但目前應置為0。TCP協(xié)議報文①緊急比特URG（URGent）當URG＝1時，表明緊急指針字段有效。它告訴系統(tǒng)此報文段中有緊急數(shù)據(jù)，應盡快傳送（相當于高優(yōu)先級的數(shù)據(jù)），而不要按原來的排隊順序來傳送。要與首部中第五個32bit字中的一半“緊急指針”（UrgentPointer）字段配合使用。TCP協(xié)議報文②確認比特ACK只有當ACK＝1時確認序號字段才有效。當ACK＝0時，確認序號無效。③推送比特PSH（Push）當兩個應用進程進行文互式的通信時，有時在一端的應用進程希望在鍵入一個命令后立即就能夠收到對方的響應。在這種情況下，TCP就可以使用推送（push）操作。接收TCP收到推送比特置1的報文段，就盡快(即“推送”向前)交付給接收應用進程，而不再等到整個緩存都填滿了后再向上交付。PSH比特也可叫作急迫比特。TCP協(xié)議報文④復位比特RST（Reset）當RST＝1時，表明TCP連接中出現(xiàn)嚴重差錯（如由于主機崩潰或其他原因），必須釋放連接，然后再重新建立傳輸連接。復位比特還用來拒絕一個非法的報文段或拒絕打開一個連接。復位比特也可稱為重建比特或重置比特。TCP協(xié)議報文同步比特SYN在連接建立時用來同步序號。當SYN＝1而ACK＝0時,表明這是一個連接請求報文段。終止比特FIN（Final）用來釋放一個迎接，當FIN＝1時，表明此報文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放傳輸連接。TCP協(xié)議報文窗口字段用來控制對方發(fā)送的數(shù)據(jù)量，單位為字節(jié)。TCP連接的一端根據(jù)自己緩存的空間大小確定自己的接收窗口大小，然后通知對方來確定對方的發(fā)送窗口。TCP協(xié)議報文檢驗和字段檢驗的范圍包括首部和數(shù)據(jù)這兩部分。在計算檢驗和時，要在TCP報文段的前面加上12字節(jié)的偽首部。TCP協(xié)議報文占16位，用來確定緊急數(shù)據(jù)的最后一個字節(jié)的位置。優(yōu)先快速地獲取緊急數(shù)據(jù)TCP協(xié)議報文長度可變。TCP只規(guī)定了一種選項，即最大報文段長度MSS(MaximumSegmentSize)。沒有選項時，TCP的首部長度是20字節(jié)。TCP協(xié)議報文填充0，用于保證首部的長度是32位的整數(shù)倍TCP協(xié)議是面向字節(jié)的。TCP將所要傳送的整個報文（這可能包括許多個報文段）看成是一個個字節(jié)組成的數(shù)據(jù)流，并使每一個字節(jié)對應于一個序號。TCP的確認是對接收到的數(shù)據(jù)的最高序號（即收到的數(shù)據(jù)流中的最后一個序號）表示確認。但接收端返回的確認序號是已收到的數(shù)據(jù)的最高序號加1。TCP有三種基本機制來控制報文段的發(fā)送。第一種機制是TCP維持一個變量，它等于最大報文段長度MSS，只要發(fā)送緩存從發(fā)送進程得到的數(shù)據(jù)達到MSS字節(jié)時，就組裝成—個TCP報文段，然后發(fā)送出去。第二種機制是發(fā)送端的應用進程指明要求發(fā)送報文段，即TCP支持的推送（push）操作。第三種機制是發(fā)送端的一個計時器時間到了，這時就把當前已有的緩存數(shù)據(jù)裝入報文段發(fā)送出去。TCP的數(shù)據(jù)編號與確認在TCP的實現(xiàn)中廣泛使用Nagle算法。若發(fā)送端應用進程將欲發(fā)送的數(shù)據(jù)逐個字節(jié)地達到發(fā)送端的TCP緩存，則發(fā)送端就將第一個字符(—個字符的長度是一個字節(jié))發(fā)送出去，將后面到達的字符將都緩存起來。當接收端收到對第一個字符的確認后，再將緩存中的所有字符裝成一個報文段發(fā)送出去，同時繼續(xù)對隨后到達的字符進行緩存。只有在收到對前一個報文段的確認時才繼續(xù)發(fā)送下一個報文段。當字符到達較快而網(wǎng)絡速率較慢時，用這樣的方法可明顯地減少所用的網(wǎng)絡帶寬。因為Nagle算法在某一個時刻只有一個報文在傳輸,會導致數(shù)據(jù)傳遞的不夠及時TCP的數(shù)據(jù)編號與確認傻窗口綜合癥。設想這種情況：接收端的緩存已滿，而交互的應用進程一次只從緩存中讀取一個字符（這樣就在緩存產(chǎn)生1個字節(jié)的空位），然后向發(fā)送端發(fā)送確認，并將窗口設置為1個字節(jié)（但發(fā)送的數(shù)據(jù)報是40字節(jié)長）。接著，發(fā)送端又傳來1個字符（但發(fā)來的IP數(shù)據(jù)報是41字節(jié)長）。接收端發(fā)回確認，仍然將窗口設置為一個字節(jié)。這樣進行下去，網(wǎng)絡的效率將會很低。這種狀況稱之為傻窗口綜合癥。要解決這個問題，可讓接收端等待一段時間，使得或者緩存已能有足夠的空間容納—個最長的報文段，或者緩存已有一半的中間處于空的狀態(tài)。只要出現(xiàn)這兩種情況之一，就發(fā)出確認報文，并向發(fā)送端通知當前的窗口大小。此外，發(fā)送端也不要發(fā)送太小的報文段，而是將數(shù)據(jù)積累成足夠大的報文段，或達到接收端緩存的空間的—半大小。TCP的數(shù)據(jù)編號與確認為了提高報文段的傳輸效率，TCP采用大小可變的滑動窗口進行流量控制。窗口大小的單位是字節(jié)。在通信的過程中，接收端可根據(jù)自己的資源情況，隨時動態(tài)地調整對方為發(fā)送窗口（可增大或減?。┰赥CP中接收端的接收窗口總是等于發(fā)送端的發(fā)送窗口（因為后者是由前者確定的），因此—般就只使用發(fā)送窗口這個詞匯。TCP的流量控制與擁塞控制(a)發(fā)送端要發(fā)送900字節(jié)長的數(shù)據(jù)，劃分為9個100個節(jié)長的報文段，對方確定的發(fā)送窗口為500字節(jié)。發(fā)送端只要收到了對方的確認，發(fā)送窗口就可前移。發(fā)送端的TCP要維護一個指針。每發(fā)送一個報文段，指針就向前移動—個報文段的距離。當指針移動到發(fā)送窗口的最右端（即窗口前沿）時就不能再發(fā)送報文段了。(b)表示發(fā)送端已發(fā)送了400字節(jié)的數(shù)據(jù)，但只收到對前200字節(jié)數(shù)據(jù)的確認，同時窗口大小不變，注意到，現(xiàn)在發(fā)送端還可發(fā)送300字節(jié)。(c)表示發(fā)送端收到了對方對前400字節(jié)數(shù)據(jù)的確認，但窗口減小到400字節(jié)，于是，發(fā)送端還可發(fā)送400字節(jié)的數(shù)據(jù)。TCP的流量控制與擁塞控制設主機A向主機B發(fā)送數(shù)據(jù)。雙方確定的窗口值是400。再設每一個報文段為100字節(jié)長，序號的初始值為1。圖6-10中右邊的注釋可幫助理解整個的過程。應注意到，主機B進行了3次流量控制。第一次將窗口減小為300字節(jié)，第二次又減為200字節(jié)，最后減至0，即不允許對方再發(fā)送數(shù)據(jù)了。這種暫停狀態(tài)將持續(xù)到主機B重新發(fā)出一個新的窗口值為止。TCP的流量控制實現(xiàn)流量控制并非僅僅為了使接收端來得及接收。如果發(fā)送端發(fā)出的報文過多會使網(wǎng)絡負荷過重。由此會引起報文段的時延增大。為了避免發(fā)生擁塞，主機應當降低發(fā)送速率。發(fā)送端的主機在發(fā)送數(shù)據(jù)時，既要考慮到接收端的接收能力，又要使網(wǎng)絡不要發(fā)生擁塞。因而發(fā)送端的發(fā)送窗口應按照以下方式確定：TCP的擁塞控制

通知窗口（advertisedwindow）是接收端根據(jù)其接收能力許諾的窗口值，是來自接收端的流量控制。接收端將通知窗口的值放在TCP報文的首部中，傳送給發(fā)送端。擁塞窗口（congestionwindow）是發(fā)送端根據(jù)網(wǎng)絡擁塞情況得出的窗口值，是來自發(fā)送端的流量控制。為了更好地進行擁塞控制，因特網(wǎng)標準推薦使用以下三種技術，即慢啟動（slow-start）、加速遞減（MultiplicativeDecrease）和擁塞避免（CongestionAvoidance）。TCP的擁塞控制1）當一個連接初始化時，將擁塞窗口置為1（即窗口允許發(fā)送1個報文段）、并設置慢啟動的門限窗口值。2）發(fā)送端的發(fā)送窗口不能超過擁塞窗口和通知窗口的最小值?，F(xiàn)在假定接收端不進行流量控制。3）發(fā)送端若收到了對所有發(fā)出的報文段的確認，就在下一次發(fā)送時將擁塞窗口加倍，可見擁塞窗口從1開始，把指數(shù)規(guī)律增長。若出現(xiàn)了超時，則將當時的擁塞窗口減半，作為新的門限窗口值，同時擁塞窗口再次變?yōu)?。4）擁塞窗口重新從1開始按指數(shù)規(guī)律增長。但當增長到新的門限窗口值時，就每次只將擁塞窗口加1，使擁塞窗口按線性規(guī)律增長。當網(wǎng)絡又出現(xiàn)超時，仍重復上述過程。TCP每發(fā)送一個報文段，就設置一次計時器。只要計時器設置的重傳時間已經(jīng)到了但還沒有收到確認，就要重傳這一報文段。TCP的重傳機制出于TCP的下層是一個互聯(lián)網(wǎng)環(huán)境，發(fā)送的報文段可能只經(jīng)過一個高速率的局域網(wǎng)，但也可能是經(jīng)過多個低速率的局域網(wǎng)，并且數(shù)據(jù)報所選擇的路由還可能會發(fā)生變化。右畫出了數(shù)據(jù)鏈路層和傳輸層的往返時延概率分布的對比。往返時延就是從數(shù)據(jù)發(fā)出到收到對方的確認所經(jīng)歷的時間。對于數(shù)據(jù)鏈路層，其往返時延的方差很小，因此將超時時間設置為圖中的T即可。但對于傳輸層來說，其往返時延的方差很大。若將超時時間設計為圖中的T，則很多報文段的重傳時間太早，因而給網(wǎng)絡增加了許多不應有的負荷。但若將超時時間選為圖中的T，則顯然使網(wǎng)絡的傳輸效率降低很多。

TCP的重傳機制

TCP的重傳機制傳輸連接的管理就是使傳輸連接的建立和釋放都能正常地進行。在連接建立過程中要解決以下三個問題。1）要使每一方能夠確知對方的存在。2）要允許雙方協(xié)商一些參數(shù)（如最大報文段長度，最大窗口大小，服務質量等）。3）能夠傳輸實體資源（如緩存大小，連接表中的項目等）進行分配。TCP的連接和建立都是采用客戶服務端方式。主動發(fā)起連接建立的進程叫作客戶（client）。而被動等待正接建立的進程叫服務器（server）。TCP的傳輸連接管理設主機B中運行一個服務器過程，如圖6-12所示，它先發(fā)出一個被動打開（passiveopen）命令，告訴它的TCP要準備接受客戶進程的連接請求。然后服務器進程就處于“聽”（listen）的狀態(tài)，不斷檢測是否有客戶進程要發(fā)起連接請求，如有，即做出響應。TCP的傳輸連接管理主機A的TCP向主機B的TCP發(fā)出連接請求報文段，其首部的同步比特SYN應置為1，同時選樣—個序號x，表明在后面?zhèn)魉蛿?shù)據(jù)時的第一個數(shù)據(jù)字節(jié)的序號是x。主機B的TCP收到連接請求報文段后，如同意，則發(fā)回確認。在確認報文段中應將SYN置為1，確認序號應為x+1，同時也為自己選擇一個序號y。主機A的TCP收到此報文段后，向B給出確認，其確認序號為y+1。運行客戶進程的主機A的TCP通知上層應用進程，連接已經(jīng)建立（或打開）連接建立采用的這種過程叫作三次握手（there-wayhandshake），或三次聯(lián)絡TCP的傳輸連接管理為什么要發(fā)送這第三個報文段呢？這主要是為了防止己失效連接請求報文段突然又傳送到了主機B，因而產(chǎn)生錯誤。主機A發(fā)出連接請求，但因連接請求報文丟失而未收到確認。主機A于是再重傳—次。后來收到了確認，建立了連接。數(shù)據(jù)傳輸完畢后，就釋放了連接。主機A共發(fā)送了兩個連接請求報文段，其中的第二個到達了主機B。主機A發(fā)出的第一個連接請求報文段并沒有丟失，而是在某些網(wǎng)絡結點滯留的時間太長，以致延誤到在這次的連接釋放以后才傳送到主機B。TCP的傳輸連接管理在數(shù)據(jù)傳輸結束后，通信的雙方都可以發(fā)出釋放連接的請求。主機A的應用進程先向其TCP發(fā)出連接釋放