計算機運輸層

第5章運輸層5.1運輸層協(xié)議概述

5.1.1進程之間的通信從通信和信息處理的角度看，運輸層向它上面的應用層提供通信服務，它屬于面向通信部分的最高層，同時也是用戶功能中的最低層。當網(wǎng)絡的邊緣部分中的兩個主機使用網(wǎng)絡的核心部分的功能進行端到端的通信時，只有位于網(wǎng)絡邊緣部分的主機的協(xié)議棧才有運輸層，而網(wǎng)絡核心部分中的路由器在轉發(fā)分組時都只用到下三層的功能。5.1運輸層協(xié)議概述

5.1.1進程之間的通信從通信和信息處理的角度看，運輸層向它上面的應用層提供通信服務，它屬于面向通信部分的最高層，同時也是用戶功能中的最低層。物理層網(wǎng)絡層運輸層應用層數(shù)據(jù)鏈路層面向信息處理面向通信用戶功能網(wǎng)絡功能運輸層為相互通信的應用進程提供了邏輯通信54321運輸層提供應用進程間的邏輯通信主機A主機B應用進程應用進程路由器1路由器2AP1LAN2WANAP2AP3AP4IP層LAN1AP1AP2AP4端口端口54321IP協(xié)議的作用范圍運輸層協(xié)議TCP和UDP的作用范圍AP3應用進程之間的通信兩個主機進行通信實際上就是兩個主機中的應用進程互相通信。應用進程之間的通信又稱為端到端的通信。運輸層的一個很重要的功能就是復用和分用。應用層不同進程的報文通過不同的端口向下交到運輸層，再往下就共用網(wǎng)絡層提供的服務?！斑\輸層提供應用進程間的邏輯通信”?！斑壿嬐ㄐ拧钡囊馑际牵哼\輸層之間的通信好像是沿水平方向傳送數(shù)據(jù)；但事實上這兩個運輸層之間并沒有一條水平方向的物理連接。運輸層協(xié)議和網(wǎng)絡層協(xié)議的主要區(qū)別應用進程…應用進程…IP協(xié)議的作用范圍（提供主機之間的邏輯通信）TCP和UDP協(xié)議的作用范圍（提供進程之間的邏輯通信）因特網(wǎng)運輸層的主要功能運輸層為應用進程之間提供端到端的邏輯通信（但網(wǎng)絡層是為主機之間提供邏輯通信）。運輸層還要對收到的報文進行差錯檢測。運輸層需要有兩種不同的運輸協(xié)議，即面向連接的TCP和無連接的UDP。兩種不同的運輸協(xié)議運輸層向高層用戶屏蔽了下面網(wǎng)絡核心的細節(jié)（如網(wǎng)絡拓撲、所采用的路由選擇協(xié)議等），它使應用進程看見的就是好像在兩個運輸層實體之間有一條端到端的邏輯通信信道。當運輸層采用面向連接的TCP協(xié)議時，盡管下面的網(wǎng)絡是不可靠的（只提供盡最大努力服務），但這種邏輯通信信道就相當于一條全雙工的可靠信道。當運輸層采用無連接的UDP

協(xié)議時，這種邏輯通信信道是一條不可靠信道。運輸層向上提供可靠的和不可靠的邏輯通信信道？應用層運輸層發(fā)送進程接收進程接收進程數(shù)據(jù)數(shù)據(jù)全雙工可靠信道數(shù)據(jù)數(shù)據(jù)使用TCP協(xié)議使用UDP協(xié)議不可靠信道發(fā)送進程TCP/IP的運輸層有兩個不同的協(xié)議：(1)用戶數(shù)據(jù)報協(xié)議UDP (UserDatagramProtocol)(2)傳輸控制協(xié)議TCP (TransmissionControlProtocol)5.1.2運輸層的兩個主要協(xié)議運輸層與其上下層之間的關系的OSI表示法運輸實體運輸實體運輸協(xié)議運輸層層接口運輸服務用戶（應用層實體）運輸服務用戶（應用層實體）層接口網(wǎng)絡層（或網(wǎng)際層）應用層主機A主機B運輸層服務訪問點TSAP網(wǎng)絡層服務訪問點NSAP兩個對等運輸實體在通信時傳送的數(shù)據(jù)單位叫作運輸協(xié)議數(shù)據(jù)單元TPDU(TransportProtocolDataUnit)。TCP傳送的數(shù)據(jù)單位協(xié)議是TCP報文段(segment)UDP傳送的數(shù)據(jù)單位協(xié)議是UDP報文或用戶數(shù)據(jù)報。TCP與UDPTCP/IP體系中的運輸層協(xié)議TCPUDPIP應用層與各種網(wǎng)絡接口運輸層TCP與UDPUDP在傳送數(shù)據(jù)之前不需要先建立連接。對方的運輸層在收到UDP報文后，不需要給出任何確認。雖然UDP不提供可靠交付，但在某些情況下UDP是一種最有效的工作方式。TCP則提供面向連接的服務。TCP不提供廣播或多播服務。由于TCP要提供可靠的、面向連接的運輸服務，因此不可避免地增加了許多的開銷。這不僅使協(xié)議數(shù)據(jù)單元的首部增大很多，還要占用許多的處理機資源。5.1.3運輸層的端口運行在計算機中的進程是用進程標識符來標志的。運行在應用層的各種應用進程卻不應當讓計算機操作系統(tǒng)指派它的進程標識符。這是因為在因特網(wǎng)上使用的計算機的操作系統(tǒng)種類很多，而不同的操作系統(tǒng)又使用不同格式的進程標識符。為了使運行不同操作系統(tǒng)的計算機的應用進程能夠互相通信，就必須用統(tǒng)一的方法對TCP/IP體系的應用進程進行標志。需要解決的問題（P183）

由于進程的創(chuàng)建和撤銷都是動態(tài)的，發(fā)送方幾乎無法識別其它機器上的進程。有時我們會改換接收報文的進程，但并不需要通知所有發(fā)送方。我們往往需要利用目的主機提供的功能來識別終點，而不需要知道實現(xiàn)這個功能的進程。端口號(protocolportnumber)

