運輸層概述

這里我們對運輸層進行概述，之前文章所介紹的計算機網(wǎng)絡體系結構中的物理層，數(shù)據(jù)鏈路層以及網(wǎng)絡層，他們共同解決了將主機通過異構網(wǎng)絡互聯(lián)起來所面臨的問題，實現(xiàn)了主機到主機的通信，

如圖所示，局域網(wǎng)1上的主機與局域網(wǎng)2上的主機，通過互聯(lián)的廣域網(wǎng)進行通信，網(wǎng)絡層的作用范圍是主機到主機，但實際上在計算機網(wǎng)絡中進行通信的真正實體是位于通信兩端主機中的進程。

Ap是應用進程的英文縮寫詞，如何為運行在不同主機上的應用進程提供直接的通信服務，是運輸層的任務，運輸層協(xié)議又稱為端到端協(xié)議，如圖所示運輸層的作用范圍是應用進程到應用進程，也稱為端到端。

接下來我們從計算機網(wǎng)絡體系結構的角度來看運輸層。這是通信雙方應用層中的應用進程。假設AP1與AP4之間進行基于網(wǎng)絡的通信，AP2與AP3之間進行基于網(wǎng)絡的通信，在運輸層需要不同的端口來對應不同的應用進程，然后通過網(wǎng)絡層及其下層來傳輸應用層報文。如圖所示，接收方的運輸層通過不同的端口將收到的應用層報文交付給應用層中相應的應用進程。

需要注意的是這里的端口并不是指看得見摸得著的物理端口，而是指用來區(qū)分不同應用進程的標識符。為了簡單起見，在學習和研究運輸層時，我們可以簡單的認為，運輸層直接為應用進程間的邏輯通信提供服務。邏輯通信的意思是運輸層之間的通信好像是沿水平方向傳送數(shù)據(jù)，但事實上這兩個運輸層之間并沒有一條水平方向的物理連接，要傳送的數(shù)據(jù)是沿著圖中上下多次的虛線方向傳送的，運輸層向高層用戶屏蔽了下面網(wǎng)絡核心的細節(jié)，如網(wǎng)絡拓撲所采用的路由選擇協(xié)議等，它是應用層看見的，就好像是在兩個運輸層實體之間，有一條端到端的邏輯通信信道，根據(jù)應用需求的不同，因特網(wǎng)的運輸層為應用層提供了兩種不同的運輸層協(xié)議，面向連接的TCP協(xié)議和無連接的UDP協(xié)議。這兩種協(xié)議就是本文要討論的主要內(nèi)容。

?

運輸層端口號、復用與分用的概念

• 復用：就是可以重復使用的意思，即各個應用層協(xié)議都可以使用TCP協(xié)議；
• 分用：就是TCP根據(jù)端口號，將報文分給不同的應用進程。

關于端口號的概念：

---

接下來我們介紹發(fā)送方的復用和接收方的分用

如圖所示，這是收發(fā)雙方的應用進程：

• 發(fā)送方的某些應用進程所發(fā)送的不同應用報文，在運輸層使用UDP協(xié)議進行封裝，這稱為UDP復用。
• 而另一些應用進程做發(fā)送的不同應用報文，在運輸層使用TCP協(xié)議進行封裝，這稱為TCP復用
• 運輸層使用端口號來區(qū)分不同的應用進程。不管是使用運輸層的UDP協(xié)議，封裝成的UDP用戶數(shù)據(jù)報，還是使用TCP協(xié)議封裝成的TCP報文段，在網(wǎng)絡層都需要使用IP協(xié)議封裝成IP數(shù)據(jù)報，這稱為IP復用。
• IP數(shù)據(jù)報首部中協(xié)議字段的值，用來表明IP數(shù)據(jù)報的數(shù)據(jù)載荷部分，封裝的是何種協(xié)議數(shù)據(jù)單元，取值為6表示封裝的是TCP報文段，取值為17表示封裝的是UDP用戶數(shù)據(jù)報接收方的網(wǎng)絡層
• 收到IP數(shù)據(jù)報后，進行IP分用，若IP數(shù)據(jù)報首部裝協(xié)議字段的值為17，則把IP數(shù)據(jù)報的數(shù)據(jù)載荷部分所封裝的UDP，用戶數(shù)據(jù)報上交運輸層的UDP
• 若協(xié)議字段的值為6，則把IP數(shù)據(jù)報的數(shù)據(jù)載荷部分所封裝的TCP報文段，上交運輸層的TCP。
• 運輸層對UDP用戶數(shù)據(jù)報進行UDP分用，對TCP報文段進行TCP分用，也就是根據(jù)端口號將它們交付給上層相應的應用進程。

---

下面我們給出TCP/IP體系的應用層常用協(xié)議所使用的運輸層熟知端口號：

不管在運輸層使用UDP還是TCP協(xié)議，在網(wǎng)絡層都需要使用IP協(xié)議，IP數(shù)據(jù)報首部中協(xié)議字段的值，表明了IP數(shù)據(jù)報數(shù)據(jù)載荷部分封裝的是何種協(xié)議數(shù)據(jù)單元。

---

接下來我們通過一個實例來進一步說明運輸層端口號的作用

如圖所示用戶PC,DNS服務器，WEB服務器通過交換機進行互聯(lián)，它們處于同一個以太網(wǎng)中，DNS服務器中記錄有web域名所對應的IP地址，我們在用戶PC中使用網(wǎng)頁瀏覽器來訪問WEB服務器的內(nèi)容，在網(wǎng)頁瀏覽器的地址欄中輸入WEB服務器的域名：

過程如下：

• 用戶PC中的DNS客戶端進程，會發(fā)送一個DNS查詢請求報文，其內(nèi)容為域名www.porttest.com，所對應的IP地址是什么？

• DNS查詢請求報文，需要使用運輸層的UDP協(xié)議封裝成UDP用戶數(shù)據(jù)報，其首部中的源端口字段值，在短暫端口號49151到65535中挑選一個未被占用的用來表示DNS客戶端進程，例如49152。目的端口字段的值設置為53，這是DNS服務器端進程所使用的熟知端口號。之后將UDP、用戶數(shù)據(jù)報封裝在IP數(shù)據(jù)報中，通過以太網(wǎng)發(fā)送給DNS的服務器
  

• DNS服務器端收到該數(shù)據(jù)報后，從中解封出UDP用戶數(shù)據(jù)報，UDP首部中的目的端口號為53，這表明應將該UDP用戶數(shù)據(jù)報的數(shù)據(jù)載荷部分，也就是DNS查詢請求報文交付給本服務器中的DNS服務器端進程，DNS服務器端進程解析DNS查詢請求報文的內(nèi)容，然后按其要求查找對應的IP地址
  

• 之后會給用戶PC發(fā)送DNS響應報文，及內(nèi)容為域名www.porttest.com，所對應的IP地址是192.168.0.3，DNS響應報文需要使用運輸層的UDP協(xié)議封裝成UDP用戶數(shù)據(jù)報，其首部中的源端口字段的值，設置為熟知端口號53，表明這是DNS服務器端進程所發(fā)送的UDP用戶數(shù)據(jù)報，目的端口字段的值設置為49152，這是之前用戶PC中發(fā)送DNS查詢請求報文的 DNS客戶端進程所使用的短暫端口號，之后將UDP用戶數(shù)據(jù)報封裝在IP數(shù)據(jù)報中，通過以太網(wǎng)發(fā)送給用戶PC。
  

• 用戶PC收到該數(shù)據(jù)報后，從中解封出UDP用戶數(shù)據(jù)報，UDP首部中的目的端口號為49152，這表明應將該UDP用戶數(shù)據(jù)報的數(shù)據(jù)載荷部分，也就是DNS響應報文交付給用戶PC中的DNS客戶端進程，DNS客戶端進程解析DNS響應報文的內(nèi)容。就可知道自己之前所請求的WEB服務器的域名所對應的IP地址為192.168.0.3。
  

• 現(xiàn)在用戶PC中的HTTP客戶端進程，可以向WEB服務器發(fā)送HTTP請求報文了。HTTP請求報文，需要使用運輸層的TCP協(xié)議，封裝成TCP報文段，其首部中的原端口字段的值在短暫端口號49151到65535中，挑選一個未被占用的用來表示HTTP客戶端進程，例如仍然使用之前用過的49152目的端口字段的值設置為80，這是HTTP服務器端進程所使用的熟知端口號。之后將TCP報文段封裝在IP數(shù)據(jù)報中，通過以太網(wǎng)發(fā)送給WEB服務器
  

• WEB服務器收到該數(shù)據(jù)報后，從中解封出TCP報文段，TCP首部中的目的端口號為80，這表明應該將該TCP報文段的數(shù)據(jù)載荷部分，也就是HTTP請求報文交付給本服務器中的HTTP服務器端進程。HTTP服務器端進程，解析HTTP請求報文的內(nèi)容，然后按其要求查找首頁內(nèi)容之后，會給用戶PC發(fā)送HTTP響應報文，其內(nèi)容是 HTTP客戶端所請求的首頁內(nèi)容。HTTP響應報文需要使用運輸層的TCP協(xié)議，封裝成TCP報文段，其首部中的原端口號字段的值，設置為熟知端口號80，表明這是HTTP服務器端進程所發(fā)送的TCP報文段，目的端口字段的值設置為49152，這是之前用戶PC中發(fā)送HTTP請求報文的HTTP客戶端進程所使用的短暫端口號。之后將TCP報文段封裝在IP數(shù)據(jù)報中，通過以太網(wǎng)發(fā)送給用戶PC
  

• 用戶收到該數(shù)據(jù)報后，從中解封出TCP報文段，TCP首部中的目的端口號為49152，這表明應該將該TCP報文段的數(shù)據(jù)載荷部分，也就是HTTP響應報文，交付給用戶PC中的HTTP客戶端進程，解析HTTP響應報文的內(nèi)容，并在網(wǎng)頁瀏覽器中進行顯示，這樣我們就可以在網(wǎng)頁瀏覽器中看到WEB服務器所提供的首頁內(nèi)容了
  

內(nèi)容小結如下：

UDP和TCP的對比

