第7章運輸層本章主要內容運輸層是計算機網絡分層體系結構中的核心層次。其主要任務是完成從源主機應用進程到目的主機應用進程之間的數(shù)據(jù)傳輸。本章將主要介紹運輸層的功能以及在TCP/IP協(xié)議簇中運輸層所采用的協(xié)議UDP和TCP。7.1運輸層概述從通信和信息處理的角度看，運輸層對上層屏蔽了下層的通信細節(jié)，為上層應用提供端到端的連接。物理層網絡層運輸層應用層數(shù)據(jù)鏈路層面向信息處理面向通信用戶功能網絡功能運輸層為相互通信的應用進程提供了邏輯通信

54321運輸層提供應用進程間的邏輯通信主機A主機B應用進程應用進程路由器1路由器2AP1LAN2WANAP2AP3AP4IP層LAN1AP1AP2AP4端口端口54321IP協(xié)議的作用范圍運輸層協(xié)議TCP和UDP的作用范圍AP3應用進程之間的通信兩個主機進行通信實際上就是兩個主機中的應用進程互相通信。應用進程之間的通信又稱為端到端的通信。運輸層的一個很重要的功能就是復用和分用。應用層不同進程的報文通過不同的端口向下交到運輸層，再往下就共用網絡層提供的服務。“運輸層提供應用進程間的邏輯通信”?！斑壿嬐ㄐ拧钡囊馑际牵哼\輸層之間的通信好像是沿水平方向傳送數(shù)據(jù)。但事實上這兩個運輸層之間并沒有一條水平方向的物理連接。運輸層協(xié)議和網絡層協(xié)議的主要區(qū)別

應用進程…應用進程…IP協(xié)議的作用范圍（提供主機之間的邏輯通信）TCP和UDP協(xié)議的作用范圍（提供進程之間的邏輯通信）因特網運輸層與其上下層之間的關系的OSI表示法

運輸實體運輸實體運輸協(xié)議運輸層層接口運輸服務用戶（應用層實體）運輸服務用戶（應用層實體）層接口網絡層（或網際層）應用層主機A主機B運輸層服務訪問點TSAP網絡層服務訪問點NSAP術語傳輸實體通過運輸層服務訪問點TSAP（TransportServiceAccessPoint）向應用層實體（又稱傳輸服務用戶）提供傳輸服務，這里的傳輸服務用戶包括應用層中的各種應用進程。傳輸實體（又稱網絡服務用戶）從網絡服務訪問點NSAP（NetworkServiceAccessPoint）獲取網絡層（或網際層）提供的服務。運輸層對等實體之間的通信遵循傳輸協(xié)議，兩個對等傳輸實體之間通信時傳送的數(shù)據(jù)單位叫做傳輸協(xié)議數(shù)據(jù)單元TPDU（TransportProtocolDataUnit）。7.2TCP/IP模型中的運輸層7.2.1TCP和UDPUDP（UserDatagramProtocol）TCP（TransmissionControlProtocol）。圖7-2TCP/IP模型中的運輸層協(xié)議運輸層向上提供可靠的和不可靠的邏輯通信信道

？應用層運輸層發(fā)送進程接收進程接收進程數(shù)據(jù)數(shù)據(jù)全雙工可靠信道數(shù)據(jù)數(shù)據(jù)使用TCP協(xié)議使用UDP協(xié)議不可靠信道發(fā)送進程7.2.2運輸層端口端口就是運輸層服務訪問點TSAP。端口的作用就是讓應用層的各種應用進程都能將其數(shù)據(jù)通過端口向下交付給運輸層，以及讓運輸層知道應當將其報文段中的數(shù)據(jù)向上通過端口交付給應用層相應的進程。從這個意義上講，端口是用來標志應用層的進程。

端口在進程之間的通信中所起的作用

應用層運輸層網絡層TCP報文段UDP用戶數(shù)據(jù)報應用進程TCP復用IP復用UDP復用TCP報文段UDP用戶數(shù)據(jù)報應用進程端口端口TCP分用UDP分用IP分用IP數(shù)據(jù)報IP數(shù)據(jù)報發(fā)送方接收方端口端口用一個16bit端口號進行標志。端口號只具有本地意義，即端口號只是為了標志本計算機應用層中的各進程。在因特網中不同計算機的相同端口號是沒有聯(lián)系的。端口號的分配有兩種基本方式