簡稱為端口(port)解決這個問題的方法就是在運輸層使用協(xié)議端口號(protocolportnumber)，或通常簡稱為端口(port)。雖然通信的終點是應用進程，但我們可以把端口想象是通信的終點，因為我們只要把要傳送的報文交到目的主機的某一個合適的目的端口，剩下的工作（即最后交付目的進程）就由TCP來完成。端口的概念端口就是運輸層服務訪問點TSAP。端口的作用就是讓應用層的各種應用進程都能將其數(shù)據(jù)通過端口向下交付給運輸層，以及讓運輸層知道應當將其報文段中的數(shù)據(jù)向上通過端口交付給應用層相應的進程。從這個意義上講，端口是用來標志應用層進程的。端口在進程之間的通信中所起的作用應用層運輸層網(wǎng)絡層TCP報文段UDP用戶數(shù)據(jù)報應用進程TCP復用IP復用UDP復用TCP報文段UDP用戶數(shù)據(jù)報應用進程端口端口TCP分用UDP分用IP分用IP數(shù)據(jù)報IP數(shù)據(jù)報發(fā)送方接收方軟件端口與硬件端口在協(xié)議棧層間的抽象的協(xié)議端口是軟件端口。路由器或交換機上的端口是硬件端口。硬件端口是不同硬件設備進行交互的接口，而軟件端口是應用層的各種協(xié)議進程與運輸實體進行層間交互的一種地址。端口端口用一個16位端口號進行標志。端口號只具有本地意義，即端口號只是為了標志本計算機應用層中的各進程。在因特網(wǎng)中不同計算機的相同端口號是沒有聯(lián)系的。三類端口熟知端口，數(shù)值一般為0~1023。登記端口號，數(shù)值為1024~49151，為沒有熟知端口號的應用程序使用的。使用這個范圍的端口號必須在IANA登記，以防止重復?？蛻舳丝谔柣蚨虝憾丝谔?，數(shù)值為49152~65535，留給客戶進程選擇暫時使用。當服務器進程收到客戶進程的報文時，就知道了客戶進程所使用的動態(tài)端口號。通信結束后，這個端口號可供其它客戶進程以后使用。端口號一些常見的“眾所周知的”端口號：FTPSMTPTFTPDNSTelnetSNMP2123255369161TCPUDP應用層傳輸層端口號：＜255:公共應用255-1023:公司＞1023:未規(guī)定20保留的TCP端口(1)保留的TCP端口(2)端口通過用報文隊列來實現(xiàn)UDP端口51000UDP端口69出隊列入隊列出隊列入隊列TFTP服務器TFTP客戶UDP用戶數(shù)據(jù)報應用層運輸層5.2用戶數(shù)據(jù)報協(xié)議UDP

5.2.1UDP概述

UDP只在IP的數(shù)據(jù)報服務之上增加了很少一點的功能，即端口的功能和差錯檢測的功能。雖然UDP用戶數(shù)據(jù)報只能提供不可靠的交付，但UDP在某些方面有其特殊的優(yōu)點。UDP的主要特點UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。UDP使用盡最大努力交付，即不保證可靠交付，同時也不使用擁塞控制。UDP是面向報文的。UDP沒有擁塞控制，很適合多媒體通信的要求。UDP支持一對一、一對多、多對一和多對多的交互通信。UDP的首部開銷小，只有8個字節(jié)。面向報文的UDP發(fā)送方UDP對應用程序交下來的報文，在添加首部后就向下交付IP層。UDP對應用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界。應用層交給UDP多長的報文，UDP就照樣發(fā)送，即一次發(fā)送一個報文。接收方UDP對IP層交上來的UDP用戶數(shù)據(jù)報，在去除首部后就原封不動地交付上層的應用進程，一次交付一個完整的報文。應用程序必須選擇合適大小的報文。UDP是面向報文的IP數(shù)據(jù)報的數(shù)據(jù)部分IP首部IP層UDP首部UDP用戶數(shù)據(jù)報的數(shù)據(jù)部分運輸層應用層報文應用層5.2.2UDP的首部格式偽首部源端口目的端口長度檢驗和數(shù)據(jù)首部UDP長度源IP地址目的IP地址017IP數(shù)據(jù)報字節(jié)44112122222字節(jié)發(fā)送在前數(shù)據(jù)首部UDP用戶數(shù)據(jù)報UDP基于端口的分用IP層UDP數(shù)據(jù)報到達端口2端口3端口1UDP分用偽首部源端口目的端口長度檢驗和數(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ù)報連接在一起。偽首部僅僅是為了計算檢驗和。計算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（填充）1001011011101101→求和得出的結果0110100100010010→檢驗和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ù)全0例題（P220：5-12）一個應用程序用UDP，到IP層把數(shù)據(jù)報再劃分為4個數(shù)據(jù)報片發(fā)送出去，結果前兩個數(shù)據(jù)報片丟失，后兩個到達目的站。過了一段時間應用程序重傳UDP，而IP層仍然劃分為4個數(shù)據(jù)報片來傳送。結果這次前兩個到達目的站而后兩個丟失。試問：在目的站能否將這兩次傳輸?shù)?個數(shù)據(jù)報片組裝成完整的數(shù)據(jù)報？假定目的站第一次收到的后兩個數(shù)據(jù)報片仍然保存在目的站的緩存中。例題答：不行。重傳時，IP數(shù)據(jù)報的標識字段會有另一個標識符。僅當標識符相同的IP數(shù)據(jù)報片才能組裝成一個IP數(shù)據(jù)報。前兩個IP數(shù)據(jù)報片的標識符與后兩個IP數(shù)據(jù)報片的標識符不同，因此不能組裝成一個IP數(shù)據(jù)報。5.3傳輸控制協(xié)議TCP概述

5.3.1TCP最主要的特點