UDP和TCP是TCP體系結構運輸層中的兩個重要協(xié)議，??如圖所示，這是TCP/IP體系結構。它的運輸層有兩個非常重要的協(xié)議??UDP和TCP。在使用TCP/IP體系結構的網(wǎng)絡通信中，這兩個協(xié)議的使用頻率??僅次于網(wǎng)際層的IP協(xié)議，TCP/IP體系結構應用層中的某些協(xié)議，??有的需要使用運輸層的TCP提供的服務，而另一些協(xié)議需要使用運輸層的UDP提供的服務。

• UDP是用戶數(shù)據(jù)報協(xié)議的英文縮寫詞
• TCP是傳輸控制協(xié)議的英文縮寫詞

接下來??我們將從幾個方面對這兩個協(xié)議進行比較：

如圖所示，這是因特網(wǎng)上的兩臺主機，??他們在運輸層使用UDP協(xié)議進行通信，縱坐標為時間：

• 使用UDP協(xié)議的通信雙方??可以隨時發(fā)送數(shù)據(jù)。

• 使用TCP協(xié)議的通信雙方??在進行數(shù)據(jù)傳輸之前，必須使用三報文握手來建立TCP連接，TCP連接建立成功后??才能進行數(shù)據(jù)傳輸結束后，必須使用四報文揮手來釋放TCP連接。??

• 需要注意的是這里所謂的連接是指邏輯連接關系，??而不是物理連接。??

綜上所述，UDP是無連接的，而TCP是面向連接的

來看這個對比項：

• 這是某個局域網(wǎng)上的需要UDP協(xié)議進行通信的4臺主機，其中任何一臺主機??都可向其他三臺主機發(fā)送廣播，也可以向某個多播組發(fā)送多播，??還可以向某臺主機發(fā)送單播，也就是說UDP支持單播多播以及廣播。??換句話說，UDP支持一對一，一對多以及一對全的通信。??
• 再來看使用TCP協(xié)議的情況，使用TCP協(xié)議的通信雙方在進行數(shù)據(jù)傳輸之前，??必須使用三報文握手來建立TCP連接，TCP連接建立成功后，通信雙方之間??就好像有一條可靠的通信信道，通信雙方使用這條基于TCP連接的可靠信道進行通信，很顯然?? TCP僅支持單播，也就是一對一的通信。

接下來我們來對比這兩個協(xié)議對應用報文的處理：

• 先來看使用UDP協(xié)議的情況，發(fā)送方的應用進程，??將應用層報文交付給運輸層的UDP，UDP直接給應用層報文，添加一個UDP首部，??使之成為UDP用戶數(shù)據(jù)報，然后進行發(fā)送。??需要說明的是為了簡單起見，??我們忽略運輸層下面的各層處理，接受方的UDP收到該UDP用戶數(shù)據(jù)報后，去掉UDP首部，??將應用層報文交付給應用進程，也就是說UDP對應用進程交下來的報文，既不合并??也不拆分，而是保留這些報文的邊界。換句話說，??UDP是面向應用報文的
• 再來看使用TCP協(xié)議的情況，發(fā)送方的TCP??把應用進程交付下來的數(shù)據(jù)塊，僅僅看作是一連串的無結構的字節(jié)流，??TCP并不知道這些待傳送的字節(jié)流的含義，僅將他們編號并存儲在自己的發(fā)送緩存中。??TCP根據(jù)發(fā)送策略，從發(fā)送緩存中提取一定數(shù)量的字節(jié)，構建TCP報文段并發(fā)送??。接收方的TCP，??一方面從所接收到的TCP報文段中取出數(shù)據(jù)載荷部分并存儲在接收緩存中，一方面將接收緩存中的一些字節(jié)交付給應用進程，??TCP不保證接收方應用進程所收到的數(shù)據(jù)塊與發(fā)送方應用進程和發(fā)出的數(shù)據(jù)塊??具有對應大小的關系。例如發(fā)送方應用進程交給發(fā)送方的TCP，共10個數(shù)據(jù)塊，??但接收方的TCP可能只用了4個數(shù)據(jù)塊，就把收到的字節(jié)流交付給了上層的應用進程，??但接收方應用進程收到的字節(jié)流??必須和發(fā)送方應用進程發(fā)出的字節(jié)流完全一樣。??當然接收方的應用進程??必須有能力識別收到的字節(jié)流，把它還原成有意義的應用層數(shù)據(jù)，也就是說?? TCP是面向自字節(jié)流的，這正是TCP實現(xiàn)可靠傳輸，流量控制以及擁塞控制的基礎。

需要說明的是為了突出示意圖的要點，我們只畫出了一個方向的數(shù)據(jù)流，在實際網(wǎng)絡中??基于TCP連接的兩端，可以同時進行TCP報文段的發(fā)送和接收，??也就是全雙工通信。另外圖中TCP報文段的數(shù)據(jù)部分只包含了幾個字節(jié)，實際當中??一個TCP報文段包含上千個字節(jié)是很常見的。??

再來看下一個對比項：

• 我們曾介紹過TCP/IP體系結構的網(wǎng)際層向其上層提供的是無連接不可靠的傳輸服務，??當運輸層使用UDP協(xié)議時，向其上層提供的也是無連接不可靠的傳輸服務，??發(fā)送方給接收方發(fā)送UDP用戶數(shù)據(jù)報，若傳輸過程中，??用戶數(shù)據(jù)報受到干擾而產(chǎn)生誤碼，接收方UDP可以通過該數(shù)據(jù)報首部中的校驗和字段的值，??檢查出產(chǎn)生誤碼的情況，但僅僅丟棄該數(shù)據(jù)報，其他什么也不做。??發(fā)送方給接收方發(fā)送UDP用戶數(shù)據(jù)報，如果該數(shù)據(jù)報被因特網(wǎng)中的某個路由器丟棄了，??發(fā)送方UDP不做任何處理，因為UDP向上層提供的是無連接不可靠的傳輸服務。因此??對于UDP用戶數(shù)據(jù)報出現(xiàn)的誤碼和丟失等問題，UDP并不關心。??基于UDP的這個特點，??UDP適用于實時應用，例如IP電話、視頻會議等。
• 再來看使用TCP協(xié)議的情況，??盡管網(wǎng)際層中的IP協(xié)議向上層提供的是無連接不可靠的傳輸服務，也就是說?? IP數(shù)據(jù)報可能在傳輸過程中出現(xiàn)丟失或誤碼，但只要運輸層使用TCP協(xié)議，??就可向其上層提供面向連接的可靠傳輸服務。我們可將其想象成使用TCP協(xié)議的收發(fā)雙方，??基于TCP連接的可靠性到進行數(shù)據(jù)傳輸，不會出現(xiàn)誤碼??丟失、亂序以及重復等傳輸差錯。TCP適用于要求可靠傳輸?shù)膽?#xff0c;??例如文件傳輸。??

最后我們再來對比一下UDP用戶數(shù)據(jù)報的首部與TCP報文段的首部??：

• 一個UDP用戶數(shù)據(jù)報由首部和數(shù)據(jù)載荷兩部分構成，其首部格式如圖所示??僅有4個字段，每個字段長度為2個字節(jié)。由于UDP不提供可靠傳輸服務，??它僅僅在網(wǎng)際層的基礎上添加了用于區(qū)分應用進程的端口，??因此他的首部非常簡單，僅有8個字節(jié)
• 1個TCP報文段由首部??和數(shù)據(jù)載荷兩部分構成，其首部格式如圖所示，這比UDP用戶數(shù)據(jù)報的首部復雜的多，??其最小長度為20字節(jié)，最大長度為60字節(jié)，這是因為TCP要實現(xiàn)可靠傳輸，??流量控制、擁塞控制等服務，其首部自然會比較復雜，首部中的字段比較多，??首部長度也比較長

內(nèi)容小結如下：

TCP的流量控制

這里我們介紹TCP的流量控制：

• 一般來說我們總是希望數(shù)據(jù)傳輸?shù)母煲恍?/li>
• 但如果發(fā)送方把數(shù)據(jù)發(fā)送的過快，接收方就可能來不及接收，這就會造成數(shù)據(jù)的丟失
• 所謂流量控制就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來得及接收
• 利用滑動窗口機制，可以很方便的在TCP連接上實現(xiàn)對發(fā)送方的流量控制

我們來舉例說明，假設主機A和B是因特網(wǎng)上的兩臺主機，它們之間已經(jīng)建立了TCP連接，A給B發(fā)送數(shù)據(jù)，B對A進行流量控制，這是主機A中帶發(fā)送數(shù)據(jù)的字節(jié)序號，假設主機A發(fā)送的每個TCP報文段可攜帶100字節(jié)數(shù)據(jù)，因此圖中每個小格子表示100個字節(jié)數(shù)據(jù)的序號，在主機A和B建立TCP連接時，B告訴A我的接收窗口為400，因此主機A將自己的發(fā)送窗口也設置為400，這意味著主機A在未收到主機B發(fā)來的確認時，可將序號落入發(fā)送窗口中的全部數(shù)據(jù)發(fā)送出去。

接下來我們舉例說明主機B對A的流量控制：

• 主機A將發(fā)送窗口內(nèi)序號1~ 100的數(shù)據(jù)，封中成一個TCP報文段發(fā)送出去，發(fā)送窗口內(nèi)還有300字節(jié)可以發(fā)送。
  • 這里的seq是TCP報文段首部中的序號字段，取值1，表示TCP報文段數(shù)據(jù)載荷的第一個字節(jié)的序號是1，這里的DATA表示這是TCP數(shù)據(jù)報文段