在TCP/IP協(xié)議的實現(xiàn)中，端口號的分配有兩種基本方式：（1）全局分配，這是一種集中分配方式，由一個公認權威的中央機構根據(jù)用戶需要進行統(tǒng)一分配，并將結果公布于眾。（2）本地分配，又稱動態(tài)連接，即進程需要訪問運輸層服務時，向本地操作系統(tǒng)提出申請，操作系統(tǒng)返回本地唯一的端口號，進程再通過合適的系統(tǒng)調用，將自己和該端口連接起來（binding，綁定）。

按端口號可分為3大類（1）熟知端口（Well

Known

Ports）：從0到1023，它們緊密綁定（binding）于一些服務。通常這些端口的通信明確表明了某種服務的協(xié)議。例如：80端口實際上總是HTTP通信。（2）注冊端口（Registered

Ports）：從1024到49151。它們松散地綁定于一些服務。也就是說有許多服務綁定于這些端口，這些端口同樣用于許多其他目的。例如：許多系統(tǒng)處理動態(tài)端口從1024左右開始。

（3）動態(tài)和/或私有端口（Dynamic

and/or

Private

Ports）：從49152到65535。理論上，不應為服務分配這些端口。實際上，機器通常從1024起分配動態(tài)端口。例如默認的HTTP端口是80，不少人將它重定向到另一個端口，如8080。7.3用戶數(shù)據(jù)報協(xié)議UDP7.3.1UDP概述用戶數(shù)據(jù)報協(xié)議UDP只在IP的數(shù)據(jù)報服務之上增加了很少一點的功能，這就是端口的功能（有了端口，運輸層就能進行復用和分用）和差錯檢測的功能。UDP在某些方面有其特殊的優(yōu)點：

（1）無需建立連接（2）無連接狀態(tài)管理（3）報文頭部開銷?。?）應用層能很好的控制要發(fā)送的數(shù)據(jù)和發(fā)送時間7.3.2UDP報文格式UDP數(shù)據(jù)報結構由頭部和數(shù)據(jù)兩部分組成，頭部包含4個字段，其中每個字段各占用2個字節(jié)。各字段的含義（1）源/目的端口號（2）數(shù)據(jù)報長度：數(shù)據(jù)報的長度是指包括報頭和數(shù)據(jù)部分在內的總的字節(jié)數(shù)。（3）校驗和：用于檢查UDP報文在傳輸中是否出錯。在計算校驗和時，要在UDP數(shù)據(jù)報之前增加12字節(jié)的偽頭部（并不是UDP的真正頭部）。UDP用戶數(shù)據(jù)報的首部格式

偽首部源端口目的端口長度檢驗和數(shù)據(jù)首部UDP長度源IP地址目的IP地址017IP數(shù)據(jù)報字節(jié)44112122222字節(jié)發(fā)送在前數(shù)據(jù)首部UDP用戶數(shù)據(jù)報偽首部源端口目的端口長度檢驗和數(shù)據(jù)首部UDP長度源IP地址目的IP地址017IP數(shù)據(jù)報字節(jié)44112122222字節(jié)發(fā)送在前數(shù)據(jù)首部UDP用戶數(shù)據(jù)報用戶數(shù)據(jù)報UDP有兩個字段：數(shù)據(jù)字段和首部字段。首部字段有8個字節(jié)，由4個字段組成，每個字段都是兩個字節(jié)。

偽首部源端口目的端口長度檢驗和數(shù)據(jù)首部UDP長度源IP地址目的IP地址017IP數(shù)據(jù)報字節(jié)44112122222字節(jié)發(fā)送在前數(shù)據(jù)首部UDP用戶數(shù)據(jù)報在計算檢驗和時，臨時把“偽首部”和UDP用戶數(shù)據(jù)報連接在一起。偽首部僅僅是為了計算檢驗和。校驗和示例例如:1111001100110011011101010101010101110111011101110111101110111011110010100010001000011wraparoundsumchecksum計算UDP檢驗和的例子