TCP是面向連接的運輸層協(xié)議。每一條TCP連接只能有兩個端點(endpoint)，每一條TCP連接只能是點對點的（一對一）。TCP提供可靠交付的服務。TCP提供全雙工通信。面向字節(jié)流。768HTCP面向流的概念發(fā)送TCP報文段發(fā)送方接收方把字節(jié)寫入發(fā)送緩存從接收緩存讀取字節(jié)應用進程應用進程1230181716151419202145131211H109H加上TCP首部構成TCP報文段TCPTCP字節(jié)流字節(jié)流H表示TCP報文段的首部x表示序號為x的數(shù)據(jù)字節(jié)TCP連接應當注意TCP連接是一條虛連接而不是一條真正的物理連接。TCP對應用進程一次把多長的報文發(fā)送到TCP的緩存中是不關心的。TCP根據(jù)對方給出的窗口值和當前網(wǎng)絡擁塞的程度來決定一個報文段應包含多少個字節(jié)（UDP發(fā)送的報文長度是應用進程給出的）。TCP可把太長的數(shù)據(jù)塊劃分短一些再傳送。TCP也可等待積累有足夠多的字節(jié)后再構成報文段發(fā)送出去。5.3.2TCP的連接TCP把連接作為最基本的抽象。每一條TCP連接有兩個端點。TCP連接的端點不是主機，不是主機的IP地址，不是應用進程，也不是運輸層的協(xié)議端口。TCP連接的端點叫做套接字(socket)或插口。端口號拼接到(contatenatedwith)IP地址即構成了套接字。插口(socket)TCP使用“連接”(而不僅僅是“端口”)作為最基本的抽象，同時將TCP連接的端點稱為插口(socket)，或套接字、套接口。插口和端口、IP地址的關系是：IP地址3端口號15003,1500插口(socket)套接字(socket)套接字socket=(IP地址:端口號)(5-1)每一條TCP連接唯一地被通信兩端的兩個端點（即兩個套接字）所確定。即：TCP連接::={socket1,socket2}={(IP1:port1),(IP2:port2)}(5-2)同一個名詞socket

有多種不同的意思應用編程接口

API

稱為socketAPI,簡稱為socket。socketAPI中使用的一個函數(shù)名也叫作socket。調(diào)用socket函數(shù)的端點稱為socket。調(diào)用socket函數(shù)時其返回值稱為socket描述符，可簡稱為socket。在操作系統(tǒng)內(nèi)核中連網(wǎng)協(xié)議的Berkeley實現(xiàn)，稱為socket實現(xiàn)。SOCKET概念TCP和UDP的SOCKET機制的工作過程：

TCPSERVERSERVERCLIENTCLIENTUDP申請SOCKET申請SOCKET申請SOCKET申請SOCKETLISTENCALLCONNECTACCEPTSENDRECEIVESENDTORECVFROMSENDTORECVFROM問題的引入Q：就TCP/IP的傳輸層，為什么在TCP之外，還要引入UDP？A：若采用面向連接的TCP服務，則必須為類似虛電路連接的建立、維護和拆除的付出必需的開銷。對于一次傳輸要交換大量報文的情形，如文件傳輸、遠程登錄等應用，這種開銷是值得的。但是，對于一次性傳輸數(shù)據(jù)量較小的網(wǎng)絡應用如SNMP、DNS應用數(shù)據(jù)的傳輸，或對可靠性要求不高的數(shù)據(jù)傳輸如實時語音視頻傳送。這種開銷就顯得不那么必要或合算。5.4可靠傳輸?shù)墓ぷ髟?/p>

5.4.1停止等待協(xié)議

(a)無差錯情況A發(fā)送M1確認M1B發(fā)送M2發(fā)送M3確認M2確認M3A發(fā)送M1B超時重傳M1發(fā)送M2確認M1丟棄有差錯的報文(b)超時重傳tttt停止等待協(xié)議算法流程

在發(fā)送結點

(1)從主機取一個數(shù)據(jù)幀，送交發(fā)送緩存。(2)V(S)←0。{將發(fā)送端狀態(tài)變量V(S)置為0}(3)N(S)←V(S)。{將V(S)的值寫入數(shù)據(jù)幀中的發(fā)送序號N(S)}(4)將發(fā)送緩存中的數(shù)據(jù)幀發(fā)送出去。{該幀的副本仍保留在發(fā)送緩存之中}(5)設置超時計時器。{選擇適當?shù)某瑫r重傳時間tout}(6)等待。{等待以下(7)和(8)這兩個事件中最先出現(xiàn)的一個}(7)收到確認幀ACKn，{這里隱含的表示已經(jīng)通過CRC的硬件差錯檢測}若n=1–V(S)，則：{已發(fā)送的數(shù)據(jù)幀被接收方確認}從主機取一個新的數(shù)據(jù)幀，放入發(fā)送緩存；V(S)←[1V(S)]；{更新發(fā)送狀態(tài)變量，使用下一個序號} 轉到(3)。否則，丟棄這個確認幀，轉到(6)。{這表明已發(fā)送的數(shù)據(jù)幀沒有被接收方確認}(8)若超時計時器時間到，則轉到(4)。{重傳數(shù)據(jù)幀}停止等待協(xié)議算法流程

在接收結點

(1)V(R)←0。{接收狀態(tài)變量初始化，其數(shù)值等于欲接收的數(shù)據(jù)幀的發(fā)送序號}(2)等待。(3)收到一個數(shù)據(jù)幀；{這里隱含的表示已經(jīng)通過CRC的硬件差錯檢測}若N(S)=V(R)，則執(zhí)行(4)；{收到正確序號的數(shù)據(jù)幀}否則丟棄此數(shù)據(jù)幀，然后轉到(6)。{丟棄的幀就是重復幀}(4)將收到的數(shù)據(jù)幀中的數(shù)據(jù)部分送交上層軟件，也就是數(shù)據(jù)鏈路層模型中的主機。(5)V(R)←[1V(R)]。{更新接收狀態(tài)變量，準備接收下一個數(shù)據(jù)幀}(6)n←V(R)；發(fā)送確認幀ACKn，轉到(2)。{期望接到n號數(shù)據(jù)幀，在它之前的幀收到了}請注意在發(fā)送完一個分組后，必須暫時保留已發(fā)送的分組的副本。分組和確認分組都必須進行編號。超時計時器的重傳時間應當比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一些。確認丟失和確認遲到A發(fā)送M1B超時重傳M1發(fā)送M2丟棄重復的M1重傳確認M1(a)確認丟失確認M1A發(fā)送M1B超時重傳M1發(fā)送M2丟棄重復的M1重傳確認M1(b)確認遲到確認M1收下遲到的確認但什么也不做tttt可靠通信的實現(xiàn)使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網(wǎng)絡上實現(xiàn)可靠的通信。這種可靠傳輸協(xié)議常稱為自動重傳請求ARQ(AutomaticRepeatreQuest)。ARQ表明重傳的請求是自動進行的。接收方不需要專門發(fā)送請求、請求發(fā)送方重傳某個出錯的分組。例題（P220：5-17）在停止等待協(xié)議中，如果收到重復的報文段時不予理睬（即悄悄地丟棄它而其它什么也沒做）是否可行？試舉出具體的例子說明理由。例題A發(fā)送M1B超時重傳M1丟棄重復的M1不重傳確認M1收到重復幀不確認，相當于確認丟失