• 主機A將發(fā)送窗口內(nèi)序號101~ 200的數(shù)據(jù)，封中成一個TCP報文段發(fā)送出去，發(fā)送窗口內(nèi)還有200字節(jié)可以發(fā)送
• 主機A將發(fā)送窗口內(nèi)，序號201~300的數(shù)據(jù)，封中成一個TCP報文段發(fā)送出去，但該報文段在傳輸過程中丟失了，主機A發(fā)送窗口內(nèi)還有100字節(jié)可以發(fā)送。
• 主機B對主機A所發(fā)送的201號以前的數(shù)據(jù)進行累計確認，并在該累計確認中將窗口字段的值調(diào)整為300，也就是對主機A進行流量控制。
  • 這里的大寫ACK是TCP報文段首部中的標志位，取值1，表示這是一個TCP確認報文段，小寫ack是TCP報文段首部中的確認號字段，取值201，表示序號201之前的數(shù)據(jù)已全部正確接收，現(xiàn)在希望收到序號201及其后續(xù)數(shù)據(jù)。RWND是TCP報文段首部中的窗口字段，取值300，表示自己的接收窗口大小為300。
• 主機A收到該累計確認后，將發(fā)送窗口向前滑動，使已發(fā)送并收到確認的這些數(shù)據(jù)的序號，移出發(fā)送窗口。

• 由于主機B在該累計確認中，將自己的接收窗口調(diào)整為了300，因此主機A相應的將自己的發(fā)送窗口調(diào)整為300。目前主機A發(fā)送窗口內(nèi)的序號為201~ 500，也就是主機A還可以發(fā)送這300字節(jié)，其中201~ 300號字節(jié)是已發(fā)送的數(shù)據(jù)，若重傳計時器超時，他們會被重傳。301號到400號字節(jié)，以及401號到500號字節(jié)還未被發(fā)送，可被分別封中在一個TCP報文段中發(fā)送。主機A現(xiàn)在可將發(fā)送緩存中序號1~200的字節(jié)數(shù)據(jù)全部刪除了，因為已經(jīng)收到了主機B對他們的累計確認。

• 主機A將發(fā)送窗口內(nèi)序號301~ 400個數(shù)據(jù)，封中成一個TCP報文段發(fā)送出去，發(fā)送窗口內(nèi)還有100字節(jié)可以發(fā)送

• 主機A將發(fā)送窗口內(nèi)序號401~500的數(shù)據(jù)，封中成一個TCP報文段發(fā)送出去，至此序號落在發(fā)送窗口內(nèi)的數(shù)據(jù)已經(jīng)全部發(fā)送出去了，不能再發(fā)送新數(shù)據(jù)了。

• 現(xiàn)在發(fā)送窗口內(nèi)序號201~300，這100個字節(jié)數(shù)據(jù)的重傳計時器超時了，主機A將它們重新封中成一個TCP報文段發(fā)送出去，暫時不能發(fā)送其他數(shù)據(jù)。

• 主機B收到該重傳的TCP報文段后，對主機A所發(fā)送的501號以前的數(shù)據(jù)進行累計確認，并在該累計確認中將窗口字段的值調(diào)整為100。這是主機B對主機A進行的第二次流量控制。
  

• 主機A收到該累計確認后，將發(fā)送窗口向前滑動，使已發(fā)送并收到確認的這些數(shù)據(jù)的序號移出發(fā)送窗口。由于主機B在該累計確認中將自己的接收窗口調(diào)整為了100，因此主機A相應的將自己的發(fā)送窗口調(diào)整為100。目前主機A發(fā)動窗口內(nèi)的序號為501~ 600，也就是主機A還可以發(fā)送這100字節(jié)，主機A現(xiàn)在可將發(fā)送緩存中序號201~ 500的字節(jié)數(shù)據(jù)全部刪除了，因為已經(jīng)收到了主機B對他們的累積確認

• 主機A將發(fā)送窗口內(nèi)序號501~600的數(shù)據(jù)，封中成一個TCP報文段發(fā)送出去，至此序號落在發(fā)送窗口內(nèi)的數(shù)據(jù)已經(jīng)全部發(fā)送出去了，不能再發(fā)送新數(shù)據(jù)了。主機B對主機A所發(fā)送的601號以前的數(shù)據(jù)進行累計確認，并在該領域確認中將窗口字段的值調(diào)整為0。這是主機B對主機A進行的第三次流量控制。
  

• 主機A收到該累計確認后，將發(fā)送窗口向前滑動，使已發(fā)送并收到確認的這些數(shù)據(jù)的序號，移出發(fā)送窗口。由于主機B在該累計確認中將自己的接收窗口調(diào)整為了0，因此主機A相應的將自己的發(fā)送窗口調(diào)整為0。

• 目前主機A不能再發(fā)送一般的TCP報文段了，主機A現(xiàn)在可將發(fā)送緩存中序號501~600的字節(jié)數(shù)據(jù)全部刪除了，因為已經(jīng)收到了主機B對他們的累計確認

• 假設主機B向主機A發(fā)送了0窗口的報文段后不久，主機B的接收緩存又有了一些存儲空間，于是主機B向主機A發(fā)送了接收窗口等于300的報文段，然而這個報文段在傳輸過程中丟失了，主機A一直等待主機B發(fā)送的非0窗口的通知，而主機B也一直等待主機A發(fā)送的數(shù)據(jù)，如果不采取措施，這種互相等待而形成的死鎖局面將一直持續(xù)下去。

• 為了解決這個問題，TCP為每一個連接設有一個持續(xù)計時器，只要TCP連接的一方，收到對方的0窗口通知，就要啟動持續(xù)計時器。若持續(xù)計時器超時，就要發(fā)送一個0窗口探測報文，僅攜帶一字節(jié)的數(shù)據(jù)，而對方在確認這個探測報文段時，給出自己現(xiàn)在的接收窗口值。如果接收窗口仍然是0，那么收到報文段的一方要重新啟動持續(xù)計時器，如果接收窗口不是0，那么死鎖的局面就可以被打破了。
  

在本例中，主機A收到零窗口通知時，就要啟動一個持續(xù)計時器，當持續(xù)計時器超時，主機A立刻發(fā)送一個僅攜帶一字節(jié)數(shù)據(jù)的零窗口探測保溫段，假設主機B此時的接收窗口又為0了，主機B就在確認零窗口探測報文段時，給出自己現(xiàn)在的接收窗口值為零。主機A再次收到零窗口通知，就要再次啟動一個持續(xù)計時器，當持續(xù)計時器超時，主機A立刻發(fā)送一個零窗口探測報文段，假設主機B此時的接收緩存又有了一些存儲空間，于是將自己的接收窗口調(diào)整為了300，主機B就在確認零窗口探測報文段時，給出自己現(xiàn)在的接收窗口值為300，這樣就打破了死鎖的局面。

同學們可能會有這樣的疑問，主機A所發(fā)送的零窗口探測報文段到達主機B時，如果主機B此時的接收窗口仍然為0，那么主機B根本就無法接受該報文段，又怎么會針對該報文段給主機A發(fā)回確認呢？實際上TCP規(guī)定即使接收窗口為0，也必須接受零窗口探測報文段，確認報文段，以及攜帶有緊急數(shù)據(jù)的報文段。

請大家再來思考一下這個問題。如果零窗口探測報文段丟失了，會出現(xiàn)怎樣的問題呢？還能否打破死鎖的局面呢？回答是肯定的，因為零窗口探測報文段也有重傳計時器，當重傳計時器超時后，零窗口探測報文段會被重傳。

內(nèi)容小結如下：

TCP的擁塞控制

首先來看擁塞控制的基本概念：

我們使用上圖來說明擁塞控制的作用：

• 橫坐標是輸入負載，代表單位時間內(nèi)輸入給網(wǎng)絡的分組數(shù)量，縱坐標是吞吐量，代表單位時間內(nèi)從網(wǎng)絡輸出的分組數(shù)量，具有理想擁塞控制的網(wǎng)絡，在吞吐量達到飽和之前，網(wǎng)絡吞吐量應等于所輸入的負載，故吞吐量曲線是45度的斜線，但當輸入負載超過某一限度時，由于網(wǎng)絡資源受限，吞吐量就不再增長，而保持水平線，也就是吞吐量達到飽和，這就表明輸入的負載中有一部分損失掉了。例如輸入到網(wǎng)絡中的某些分組，被某個節(jié)點丟棄了。雖然如此，在這種理想的擁塞控制作用下，網(wǎng)絡的吞吐量仍然維持在其所能達到的最大值。
• 然而實際的網(wǎng)絡情況就很不同了。我們再來看這條吞吐量曲線，隨著輸入負載的增大，網(wǎng)絡吞吐量的增長率逐漸減小，也就是在網(wǎng)絡吞吐量還未達到飽和時，就已經(jīng)有一部分的輸入分組被丟棄了。當網(wǎng)絡的吞吐量明顯的小于理想的吞吐量時，網(wǎng)絡就進入了輕度擁塞的狀態(tài)。
• 更值得注意的是，當輸入負載到達某一數(shù)值時，網(wǎng)絡的吞吐量反而隨輸入負載的增大而減小，這時網(wǎng)絡就要進入了擁塞狀態(tài)，當輸入負載繼續(xù)增大到某一數(shù)值時，網(wǎng)絡的吞吐量就要減小為零，此時網(wǎng)絡就要無法工作了，這就是所謂的死鎖。因此進行擁塞控制是非常有必要的。實際的擁塞控制曲線應該盡量接近理想的擁塞控制曲線。

接下來我們介紹TCP的4種擁塞控制算法，他們分別是：

• 慢開始
• 擁塞避免
• 快重傳
• 快恢復

我們來舉例說明TCP這4種擁塞控制算法的基本原理，為了集中精力討論擁塞控制，我們假定如下條件：

• 一數(shù)據(jù)是單方向傳送的，而另一個方向只傳送確認。
• 二接收方總是有足夠大的緩存空間，因而發(fā)送方發(fā)送窗口的大小僅由網(wǎng)絡的擁塞程度來決定。
• 三以TCP最大報文段MSS的個數(shù)為討論問題的單位，而不是以字節(jié)為單位。

假設這是TCP的發(fā)送方和接收方，發(fā)送方給接收方發(fā)送TCP數(shù)據(jù)報文段，接收方收到后給發(fā)送方發(fā)送TCP確認報文段：

我們前面說過送方發(fā)送窗口的大小僅由網(wǎng)絡的擁塞程度來決定，所以這里發(fā)送窗口的大小和擁塞窗口一樣的大，正常情況下并不一定是這樣的。

---