1001100100010011→153.190000100001101000→8.1041010101100000011→171.30000111000001011→14.110000000000010001→0和170000000000001111→150000010000111111→10870000000000001101→130000000000001111→150000000000000000→0（檢驗和）0101010001000101→數(shù)據(jù)0101001101010100→數(shù)據(jù)0100100101001110→數(shù)據(jù)0100011100000000→數(shù)據(jù)和0（填充）1001011011101011→求和得出的結果0110100100010100→檢驗和04112字節(jié)偽首部8字節(jié)UDP首部7字節(jié)數(shù)據(jù)填充按二進制反碼運算求和將得出的結果求反碼全0171510871315全0數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)全07.4傳輸控制協(xié)議TCP傳輸控制協(xié)議TCP（TransmissionControlProtocol）是運輸層中使用最廣泛的一個協(xié)議。TCP提供全雙工和可靠的、面向連接的數(shù)據(jù)傳輸服務。并通過通信雙方三次握手、收方肯定確認、重傳（時鐘控制），流量控制等機制保證數(shù)據(jù)在應用進程之間傳遞的可靠性。端口…發(fā)送

TCP

報文段TCP…TCP接收緩存發(fā)送緩存報文段…報文段報文段端口發(fā)送端接收端向發(fā)送緩存寫入數(shù)據(jù)塊從接收緩存讀取數(shù)據(jù)塊應用進程應用進程7.4.1TCP提供的服務TCP的主要目的是提供可靠的端到端應用進程之間的數(shù)據(jù)傳輸，IP層只保證數(shù)據(jù)在主機之間的傳遞，而且是不可靠的，因此TCP需要很多自己的服務實現(xiàn)可靠傳輸?shù)哪康摹＂琶嫦蜻B接⑵可靠性⑶數(shù)據(jù)流傳輸⑷流量控制⑸全雙工7.4.2TCP報文段格式一個TCP報文段分為頭部和數(shù)據(jù)兩部分。頭部的前20字節(jié)是固定的，選項部分最多為40字節(jié)。因此TCP報文段頭部的最小長度是20字節(jié)。圖7-7TCP報文段格式7.4.3TCP連接管理TCP是面向連接的協(xié)議。TCP傳輸連接的建立和釋放是每一次面向連接的通信中必不可少的過程。TCP的傳輸連接包括三個狀態(tài)：連接建立數(shù)據(jù)傳送連接釋放1．連接的建立第一步，A端的TCP首先向B端的TCP發(fā)送一個特殊的TCP報文段SYN，此報文段中的SYN標志被置1，同時初始化一個起始序號；1．連接的建立第二步，當B端收到A端發(fā)來的SYN報文段，會為該TCP連接分配TCP緩存和變量，并向A端回復一個允許連接的報文段SYNACK；1．連接的建立第三步，在收到允許連接的報文段后，Ａ端也要給該連接分配緩存和變量。然后向Ｂ端發(fā)送另一個報文段，用于對Ｂ端允許連接的SYNACK報文段進行確認。這種通信雙發(fā)進行三次報文交換的過程被稱為三次握手（three-wayhandshake）。2．數(shù)據(jù)傳輸一旦建立起TCP連接，兩個應用進程之間就可以相互發(fā)送數(shù)據(jù)了。通信雙方主機中的應用進程之間的數(shù)據(jù)傳輸是字節(jié)流方式的。發(fā)送方主機中的TCP將來自進程的數(shù)據(jù)放到該連接的發(fā)送緩存里，然后TCP就會不時從發(fā)送緩存里取出一塊數(shù)據(jù)準備發(fā)送。圖7-9TCP發(fā)送報文段的過程3．連接的釋放在數(shù)據(jù)傳輸結束后，通信雙方都可以發(fā)出釋放連接的請求。基于網絡服務的不可靠性，必須考慮到在釋放連接時，可能由于數(shù)據(jù)包的失序而使釋放連接請求的數(shù)據(jù)包會比其他數(shù)據(jù)包先到達目的端。此時，如果目的端由于收到了釋放連接請求的數(shù)據(jù)包而立即釋放該連接，則勢必造成那些先發(fā)而后至的數(shù)據(jù)包丟失。為了解決這些問題，可以把TCP連接看成是一對單工來處理連接的釋放，每個單工連接獨立的釋放。圖7-10TCP連接釋放過程7.5TCP流量控制與擁塞控制7.5.1TCP的流量控制TCP采用大小可變的滑動窗口給應用進程提供流量控制服務，用以消除接收緩存溢出的可能性。TCP通過讓發(fā)送方保留一個稱為接收窗口（receivewindow）的變量來提供流量控制。發(fā)送窗口在連接建立時由雙方商定。但在通信過程中，接收方根據(jù)自己的資源情況，隨時動態(tài)地調整對方的發(fā)送窗口上限值。圖7-11TCP利用可變窗口進行流控收到確認即可前移1002003004005006007008009001012013014015016017018011發(fā)送窗口可發(fā)送不可發(fā)送指針發(fā)送端要發(fā)送900字節(jié)長的數(shù)據(jù)，劃分為9個100字節(jié)長的報文段，而發(fā)送窗口確定為500字節(jié)。發(fā)送端只要收到了對方的確認，發(fā)送窗口就可前移。發(fā)送TCP要維護一個指針。每發(fā)送一個報文段，指針就向前移動一個報文段的距離。收到確認即可前移1002003004005006007008009001012013014015016017018011可發(fā)送不可發(fā)送指針1002003004005006007008009001012013014015016017018011發(fā)送窗口可發(fā)送不可發(fā)送指針發(fā)送窗口前移發(fā)送端已發(fā)送了400字節(jié)的數(shù)據(jù)，但只收到對前200字節(jié)數(shù)據(jù)的確認，同時窗口大小不變?，F(xiàn)在發(fā)送端還可發(fā)送300字節(jié)。已發(fā)送并被確認已發(fā)送但未被確認1002003004005006007008009001012013014015016017018011已發(fā)送并被確認已發(fā)送但未被確認可發(fā)送不可發(fā)送指針1002003004005006007008009001012013014015016017018011已發(fā)送并被確認可發(fā)送不可發(fā)送指針發(fā)送窗口前移發(fā)送窗口縮小發(fā)送端收到了對方對前400字節(jié)數(shù)據(jù)的確認，但對方通知發(fā)送端必須把窗口減小到400字節(jié)?，F(xiàn)在發(fā)送端最多還可發(fā)送400字節(jié)的數(shù)據(jù)。利用可變窗口大小進行流量控制