確認M1tt信道利用率停止等待協(xié)議的優(yōu)點是簡單，但缺點是信道利用率太低。TDRTTATD+RTT+TAB分組確認tt分組確認信道的利用率U

(5-3)流水線傳輸發(fā)送方可連續(xù)發(fā)送多個分組，不必每發(fā)完一個分組就停頓下來等待對方的確認。由于信道上一直有數(shù)據(jù)不間斷地傳送，這種傳輸方式可獲得很高的信道利用率。B分組ttAACK5.4.2連續(xù)ARQ協(xié)議123456789101112(a)發(fā)送方維持發(fā)送窗口（發(fā)送窗口是5）發(fā)送窗口(b)收到一個確認后發(fā)送窗口向前滑動向前123456789101112發(fā)送窗口01234567012發(fā)送窗口WT不允許發(fā)送這些幀允許發(fā)送5個幀(a)01234567012不允許發(fā)送這些幀還允許發(fā)送4個幀WT已發(fā)送(b)01234567012不允許發(fā)送這些幀WT已發(fā)送(c)01234567012不允許發(fā)送這些幀還允許發(fā)送3個幀WT已發(fā)送已發(fā)送并已收到確認(d)累積確認接收方一般采用累積確認的方式。即不必對收到的分組逐個發(fā)送確認，而是對按序到達的最后一個分組發(fā)送確認，這樣就表示：到這個分組為止的所有分組都已正確收到了。累積確認有的優(yōu)點是：容易實現(xiàn)，即使確認丟失也不必重傳。缺點是：不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息。Go-back-N（回退N）如果發(fā)送方發(fā)送了前5個分組，而中間的第3個分組丟失了。這時接收方只能對前兩個分組發(fā)出確認。發(fā)送方無法知道后面三個分組的下落，而只好把后面的三個分組都再重傳一次。這就叫做Go-back-N（回退N），表示需要再退回來重傳已發(fā)送過的N個分組。可見當通信線路質(zhì)量不好時，連續(xù)ARQ協(xié)議會帶來負面的影響。連續(xù)ARQ協(xié)議的工作原理DATA0DATA1DATA2DATA3DATA4DATA5重傳DATA2重傳DATA3ACK1ACK2ACK1確認DATA0ACK2確認DATA1DATA2出錯，丟棄DATA3不按序，丟棄，重傳ACK2DATA4不按序，丟棄，重傳ACK2DATA5不按序，丟棄，重傳ACK2ACK3ACK3確認DATA2ACK4確認DATA3ACK4重傳DATA5重傳DATA4超時重傳時間ABtout送交主機送交主機…??ACK2ACK2ACK2例題（P221：5-20）

在連續(xù)ARQ協(xié)議中，若發(fā)送窗口為7，則發(fā)送端在開始時可連續(xù)發(fā)送7個數(shù)據(jù)幀。因此，在每一個幀發(fā)出后，都要設置一個超時計時器?，F(xiàn)在計算機里只有一個硬時鐘。設這7個數(shù)據(jù)幀發(fā)出的時間分別為t0,t1,t2,…,t6，且tout超時重傳時間一樣大。試問如何實現(xiàn)7個超時計時器（這叫軟時鐘法）？例題答：用相對發(fā)送時間實現(xiàn)一個鏈表：實時時鐘t00t1-t01t2-t12指向下一分組分組的序號分組發(fā)送的相對時間TCP可靠通信的具體實現(xiàn)TCP連接的每一端都必須設有兩個窗口——一個發(fā)送窗口和一個接收窗口。TCP的可靠傳輸機制用字節(jié)的序號進行控制。TCP所有的確認都是基于序號而不是基于報文段。TCP兩端的四個窗口經(jīng)常處于動態(tài)變化之中。TCP連接的往返時間RTT也不是固定不變的。需要使用特定的算法估算較為合理的重傳時間。發(fā)送窗口的最大值當用n個比特進行編號時，若接收窗口的大小為1，則只有在發(fā)送窗口的大小WT

2n1時，連續(xù)ARQ協(xié)議才能正確運行。例如，當采用3bit編碼時，發(fā)送窗口的最大值是7而不是8。01234567012發(fā)送窗口WT(a)123456712WT(b)0001234567012發(fā)送窗口WT(c)例題（P221：5-21）

假定使用連續(xù)ARQ協(xié)議，發(fā)送窗口大小是3，而序列范圍[0,15]，而傳輸媒體保證在接收方能夠按序收到分組。在某時刻，接收方，下一個期望收到序號是5。試問：（1）在發(fā)送方的發(fā)送窗口中可能有出現(xiàn)的序號組合有哪幾種？（2）接收方已經(jīng)發(fā)送出去的、但在網(wǎng)絡中（即還未到達發(fā)送方）的確認分組可能有哪些？說明這些確認分組是用來確認哪些序號的分組。例題答：(1)題意表明序號到4為止的分組都已收到。如果按照最正常的情況，網(wǎng)絡傳輸沒有出錯，則發(fā)送窗口的范圍是[2,4]。

如果按照最差的情況，發(fā)送方序號為5的分組傳輸出錯，即使后續(xù)分組傳輸正確，接收方因為要按序接收，所以要重復發(fā)送序號為5的確認，這時發(fā)送窗口應為[5,7]。以上為兩種極端情況，因此發(fā)送窗口可以是[2,4]，[3,5]，[4,6]，[5,7]中的任何一個。例題答：(2)接收方期望收到序號5的分組，說明序號為2,3,4的分組都已收到，并且發(fā)送了確認。對序號為1的分組的確認肯定被發(fā)送方收到了，否則發(fā)送方不可能發(fā)送4號分組?？梢?，對序號為2,3,4的分組的確認有可能仍滯留在網(wǎng)絡中，為ACK3~5。這些確認是用來確認序號為2,3,4的分組。TCP首部20字節(jié)的固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FIN32位SYNRSTPSHACKURG位08162431填充TCP數(shù)據(jù)部分TCP首部TCP報文段IP數(shù)據(jù)部分IP首部發(fā)送在前5.5TCP報文段的首部格式TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充源端口和目的端口字段——各占2字節(jié)。端口是運輸層與應用層的服務接口。運輸層的復用和分用功能都要通過端口才能實現(xiàn)。例題（P221：5-28）