首先來看慢開始算法，為了更清楚的顯示出擁塞控制過程，我們還可以繪制這樣一幅擁塞窗口隨傳輸輪次變化的圖，橫坐標為傳輸輪次，傳輸輪次是指發(fā)送方給接收方發(fā)送數(shù)據(jù)報文段后，接收方給發(fā)送方發(fā)回相應的確認報文段。一個傳輸輪次所經(jīng)歷的時間，其實就是往返時間。請注意往返時間并非是恒定的數(shù)值，使用傳輸輪次是為了強調(diào)把擁塞窗口所允許發(fā)送的報文段都連續(xù)發(fā)送出去，并收到了對已發(fā)送的最后一個報文段的確認。

縱坐標是擁塞窗口，它會隨網(wǎng)絡擁塞程度以及所使用的擁塞控制算法動態(tài)變化。

• 在TCP雙方建立邏輯連接關系時，擁塞窗口的值被設置為1，我們在圖上標出傳輸輪次0時的擁塞窗口值為1，另外還需設置慢開始門限的初始值，本例采用16，我們也將它在圖中標出，在執(zhí)行慢開始算法時，發(fā)送方每收到一個對新報文段的確認時，就把擁塞窗口值加1，然后開始下一輪的傳輸，當擁塞窗口值增長到慢開始門限值時，就要改為執(zhí)行擁塞避免算法。

  

• 由于發(fā)送方當前的擁塞窗口值是1，而發(fā)送窗口值等于擁塞窗口值，因此發(fā)送方當前只能發(fā)送1個TCP數(shù)據(jù)報文段，換句話說，擁塞窗口值是幾，就能發(fā)送幾個數(shù)據(jù)報文段，如圖所示發(fā)送方發(fā)送0號數(shù)據(jù)報文段，接收方收到后給發(fā)送方發(fā)回對0號報文段的確認報文段，
  

• 發(fā)送方收到該確認報文段后，將擁塞窗口值加1增大到2，我們在圖中標出該值，這意味著發(fā)送方現(xiàn)在可以發(fā)送1~ 2號共兩個數(shù)據(jù)報文段，接收方收到后給發(fā)送方發(fā)回對1~2號報文段的確認報文段，

  

• 發(fā)送方收到后將擁塞窗口值加2增大到4。我們在圖中標出該值，發(fā)送方現(xiàn)在可以發(fā)送3~ 6號共4個數(shù)據(jù)報文段，接收方收到后給發(fā)送方發(fā)回，對3~6號報文段的確認報文段，發(fā)送方收到后將擁塞窗口值加四增大到8
  

• 我們在圖中標出該值發(fā)送方現(xiàn)在可以發(fā)送7~14號，共8個數(shù)據(jù)報文段，接收方收到后給發(fā)送方發(fā)回，對7 ~ 14號報文段的確認報文段，發(fā)送方收到后將擁塞窗口值加8增大到16，我們在圖中標出該值，發(fā)送方當前的擁塞窗口值已經(jīng)增大到了慢開始門限值之后，我們要改用擁塞避免算法，也就是每個傳輸輪次結束后，擁塞窗口值只能線性加一，而不像慢開始算法那樣，每個傳輸輪次結束后，擁塞窗口值按指數(shù)規(guī)律增長
  

• 發(fā)送方現(xiàn)在可以發(fā)送15 ~ 30號，共16個數(shù)據(jù)報文段，接收方收到后給發(fā)送方發(fā)回，對15 ~ 30號報文段的確認報文段，發(fā)送方收到后將擁塞窗口值加一增大到17。我們在圖中標出該值現(xiàn)在可以發(fā)送31~47號，共17個數(shù)據(jù)報文段，接收方收到后給發(fā)送方發(fā)回，對31 ~47號報文段的確認報文段，發(fā)送方收到后將擁塞窗口值加一增大到18。我們在圖中標出該值
  

• 隨著傳輸輪次的增加，擁塞窗口值每輪次都線性加一，例如當前擁塞穿口值增加到了24，發(fā)送方現(xiàn)在可以發(fā)送171~194號，共24個數(shù)據(jù)報文段。假設這24個數(shù)據(jù)報文段在傳輸過程中丟失了幾個，這必然會造成發(fā)送方對這些丟失報文段的超時重傳。發(fā)送方以此判斷網(wǎng)絡很可能出現(xiàn)了擁塞，需要進行以下工作。

  • 1.將慢開始門限值更新為發(fā)生擁塞時擁塞窗口值的一半，網(wǎng)絡發(fā)生擁塞時的擁塞窗口值是24，因此更新慢開始門限值為該值的一半，即12
    
  • 2.將擁塞窗口值減小為1，并重新開始執(zhí)行慢開始算法，如圖所示，當慢開始執(zhí)行到擁塞窗口值增大到新的慢開始門限值時，就要停止使用慢開始算法，轉而執(zhí)行擁塞避免算法。
    

通過本例可以看出，我們可以總結出：

• TCP發(fā)送方一開始使用慢開始算法，讓擁塞窗口值從一開始按指數(shù)規(guī)律增大
• 當擁塞窗口值增大到慢開始門限值時停止使用慢開始算法，轉而執(zhí)行擁塞避免算法，讓擁塞窗口值按線性加1的規(guī)律增大
• 當發(fā)生超時重傳時，就要判斷網(wǎng)絡很可能出現(xiàn)了擁塞，采取相應的措施，一方面將慢開始門限值更新為發(fā)生擁塞時擁塞窗口值的一半，另一方面將擁塞窗口值減小為一，并重新開始執(zhí)行慢開始算法。
• 擁塞窗口值又從一開始按指數(shù)規(guī)律增大，當增大到了新的慢開始門限值時，停止使用慢開始算法，轉而執(zhí)行用在避免算法，讓擁塞窗口值按線性加1的規(guī)律增大。

需要注意的是：

• 慢開始是指一開始向網(wǎng)絡注入的報文段少，而并不是指擁塞窗口值增長速度慢，
• 擁塞避免，也并非指完全能夠避免營塞。而是只在擁塞避免階段將擁塞窗口值控制為按線性規(guī)律增長，使網(wǎng)絡比較不容易出現(xiàn)擁塞

---

慢開始和擁塞避免是1988年就提出的TCP擁塞控制算法，也就是TCP的Tahoe版本，1990年又增加了兩個新的擁塞控制算法，以便改進TCP的性能，這就是快重傳和快恢復，被稱為TCP的Reno版本。有時個別報文段會在網(wǎng)絡中丟失，但實際上網(wǎng)絡并未發(fā)生擁塞，這將導致發(fā)送方超時重傳，并誤認為網(wǎng)絡發(fā)生了擁塞。

例如在之前的例子中，當擁塞窗口值增大到24時，發(fā)生了超時重傳，而網(wǎng)絡此時并沒有發(fā)生擁塞，但是發(fā)送方卻誤認為網(wǎng)絡發(fā)生了擁塞，于是發(fā)送方把擁塞窗口值減小為1并錯誤的啟動慢開始算法，因而降低了傳輸效率。

采用快重傳算法，可以讓發(fā)送方盡早知道發(fā)生了個別報文段的丟失。所謂快重傳是發(fā)送方盡快進行重傳，而不是等超時重傳計時器超時再重傳

• 這就要求接收方不要等待自己發(fā)送數(shù)據(jù)時才進行捎帶確認，而是要立即發(fā)送確認，
• 即使收到了失序的報文段，也要立即發(fā)送，對已收到的報文段的重復確認，
• 發(fā)送方一旦收到三個連續(xù)的重復確認，就將相應的報文段立即重傳，而不是等該報文段的重傳計時器超時再重傳

我們來舉例說明快重傳算法：

• 發(fā)送方發(fā)送1號數(shù)據(jù)報文段，接收方收到后給發(fā)送方發(fā)回，對1號報文段的確認，在該確認報文段到達發(fā)送方之前，發(fā)送方還可以將發(fā)送窗口內(nèi)的2號數(shù)據(jù)報文段發(fā)送出去，
• 接收方收到后給發(fā)送方發(fā)回對2號報文段的確認。
• 在該確認報文段到達發(fā)送方之前，發(fā)送方還可以將發(fā)送窗口內(nèi)的3號數(shù)據(jù)報文段發(fā)送出去，但該報文段丟失了，接收方自然不會給發(fā)送方發(fā)回針對該報文段的確認，
• 發(fā)送方還可以將發(fā)送窗口內(nèi)的4號數(shù)據(jù)報文段發(fā)送出去，接收方收到后，發(fā)現(xiàn)這不是按序到達的報文段，因此給發(fā)送方發(fā)回，針對2號報文段的重復確認，表明我現(xiàn)在希望收到的是三號報文段，但是我沒有收到三號報文段，而是收到了未按序到達的報文段，
• 發(fā)送方還可以將發(fā)送窗口內(nèi)的5號數(shù)據(jù)報文段發(fā)送出去，接收方收到后發(fā)現(xiàn)這不是按序到達的報文段，因此給發(fā)送方發(fā)回針對2號報文段的重復確認，
• 發(fā)送方還可以將發(fā)送窗口內(nèi)的6號數(shù)據(jù)報文段發(fā)送出去，接收方收到后發(fā)現(xiàn)這不是按需到達的報文段，因此給發(fā)送方發(fā)回針對2號報文段的重復確認，至- 此發(fā)送方會收到三個連續(xù)的對二號報文段的重復確認，就要立即重傳三號報文段，
• 接收方收到后給發(fā)送方發(fā)回針對6號報文段的確認，表明序號到六為止的報文段都正確接收了，這樣就不會造成對三號報文段的超時重傳，而是提早進行了重傳。
• 對于個別丟失的報文段，發(fā)送方不會出現(xiàn)超時重傳，也就不會誤認為出現(xiàn)了擁塞，而錯誤的降低擁塞窗口值為最小值一，使用快重傳可以使整個網(wǎng)絡的吞吐量提高約20%

---

再來看快恢復算法，發(fā)送方一旦收到三個重復確認，就知道現(xiàn)在只是丟失了個別的報文段，于是不啟動慢開始算法，而是執(zhí)行快恢復算法，