雙方確定的窗口值是400

SEQ=1SEQ=201SEQ=401SEQ=301SEQ=101SEQ=501ACK=201,WIN=300ACK=601,WIN=0ACK=501,WIN=200主機A主機B允許A再發(fā)送300字節(jié)（序號201至500）A還能發(fā)送200字節(jié)A還能發(fā)送200字節(jié)（序號301至500）A還能發(fā)送300字節(jié)A還能發(fā)送100字節(jié)（序號401至500）A超時重發(fā)，但不能發(fā)送序號500以后的數(shù)據(jù)允許A再發(fā)送200字節(jié)（序號501至700）A還能發(fā)送100字節(jié)（序號501至700）不允許A再發(fā)送（到序號600的數(shù)據(jù)都已收到）SEQ=201丟失！7.5.2TCP的擁塞控制由于在TCP端到端擁塞控制中，網絡層沒有為運輸層擁塞控制提供顯式的支持，即使在網絡中存在擁塞，端系統(tǒng)也必須通過端到端的方法處理擁塞控制，因為IP層不會向端系統(tǒng)提供有關網絡擁塞的反饋信息。TCP采用的方法是讓每一個發(fā)送方根據(jù)所感知的網絡擁塞，來限制其能向連接發(fā)送流量的速率。如果一個TCP發(fā)送方感知從它到目的地之間的路徑上沒有擁塞，則該發(fā)送方就會增加其發(fā)送速率；如果一個TCP發(fā)送方感知從它到目的地之間的路徑上有擁塞（例如TCP段的丟失等），則該發(fā)送方就會降低其發(fā)送速率。發(fā)送窗口、接收窗口和擁塞窗口發(fā)送方的發(fā)送窗口Swnd（senderwindow）應按以下方式確定：發(fā)送窗口=Min[接收窗口，擁塞窗口]接收窗口Rwnd（receiverwindow）是接收方根據(jù)其接收能力確定的窗口值，是來自接收方的流量控制。擁塞窗口Cwnd（congestionwindow）是發(fā)送方根據(jù)網絡擁塞情況確定的窗口值，是由發(fā)送方的流量控制算法確定的。在沒有擁塞的穩(wěn)定工作狀態(tài)下，接收方的通知窗口和擁塞窗口應該是一致的。為了更好的在運輸層進行擁塞控制，1999年公布的Internet建議標準RFC2581定義了四種算法，慢啟動（slow-start）擁塞避免（congestionavoidance）快重傳（fastretransmit）快恢復（fastrecovery）使用這些技術的一個前提就是：由于通信線路帶來的誤碼而使分組丟失的概率很小。因此，當TCP收到路由器發(fā)來的ICMP源抑制報文，或者發(fā)現(xiàn)連續(xù)的報文丟失現(xiàn)象或延遲過長而引起超時重發(fā)，就認為發(fā)生了網絡擁塞。1.慢啟動在主機剛剛開始發(fā)送報文段時可先將擁塞窗口cwnd設置為一個最大報文段MSS的數(shù)值。在每收到一個對新的報文段的確認后，將擁塞窗口增加至多一個MSS的數(shù)值。用這樣的方法逐步增大發(fā)送端的擁塞窗口cwnd，可以使分組注入到網絡的速率更加合理。

