第七章

運輸層PrincipleandApplicationofComputerNetwork課件制作：章全信息管理系第七章運輸層PrincipleandApplicationofComputerNetwork本章重點（一）（二）（三）運輸層的作用及兩個主要協議UDP結構與應用TCP服務、確認機制、報文格式及連接管理（四）TCP可靠傳輸機制與實現第七章運輸層PrincipleandApplicationofComputerNetwork本章重點（五）（六）TCP流量控制TCP擁塞控制第一節運輸層概述ChaptersandSections本章章節第二節用戶數據報協議UDP第三節傳輸控制協議TCP第四節可靠傳輸的工作原理第五節TCP可靠傳輸的實現ChaptersandSections本章章節第六節

TCP流量控制第七節TCP擁塞控制PART1運輸層概述第一節運輸層概述從通信和信息處理的角度看，運輸層向它上面的應用層提供通信服務，它屬于面向通信部分的最高層，同時也是用戶功能中的最低層。當網絡的邊緣部分中的兩臺主機使用網絡的核心部分的功能進行端到端的通信時，只有主機的協議棧才有運輸層，而網絡核心部分中的路由器在轉發分組時都只用到下三層的功能。從IP層來說，通信的兩端是兩臺主機。IP數據報的首部明確地標志了這兩臺主機的IP地址。但“兩臺主機之間的通信”這種說法還不夠清楚。這是因為，真正進行通信的實體是在主機中的進程，是這臺主機中的一個進程和另一臺主機中的一個進程在交換數據（即通信）。因此嚴格地講，兩臺主機進行通信就是兩臺主機中的應用進程互相通信。IP協議雖然能把分組送到目的主機，但是這個分組還停留在主機的網絡層而沒有交付主機中的應用進程。從運輸層的角度看，通信的真正端點并不是主機而是主機中的進程。也就是說，端到端的通信是應用進程之間的通信。第一節運輸層概述一、運輸層的基本功能網絡層、數據鏈路層與物理層實現了網絡中主機之間的數據通信，但是數據通信不是組建計算機網絡的最終目的。計算機網絡的本質活動是實現分布在不同地理位置的主機之間的進程通信，以實現應用層的各種網絡服務功能。運輸層的主要功能是要實現分布式進程通信。因此，運輸層是實現各種網絡應用的基礎。圖7-1給出了傳輸層基本功能的示意圖。圖7-1傳輸層的基本功能第一節運輸層概述二、運輸層的兩個主要協議TCP/IP模型運輸層的兩個主要協議分別是UDP和TCP，它們都是Internet的正式標準。（1）UDP（UserDatagramProtocol，用戶數據報協議）。（2）TCP（TransmissionControlProtocol，傳輸控制協議）。UDP和TCP在協議模型中的位置如圖7-2所示。圖7-2TCP/IP體系結構中的運輸層協議第一節運輸層概述（一）UDP及其服務()UDP是一種提供最少服務的輕量級運輸層協議。UDP是無連接的，因此在通信之前不需要建立連接。UDP提供了一種不可靠的數據傳輸服務，它不保證報文一定能到達接收進程，而且報文到達接收進程的順序也可能與發送時的順序不同，這一點與IP協議是類似的。（二）TCP及其服務TCP提供面向連接的、可靠數據傳輸和擁塞控制等服務。（1）面向連接。（2）可靠數據傳輸（3）擁塞控制服務第一節運輸層概述（三）常用的TCP和UDP應用表7-1給出了使用UDP或TCP的常用網絡應用實例。對帶寬要求不高的網絡應用屬于彈性服務（Elasticalservice）。對時延不敏感的網絡應用，較長的網絡時延會影響用戶的使用體驗，但不會對應用造成有害影響，這類應用更關注的是數據傳輸的完整性，例如文件傳輸。而對時延敏感的網絡應用，通常允許有少量的數據包丟失，例如在多媒體通信中，偶爾的丟包只會對音/視頻的播放造成偶爾的干擾，而且通常可以用技術手段將這些丟包部分或全部隱藏起來。表7-1使用UDP或TCP的常用應用實例第一節運輸層概述三、應用進程、端口、套接字與TCP連接運輸層端口與套接字是運輸層一個重要的概念。圖7-3給出了應用進程、套接字與IP地址關系的示意圖。理解應用進程、運輸層端口與套接字的關系，需要注意以下問題。（1）應用進程、運輸層協議與本地主機操作系統的關系（2）進程通信、運輸層端口號與網絡層IP地址的關系（3）套接字與TCP連接圖7-3應用進程、套接字與IP地址的關系第一節運輸層概述運輸層還必須要解決的一個重要問題是進程標識。在一臺計算機中，不同進程需要用進程號（ProcessID）唯一地標識。進程號也稱為端口號。在網絡環境中，標識一個進程必須同時使用IP地址與端口號。套接字（Socket）就是由IP地址與對應的端口號（IP地址：端口號）組成。具體表示為：套接字（Socket）=（IP地址:端口號）