發(fā)送方將慢開始門限值和擁塞窗口值調(diào)整為當前窗口值的一半，開始執(zhí)行擁塞避免算法，

也有的快恢復實現(xiàn)，是把快恢復開始時的擁塞窗口值再增大一些，也就是等于新的慢開始門限值加三。這樣做的理由是；

• 既然發(fā)送方收到三個重復的確認，就要表明有三個數(shù)據(jù)報文段已經(jīng)離開了網(wǎng)絡，
• 這三個報文段不再消耗網(wǎng)絡資源，而是停留在接收方的接收緩存中。
• 可見現(xiàn)在網(wǎng)絡中不是堆積的報文段，而是減少了三個報文段，因此可以適當把用塞窗口值擴大一些。

接下來我們給出TCP擁塞窗口值，在擁塞控制時的變化情況舉例，里面包含了TCP擁塞控制的4種算法：

• TCP發(fā)送方一開始使用慢開始算法，讓擁塞窗口值從一開始按指數(shù)規(guī)律增大，當增大到慢開始門線初始值時，停止使用慢開始算法，轉而執(zhí)行擁塞避免算法，讓擁塞窗口值按線性加1的規(guī)律增大。

• 當發(fā)生超時重傳時，就要判斷網(wǎng)絡可能出現(xiàn)了擁塞，采取相應的措施，一方面將慢開始門限值，更新為發(fā)生擁塞時擁塞窗口值的一半，另一方面將擁塞窗口值減小為一，并重新開始執(zhí)行慢開始算法。

• 擁塞窗口值又從一開始按指數(shù)規(guī)律增大，當增大到了新的慢開始門限值時，停止使用慢開始算法，轉而執(zhí)行擁塞避免算法，讓擁塞窗口值按線性加1的規(guī)律增大。

• 當發(fā)送方收到三個重復的確認時，就要進行快重傳和快恢復，也就是更新慢開始門限值為當前擁塞窗口值的一半，并將擁塞窗口值也取為新的慢開始門限值，轉而執(zhí)行擁塞避免算法，讓擁塞窗口值按線性加1的規(guī)律增大。

TCP超時重傳時間的選擇

超時重傳時間的選擇是TCP最復雜的問題之一。我們來舉例說明，假設主機A和B是因特網(wǎng)上的兩臺主機，他們之間已經(jīng)建立了TCP連接，縱坐標為時間，現(xiàn)在主機A給主機B發(fā)送TCP數(shù)據(jù)報文段0，并記錄下當前的時間。主機B收到后給主機A發(fā)送相應的確認報文段。主機A收到確認報文段后，記錄下當前的時間，那么主機A記錄下的這兩個時間，它們的差值，就是報文段的往返時間RTT由于這是第0個報文段的RTT，我們就用RTT0來表示。試想一下，如果我們將超時重穿時間，RTO的值設置的比RTT0的值小，會出現(xiàn)怎樣的情況？很顯然這會引起報文段不必要的重傳，使網(wǎng)絡負荷增大。

那么如果將超時重傳時間，RTO的值設置的遠大于RTT0的值，又會出現(xiàn)怎樣的情況？很顯然這會使重傳推遲的時間太長，使網(wǎng)絡的空閑時間增大，降低了傳輸效率。

綜合上述兩種情況，我們可以得出這樣的結論，超時重傳時間RTO的值應該設置為略大于報文段往返時間RTT的值。至此同學們可能會覺得超時重傳時間的選擇也并不是很復雜，然而 TCP下層是復雜的互聯(lián)網(wǎng)環(huán)境，主機A所發(fā)送的報文段可能只經(jīng)過一個高速率的局域網(wǎng)，也有可能經(jīng)過多個低速率的網(wǎng)絡，并且每個IP數(shù)據(jù)報的轉發(fā)路由還可能不同。

例如現(xiàn)在主機A給主機B發(fā)送TCP數(shù)據(jù)報文段一，主機B收到后，給主機A發(fā)送相應的確認報文段，主機A這次測得的報文段往返時間RTT一如圖所示，顯然RTT1遠大于RTT0，如果超時重裝時間RTO還是我們之前所確定的略大于RTT0的話，這對于數(shù)據(jù)報文段1是不合適的，會造成該報文段不必要的重傳。

這樣看來超時重傳時間的選擇確實不那么簡單了，我們不能直接使用某次測量得到的RTT樣本來計算超時重裝時間RTO，但是我們可以利用每次測量得到的RTT樣本，計算加權平均往返時間RTTS，這樣可以得到比較平滑的往返時間。當測量到第一個RTT樣本時，RTTS的值直接取為第一個RTT樣本的值，以后每測量到一個RTT樣本時，都按該公式來計算新的RTT S值。

在上式中阿爾法的取值大于等于0，且小于一，若阿爾法很接近于零，則新RTT樣本對RTTS的影響不大，若阿爾法很接近于一則新RTT樣本，對RTTS的影響較大，已成為建議標準的RFC6298，推薦的阿爾法值為1/8，即0.125，用這種方法得出的加權平均往返時間RTTS的值就要比測量出的RTT的值更加平滑。
顯然超時重穿時間，RTO的值應略大于加權平均往返時間RTTS的值。

下面我們給出RFC6298建議使用的超時重傳時間RTO的計算公式，該公式中的RTTS是加權平均往返時間，我們剛剛介紹過它的計算方法，RTTD是RTT偏差的加權平均，計算方法如下，當測量到第一個RTT樣本時，RTTD的值取為該樣本值的一半，以后每測量到一個RTT樣本時，都按該公式來計算新的RTTD的值。在上式中貝塔的取值大于等于0且小于1，已成為建議標準的RFC6298推薦的貝塔值為1/4，即0.25。我們可以發(fā)現(xiàn)不管是RTTS還是RTTD都是基于所測量到的RTT樣本進行計算的。如果所測量到的RTT樣本不正確，那么所計算出的RTTS和RTTD自然就要不正確，進而所計算出的超時重穿時間RTO也就不正確。

然而往返時間RTT的測量確實是比較復雜的。我們來舉例說明，主機A給主機B發(fā)送TCP數(shù)據(jù)報文段，但該報文段在傳輸過程中丟失了，當超時重傳計時器超時后，主機A就重傳該報文段，主機B收到后給主機A發(fā)送確認報文段。現(xiàn)在問題來了，主機A收到該確認報文段后，無法判斷該報文段是對原報文段的確認，還是對重傳報文段的確認。該報文段實際上是對重傳報文段的確認，也就是說正確的RTT應該是這一段時間。但是如果主機A誤將該確認當做是對原報文段的確認，也就是誤認為這段時間是RTT則所計算出的RTTS和RTO就會偏大，降低了傳輸效率。

再來看另一種情況，主機A給主機B發(fā)送TCP數(shù)據(jù)報文段，主機B收到后給主機A發(fā)送確認報文段，由于某種原因，該確認報文段沒有在正常時間內(nèi)到達主機A這必然會導致主機A對之前所發(fā)送的數(shù)據(jù)報文段的超時重傳。現(xiàn)在問題又來了，主機A收到遲到的確認報文段后，無法判斷該報文段是對原報文段的確認，還是對重傳報文段的確認。該報文段實際上是對原報文段的確認，也就是說正確的RTT應該是這一段時間。但是如果主機A誤將該確認當做是對重傳報文段的確認，也就是誤認為這段時間是RTT，則所計算出的RTTS和RTO就會偏小，這會導致報文段沒有必要的重傳，增大網(wǎng)絡負荷。

?
通過這兩個例子可以看出，當發(fā)送方出現(xiàn)超時重傳后，收到確認報文段時，是無法判斷出該確認到底是對原報文段的確認，還是對重傳報文段的確認，也就是無法準確測量出RTT，進而無法正確計算超時重傳時間RTO。因此針對出現(xiàn)超時重傳時，無法測準往返時間RTT的問題，Karn提出了一個算法，在計算加權平均往返時間RTTS時，只要報文段重傳了，就要不采用其往返時間RTT樣本，也就是出現(xiàn)重傳時，不重新計算RTTS，進而超時重傳時間RTO也不會重新計算。然而這要引起了新的問題，設想出現(xiàn)這樣的情況，報文段的時延突然增大了很多，并且之后很長一段時間內(nèi)都會保持這種時延，因此在原來得出的重傳時間內(nèi)，不會收到確認報文段，于是就重傳報文段。根據(jù)Karn算法，不考慮重傳的報文段的往返時間樣本，這樣超時重傳時間就要無法更新，這會導致報文段反復被重傳。因此要對Karn算法進行修正，方法是報文段每重傳一次，就把超時重傳時間RTO增大一些，典型的做法是將新RTO的值取為舊RTO值的兩倍。

接下來我們舉例說明，TCP超時重傳時間的計算，這是測量得到的第一個RTT樣本RTT1。根據(jù)RTTS1的計算公式可知RTTS1的值.根據(jù)RTTDE的計算公式，可知RTTD1的值在根據(jù)IPO的計算公式可計算出RTO1的值，這是測量得到的第二個RTT2，根據(jù)RTTS2的計算公式和阿爾法的值和寫出計算RTTS2的表達式，將之前計算出的RTTS1的值和本次測量得到的RTT2的值代入干涉，可計算出RTTS2的值。根據(jù)RTTD的計算公式和貝塔的值，可寫出計算RTTD2的表達式，將之前計算出的RTTD1，RTTS,1以及本次測量得到的RTT2的值，代入該式，可計算出RTTD2的值。再根據(jù)RTO的計算公式，可計算出RTO2的值。假設這是測量得到的第3個和第4個RTT樣本。計算一下RTO3和RTO4的值分別是多少？答案如圖所示，相信大家都能正確解答。假設這是測量得到的第5個RTT樣本，但是根據(jù)RTO4的值可知，在收到確認之前就會產(chǎn)生超時重傳。我們之前介紹過，若出現(xiàn)超時重傳，則不采用上述公式計算RTO，而是將新RTO的值取為舊RTO值的兩倍。因此RTO5的值取為兩倍的RTO4的值。

內(nèi)容小結如下：

TCP可靠傳輸?shù)膶崿F(xiàn)