這個被稱為慢啟動（slowstart）的初始化階段期間，TCP發(fā)送方以很慢的速率（因此叫“慢啟動”）開始發(fā)送，但是以指數(shù)的速度快速增加其發(fā)送速率。2．擁塞避免在慢啟動階段，可以發(fā)送的報文數(shù)量按指數(shù)級增加，為了防止擁塞窗口的增長引起網絡擁塞，還需要一個狀態(tài)變量，即慢啟動門限ssthresh（slowstartthreshold）。其用法如下：當Cwnd<ssthresh時，處于慢啟動階段；當Cwnd>ssthresh時，進入擁塞避免階段（使用擁塞避免算法）；當Cwnd=ssthresh時，既可以使用慢啟動算法，也可以使用擁塞避免算法。在慢啟動階段，當擁塞窗口大于慢啟動門限時，擁塞窗口按照線性增加，即發(fā)送方的擁塞窗口Cwnd每經過一個往返時間RTT就增加一個MSS的大?。ǘ还茉跁r間RTT內收到了幾個ACK）。當發(fā)送方發(fā)現(xiàn)網絡出現(xiàn)擁塞，慢啟動門限ssthresh設置為發(fā)生擁塞時發(fā)送窗口Swnd的一半。圖7-12擁塞避免過程“加性增，乘性減”（additiveincrease，multiplicativedecrease，也稱為AIMD算法）。

3．快速重傳和快速恢復由于網絡擁塞導致某些報文段丟失，這樣在發(fā)送方可能會收到針對某一個報文段的重復確認ACK?？焖僦貍魉惴ㄒ?guī)定，發(fā)送方只要一連收到三個重復的ACK即可判定有分組丟失了，就應立即重傳丟失的報文段，而不必繼續(xù)等待為丟失的那個報文所設置重傳計時器的超時。不難看出，快速重傳并非取消重傳計時器，而是在某些情況下可以更早地重傳丟失的報文段，避免TCP連接會因為等待重傳計時器的超時而空閑較長的時間?？熘貍髋e例M1,M2ACK2,ACK3M4主機A主機BB確認M1

和

M2A發(fā)送M1和M2A收到了三個重復的確認ACK3，就立即重傳M3，而不必等待超時重傳。M3丟失！A發(fā)送M3但丟失了A發(fā)送M4ACK3M5A發(fā)送M5ACK3B發(fā)送第二個重復確認

ACK3M6A發(fā)送M6ACK3M3B發(fā)送第三個重復確認

ACK3B只能再次確認

M2(因為M3

沒有收到）快速恢復算法與快速重傳配合使用的還有快速恢復算法。當發(fā)送方收到3個連續(xù)重復的ACK時，按“乘法減小”重新設置慢啟動門限。與慢啟動不同的是擁塞窗口Cwnd不是設置為1，而是設置為ssthresh+3×MSS同樣道理，假設發(fā)送方收到n個（n是大于3的自然數(shù)

）重復ACK，則將Cwnd設置為ssthresh+n×MSS若發(fā)送窗口還允許發(fā)送報文段，就按擁塞避免算