主機A向主機B發(fā)送TCP報文段，首部中的源端口是m而目的端口是n。當B向A發(fā)送回信時，其TCP報文段的首部中源端口和目的端口分別是什么？答：回信TCP報文段的首部中源端口為n,目的端口為m。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充序號字段——占4字節(jié)。TCP連接中傳送的數(shù)據(jù)流中的每一個字節(jié)都編上一個序號。序號字段的值則指的是本報文段所發(fā)送的數(shù)據(jù)的第一個字節(jié)的序號。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充確認號字段——占4字節(jié)，是期望收到對方的下一個報文段的數(shù)據(jù)的第一個字節(jié)的序號。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充數(shù)據(jù)偏移（即首部長度）——占4位，它指出TCP報文段的數(shù)據(jù)起始處距離TCP報文段的起始處有多遠。“數(shù)據(jù)偏移”的單位是32bit位（以4字節(jié)為計算單位）。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充保留字段——占6位，保留為今后使用，但目前應置為0。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充緊急URG——當URG1時，表明緊急指針字段有效。它告訴系統(tǒng)此報文段中有緊急數(shù)據(jù)，應盡快傳送(相當于高優(yōu)先級的數(shù)據(jù))。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充確認ACK——只有當ACK1時確認號字段才有效。當ACK0時，確認號無效。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充推送PSH(PuSH)——接收端TCP收到PSH=1的報文段，就盡快地交付接收應用進程，而不再等到整個緩存都填滿了后再向上交付。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充復位RST(ReSeT)——當RST1時，表明TCP連接中出現(xiàn)嚴重差錯（如由于主機崩潰或其它原因），必須釋放連接，然后再重新建立運輸連接。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充同步SYN——同步SYN=1表示這是一個連接請求或連接接受報文。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充終止FIN(FINis)——用來釋放一個連接。FIN1表明此報文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放運輸連接。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充窗口字段——占2字節(jié)，用來讓對方設置發(fā)送窗口的依據(jù)，單位為字節(jié)。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充檢驗和——占2字節(jié)。檢驗和字段檢驗的范圍包括首部和數(shù)據(jù)這兩部分。在計算檢驗和時，要在TCP報文段的前面加上12字節(jié)的偽首部。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充緊急指針字段——占16位，指出在本報文段中緊急數(shù)據(jù)共有多少個字節(jié)（緊急數(shù)據(jù)放在本報文段數(shù)據(jù)的最前面）。

TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充選項字段——長度可變。TCP最初只規(guī)定了一種選項，即最大報文段長度MSS。MSS告訴對方TCP：“我的緩存所能接收的報文段的數(shù)據(jù)字段的最大長度是MSS個字節(jié)?！盡SS(MaximumSegmentSize)是TCP報文段中的數(shù)據(jù)字段的最大長度。數(shù)據(jù)字段加上TCP首部才等于整個的TCP報文段。其它選項窗口擴大選項——占3字節(jié)，其中有一個字節(jié)表示移位值S。新的窗口值等于TCP首部中的窗口位數(shù)增大到(16+S)，相當于把窗口值向左移動S位后獲得實際的窗口大小。時間戳選項——占10字節(jié)，其中最主要的字段時間戳值字段（4字節(jié)）和時間戳回送回答字段（4字節(jié)）。選擇確認選項——在后面的5.6.3節(jié)介紹。例題（P221：5-22）

主機A向主機B發(fā)送一個很長的文件，其長度為L字節(jié)。假定TCP使用的MSS有1460字節(jié)。（1） 在TCP的序號不重復使用的條件下，L的最大值是多少？（2） 假定使用上面計算出文件長度，而運輸層、網(wǎng)絡層和數(shù)據(jù)鏈路層所使用的首部開銷共66字節(jié)，鏈路的數(shù)據(jù)率為10Mb/s，試求這個文件所需的最短發(fā)送時間。例題主機A向主機B發(fā)送一個很長的文件，其長度為L字節(jié)。假定TCP使用的MSS有1460字節(jié)。（1）在TCP的序號不重復使用的條件下，L的最大值是多少？答：L的最大值是232=4294967296字節(jié)=4GB,G=230。（P193）例題（2） 假定使用上面計算出文件長度，而運輸層、網(wǎng)絡層和數(shù)據(jù)鏈路層所使用的首部開銷共66字節(jié)，鏈路的數(shù)據(jù)率為10Mb/s，試求這個文件所需的最短發(fā)送時間。答：假設每個TCP報文均滿載，則需報文數(shù)：Q=4294967296/1460≈2941758個，余616字節(jié)，需要另一個TCP報文。由此可得總發(fā)送的數(shù)據(jù)量為：N=Q*(MSS+66)+(616+66)=4489123390字節(jié)=35912987120bits，故：文件所需的最短發(fā)送時間=35912987120/107=3591.298712秒≈59.85分≈1小時。TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG位08162431填充填充字段——這是為了使整個首部長度是4字節(jié)的整數(shù)倍。例題（P221：5-27）

一個TCP報文段的數(shù)據(jù)部分最多為多少個字節(jié)？為什么？如果用戶要傳送的數(shù)據(jù)的字節(jié)長度超過TCP報文字段中的序號字段可能編出的最大序號，問還能否用TCP來傳送？例題答：65495字節(jié)，此數(shù)據(jù)部分加上TCP首部的20字節(jié)，再加上IP首部的20字節(jié)，正好是IP數(shù)據(jù)報的最大長度65535.（當然，若IP首部包含了選擇，則IP首部長度超過20字節(jié)，這時TCP報文段的數(shù)據(jù)部分的長度將小于65495字節(jié)。）數(shù)據(jù)的字節(jié)長度超過TCP報文段中的序號字段可能編出的最大序號，通過循環(huán)使用序號，仍能用TCP來傳送。5.6TCP可靠傳輸?shù)膶崿F(xiàn)