TCP基于以字節(jié)為單位的滑動窗口來實現(xiàn)可靠傳輸

我們來舉例說明，這是因特網(wǎng)上的兩臺主機，他們之間已經(jīng)建立了一個TCP連接，為了簡單起見，我們假定數(shù)據(jù)傳輸只在一個方向進行，換句話說，發(fā)送方給接收方發(fā)送TCP數(shù)據(jù)報文段，接收方給發(fā)送方發(fā)送相應的TCP確認報文段，這樣的好處是使討論僅限于兩個窗口，也就是發(fā)送方的發(fā)送窗口和接收方的接收窗口。TCP的滑動窗口是以字節(jié)為單位的。

• 現(xiàn)在假設發(fā)送方收到了一個來自接收方的確認報文段，在報文段首部中的窗口字段的值為20，也就是接收方表明自己的接收窗口的尺寸為20字節(jié)，確認號字段的值為31，這表明接收方希望收到下一個數(shù)據(jù)的序號是31，而序號30為止的數(shù)據(jù)已經(jīng)全部正確接收了。
  

• 因此發(fā)送方根據(jù)這兩個字段的值，構造出自己的發(fā)送窗口。為了簡單起見，我們假定網(wǎng)絡不存在擁塞問題，也就是發(fā)送方在構造自己的發(fā)送窗口時，僅考慮接收方的接收窗口，而不考慮擁塞窗口。由于本例中接收方告訴發(fā)送方自己的接收窗口尺寸為20，因此發(fā)送方將自己的發(fā)送窗口尺寸也設置為20，發(fā)送方在沒有收到接收方確認的情況下，可以把發(fā)送窗口內(nèi)的數(shù)據(jù)依次全部發(fā)送出去，凡是已經(jīng)發(fā)送過的數(shù)據(jù)，在未收到確認之前都必須暫時保留，以便在超時重傳時使用。
  

• 發(fā)送窗口后沿的后面部分是已發(fā)送并已收到確認的數(shù)據(jù)字節(jié)的序號，這些數(shù)據(jù)字節(jié)顯然不需要再保存在發(fā)送緩存中了，可以將它們刪除。發(fā)送窗口前沿的前面部分是當前不允許發(fā)送的數(shù)據(jù)字節(jié)的序號。
  

• 然后我們說說發(fā)送窗口前沿的移動情況和后延的移動情況。
  

• 其中發(fā)送窗口的前沿還可能向后收縮，這發(fā)生在接收方通知的窗口變小了，但TCP標準強烈不贊成這樣做，因為很可能發(fā)送方在收到這個通知之前，就已經(jīng)發(fā)送了窗口中的許多數(shù)據(jù)，現(xiàn)在又要收縮窗口，不讓發(fā)送這些數(shù)據(jù)，顯然就會產(chǎn)生錯誤。

• 現(xiàn)在假定發(fā)送方將發(fā)送窗口內(nèi)序號31~ 41的數(shù)據(jù)，封裝在幾個不同的報文段中發(fā)送出去，此時發(fā)送窗口的位置并沒有改變，發(fā)送窗口內(nèi)序號31~41的數(shù)據(jù)已經(jīng)發(fā)送，但未收到確認，而序號42 ~50的數(shù)據(jù)是允許發(fā)送，但還未發(fā)送的。請同學們思考一下，我們?nèi)绾蚊枋霭l(fā)送窗口的狀態(tài)，換句話說，如果我們要編程實現(xiàn)滑動窗口機制，那么對于發(fā)送窗口的狀態(tài)，應該如何標記和維護呢？如圖所示可以使用三個指針，P1、P2、P3分別指向相應的字節(jié)序號，這樣小于P1的，就是已發(fā)送并已收到確認的部分，大于等于P3的是不允許發(fā)送的部分。
  

• 我們再來看看接收方的接收窗口，它的尺寸為20，在接收窗口外面到30號為止的數(shù)據(jù)是已經(jīng)發(fā)送過相應確認，并已交付給應用進程的數(shù)據(jù)，因此無需再保留這些數(shù)據(jù)，可將他們從接收緩存中刪除了。接收窗口內(nèi)31~ 50號數(shù)據(jù)是允許接收的數(shù)據(jù)，接收窗口外51號及其后續(xù)數(shù)據(jù)目前不允許接收。假設發(fā)送方之前發(fā)送的封裝有32和33號數(shù)據(jù)的報文段到達了接收方，由于數(shù)據(jù)序號落在接收窗口內(nèi)，所以接收方接受他們，并將他們存入接收緩存，但是他們是未按序到達的數(shù)據(jù)，因為31號數(shù)據(jù)還沒有到達，這有可能是丟了，也有可能是滯留在網(wǎng)絡中的某處。請注意接收方只能對按序收到的數(shù)據(jù)中的最高序號給出確認，因此接收方發(fā)出的確認報文段中的確認序號仍然是31，也就是希望收到31號數(shù)據(jù)，窗口字段的值仍是20，表明接收方?jīng)]有改變自己接收窗口的大小
  

• 發(fā)送方收到該確認報文段后，發(fā)現(xiàn)這是一個針對31號數(shù)據(jù)的重復確認，就知道接收方收到了未按序到達的數(shù)據(jù)，由于這是針對31號數(shù)據(jù)的第一個重復確認因此，這并不會引起發(fā)送方針對該數(shù)據(jù)的快重傳。另外接收方通知的窗口尺寸仍是20，因此發(fā)送方保持自己的發(fā)送窗口尺寸為20，現(xiàn)在假設封裝有31號數(shù)據(jù)的報文段到達了接收方，方接受該報文段，將其封裝的31號數(shù)據(jù)存入接收緩存，接收方現(xiàn)在可將接收到的31~33號數(shù)據(jù)交付給應用進程
  

• 然后將接收窗口向前移動三個序號，并給發(fā)送方發(fā)送確認報文段。該確認報文段中窗口字段的值仍為20，表明接收方?jīng)]有改變自己接收窗口的大小，確認號字段的值為34，這表明接收方已經(jīng)收到了序號33為止的全部數(shù)據(jù)。
  

• 現(xiàn)在假設又有幾個數(shù)據(jù)報文段到達了接收方，他們封裝有37 38以及40號數(shù)據(jù)，這些數(shù)據(jù)的序號雖然落在接收窗口內(nèi)，但他們都是未按需到達的數(shù)據(jù)，只能先暫存在接收緩存中。假設接收方先前發(fā)送的確認報文段到達了發(fā)送方，發(fā)送方接收后，將發(fā)送窗口向前滑動三個序號，發(fā)送窗口的尺寸保持不變，這樣就有新序號51~ 53落入發(fā)送窗口內(nèi)，而序號31~ 33移出了發(fā)送窗口，現(xiàn)在可將31~33號數(shù)據(jù)從發(fā)送緩存中刪除了，因為已經(jīng)收到了接收方針對他們的確認
  

• 發(fā)送方繼續(xù)將發(fā)送窗口內(nèi)，序號42~53的數(shù)據(jù)封裝在幾個不同的報文段中發(fā)送出去，現(xiàn)在發(fā)送窗口內(nèi)的序號已經(jīng)用完了，發(fā)送方在未收到接收方發(fā)來確認的情況下，不能再發(fā)送新的數(shù)據(jù)，序號落在發(fā)送窗口內(nèi)的已發(fā)送數(shù)據(jù)，如果遲遲收不到接收方的確認，則會產(chǎn)生超時重傳。
  

接下來我們還要對TCP可靠傳輸?shù)膶崿F(xiàn)做幾點補充說明：

?內(nèi)容小結如下：

TCP的運輸連接管理

TCP的連接建立(3次握手)

• TCP是面向連接的協(xié)議，它基于運輸連接來傳送TCP報文段，

• TCP運輸連接的建立和釋放是每一次面向連接的通信中必不可少的過程。

• TCP運輸連接有以下三個階段，

  • 第一個階段是建立TCP連接，也就是通過三報文握手來建立TCP連接。
  • 第二個階段是數(shù)據(jù)傳送，也就是基于已建立的TCP連接，進行可靠的數(shù)據(jù)傳輸。
  • 第三個階段是釋放連接，也就是在數(shù)據(jù)傳輸結束后，還要通過四報文揮手來釋放TCP連接，

• TCP的運輸連接管理就是使運輸連接的建立和釋放都能正常的進行。

TCP的連接建立要解決以下三個問題：

• 第一使TCP雙方能夠確知對方的存在
• 第二使TCP雙方能夠協(xié)商一些參數(shù)，例如最大窗口值是否使用窗口擴大選項和時間戳選項以及服務質量等
• 第三使TCP雙方能夠對運輸實體資源，例如緩存大小，連接表中的項目等進行分配

接下來我們就來看看TCP使用三報文握手建立連接的具體過程：

• 這是兩臺要基于TCP進行通信的主機，其中一臺主機中的某個應用進程，主動發(fā)起TCP連接，建立稱為TCP客戶。另一臺主機裝被動等待TCP連接建立的應用進程，稱為TCP服務器。我們可以將TCP建立連接的過程比喻為握手，握手需要在TCP客戶和服務器之間交換三個TCP報文段
  

• 最初兩端的TCP進程都處于關閉狀態(tài)，一開始 TCP服務器進程首先創(chuàng)建傳輸控制塊，用來存儲TCP連接中的一些重要信息，例如 TCP連接表，指向發(fā)送和接收緩存的指針，指向重傳隊列的指針，當前發(fā)送和接收序號等。之后就要準備接受TCP客戶進程的連接請求。此時TCP服務器進程就要進入監(jiān)聽狀態(tài)，等待TCP客戶進程的連接請求。TCP服務器進程是被動等待來自TCP客戶進程的連接請求，而不是主動發(fā)起，因此稱為被動打開連接。
  