（7-1）例如，一個IP地址為的客戶端使用30022端口號，與一個IP地址為且端口號為80的Web服務器建立TCP連接，那么標識客戶端的套接字為（:30022），標識服務器端的套接字為（:80）。從上面可以看出，每一條TCP連接唯一地被通信兩端的兩個端點（即兩個套接字）所確定，因此TCP連接可具體表示為：TCP連接::={socket1，socket2}={(IP1:port1)，(IP2:port2)}（7-2）這里IP1和IP2分別是兩個端點主機的地址，而port1和port2分別是兩個端點主機中的端口號。TCP連接的兩個套接字就是socket1和socket2。可見套接字socket是個很抽象的概念。第一節運輸層概述四、分布式進程標識計算機網絡環境中，應用進程是分布在多臺不同的主機之上進行通信的，因此分布式進程通信首先要解決兩個基本問題：進程標識和多重協議的識別。（一）進程標識（1）進程標識的基本方法（2）端口號的分配方法第一節運輸層概述在TCP/IP協議中，端口號采用16位2進制數表示，其數值取0~65535之間的整數。互聯網上的計算機通信是采用客戶-服務器方式。客戶端在發起通信請求時，必須先知道對方服務器的IP地址和端口號。因此運輸層的端口號分為下面的兩大類。①服務器端使用的端口號服務器端使用的端口號分為兩類，最重要的一類叫做熟知端口號（wellknownportnumber）或系統端口號，數值為0-1023。另一類叫做登記端口號，數值為1024~49151。這類端口號是為沒有熟知端口號的應用程序使用的。使用這類端口號必須在IANA按照規定的手續登記，以防止重復。表7-2常用的熟知端口第一節運輸層概述②客戶端使用的端口號客戶端使用的端口號數值為49152~65535。由于這類端口號僅在客戶進程運行時才動態選擇，因此又叫做臨時端口號。這類端口號留給客戶進程選擇暫時使用。當服務器進程收到客戶進程的報文時，就知道了客戶進程所使用的端口號，因而可以把數據發送給客戶進程。通信結束后，剛才已使用過的客戶端口號就不復存在，這個端口號就可以供其他客戶進程使用。第一節運輸層概述（二）多重協議的識別實現分布式進程通信要解決的另一個重要問題是多重協議的識別。網絡中兩臺主機要實現進程通信，就必須事先約定好使用的運輸層協議類型。如果主機的傳輸層使用TCP，另一臺主機的傳輸層使用UDP，由于兩種協議的報文格式、端口號分配的規定，以及協議執行過程都不相同，因而使得兩個進程無法正常地交換數據。因此，兩臺主機必須在通信之前就確定都采用TCP，還是都采用UDP。圖7-4進程標識方法第一節運輸層概述五、運輸層的多路復用與多路分用一臺運行TCP/IP協議的主機可能同時運行不同的應用程序。如果客戶和服務器同時運行4個應用程序，分別是域名服務（DNS）、Web服務（HTTP）、電子郵件（SMTP）與網絡管理（SNMP）。其中，HTTP、SMTP使用TCP協議，DNS、SNMP使用UDP協議。TCP/IP協議允許多個不同的應用程序的數據，同時使用同一個IP地址和物理鏈路來發送和收數據。圖7-5運輸層多路復用與分用示意圖PART2用戶數據報協議UDP第二節用戶數據報協議UDP一、UDP協議的主要特點設計UDP協議的主要原則是簡潔、快捷。其主要特點表現在以下幾個方面。（1）UDP協議是一種無連接的運輸層協議（2）UDP協議是一種面向報文的運輸層協議.圖7-6描述了UDP協議對應用程序提交數據的處理方式。圖7-6UDP對應應用程序提交數據的處理方式第二節用戶數據報協議UDP二、UDP協議的結構UDP用戶數據報的格式如圖7-7所示。其報文有固定的8B的報頭。UDP用戶數據報的報頭主要有以下字段。（1）端口號（2）長度（3）校驗和圖7-7UDP用戶數據報格式第二節用戶數據報協議UDP三、UDP協議適用的范圍確定應用程序在運輸層是否采用UDP協議有以下三個考慮的原則。（1）視頻播放應用（2）簡短的交互式應用（3）多播與廣播應用當然，任何事情都有兩面性。簡潔、快速、高效是UDP協議的優點，但是由于它不能提供必需的差錯控制機制，同時在擁塞嚴重時缺乏必要的控制與調節機制。這些問題需要使用UDP的應用程序設計者在應用層設置必要的機制加以解決，UDP協議是一種適用于實時語音與視頻傳輸的運輸層協議。第二節用戶數據報協議UDP三、UDP協議適用的范圍確定應用程序在運輸層是否采用UDP協議有以下三個考慮的原則。（1）視頻播放應用（2）簡短的交互式應用（3）多播與廣播應用當然，任何事情都有兩面性。簡潔、快速、高效是UDP協議的優點，但是由于它不能提供必需的差錯控制機制，同時在擁塞嚴重時缺乏必要的控制與調節機制。這些問題需要使用UDP的應用程序設計者在應用層設置必要的機制加以解決，UDP協議是一種適用于實時語音與視頻傳輸的運輸層協議。PART3傳輸控制協議TCP第三節傳輸控制協議TCP一、TCP協議的主要特點（1）面向字節流的傳輸服務（2）發送和接收緩存（3）字節與數據段（4）全雙工服務（5）面向連接服務（6）可靠服務圖7-8TCP協議字節流傳輸過程第三節傳輸控制協議TCP二、TCP字節編號與確認機制（一）字節編號雖然TCP將字節流組裝成數據段之后發送，但TCP仍然只對字節流按字節進行編號，而不是按數據段編號。為了標識每個TCP數據段，TCP規定將每個數據段的第一個字節的編號作為該數據段的序號。例如，在建立TCP連接時，發送方選取的ISN為10000，并發送了6000B的數據，這些數據被組裝成5個數據段進行傳輸，其中，前4個數據段長度為1000B，最后一個數據段長度為2000B，則每個數據段的序號及組成這個數據段的字節數據的編號范圍如表7-3所示。表7-3數據段序號及字節數據編號示例第三節傳輸控制協議TCP（二）TCP確認機制TCP提供可靠服務的前提條件是TCP的確認機制。TCP的確認機制的基本思想就是發送方發送的每個字節數據都要在規定的時間內得到接收方的確認。但在實現時，TCP采用累計確認方式，即接收方對正確接收的、按序到達的連續字節流只要確認最后一個字節即可。接收方在確認時，確認號是數據段的最后一個字節的編號加1，表示該字節編號之前的所有數據均已正確接收，并指明期望接收下一個數據段的序號。為了提高效率，TCP的實現可以使用延遲確認算法。該算法的基本思想是：TCP不必每收到一個報文就立即發回確認，而是推遲一段時間，等收到一個以上連續的報文后，對最后一個按序到達的報文進行確認即可。第三節傳輸控制協議TCP三、TCP報文的結構TCP實體之間傳輸的協議數據單元PDU稱為TCP報文，也稱TCP報文段，其報文格式如圖7-9所示。TCP頭部由固定頭部和選項兩部分組成，其中，前面20B即前5行為固定頭部（淺灰色部分），后面為可選項（白色部分）。（1）源端口和目的端口（2）序號（3）確認號（4）頭部長度（5）保留（6）標志（7）窗口（8）校驗和（9）緊急指針（10）選項（11）填充圖7-9TCP報文格式第三節傳輸控制協議TCP四、TCP連接管理（一）建立TCP連接TCP是面向連接的協議，建立TCP連接的過程被形象地稱為三次握手過程，其過程及連接狀態變化如圖7-10所示，其中的Seq為序號，Ack為確認號，[SYN]表示SYN標志置位，[SYN，ACK]表示SYN和ACK標志置位。圖7-10TCP的三次握手過程第三節傳輸控制協議TCP建立TCP連接的三次握手過程說明如下。第一次握手：當客戶端打算與服務器端建立TCP連接時，就主動發送標志位SYN置1的TCP報文給服務器端以請求建立TCP連接，其中，報文中的序號字段Seq=X。TCP規定，SYN標志置1的TCP報文不能攜帶數據，但要消耗掉一個序號。這時，客戶端的TCP進程將從CLOSED狀態轉到SYN_SENT狀態。第二次握手：服務器端接收到連接請求報文后，如同意建立連接，則選擇自己的序號Seq=Y，并向客戶端返回標志位SYN和ACK均置1的確認報文，其中，確認號Ack=X+1。這時TCP服務器進程進入到SYN_RCVD狀態。第三次握手：客戶端收到確認報文后就表明本端的TCP連接已經建立，TCP進程進入到ESTABLISHED狀態。此時，客戶端的應用進程就可以利用此連接向服務器發送數據，但此時仍然需要向服務器發出確認報文，該確認報文可以稍帶在用戶數據報文中一并發送給服務器端，報文中的序號Seq=X+1，確認號Ack=Y+1，標志位ACK置1。TCP規定ACK標志置1的TCP確認報文可以攜帶數據，但如果不攜帶數據則不消耗序號。服務器端收到客戶端的確認報文后，也進入到ESTABLISHED狀態，并通知其上層應用進程，自此，雙方的TCP連接建立成功。為什么客戶端最后還要再發送一次確認呢？這主要是為了防止已失效的連接請求報文段突然又傳送到了服務器端，因為服務器端誤認為這是有效的請求連接報文，因而產生錯誤。因此，采用三次握手的機制，避免這類錯誤的產生。第三節傳輸控制協議TCP（二）釋放TCP連接數據傳輸結束后，通信的任意一方都可以釋放TCP連接。假設客戶端應用進程先發出連接釋放請求報文，主動請求關閉TCP連接，并停止發送數據。釋放TCP連接的過程被形象地稱為四次揮手。具體過程及TCP進程的連接狀態變化如圖7-11所示。圖7-11TCP釋放連接時的四次揮手過程第三節傳輸控制協議TCP（三）重置TCP連接前面所介紹的是應用程序傳輸完數據之后正常地關閉連接，但有時也會出現異常情況導致中途需要突然關閉TCP連接，TCP為此提供了重置措施。要重置一個TCP連接，只要發送一個標志RST置1的TCP報文即可。對方收到RST標志置1的報文時就立即退出TCP連接。連接雙方立即停止數據傳輸并釋放這一連接所占用的緩存等系統資源。異常的突然重置可能會導致數據丟失。以下三種情況會重置TCP連接。（1）一方的TCP請求連接到一個并不存在的端口。對方就會發送RST報文來拒絕該請求。（2）一方的TCP由于異常情況（如主機崩潰）而突然退出連接。這時它必須先釋放連接，然后重建TCP連接（3）一方的TCP發現另一方的TCP長時間空閑。為了節省系統資源，它可以發送RST報文來撤銷這個TCP連接。PART4可靠傳輸的工作原理第四節可靠傳輸的工作原理TCP發送的報文段是交給網絡層的IP協議傳送的。但前面講到IP協議實現的是盡最大努力交付的服務。也就是說，TCP下面的網絡所提供的是不可靠的傳輸。因此，TCP必須采用適當的措施才能使得兩個運輸層之間的通信變得可靠。理想的傳輸條件有以下幾個特點（1）傳輸信道數據不會產生差錯。（2）不管發送方以多快的速度發送數據，接收方總是來得及處理收到的數據。第四節可靠傳輸的工作原理一、停止等待協議停止等待協議是最簡單但也是最基礎的可靠傳輸協議。停止等待的基本思想就是每發送完一個報文就停止發送，等待對方的確認。在收到確認后才能發送下一個報文。顯然，在這種環境中，每個報文都需要進行編號。在報文的傳輸過程中，有4種可能的狀態：正常運行、報文丟失、確認丟失或確認延遲。停止等待協議對這四種情況都采取了相依的措施，來保障可靠傳輸的實現。具體情況如圖7-12所示。圖7-12停止等待協議運行可能出現的4個情況第四節可靠傳輸的工作原理二、連續ARQ協議停止等待協議雖然實現了可靠傳輸，但是缺點也很明細，通信效率非常低。為了提高傳輸效率，發送方可以不使用低效率的停止等待協議，而是采用流水線傳輸，如圖7-13所示。流水線傳輸就是發送方可連續發送多個分組，不必每發完一個分組就停頓下來等待對方的確認。這樣可使信道上一直有數據不間斷地在傳送。顯然，這種傳輸方式可以獲得很高的信道利用率。圖7-13流水線傳輸模式第四節可靠傳輸的工作原理連續ARQ協議就是使用流水線傳輸方式。為了實現流水線傳輸，連續ARQ協議采用滑動窗口機制來維護流水線傳輸方式。收發雙方以全雙工方式工作，在發送緩存和接收緩存中各開辟一個空間作為發送窗口和接收窗口。圖7-14（a）表示發送方維持的發送窗口，發送窗口的意義在于：位于發送窗口中的5個分組均可以連續發送出去，而不需要等待接收方的確認。因此，發送方就可以以流水線的方式一次性發送多個分組，從而提高了信道的利用率。圖7-14發送窗口第四節可靠傳輸的工作原理連續ARQ協議規定，發送方每收到一個分組的確認，就把發送窗口向前滑動一個分組的位置。圖7-14（b）表示發送方收到了對第1個分組的確認，于是把發送窗口向前移動一個分組的位置。如果原來已經發送了前5個分組，那么現在就可以發送窗口內的第6個分組了。接收方一般都是采用累積確認的方式。這就是說，接收方不必對收到的分組逐個發送確認，而是在收到幾個分組后，對按序到達的最后一個分組發送確認，這就表示：到這個分組為止的所有分組都已正確收到了。累積確認有優點也有缺點。優點是：容易實現，即使確認丟失也不必重傳。但缺點是不能向發送方反映出接收方已經正確收到的所有分組的信息。圖7-14發送窗口PART5TCP可靠傳輸的實現第五節TCP可靠傳輸的實現一、滑動窗口機制在建立TCP連接時，通信雙方均通過TCP報頭中的窗口字段來告知對方本結點接收窗口的大小，發送方根據對方告知的窗口大小來動態設定自己的發送窗口的大小，發送窗口必須小于或等于對方的接收窗口的大小。如圖7-15（a）所示，發送方根據接收方通知的窗口大小（假設為500B）將自己的發送窗口設定為500，并假定每個TCP報文段長度為100B，則發送窗口包含5個TCP報文段。圖中的三個指針（P1、P2和P3）將發送方要發送的9個TCP報文分成以下4個部分。（1）P1左側的是已發送且已收到確認的報文。（2）位于P2與P1之間的為已經發送但還未收到確認的報文。（3）位于P3與P2之間的為允許發送但當前還未發送的報文。P3-P2=可用窗口大小，或有效窗口大小。（4）P3右側的為還不可以發送的報文.圖7-15以字節為單位的滑動窗口示例第五節TCP可靠傳輸的實現一、滑動窗口機制在建立TCP連接時，通信雙方均通過TCP報頭中的窗口字段來告知對方本結點接收窗口的大小，發送方根據對方告知的窗口大小來動態設定自己的發送窗口的大小，發送窗口必須小于或等于對方的接收窗口的大小。如圖7-15（a）所示，發送方根據接收方通知的窗口大小（假設為500B）將自己的發送窗口設定為500，并假定每個TCP報文段長度為100B，則發送窗口包含5個TCP報文段。圖中的三個指針（P1、P2和P3）將發送方要發送的9個TCP報文分成以下4個部分。（1）P1左側的是已發送且已收到確認的報文。（2）位于P2與P1之間的為已經發送但還未收到確認的報文。（3）位于P3與P2之間的為允許發送但當前還未發送的報文。P3-P2=可用窗口大小，或有效窗口大小。（4）P3右側的為還不可以發送的報文.圖7-15以字節為單位的滑動窗口示例第五節TCP可靠傳輸的實現二、超時重傳機制TCP超時重傳機制是為了進行差錯控制，是TCP實現可靠傳輸的一個重要措施。TCP要求發送端每發送一個報文都要保存一份該報文的副本，同時啟動一個重傳定時器（RetransmissionTimer，RT）并等待確認信息。接收端成功接收報文后就返回一個確認信息。RT設定了一個超時重傳時間（RetransmissionTimeOut，RTO），若在RTO超時前報文仍未被確認，TCP就認為該報文已丟失或損壞，需要重傳該報文。超時重傳時間RTO是影響超時重傳機制協議效率的一個關鍵參數。RTO的值被設置過大或過小都會對協議造成不利影響。如果RTO設置過大將會使發送端經過較長時間的等待才能發現報文丟失，降低了TCP連接數據傳輸的吞吐量；另一方面，若RTO過小，發送端盡管可以很快地檢測出報文的丟失，但也可能將一些延遲大的報文誤認為是丟失，造成不必要的重傳，浪費了網絡資源。PART6TCP流量控制第六節TCP流量控制所謂流量控制就是讓發送方的發送速率不要過快，讓接收方來得及接收。利用滑動窗口機制可以很方便地在TCP連接上實現對發送方的流量控制。一、滑動窗口與流量控制TCP使用可變的滑動窗口來實現流量控制。除了在建立TCP連接時，通信雙方相互通過TCP報文中的窗口字段來告知對方本結點的接收窗口大小。在通信的過程中，接收方還會使用TCP確認報文中的窗口字段來動態地向發送方反饋本結點的接收窗口大小，發送方則據此對發送窗口的大小在向前滑動時進行調節，使之等于接收方反饋的窗口大小，從而調節了發送數據的流量，以適應接收方的接收能力。圖7-16示例了可變的滑動窗口進行流量控制的過程。圖7-16利用滑動窗口實現流量控制第六節TCP流量控制二、零窗口與持續定時器當接收方的接收緩存已經飽和，接收方可以使用大小為0的接收窗口來通知發送方停止發送數據。當接收緩存又有空間后，再用一個非零接收窗口激活發送方繼續發送數據。實際應用中，零窗口可能帶來一個問題。例如，接收方發出了一個零窗口，發送方將發送窗口大小調整為0，暫停發送。一段時間后，接收方緩存有空間了，接收方發送一個非零窗口的報文來激活發送方。但不幸的是這個非零窗口的報文丟失了，發送方和接收方將都處于等待對方的狀態，從而導致了死鎖。為了解決這個問題，TCP為每一個連接設置一個持續定時器。第六節TCP流量控制三、TCP傳輸效率應用進程將數據傳送到TCP的發送緩存后，剩下的發送任務就由TCP來控制了。TCP可以采用以下三種控制機制來控制發送TCP報文段的時機。（1）TCP維持一個變量，它等于最大報文段長度MSS。只要緩存中存放的數據達到MSS字節時，就組裝成一個TCP報文段發送出去（2）發送方的應用進程指明要求立即發送報文段，即TCP支持的PUSH操作，也就是標志位PSH置1的報文。（3）發送方維持一個定時器，當定時器到時后，就把當前已有的緩存數據裝入報文段（但長度不能超過MSS）發送出去。第六節TCP流量控制三、TCP傳輸效率應用進程將數據傳送到TCP的發送緩存后，剩下的發送任務就由TCP來控制了。TCP可以采用以下三種控制機制來控制發送TCP報文段的時機。（1）TCP維持一個變量，它等于最大報文段長度MSS。只要緩存中存放的數據達到MSS字節時，就組裝成一個TCP報文段發送出去（2）發送方的應用進程指明要求立即發送報文段，即TCP支持的PUSH操作，也就是標志位PSH置1的報文。（3）發送方維持一個定時器，當定時器到時后，就把當前已有的緩存數據裝入報文段（但長度不能超過MSS）發送出去。PART7TCP擁塞控制第七節TCP擁塞控制一、擁塞控制的基本原理計算機網絡中的帶寬、交換結點中的緩存和路由器等，都是網絡的資源。在某段時間若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就會變壞。這種情況就叫做擁塞。就像現實生活中城市道路擁堵一樣，當汽車的流量超過馬路設計的最大流量時，道路就會出現擁堵。擁塞控制就是防止過多的數據注入網絡，這樣可以使網絡中的路由器或鏈路不至于過載，從而減小擁塞的產生概率。擁塞控制是一個全局性的過程，它涉及網絡中的所有路由器和主機，以及與降低網絡傳輸性能有關的所有因素，擁塞控制所要做的就是使網絡負載與網絡的承受能力相適應。擁塞控制與流量控制是兩個不同的概念。流量控制是指點對點通信量的控制，它只涉及發送端與接收端，流量控制所要做的是抑制發送端發送數據的速率，以便使接收端來得及接收和處理數據。第七節TCP擁塞控制在研究網絡擁塞時，可以用兩個指標來描述網絡的性能，一個是網絡的吞吐量，另一個是端到端時延，它們與網絡負載有關。網絡負載代表單位時間內輸入到網絡的分組數，吞吐量則代表單位時間內從網絡輸出的分組數。吞吐量、端到端時延與網絡負載之間的關系如圖7-17所示。圖7-17吞吐量、時延與網絡負載的關系第七節TCP擁塞控制二、TCP擁塞控制策略TCP的擁塞控制策略屬于閉環控制策略，包括反饋和控制兩個環節。反饋機制要求發送方發現擁塞，可由交換結點直接報告，也可以是間接地由發送方從本地觀察到分組延遲或丟失等情況來推斷。源結點擁塞的控制手段是源抑制，即降低發送流量。這一點與流量容有點兒相似，但仍與流量控制有本質區別。TCP推薦使用以下幾種控制策略：慢啟動、擁塞避免、快重傳和快恢復。使用這些策略的前提是認為絕大多數報文丟失都是由擁塞所致，因為在目前的通信技術條件下，由于通信線路問題引起的傳輸差錯面造成報文丟棄的概率已經很小了。第七節TCP擁塞控制（一）慢啟動與擁塞避免慢啟動和擁塞避免是較早提出的擁塞控制策略，TCP通過報文段的超時重傳，或者接收到ICMP的源抑制報文來發現擁塞。為了進行擁塞控制，發送方的TCP又設置了一個叫做擁塞窗口cwnd的狀態變量，擁塞窗口的大小取決于網絡的擁塞程度，并且動態地變化，發送方讓自己的發送窗口等于擁塞窗口，另外考慮到接收方的接收能力，發送窗口還可能小于擁塞窗口，發送窗口的值按以下公式獲得：swnd=min(cwnd,rwnd)（7-3）公式中，變量sw