5.6.1以字節(jié)為單位的滑動窗口前移不允許發(fā)送已發(fā)送并收到確認A的發(fā)送窗口=20允許發(fā)送的序號26272829303132333435363738394041424344454647484950515253545556B期望收到的序號前沿后沿前移收縮根據(jù)B給出的窗口值A構造出自己的發(fā)送窗口TCP標準強烈不贊成發(fā)送窗口前沿向后收縮不允許發(fā)送已發(fā)送并收到確認A的發(fā)送窗口位置不變允許發(fā)送但尚未發(fā)送262728293031323334353637383940414243444546474849505152535455已發(fā)送但未收到確認56P1P2P3不允許接收已發(fā)送確認并交付主機B的接收窗口允許接收26272829303132333435363738394041424344454647484950515253545556未按序收到可用窗口A發(fā)送了11個字節(jié)的數(shù)據(jù)P3–P1=A的發(fā)送窗口（又稱為通知窗口）P2–P1=已發(fā)送但尚未收到確認的字節(jié)數(shù)P3–P2=允許發(fā)送但尚未發(fā)送的字節(jié)數(shù)（又稱為可用窗口）允許發(fā)送但尚未發(fā)送A的發(fā)送窗口向前滑動262728293031323334353637383940414243444546474849505152535455已發(fā)送并收到確認不允許發(fā)送已發(fā)送但未收到確認56P1P2P3允許接收B的接收窗口向前滑動262728293031323334353637383940414243444546474849505152535455已發(fā)送確認并交付主機不允許接收56未按序收到A收到新的確認號，發(fā)送窗口向前滑動先存下，等待缺少的數(shù)據(jù)的到達不允許發(fā)送已發(fā)送并收到確認A的發(fā)送窗口已滿，有效窗口為零262728293031323334353637383940414243444546474849505152535455已發(fā)送但未收到確認56P1P2P3A的發(fā)送窗口內(nèi)的序號都已用完，但還沒有再收到確認，必須停止發(fā)送。發(fā)送緩存最后被確認的字節(jié)發(fā)送應用程序發(fā)送緩存最后發(fā)送的字節(jié)發(fā)送窗口已發(fā)送TCP序號增大接收緩存接收應用程序已收到接收窗口TCP接收緩存下一個讀取的字節(jié)序號增大下一個期望收到的字節(jié)（確認號）發(fā)送緩存與接收緩存的作用發(fā)送緩存用來暫時存放：

發(fā)送應用程序傳送給發(fā)送方TCP準備發(fā)送的數(shù)據(jù)；TCP已發(fā)送出但尚未收到確認的數(shù)據(jù)。接收緩存用來暫時存放：

按序到達的、但尚未被接收應用程序讀取的數(shù)據(jù)；不按序到達的數(shù)據(jù)。

需要強調(diào)三點A的發(fā)送窗口并不總是和B的接收窗口一樣大（因為有一定的時間滯后）。TCP標準沒有規(guī)定對不按序到達的數(shù)據(jù)應如何處理。通常是先臨時存放在接收窗口中，等到字節(jié)流中所缺少的字節(jié)收到后，再按序交付上層的應用進程。TCP要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷。例題（P221：5-23）

主機A向主機B連續(xù)發(fā)送了兩個TCP報文段，其序號分別為70和100。試問：（1）第一個報文段攜帶了多少個字節(jié)的數(shù)據(jù)？（2）主機B收到第一個報文段后發(fā)回的確認中的確認號應當是多少？（3）如果主機B收到第二個報文段后發(fā)回的確認中的確認號是180，試問A發(fā)送的第二個報文段中的數(shù)據(jù)有多少字節(jié)？（4）如果A發(fā)送的第一個報文段丟失了，但第二個報文段到達了B。B在第二個報文段到達后向A發(fā)送確認。試問這個確認號應為多少？例題答：（1）主機A向主機B連續(xù)發(fā)送了兩個TCP報文段，其序號分別為70和100，第一個報文段攜帶的數(shù)據(jù)序號從70到99，共30字節(jié)數(shù)據(jù)。（2）主機B收到第一個報文段后發(fā)回的確認中的確認號應當是100。（3）如果主機B收到第二個報文段后發(fā)回的確認中的確認號是180，則A發(fā)送的第二個報文段中的數(shù)據(jù)序號從100到179，共80字節(jié)。（4）如果A發(fā)送的第一個報文段丟失了，但第二個報文段到達了B。B在第二個報文段到達后向A發(fā)送確認。這個確認號應為70。例題（P221：5-24）

一個TCP連接下面使用256kb/s的鏈路，其端到端時延為128ms。經(jīng)測試，發(fā)現(xiàn)吞吐量只有120kb/s。試問發(fā)送窗口W是多少？（提示：可以有兩種答案，取決于接收端發(fā)出確認的時機）。兩種情況TDRTTATD+RTTB分組確認tt分組確認ARTTB分組確認tt分組確認情況一設窗口大小為Wbits，接收方在收到一窗口數(shù)據(jù)后才發(fā)送確認，發(fā)送方收到確認后再發(fā)送下一窗口數(shù)據(jù)，則：發(fā)送方將Wbits數(shù)據(jù)送到網(wǎng)絡上所需要時間T0=W/256kbps

發(fā)送方收到確認后經(jīng)過時間T1=T0+128×10-3×2=T0+0.256s；在T1時間內(nèi)共傳送數(shù)據(jù)為：T1×120kbps，其大小應為Wbits（發(fā)送方全部窗口中數(shù)據(jù)），所以：(W/256kbps+0.256s)×120kbps=W

由此解得W=57825.88bits7228字節(jié)。情況二接收方收到發(fā)送方發(fā)送來的很小報文后即發(fā)確認，此時發(fā)送方再次發(fā)送數(shù)據(jù)，用時約為： 128ms×2=256ms，故發(fā)送窗口大小約為： 256×10-3s×120kb/s=30720bits=3840字節(jié)。例題（P222：5-31）

通信信道帶寬為1Gb/s，端到端時延為10ms。TCP的發(fā)送窗口為65535字節(jié)。試問:可能達到的最大吞吐量是多少?信道的利用率是多少?答：設報文長度為L，信道帶寬為C，傳播時延為Td，則：最大吞吐量=L/(L/C+2×Td)=

524280/0.0205242825.5Mb/s信道利用率=(L/C)/(L/C+2×Td)=2.55%。

例題（P221：5-30）