• TCP客戶進程也是首先創(chuàng)建傳輸控制塊，然后在打算建立TCP連接時，向TCP服務器進程發(fā)送TCP連接請求報文段，并進入同步已發(fā)送狀態(tài)。TCP連接請求報文段首部中的同步位SYN被設置為1，表明這是一個TCP連接請求報文段，序號字段seq被設置了一個初始值X，作為TCP客戶進程所選擇的初始序號。請注意TCP規(guī)定，SYN被設置為1的報文段，不能攜帶數(shù)據(jù)，但要消耗掉一個序號。由于TCP連接建立是由TCP客戶進程主動發(fā)起的，因此稱為主動打開連接。

  SYN表示synchronization，原意是同步的意思。打開就意味著客戶端想和服務端進行數(shù)據(jù)的同步，在同步以后(也就是三次握手之后)，客戶端和服務端就可以互相發(fā)送消息。
  seq表示sequence，原意為序號。需要這個seq是因為應用程序可能連續(xù)發(fā)送多個序號給服務器，有了seq就可以有依據(jù)判斷哪些是累贅信息，ack搭配seq用于確認數(shù)據(jù)是否準確，是否正常通信。并且這個seq序號是隨機生成的，作為初始值來進行后續(xù)的判斷依據(jù)，保證了通道唯一性

  
  

• TCP服務器進程收到TCP連接請求報文段后。如果同意建立連接，則向TCP客戶進程發(fā)送TCP連接請求確認報文段，并進入同步已接收狀態(tài)。該報文段首部中的同步位SYN和確認位ACK都設置為1，表明這是一個TCP連接請求確認報文段。序號字段seq被設置了一個初始值Y，作為TCP服務器進程所選擇的初始序號，確認號字段ack的值被設置成了X+1，這是對TCP客戶進程所選擇的初始序號的確認。請注意這個報文段也不能攜帶數(shù)據(jù)，因為它是SYN被設置為1的報文段，但同樣要消耗掉一個序號

  ACK表示Acknowledgment，原意為確認。當ACK和SYN一起開啟表示確認同步
  小寫的ack表示的確認序號，也就是說光有自己的序號seq還不夠，還要有確認序號ack，這個ack是根據(jù)客戶端的序號+1得到的，這樣客戶端在收到號碼后-1就知道是不是自己發(fā)送的TCP報文了

  

• TCP客戶進程收到TCP連接請求確認報文段后，還要向TCP服務器進程發(fā)送一個普通的TCP確認報文段，并進入連接已建立狀態(tài)。該報文段首部中的確認位ACK被設置為1，表明這是一個普通的TCP確認報文段，序號字段seq被設置為X+1，這是因為 TCP客戶進程發(fā)送的第一個TCP報文段的序號為X并且不攜帶數(shù)據(jù)，因此第二個報文段的序號為X+1。請注意TCP規(guī)定，普通的TCP確認報文段可以攜帶數(shù)據(jù)，但如果不攜帶數(shù)據(jù)則不消耗序號。在這種情況下，所發(fā)送的下一個數(shù)據(jù)報文段的序號仍是X+1，確認號字段ack被設置為Y+1，這是對TCP服務器進程所選擇的初始序號的確認。
  

• TCP服務器進程收到該確認報文段后也進入連接已建立狀態(tài)。現(xiàn)在TCP雙方都進入了連接已建立狀態(tài)，他們可以基于已建立好的TCP連接進行可靠的數(shù)據(jù)傳輸了。
  

想一想，為什么TCP客戶進程最后還要發(fā)送一個普通的TCP確認報文段，這是否多余？換句話說，能否使用兩報文握手建立連接？

答案是并不多余，不能簡化為兩報文握手

我們來舉例說明，考慮這樣一種情況：

• TCP客戶進程發(fā)出一個TCP連接請求報文段，但該報文段在某些網(wǎng)絡節(jié)點長時間滯留了，這必然會造成該報文段的超時重傳。假設重傳的報文段在TCP服務器進程正常接收，TCP服務器進程給TCP客戶進程發(fā)送一個TCP連接，請求確認報文段，并進入連接已建立狀態(tài)。
  

• 請注意，由于我們改為兩報文握手，因此TCP服務器進程發(fā)送完TCP連接請求確認報文段后進入的是連接已建立狀態(tài)，而不像三報文握手那樣進入同步已接收狀態(tài)，并等待TCP客戶進程發(fā)來針對TCP連接請求確認報文段的普通確認報文段。

• TCP客戶進程收到TCP連接請求確認報文段后，進入TCP連接已建立狀態(tài)，但不會給TCP服務器進程發(fā)送針對該報文段的普通確認報文段，現(xiàn)在 TCP雙方都處于連接已建立狀態(tài)，他們可以相互傳輸數(shù)據(jù)之后可以通過四報文揮手來釋放連接，TCP雙方都進入了關閉狀態(tài)
  

• 一段時間后之前滯留在網(wǎng)絡中的失效的TCP連接請求報文段到達了TCP服務器進程，TCP服務器進程會誤認為這是TCP客戶進程，又發(fā)起了一個新的TCP連接請求，于是給TCP客戶進程發(fā)送TCP連接請求，確認報文段，并進入連接已建立狀態(tài)。該報文段到達TCP客戶進程，由于TCP客戶進程并沒有發(fā)起新的TCP連接請求，并且處于關閉狀態(tài)，因此不會理會該報文段，但TCP服務器進程已進入了連接已建立狀態(tài)，他認為新的TCP連接已建立好了，并一直等待TCP客戶進程發(fā)來數(shù)據(jù)，這將白白浪費TCP服務器進程所在主機的很多資源。

  

內(nèi)容小結如下：

TCP的連接釋放(4次揮手)

TCP通過四報文揮手來釋放連接

我們來舉例說明：

• 數(shù)據(jù)傳輸結束后，TCP通信雙方都可以釋放連接，現(xiàn)在TCP客戶進程和TCP服務器進程都處于連接已建立狀態(tài)。假設使用TCP客戶進程的應用進程，通知其主動關閉TCP連接，TCP客戶進程會發(fā)送TCP連接釋放報文段，并進入終止等待1狀態(tài)。

  • 該報文段首部中的終止位FIN(Finish的縮寫)和確認位ACK的值都被設置為1，表明這是一個TCP連接釋放報文段，同時也對之前收到的報文段進行確認。序號seq字段的值設置為U它等于TCP客戶進程之前已傳送過的數(shù)據(jù)的最后一個字節(jié)的序號加1。
  • 請注意TCP規(guī)定終止為FIN等于1的報文段，即使不攜帶數(shù)據(jù)也要消耗掉1個序號，確認號ack字段的值設置為v，它等于TCP客戶進程之前已收到的數(shù)據(jù)的最后一個字節(jié)的序號加1。
    

• TCP服務器進程收到TCP連接釋放報文段后，會發(fā)送一個普通的TCP確認報文段，并進入關閉等待狀態(tài)

  • 該報文段首部中的確認為ACK的值，被設置為1，表明這是一個普通的TCP確認報文段，序號seq字段的值設置為V，它等于TCP服務器進程之前已傳送過的數(shù)據(jù)的最后一個字節(jié)的序號加1，這也與之前收到的TCP連接釋放報文段中的確認號匹配，確認號ACK字段的值設置為U+1，這是對TCP連接釋放報文段的確認。
    

• TCP服務器進程這時應通知高層應用進程，TCP客戶進程要斷開與自己的TCP連接，此時從TCP客戶進程到TCP服務器進程，這個方向的連接就釋放了，這時的TCP連接屬于半關閉狀態(tài)，也就是TCP客戶進程已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但TCP服務器進程如果還有數(shù)據(jù)要發(fā)送，TCP客戶進程仍要接收，也就是說從TCP服務器進程到TCP客戶進程，這個方向的連接并未關閉，這個狀態(tài)可能會持續(xù)一段時間，TCP客戶進程收到TCP確認報文段后，就進入終止等待2狀態(tài)，等待TCP服務器進程發(fā)出的TCP連接釋放報文段。
  

• 若使用TCP服務器進程的應用進程已經(jīng)沒有數(shù)據(jù)要發(fā)送了，應用進程就要通知其TCP服務器進程釋放連接。由于TCP連接釋放是由TCP客戶進程主動發(fā)起的，因此TCP服務器進程對TCP連接的釋放稱為被動關閉連接，TCP服務器進程發(fā)送TCP連接釋放報文段，并進入最后確認狀態(tài)。

  • 該報文段首部中的終止位FIN和確認位ACK的值，都被設置為1，表明這是一個TCP連接釋放報文段，同時也對之前收到的報文段進行確認。現(xiàn)在假定序號seq字段的值為W，這是因為在半關閉狀態(tài)下，TCP服務器進程可能又發(fā)送了一些數(shù)據(jù)，確認號ACK字段的值為U+1，這是對之前收到的TCP連接釋放報文段的重復確認。
    

• TCP客戶進程收到TCP連接釋放報文段后，必須針對該報文段發(fā)送普通的TCP確認報文段，之后進入時間等待狀態(tài)

  • 該報文段首部中的確認為ACK的值，被設置為1，表明這是一個普通的TCP確認報文段，序號SEQ字段的值設置為U+1，這是因為TCP客戶進程之前發(fā)送的TCP連接釋放報文段，雖然不攜帶數(shù)據(jù)，但要消耗掉一個序號，確認號ACK字段的值設置為W+1，這是對所收到的TCP連接釋放報文段的確認。
    

• TCP服務器進程收到該報文段后就要進入關閉狀態(tài)，而TCP客戶進程還要經(jīng)過兩倍的MSL后才能進入關閉狀態(tài)。MSL的意思是最長報文段壽命，RFC793文檔建議為兩分鐘
  

也就是說 TCP客戶進程進入時間等待狀態(tài)后，還要經(jīng)過4分鐘才能進入關閉狀態(tài)，這完全是從工程上來考慮的。對于現(xiàn)在的網(wǎng)絡MSL取為兩分鐘可能太長了，因此TCP允許不同的實現(xiàn)和根據(jù)具體情況使用更小的MSL值。

---

那么 TCP客戶進程在發(fā)送完最后一個確認報文段后，為什么不直接進入關閉狀態(tài)，而是要進入時間等待狀態(tài)，兩倍MSL后才進入關閉狀態(tài)，這是否有必要呢？

來看這種情況，TCP服務器進程發(fā)送TCP連接釋放報文段后進入最后確認狀態(tài)，TCP客戶進程收到該報文段后，發(fā)送普通的TCP確認報文段，并進入關閉狀態(tài)，而不是時間等待狀態(tài)。然而該TCP確認報文段丟失了，這必然會造成TCP服務器進程，對之前所發(fā)送的TCP連接釋放報文段的超時重傳，并仍處于最后確認狀態(tài)。重傳的TCP連接釋放報文段到達TCP客戶進程，由于TCP客戶進程屬于關閉狀態(tài)，因此不理睬該報文段，這必然會造成 TCP服務器進程反復重傳TCP連接釋放報文段，并一直處于最后確認狀態(tài)，而無法進入關閉狀態(tài)。

因此時間等待狀態(tài)以及處于該狀態(tài)兩倍MSL的時長，可以確保TCP服務器進程可以收到最后一個TCP確認報文段而進入關閉狀態(tài)。另外TCP客戶進程在發(fā)送完最后一個TCP確認報文段后，再經(jīng)過兩倍MSL時長，就可以使本次連接持續(xù)時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡中消失，這樣就可以使下一個新的TCP連接中不會出現(xiàn)舊連接中的報文段。以上就是TCP通過4報文揮手釋放連接的過程。

---

最后我們再來看看TCP中飽和計時器的作用。設想這樣一種情況，TCP雙方已經(jīng)建立了連接，后來TCP客戶進程所在的主機突然出現(xiàn)了故障，顯然 TCP服務器進程以后就不能再收到TCP客戶進程發(fā)來的數(shù)據(jù)，因此應當有措施使TCP服務器進程，不要再白白等待下去。換句話說，TCP服務器進程應該如何發(fā)現(xiàn)這種情況？

方法就是使用?；钣嫊r器。TCP服務器進程每收到一次TCP客戶進程的數(shù)據(jù)，就要重新設置并啟動?；钣嫊r器，若?；钣嫊r器定時周期內(nèi)未收到TCP客戶進程發(fā)來的數(shù)據(jù)，則當保活計時器到時后，TCP服務器進程就向TCP客戶進程發(fā)送一個探測報文段，以后每隔75秒鐘發(fā)送一次，若一連發(fā)送10個探測報文段，后仍無TCP客戶進程的響應，TCP服務器進程就認為TCP客戶進程所在主機出了故障，接著就要關閉這個連接

內(nèi)容小結如下：

TCP報文段的首部格式

接下來我們就來看看TCP報文段的首部格式，TCP報文段的首部格式與IP數(shù)據(jù)報的首部格式類似，都是由二十字節(jié)的固定首部和最大四十字節(jié)的擴展首部構成。

我們首先來看源端口和目的端口字段：

• 源端口字段占16比特，用來寫入源端口號，而源端口號用來標識發(fā)送該TCP報文段的應用進程
• 目的端口號字段占16比特，用來寫入目的端口號，而目的端口號用來標識接收該TCP報文段的應用進程。

我們來舉例說明源端口和目的端口的作用：

假設主機中的瀏覽器進程要訪問WEB服務器中的WEB服務器進程，為了簡單起見，我們僅從運輸層端口號這個角度來舉例說明，而不考慮其他細節(jié)。例如ARP、域名解析，TCP連接建立等。

• 當在瀏覽器地址欄中輸入了外部服務器的域名后，瀏覽器進程會構建一個封裝有HTTP請求報文的TCP報文段，該報文段首部中的源端口字段，會填寫一個短暫端口號，例如49152用來標識發(fā)送該報文段的瀏覽器進程，目的端口字段會填寫熟知端口號80，因為是用HTTP協(xié)議的WEB服務器進程，默認監(jiān)聽該端口
  

• WEB服務器收到該TCP報文段后，從中解封出HTTP請求報文，并根據(jù)TCP報文段首部中目的端口字段的值80，將HTTP請求報文上交給WEB服務器進程，WEB服務器進程根據(jù)HTTP請求報文的內(nèi)容進行相應處理，并構建一個HTTP響應報文，HTTP響應報文需要封裝成TCP報文段進行發(fā)送。該報文段首部中的源端口字段，會填寫熟知端口號80，用來標識發(fā)送該TCP報文段的WEB服務器進程，而目的端口字段會填寫49152，這是主機中需要接收該TCP報文段的瀏覽器進程所對應的端口號。
  

• 主機收到該TCP報文段后，從中解封出HTTP響應報文，并根據(jù)TCP報文段首部裝目的端口字段的值49152，將HTTP響應報文上交給瀏覽器進程，瀏覽器進程對HTTP響應報文的內(nèi)容進行解析并顯示。

接下來我們再來看看與TCP實現(xiàn)可靠傳輸相關的序號字段，確認號字段以及確認標志位ACK。

例如這是一個TCP報文段，它有首部、數(shù)據(jù)載荷兩部分構成，數(shù)據(jù)載荷中的每個字節(jié)數(shù)據(jù)都有序號，如圖所示，請注意他們是字節(jié)數(shù)據(jù)的序號而不是內(nèi)容。對于本例首部中序號字段應填入的10進制值為166，用來指出數(shù)據(jù)載荷的第一個字節(jié)的序號為166

我們來舉例說明這三個字段的作用：

• TCP客戶進程發(fā)送一個TCP報文段，該報文段首部中序號字段的取值為201，這表示該TCP報文段數(shù)據(jù)載荷的第一個字節(jié)的序號為201，假設數(shù)據(jù)載荷的長度為100字節(jié)，首部中確認號字段的取值為800，這表示TCP客戶進程收到了TCP服務器進程發(fā)來的序號到799為止的全部數(shù)據(jù)，現(xiàn)在期望收到序號從800開始的數(shù)據(jù)，為了使確認號字段有效，首部中的確認標志位ACK的值必須設置為1。
  
• TCP服務器進程收到該報文段后，也給TCP客戶進程發(fā)送TCP報文段，該報文段首部裝序號字段的取值為800，這表示該TCP報文段數(shù)據(jù)載荷的第一個字節(jié)的序號為800，這正好與TCP客戶進程的確認相匹配，假設數(shù)據(jù)載荷的長度為200字節(jié)，首部中確認號字段的取值為301，這表示TCP服務器進程收到了TCP客戶進程發(fā)來的序號到300為止的全部數(shù)據(jù)，現(xiàn)在期望收到序號從301開始的數(shù)據(jù)，為了使確認號字段有效，首部中的確認標志為ACK的值必須設置唯一。
  

我們再來看數(shù)據(jù)偏移字段：

• TCP報文段首部中的保留字段占6比特，保留為今后使用，目前應至為0。

• 我們再來看看窗口字段：

  • 該字段占16比特，以字節(jié)為單位，該字段指出的是發(fā)送本報文段的一方的接收窗口，窗口值作為接收方讓發(fā)送方設置其發(fā)送窗口的依據(jù)，這是以接收方的接收能力來控制發(fā)送方的發(fā)送能力，也就是所謂的流量控制，需要注意的是發(fā)送窗口的大小還取決于擁塞窗口的大小，也就是應該從接收窗口和擁塞窗口中取小者

• TCP報文段首部中的校驗和字段占16比特，用來檢查整個TCP報文段在傳輸過程中是否出現(xiàn)了誤碼，與UDP類似。在計算校驗和時要在TCP報文段的前面加上12字節(jié)的尾首部，具體的校驗算法就不再贅述了，因為它僅僅是一種檢測算法，與TCP的其他重要功能相比，檢錯算法并不是重點。

• 接下來我們來看同步標志位SYN，該標志位在TCP連接建立時用來同步序號：
  

  • 如圖所示，TCP通過三報文握手建立連接的過程，TCP客戶進程發(fā)送的TCP連接請求報文段，首部中的同步標志位SYN被置1，表明這是一個TCP連接請求報文段，TCP服務器進程發(fā)送的TCP連接請求確認報文段，首部中的同步標志位SYN被置1，確認為ACK也被置1，表明這是一個TCP連接請求確認報文段。

• 再來看看終止標志位FIN，該標志位用來釋放TCP連接：
  

  • 如圖所示，TCP通過四報文揮手釋放連接的過程，不管是TCP客戶進程還是TCP服務器進程，他們所發(fā)送的TCP連接釋放報文段，首部中的終止標志位FIN都被置1，表明這是TCP連接釋放報文段

• 首部中的復位標志位RST用來復位TCP連接，當RST等于1時表明TCP連接出現(xiàn)了異常，必須釋放連接，然后再重新建立連接，RST置1還可以用來拒絕一個非法的報文段，或拒絕打開一個TCP連接

• 首部中的推送標志位PSH用來實現(xiàn)推送操作。當接收方的TCP收到該標志位為1的報文段，會盡快上交應用進程，而不必等到接收緩存都填滿后再向上交付。

• 首部中的緊急標志位URG和緊急指針字段用來實現(xiàn)緊急操作。緊急標志為URG取之為1時，緊急指針字段有效，取值為0時，緊急指針字段無效，緊急指針字段占16比特，以字節(jié)為單位，用來指明緊急數(shù)據(jù)的長度。當發(fā)送方有緊急數(shù)據(jù)時，可將緊急數(shù)據(jù)插隊的發(fā)送緩存的最前面，并立刻封裝到一個TCP報文段中進行發(fā)送。緊急指針會指出本報文段數(shù)據(jù)載荷部分包含了多長的緊急數(shù)據(jù)，緊急數(shù)據(jù)之后是普通數(shù)據(jù)，接收方收到緊急標志為1的報文段，會按照緊急指針字段的值，從報文端數(shù)據(jù)載荷部分取出緊急數(shù)據(jù)，并直接上交應用進程，而不必在接收緩存中排隊。

• TCP報文段首部除了24節(jié)的固定部分，還有最大40節(jié)的選項部分，增加選項可以增加TCP的功能。
  

• 由于選項的長度可變，因此還需要使用填充字段來確保報文段首部能被四整除。這是因為數(shù)據(jù)偏移字段，也就是首部長度字段是以四字節(jié)為單位的，如果選項的長度加上20字節(jié)固定首部的長度不能被4整除，則需要使用填充字段來確保首部能被四整除。

內(nèi)容小結如下;