設TCP使用的最大窗口為65535字節(jié)，而傳輸信道不產(chǎn)生差錯，帶寬也不受限制。若報文段的平均往返時延為20ms，問所能得到的最大吞吐量是多少?答：在發(fā)送時延可忽略的情況下，最大數(shù)據(jù)率=最大窗口×8/平均往返時間=26.214Mb/s。(沒有考慮IP和TCP首部)5.6.2超時重傳時間的選擇重傳機制是TCP中最重要和最復雜的問題之一。TCP每發(fā)送一個報文段，就對這個報文段設置一次計時器。只要計時器設置的重傳時間到但還沒有收到確認，就要重傳這一報文段。往返時延的方差很大由于TCP的下層是一個互聯(lián)網(wǎng)環(huán)境，IP數(shù)據(jù)報所選擇的路由變化很大。因而運輸層的往返時間的方差也很大。時間數(shù)據(jù)鏈路層運輸層T1T2T3往返時間的概率分布加權平均往返時間TCP保留了RTT的一個加權平均往返時間RTTS（這又稱為平滑的往返時間）。第一次測量到RTT樣本時，RTTS值就取為所測量到的RTT樣本值。以后每測量到一個新的RTT樣本，就按下式重新計算一次RTTS：

新的RTTS

(1

)(舊的RTTS)

(新的RTT樣本)(5-4)式中，0

1。若很接近于零，表示RTT值更新較慢。若選擇接近于1，則表示RTT值更新較快。RFC2988推薦的值為1/8，即0.125。已知第一次測得TCP的往返時延的當前值是30ms?，F(xiàn)在收到了三個接連的確認報文段，它們比相應的數(shù)據(jù)報文段的發(fā)送時間分別滯后的時間是：26ms、32ms和24ms。設=0.1。試計算每一次的新的加權平均往返時間值RTTS。討論所得出的結果。例題（P222：5-34）

答：根據(jù)題意=0.1，RTTS(0)=30msRTTS(1)=(1-)RTTS(0)+26=29.6msRTTS(2)=(1-)RTTS(1)+32=29.84msRTTS(3)=(1-)RTTS(2)+24=29.256ms三次算出加權平均往返時間分別為29.6，29.84和29.256ms?？梢钥闯觯琑TT的樣本值變化多達20%時，加權平均往返時間的變化卻很小。例題超時重傳時間RTO(RetransmissionTime-Out)

RTO應略大于上面得出的加權平均往返時間RTTS。RFC2988建議使用下式計算RTO：RTORTTS+4RTTD(5-5)RTTD是RTT的偏差的加權平均值。RFC2988建議這樣計算RTTD。第一次測量時，RTTD值取為測量到的RTT樣本值的一半。在以后的測量中，則使用下式計算加權平均的RTTD：新的RTTD=(1

)(舊的RTTD)+

RTTS

新的RTT樣本(5-6)是個小于1的系數(shù)，其推薦值是1/4，即0.25。假定TCP在開始建立連接時，發(fā)送方設定超時重傳時間是RTO=6s。（1）當發(fā)送方接到對方的連接確認報文段時，測量出RTT樣本值為1.5s。試計算現(xiàn)在的RTO值。（2）當發(fā)送方發(fā)送數(shù)據(jù)報文段并接收到確認時，測量出RTT樣本值為2.5s。試計算現(xiàn)在的RTO值。例題（P222：5-33）

答：（1）據(jù)RFC2988建議，RTO=RTTS+4RTTD。其中RTTD是RTTS的偏差加權均值。初次測量時，RTTD(1)=RTT(1)/2；后續(xù)測量中，RTTD(i)=(1-)RTTD(i-1)+

|RTTS-RTT(i)|

=1/4依題意，RTT(1）樣本值為1.5秒，則RTTS(1)=RTT(1)=1.5sRTTD(1)=RTT(1)/2=0.75sRTO(1)=RTTS(1)+4RTTD(1)=1.5+40.75=4.5(s)例題答:（2）RTT(2)=2.5RTTS(1)=1.5sRTTD(1)=0.75sRTTD(2)=(1-)

RTTD

(1)+

|RTTS

(1)-RTT(2)|=0.753/4+|1.5-2.5|/4=13/16RTO(2)=RTTs(1)+4RTTd(2)=1.5+413/16=4.75s例題往返時間RTT?往返時間的測量相當復雜TCP報文段1沒有收到確認。重傳（即報文段2）后，收到了確認報文段ACK。如何判定此確認報文段是對原來的報文段1的確認，還是對重傳的報文段2的確認？發(fā)送一個TCP報文段超時重傳TCP報文段收到ACK時間12往返時間RTT?是對哪一個報文段的確認？Karn算法在計算平均往返時間RTT時，只要報文段重傳了，就不采用其往返時間樣本。這樣得出的加權平均平均往返時間RTTS和超時重傳時間RTO就較準確。報文段每重傳一次，就把RTO增大一些：新的RTO

(舊的RTO)系數(shù)的典型值是2。當不再發(fā)生報文段的重傳時，才根據(jù)報文段的往返時延更新平均往返時延RTT和超時重傳時間RTO的數(shù)值。實踐證明，這種策略較為合理。修正的Karn算法5.6.3選擇確認SACK

(SelectiveACK)

接收方收到了和前面的字節(jié)流不連續(xù)的兩個字節(jié)塊。如果這些字節(jié)的序號都在接收窗口之內(nèi)，那么接收方就先收下這些數(shù)據(jù)，但要把這些信息準確地告訴發(fā)送方，使發(fā)送方不要再重復發(fā)送這些已收到的數(shù)據(jù)。110001501300035014500確認號=1001L1=1501L2=3501R1=3001R1=4501接收到的字節(jié)流序號不連續(xù)……連續(xù)的字節(jié)流………第一個字節(jié)塊第二個字節(jié)塊和前后字節(jié)不連續(xù)的每一個字節(jié)塊都有兩個邊界：左邊界和右邊界。圖中用四個指針標記這些邊界。第一個字節(jié)塊的左邊界L1=1501，但右邊界R1=3001。左邊界指出字節(jié)塊的第一個字節(jié)的序號，但右邊界減1才是字節(jié)塊中的最后一個序號。第二個字節(jié)塊的左邊界L2=3501，而右邊界R2=4501。RFC2018的規(guī)定如果要使用選擇確認，那么在建立TCP連接時，就要在TCP首部的選項中加上“允許SACK”的選項，而雙方必須都事先商定好。如果使用選擇確認，那么原來首部中的“確認號字段”的用法仍然不變。只是以后在TCP報文段的首部中都增加了SACK選項，以便報告收到的不連續(xù)的字節(jié)塊的邊界。由于首部選項的長度最多只有40字節(jié)，而指明一個邊界就要用掉4字節(jié)，因此在選項中最多只能指明4個字節(jié)塊的邊界信息。5.7TCP的流量控制

5.7.1利用滑動窗口實現(xiàn)流量控制一般說來，我們總是希望數(shù)據(jù)傳輸?shù)酶煲恍?。但如果發(fā)送方把數(shù)據(jù)發(fā)送得過快，接收方就可能來不及接收，這就會造成數(shù)據(jù)的丟失。流量控制(flowcontrol)就是讓發(fā)送方的發(fā)送速率不要太快，既要讓接收方來得及接收，也不要使網(wǎng)絡發(fā)生擁塞。利用滑動窗口機制可以很方便地在TCP連接上實現(xiàn)流量控制。seq=1,DATAseq=201,DATAseq=401,DATAseq=301,DATAseq=101,DATAseq=201,DATAseq=501,DATAACK=1,ack=201,rwnd=300ACK=1,ack=601,rwnd=0ACK=1,ack=501,rwnd=100AB允許A發(fā)送序號201至500共300字節(jié)A發(fā)送了序號101至200，還能發(fā)送200字節(jié)A發(fā)送了序號301至400，還能再發(fā)送100字節(jié)新數(shù)據(jù)A發(fā)送了序號1至100，還能發(fā)送300字節(jié)A發(fā)送了序號401至500，不能再發(fā)送新數(shù)據(jù)了A超時重傳舊的數(shù)據(jù)，但不能發(fā)送新的數(shù)據(jù)允許A發(fā)送序號501至600共100字節(jié)A發(fā)送了序號501至600，不能再發(fā)送了不允許A再發(fā)送（到序號600為止的數(shù)據(jù)都收到了）丟失！流量控制舉例A向B發(fā)送數(shù)據(jù)。在連接建立時，

B告訴A：“我的接收窗口rwnd=400（字節(jié)）”。持續(xù)計時器

(persistencetimer)。TCP為每一個連接設有一個持續(xù)計時器。只要TCP連接的一方收到對方的零窗口通知，就啟動持續(xù)計時器。若持續(xù)計時器設置的時間到期，就發(fā)送一個零窗口探測報文段（僅攜帶1字節(jié)的數(shù)據(jù)），而對方就在確認這個探測報文段時給出了現(xiàn)在的窗口值。若窗口仍然是零，則收到這個報文段的一方就重新設置持續(xù)計時器。若窗口不是零，則死鎖的僵局就可以打破了。5.7.2必須考慮傳輸效率可以用不同的機制來控制TCP報文段的發(fā)送時機：第一種機制是TCP維持一個變量，它等于最大報文段長度MSS。只要緩存中存放的數(shù)據(jù)達到MSS字節(jié)時，就組裝成一個TCP報文段發(fā)送出去。第二種機制是由發(fā)送方的應用進程指明要求發(fā)送報文段，即TCP支持的推送(push)操作。第三種機制是發(fā)送方的一個計時器期限到了，這時就把當前已有的緩存數(shù)據(jù)裝入報文段（但長度不能超過MSS）發(fā)送出去。5.8TCP的擁塞控制

5.8.1擁塞控制的一般原理在某段時間，若對網(wǎng)絡中某資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡的性能就要變壞——產(chǎn)生擁塞(congestion)。出現(xiàn)資源擁塞的條件：對資源需求的總和>可用資源(5-7)若網(wǎng)絡中有許多資源同時產(chǎn)生擁塞，網(wǎng)絡的性能就要明顯變壞，整個網(wǎng)絡的吞吐量將隨輸入負荷的增大而下降。擁塞控制與流量控制的關系擁塞控制所要做的都有一個前提，就是網(wǎng)絡能夠承受現(xiàn)有的網(wǎng)絡負荷。擁塞控制是一個全局性的過程，涉及到所有的主機、所有的路由器，以及與降低網(wǎng)絡傳輸性能有關的所有因素。流量控制往往指在給定的發(fā)送端和接收端之間的點對點通信量的控制。流量控制所要做的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來得及接收。擁塞控制所起的作用提供的負載吞吐量理想的擁塞控制實際的擁塞控制0死鎖（吞吐量=0）無擁塞控制擁塞輕度擁塞擁塞控制的一般原理擁塞控制是很難設計的，因為它是一個動態(tài)的（而不是靜態(tài)的）問題。當前網(wǎng)絡正朝著高速化的方向發(fā)展，這很容易出現(xiàn)緩存不夠大而造成分組的丟失。但分組的丟失是網(wǎng)絡發(fā)生擁塞的征兆而不是原因。在許多情況下，甚至正是擁塞控制本身成為引起網(wǎng)絡性能惡化甚至發(fā)生死鎖的原因。這點應特別引起重視。開環(huán)控制和閉環(huán)控制開環(huán)控制方法就是在設計網(wǎng)絡時事先將有關發(fā)生擁塞的因素考慮周到，力求網(wǎng)絡在工作時不產(chǎn)生擁塞。閉環(huán)控制是基于反饋環(huán)路的概念。屬于閉環(huán)控制的有以下幾種措施：監(jiān)測網(wǎng)絡系統(tǒng)以便檢測到擁塞在何時、何處發(fā)生。將擁塞發(fā)生的信息傳送到可采取行動的地方。調(diào)整網(wǎng)絡系統(tǒng)的運行以解決出現(xiàn)的問題。5.8.2幾種擁塞控制方法

1.慢開始和擁塞避免發(fā)送方維持一個叫做擁塞窗口cwnd(congestionwindow)的狀態(tài)變量。擁塞窗口的大小取決于網(wǎng)絡的擁塞程度，并且動態(tài)地在變化。發(fā)送方讓自己的發(fā)送窗口等于擁塞窗口。如再考慮到接收方的接收能力，則發(fā)送窗口還可能小于擁塞窗口。發(fā)送方控制擁塞窗口的原則是：只要網(wǎng)絡沒有出現(xiàn)擁塞，擁塞窗口就再增大一些，以便把更多的分組發(fā)送出去。但只要網(wǎng)絡出現(xiàn)擁塞，擁塞窗口就減小一些，以減少注入到網(wǎng)絡中的分組數(shù)。慢開始算法的原理在主機剛剛開始發(fā)送報文段時可先設置擁塞窗口cwnd=1，即設置為一個最大報文段MSS的數(shù)值。在每收到一個對新的報文段的確認后，將擁塞窗口加1，即增加一個MSS的數(shù)值。用這樣的方法逐步增大發(fā)送端的擁塞窗口cwnd，可以使分組注入到網(wǎng)絡的速率更加合理。發(fā)送方接收方