計算機網(wǎng)絡傳輸層

傳輸層1主要內(nèi)容24.1傳輸層的基本概念傳輸層的作用傳輸層與應用層、網(wǎng)絡層之間的關(guān)系網(wǎng)絡環(huán)境中應用進程標識、端口、套接字多路復用與多路分解4.2傳輸層協(xié)議的特點與比較4.3UDP協(xié)議UDP協(xié)議的主要特點UDP報文格式UDP校驗和的基本概念與計算示例UDP協(xié)議適用的范圍4.4TCP協(xié)議TCP協(xié)議的主要特點TCP報文格式可靠傳輸?shù)墓ぷ髟硗５仁?stop-and-wait）ARQ，回退N幀（go-back-n）ARQ，選擇性重傳（selectiverepeat）ARQTCP可靠通信的具體實現(xiàn)TCP序號和確認號以字節(jié)為單位的滑動窗口超時重傳時間的選擇選擇確認SACKTCP的流量控制TCP的擁塞控制TCP的運輸連接管理4.1傳輸層的基本概念4面向信息處理應用層運輸層網(wǎng)絡層應用層數(shù)據(jù)鏈路層物理層面向通信用戶功能網(wǎng)絡功能是整個網(wǎng)絡體系結(jié)構(gòu)中關(guān)鍵的一層。只有主機的協(xié)議棧才有運輸層。傳輸層的基本功能計算機網(wǎng)絡本質(zhì)的活動是實現(xiàn)分布在不同地理位置的聯(lián)網(wǎng)主機之間的進程通信，以實現(xiàn)各種網(wǎng)絡服務功能；傳輸層的主要作用就是要實現(xiàn)分布式進程通信。傳輸層的作用主機A主機B路由器1路由器2AP1LAN2WANAP2AP3AP4LAN1IP協(xié)議的作用范圍運輸層協(xié)議TCP和UDP的作用范圍IP協(xié)議能夠把源主機發(fā)送出的分組按照首部中的目的地址送交到目的主機，那么為什么還需要再設置一個運輸層呢？對IP層來說，通信的兩端是兩個主機，是“兩個主機之間的通信”；計算機網(wǎng)絡的本質(zhì)是什么？主機間的進程通信實現(xiàn)應用層的各種網(wǎng)絡服務功能運輸層的作用6如何理解端到端的通信？運輸協(xié)議運行在端系統(tǒng)中發(fā)送方：將應用報文劃分為段，傳向網(wǎng)絡層接收方：將段重新裝配為報文，傳向應用層“端-端”進程通信服務的基本概念7運輸層提供應用進程間的邏輯通信；真正進行通信的實體是在主機中的進程；通信的真正端點并不是主機而是主機中的進程；；什么是端到端/endtoend（或進程到進程/processtoprocess）通信？什么是點到點通信？TCP就是用來建立這種端到端連接的一個具體協(xié)議。端到端是傳輸層的比如你要將數(shù)據(jù)從A傳送到E，中間可能經(jīng)過A->B->C->D->E,對于傳輸層來說他并不知道b,c,d的存在，他只認為我的報文數(shù)據(jù)是從a直接到e的，這就叫做端到端?？傊?，一句話概括就是端到端是由無數(shù)的點到點實現(xiàn)和組成的。好像是沿水平方向傳送數(shù)據(jù)，但之間并沒有物理連接，是沿虛線方向經(jīng)過多個層次傳送的。傳輸層與應用層、網(wǎng)絡層之間的關(guān)系傳輸層之間傳輸?shù)膱笪姆Q為傳輸協(xié)議數(shù)據(jù)單元（TPDU）；TPDU有效載荷是應用層的數(shù)據(jù)；傳輸層在有效載荷TPDU之前加上TPDU頭，就形成了TPDU傳輸協(xié)議數(shù)據(jù)單元。9運輸層vs.網(wǎng)絡層網(wǎng)絡層:

主機間的邏輯通信運輸層:

進程間的邏輯通信依賴、強化網(wǎng)絡層服務家庭類比:12個孩子向12個孩子發(fā)信進程=孩子應用報文=信封中的信主機=家庭運輸協(xié)議=Ann和Bill網(wǎng)絡層協(xié)議=郵政服務在Internet上，各個數(shù)據(jù)包根據(jù)其目的主機的ip地址來進行互聯(lián)網(wǎng)絡中的路由選擇。可見，把數(shù)據(jù)包順利的傳送到目的主機是沒有問題的。問題出在哪里呢?我們知道大多數(shù)操作系統(tǒng)都支持多程序（進程）同時運行，那么目的主機應該把接收到的數(shù)據(jù)包傳送給眾多同時運行的進程中的哪一個呢？顯然這個問題有待解決，端口機制便由此被引入進來。端口是應用層的各種協(xié)議進程與運輸實體進行層間交互的一種地址。網(wǎng)絡環(huán)境中應用進程標識11網(wǎng)絡上的計算機中運行的任何網(wǎng)絡應用程序都有一個或多個端口號與之對應。傳輸層尋址是通過端口實現(xiàn)的端口號：每個應用層實體通過自己特定的端口和運輸層實體進行數(shù)據(jù)交換（即對運輸層實體的復用/分用）。為了區(qū)分不同應用層實體的端口，給每個應用層實體的端口賦予了一個唯一的標號，即端口號。端口號是一個16位的地址，取0~65535之間的整數(shù)端口號分為兩類：熟知端口：被限制使用專門分配給一些最常用的服務器進程:如HTTP、FTP、SMTP等。注冊端口號：用戶根據(jù)需要可以在IANA注冊。（IANA(TheInternetAssignedNumbersAuthority，互聯(lián)網(wǎng)數(shù)字分配機構(gòu))是負責協(xié)調(diào)一些使Internet正常運作的機構(gòu)。）臨時端口：隨時分配給請求通信的客戶進程。端口號只具有本地意義，不同計算機中，相同的端口號是沒有關(guān)聯(lián)的。熟知端口號的分配方法UDP的熟知端口號的分配13端口號服務進程說明53domain域名服務67/68DHCP動態(tài)主機配置協(xié)議69TFTP簡單文件傳送協(xié)議111RPC遠程過程調(diào)用123NTP網(wǎng)絡時間協(xié)議161/162SNMP簡單網(wǎng)絡管理協(xié)議520RIP路由信息協(xié)議TCP的熟知端口號的分配14端口號服務進程說明20FTP文件傳輸協(xié)議（數(shù)據(jù)連接）21FTP文件傳輸協(xié)議（控制連接）23TELNET網(wǎng)絡虛擬終端協(xié)議25SMTP簡單郵件傳輸協(xié)議80HTTP超文本傳輸協(xié)議119NNTP網(wǎng)絡新聞傳輸協(xié)議179BGP邊界路由協(xié)議端口的使用本地操作系統(tǒng)會給那些有需求的進程分配協(xié)議端口（protocolport，即我們常說的端口），每個協(xié)議端口由一個正整數(shù)標識，如：80，139，445，等等。當目的主機接收到數(shù)據(jù)包后，將根據(jù)報文首部的目的端口號，把數(shù)據(jù)發(fā)送到相應端口，而與此端口相對應的那個進程將會領(lǐng)取數(shù)據(jù)并等待下一組數(shù)據(jù)的到來。不光接受數(shù)據(jù)包的進程需要開啟它自己的端口，發(fā)送數(shù)據(jù)包的進程也需要開啟端口，這樣，數(shù)據(jù)包中將會標識有源端口，以便接受方能順利的回傳數(shù)據(jù)包到這個端口。端口使用舉例主機A服務器Bsourceport:xdest.port:23sourceport:23dest.port:x端口的使用:簡單的telnet應用Web客戶端主機AWeb服務器BWeb客戶端主機CSourceIP:CDest.IP:Bsourceport:ydest.port:80SourceIP:CDest.IP:Bsourceport:xdest.port:80端口的使用:Web服務器SourceIP:ADestIP:Bsourceport:xdest.port:80….….….….主頁1主頁2Web服務器BWeb客戶端主機ASourceIP:CDest.IP:Bsourceport:ydest.port:80SourceIP:CDest.IP:Bsourceport:xdest.port:80端口的使用:Web服務器….….….….考慮：1.同一主機多個應用進程，發(fā)往同一個目的端口？？？2.不同的主機隨即源端口相同，發(fā)往同一目的端口？？？Web客戶端主機ASourceIP:ADestIP:Bsourceport:xdest.port:80TCP使用“連接”（而不僅僅是“端口”）作為最基本的標識。一個TCP連接由它的兩個端點來標識。這樣的端點就叫做“插口”，或“套接字”。插口/套接字/Socket每個主機（可用IP地址唯一標識）都可以獨立分配自己的端口號，因此為了在通信時不至于發(fā)生混亂，就必須把端口號和IP地址結(jié)合在一起使用，用于區(qū)別同時通信的多個主機中的多個進程。插口/Socket，是因特網(wǎng)中某一個通信端點的標識，它由IP地址（32位）和端口號（16位）構(gòu)成。服務器套接字地址唯一地定義服務器應用程序；客戶機套接字地址唯一地定義客戶機應用程序；由于套接字是建立網(wǎng)絡應用程序的可編程接口，因此套接字又稱為應用程序編程接口（API）。運輸層實際上并沒有直接將數(shù)據(jù)交付給進程，而是通過一個中間的套接字來傳遞不同的網(wǎng)絡系統(tǒng)，不同的傳輸層協(xié)議；不同的傳輸層協(xié)議之間不能通信；網(wǎng)絡中一個進程的全網(wǎng)唯一的標識需要用一個三元組表示協(xié)議、本地地址、本地端口號一個完整的進程通信標識需要用一個五元組表示協(xié)議、本地地址、本地端口號、遠程地址、遠程端口號連接一的客戶端套接字是3:500服務器端的套接字是5:25圖中標識連接1的五元組是（TCP,3:500,5:25）傳輸層的多路復用與多路分解22復用/分解應用層運輸層網(wǎng)絡層鏈路層物理層P1應用層運輸層網(wǎng)絡層鏈路層物理層應用層運輸層network鏈路層物理層P2P3P4P1主機1主機2主機3=進程=套接字從多個套接字收集數(shù)據(jù)，用首部封裝數(shù)據(jù)(以后用于分解)在發(fā)送主機復用:將接收到的段交付給正確的套接字在接收主機分解：多路復用/分解——運輸層支持一臺主機上多個進程通過一個單一的網(wǎng)絡接口實現(xiàn)數(shù)據(jù)發(fā)送/接收操作發(fā)送端AP1AP2AP3AP4AP5AP6接收端傳輸信道傳輸信道多路復用/多路分解的實現(xiàn)要保證復用/分用的進程都有唯一的標識（套接字標識符）每個報文段要有特定的字段指示所要交付的套接字分解工作過程1.無連接分解生成具有端口號的套接字:DatagramSocketmySocket1=newDatagramSocket(99111);DatagramSocketmySocket2=newDatagramSocket(99222);UDP套接字由二元組標識:(目的地IP地址,目的地端口號)當主機接收UDP段時:在段中檢查目的地端口號將UDP段定向到具有該端口號的套接字具有不同源IP地址和/或源端口號的IP數(shù)據(jù)報定向到相同的套接字無連接分解DatagramSocket

serverSocket=newDatagramSocket(6428);客戶機IP:BP2客戶機IP:AP1P1P3服務器IP:CSP:6428DP:9157SP:9157DP:6428SP:6428DP:5775SP:5775DP:6428SP提供了“返回地址”2.面向連接分解TCP套接字由四元組標識:源IP地址源端口號目的IP地址目的端口號接收主機使用這四個值來將段定向到適當?shù)奶捉幼址掌髦鳈C可能支持許多并行的TCP套接字：每個套接字由其自己的四元組標識Web服務器對每個連接的客戶機具有不同的套接字非持久HTTP將為每個請求具有不同的套接字P1客戶機IP:AP1P2P4服務器IP:CSP:9157DP:80SP:9157DP:80P5P6P3D-IP:CS-IP:AD-IP:CS-IP:BSP:5775DP:80D-IP:CS-IP:B客戶機IP:BP1客戶機IP:AP1P2服務器IP:CSP:9157DP:80SP:9157DP:80P4P3D-IP:CS-IP:AD-IP:CS-IP:BSP:5775DP:80D-IP:CS-IP:B高性能web服務器：同一端口建立多個連接，每個連接創(chuàng)建一個新的線程同一端口建立多個連接，每個連接產(chǎn)生一個新的進程。連接套接字與進程間并非總是一一對應4.2傳輸層協(xié)議的特點與比較TCP/IP的運輸層有兩個不同的協(xié)議：(1)用戶數(shù)據(jù)報協(xié)議UDP (UserDatagramProtocol)(2)傳輸控制協(xié)議TCP (TransmissionControlProtocol)1.TCP與UDP協(xié)議的比較特征/描述TCPUDP一般描述允許應用程序可靠地發(fā)送數(shù)據(jù)，功能齊全簡單、高速，只負責將應用層與網(wǎng)絡層銜接起來面向連接或無連接面向連接，在TPDU傳輸之前需要建立TCP連接無連接，在TPDU傳輸之前不需要建立UDP連接與應用層的數(shù)據(jù)接口基于字節(jié)流，應用層不需要規(guī)定特定的數(shù)據(jù)格式基于報文，應用層需要將數(shù)據(jù)分成包來傳送可靠性與確認可靠報文傳輸，對所有的數(shù)據(jù)均要確認不可靠，不需要對傳輸?shù)臄?shù)據(jù)確認，盡力而為地交付重傳自動重傳丟失的數(shù)據(jù)不負責檢查是否丟失數(shù)據(jù)和重傳開銷高于UDP很低傳輸速率低于UDP很高適用的數(shù)據(jù)量從少量到幾個GB的數(shù)據(jù)從少量到幾百個字節(jié)的數(shù)據(jù)適用的應用類型對數(shù)據(jù)傳輸可靠性要求較高的應用，例如文件與報文傳輸發(fā)送數(shù)量比較少、對數(shù)據(jù)傳輸可靠性要求較低的應用，例如IP電話、視頻會議、多播與廣播302.TCP、UDP協(xié)議與應用層協(xié)議的關(guān)系應用數(shù)據(jù)丟失帶寬時間敏感文件傳輸不能丟失彈性不電子郵件不能丟失彈性不Web文檔不能丟失彈性不即時訊息不能丟失彈性是和不是實時音頻視頻容忍丟失音頻（幾kb/s-1Mb/s）是，100ms視頻（10kb/s-5Mb/s）交互式游戲容忍丟失幾kb/s-1Mb/s是，100ms一些因特網(wǎng)應用在可靠性、帶寬及時間方面的要求32SMTPHTTPTelnetFTPDNSRIPDHCPIP電話流媒體如果設計一個只提供必要服務的最簡化的運輸層協(xié)議，你打算怎樣做？4.3UDP協(xié)議考慮使用一個無所事事的運輸層協(xié)議發(fā)送方將來自應用進程的報文直接交給網(wǎng)絡層。接收方將來自網(wǎng)絡層的報文直接交給應用進程。正如前一節(jié)所學運輸層必須做一點兒事，而不是什么都不做！至少必須提供一個多路復用/多路分解服務，在網(wǎng)絡層與正確的應用進程之間傳遞數(shù)據(jù)。1.UDP協(xié)議的主要特點：34只提供多路復用/分解功能及一些簡單的差錯檢查。應用程序幾乎是直接與IP打交道“盡力而為”服務，UDP段可能：丟包對應用程序交付失序無連接:在UDP發(fā)送方和接收方之間無握手每個UDP段的處理獨立于其他段面向報文的傳輸層協(xié)議為何要有UDP協(xié)議?應用層能夠更好地控制要發(fā)送的數(shù)據(jù)和發(fā)送時間；無需建立連接(它將增加時延)；不維護連接狀況；分組首部開銷?。粺o擁塞控制:UDP能夠盡可能快地傳輸常用于流式多媒體應用丟包容忍速率敏感經(jīng)UDP的可靠傳輸:在應用層增加可靠性應用程序特定的差錯恢復！缺乏擁塞控制會導致UDP發(fā)送方和接收方之間的高丟包率，并擠垮TCP會話；需要擁塞控制來預防網(wǎng)絡進入一種低效狀態(tài)；提出新的機制執(zhí)行自適應擁塞機制2.UDP報文格式UDP報文有固定8字節(jié)的報頭。36應用層數(shù)據(jù)占用了UDP報文段的數(shù)據(jù)字段。UDP報頭主要字段：端口號端口號字段包括源端口號和目的端口號；端口號字段長度為16位（2個字節(jié)）；源端口號表示發(fā)送端進程端口號，目的端口號表示接收端進程端口號；如果源進程是客戶端，則源端口號是分配的臨時端口號；服務器使用的是熟知端口號。37長度長度字段長度也是16位（2字節(jié)），它定義了包括報頭在內(nèi)的用戶數(shù)據(jù)報的總長度；用戶數(shù)據(jù)報的長度最大為65535字節(jié)，最小是8字節(jié)；如果長度字段是8字節(jié)，那么說明該用戶數(shù)據(jù)報只有報頭，而沒有數(shù)據(jù)。38校驗和UDP校驗和用來檢驗整個用戶數(shù)據(jù)報（包括報頭）在傳輸中是否出現(xiàn)差錯。有錯就丟棄。UDP校驗和包括三個部分：偽報頭（pseudoheader）、UDP報頭與應用層數(shù)據(jù)。39鏈路中或路由器中噪聲干擾偽首部源端口目的端口長度檢驗和數(shù)據(jù)首部UDP長度源IP地址目的IP地址017IP數(shù)據(jù)報字節(jié)44112122222字節(jié)發(fā)送在前數(shù)據(jù)首部UDP用戶數(shù)據(jù)報3.UDP校驗和的基本概念與計算示例在計算檢驗和時，臨時把“偽首部”和UDP用戶數(shù)據(jù)報連接在一起。偽首部既不向下傳送也不向上提交，僅僅是為了計算檢驗和。協(xié)議號填充字段不包括偽報頭校驗和計算方法把首部和數(shù)據(jù)部分一起都檢驗發(fā)送方:先把全零放入檢驗和字段將段內(nèi)容（偽首部和UDP數(shù)據(jù)報）處理為16bit整數(shù)序列數(shù)據(jù)部分不是16bit整數(shù)倍要需要填寫一個全零字節(jié)（但此字節(jié)不發(fā)送）；計算檢查和:段內(nèi)容的加法(反碼和)發(fā)送方將檢查和放入UDP檢查和字段接收方:所有段內(nèi)容（偽首部和UDP數(shù)據(jù)報）二進制求和計算16位的和結(jié)果全為1，說明數(shù)據(jù)傳輸正確，丟棄偽報頭和填充，接收！如果出現(xiàn)零，則有差錯，接收方應丟棄（也可以交給應用層，但附上出現(xiàn)了差錯的警告）偽首部源端口目的端口長度檢驗和UDP長度源IP地址目的IP地址017字節(jié)44112122222字節(jié)注意當數(shù)字作加法時，最高位進比特位的進位需要加到結(jié)果中例子:兩個16-bit整數(shù)相加111100110011001101110101010101010111011101110111011

11

101110111011110010100010001000011回卷和檢查和發(fā)送端計算UDP校驗和的例子43算法簡單，處理快，但檢錯能力不強4.UDP協(xié)議適用的范圍確定應用程序在傳輸層是否采用UDP協(xié)議的原則：系統(tǒng)對性能的要求高于對數(shù)據(jù)完整性的要求；需要“簡短快捷”的數(shù)據(jù)交換；需要多播和廣播的應用；

UDP協(xié)議是一種適用于實時語音與視頻傳輸?shù)膫鬏攲訁f(xié)議。444.4TCP協(xié)議4.4.1TCP協(xié)議的主要特點支持面向連接的傳輸服務應用程序在使用TCP傳送數(shù)據(jù)之前，必須在源進程端口與目的進程端口之間建立一條傳輸連接；每個TCP連接唯一地用雙方套接字來標識；每個TCP連接為通信雙方的一次進程通信提供服務。45支持字節(jié)流的傳輸流（stream）指的是流入到進程或從進程流出的字節(jié)序列。TCP把應用層數(shù)據(jù)看成是無結(jié)構(gòu)字節(jié)流，不知道字節(jié)流的含義。TCP根據(jù)接收方給出的窗口大小和網(wǎng)絡擁塞程度來決定一個報文段應包括多少個字節(jié)。（UDP報文長度是應用層給出的）因此接收端應用程序數(shù)據(jù)字節(jié)的起始與終結(jié)位置必須由應用程序自己確定。46TCP協(xié)議

支持字節(jié)

流傳輸

示意圖47發(fā)送和接收緩沖區(qū)由于通信的雙方都設置有發(fā)送和接收緩沖區(qū)，應用程序?qū)⒁l(fā)送的數(shù)據(jù)字節(jié)提交給發(fā)送緩沖區(qū)，數(shù)據(jù)字節(jié)的實際發(fā)送過程由TCP協(xié)議來控制；接收端在接收到數(shù)據(jù)字節(jié)之后也將它存放到接收緩沖區(qū)，高層應用程序在它合適的時間到緩沖區(qū)中讀取數(shù)據(jù)。支持全雙工服務TCP允許通信雙方的應用程序在任何時候都可以發(fā)送數(shù)據(jù)；流量控制發(fā)送方不能淹沒接收方擁塞控制抑止發(fā)送方速率來防止過分占用網(wǎng)絡資源49支持同時建立多個并發(fā)的TCP連接根據(jù)應用程序的需要，TCP協(xié)議支持一個服務器與多個客戶端同時建立多個TCP連接；也支持一個客戶端與多個服務器同時建立多個TCP連接；50支持可靠傳輸服務TCP是一種可靠的傳輸服務協(xié)議，它使用確認機制檢查數(shù)據(jù)是否安全和完整地到達，并且提供擁塞控制功能；TCP支持可靠數(shù)據(jù)通信的關(guān)鍵是對發(fā)送和接收的數(shù)據(jù)進行跟蹤、確認與重傳；傳輸層傳輸?shù)目煽啃允墙⒃诰W(wǎng)絡層基礎上，同時也就會受到它們的限制。51總結(jié)TCP協(xié)議的特點是：面向連接面向字節(jié)流支持全雙工支持并發(fā)連接提供確認重傳與擁塞控制524.4.2TCP報文格式TCP報頭長度為20～60字節(jié)，其中固定部分長度為20字節(jié)；選項部分長度可變，最多為40字節(jié)。53TCP報頭包括的主要字段：端口號端口號字段包括源端口號與目的端口號；每個端口號字段長度為16位（2字節(jié)），分別表示發(fā)送該報文段的應用進程的源端口號與接收進程的目的端口號。序號序號字段長度為32位（4個字節(jié)），序號范圍在0～（232-1），即0～4284967295；序號增加到232-1后，下一個序號又回到0；為發(fā)送字節(jié)流中的每個字節(jié)都按順序編號；起始序號必須在連接建立時設置；序號字段值是本報文段所發(fā)送的數(shù)據(jù)的第一個字節(jié)的序號54確認號確認號字段長度為32位（4字節(jié)）；確認號表示一個進程已經(jīng)正確接收序號為N的字節(jié)，要求發(fā)送方下一個應該發(fā)送序號為N+1的字節(jié)的報文段?？蓪?GB的數(shù)據(jù)進行編號。在一般情況下可保證數(shù)據(jù)當序號重復使用時，舊序號的數(shù)據(jù)早已通過網(wǎng)絡到達終點了。報頭長度報頭長度字段的長度為4位;TCP報頭長度是以4字節(jié)為一個單元來計算的，實際報頭長度是在20～60字節(jié)，因此這個字段的值是在5至15之間。55控制字段控制字段定義了6種不同的控制位或標志位;控制字段將在TCP的連接建立和終止、流量控制，以及數(shù)據(jù)傳送中發(fā)揮作用。56標志說明SYN在連接時對序號進行同步。ACK確認字段的值有效。當ACK=1時，確認號才有效。FIN終止連接RST連接必須復位。TCP連接出現(xiàn)嚴重差錯要重新建立連接。還可用來拒絕一個非法報文段或拒絕打開一個鏈接。URG緊急指針字段的值有效。有緊急數(shù)據(jù)盡快傳送，插入到報文段最前面，與緊急指針配合使用。PSH將數(shù)據(jù)推向前，希望立即收到對方響應。接收方收到后盡快交付給接收應用進程。窗口大小窗口字段長度為16位;窗口的長度值是在0～65535之間；窗口字段值指示對方最多可以發(fā)送的字節(jié)數(shù)，作為發(fā)送方確定發(fā)送窗口的依據(jù)。明確指出了從被確認的字節(jié)算起可以發(fā)送的數(shù)據(jù)量。窗口字段值是動態(tài)變化的。窗口值為0也是合法的。表示接收方暫時不能接收數(shù)據(jù)，發(fā)送方要停止發(fā)送。57校驗和計算校驗和與UDP校驗和的方法相同；TCP校驗和同樣需要偽報頭，唯一不同的是協(xié)議字段的值是6。緊急指針緊急指針字段的長度為16位，只有當緊急標志URG=1時，這個字段才有效，這時的報文段中包括緊急數(shù)據(jù)；指出了緊急數(shù)據(jù)的末尾在報文段中的位置。TCP軟件要在優(yōu)先處理完緊急數(shù)據(jù)之后才能夠恢復正常操作。注意，即使窗口為零時也可以發(fā)送緊急數(shù)據(jù)。偽首部UDP長度源IP地址目的IP地址06字節(jié)4411212字節(jié)TCP最大段長度（MSS）理解MSS時需要注意以下幾個問題：TCP報文段的最大長度與窗口長度的概念不同。設置窗口大小是通知發(fā)送方下一次可以連續(xù)傳輸?shù)淖止?jié)數(shù)；最大段長度MSS是在構(gòu)成一個TCP報文段時最多可以在報文的數(shù)據(jù)字段中放置的數(shù)據(jù)字節(jié)數(shù)量；MSS值的確定與每次傳輸?shù)拇翱诖笮o關(guān)；MSS是TCP報文中數(shù)據(jù)部分的最大長度，不包括報頭長度。59MSS值的選擇應該考慮的因素：MSS值太小——協(xié)議開銷TCP報文的長度等于報頭部分加上數(shù)據(jù)部分，選擇MSS值太小會增大協(xié)議開銷所占的比例。MSS值太大——IP分片如果MSS值選擇得比較大，受到IP分組長度的限制，較長的報文段在IP層將會被分片傳輸；分片的結(jié)果同樣會增加網(wǎng)絡層的開銷和傳輸出錯的概率。IP分組經(jīng)歷的路徑是動態(tài)變化的，因此這條路徑不需要分片的MSS，如果該走另一條路徑就可能需要分片。最佳的MSS是很難確定的。60MSS值的設定在建立TCP連接的時候，雙方把自己能夠支持的MSS寫入這一字段中，以后按照這個值傳送數(shù)據(jù)。（不是協(xié)商，只是通知對方）TCP允許連接的雙方可以選擇使用不同的MSS值。若主機未填寫，則默認的MSS值為536字節(jié)。61窗口擴大選項首部中窗口字段16位，最大為64K字節(jié)。對于衛(wèi)星信道的網(wǎng)絡，要獲得高吞吐率需要更大的窗口；其中有一個字節(jié)表示移位值S。新窗口值等于16+S。移位值允許使用的最大值是14。相當于窗口增大到216+14雙方建立連接時協(xié)商。當不再需要擴大時，可發(fā)送S=0時間戳占10個字節(jié)，主要是時間戳值字段（4個字節(jié)）和時間戳回送回答字段（4個字節(jié)）；計算往返時間RTT。發(fā)送方在發(fā)送時把當前時間值放入時間戳字段，接收方在確認報文段時把時間戳字段值復制到時間戳回送回答字段。發(fā)送方收到確認后，可以準確計算出RTT。用于處理TCP序號超過的232情況，稱為防止序號繞回。當使用高速網(wǎng)絡時發(fā)送序號很可能被重復使用，為了是接收方能夠把新的報文段和遲到報文段區(qū)分開，可以加上時間戳。0050/源端口：8005A6/目的端口：1446A3853DB7/發(fā)送序號：2743418295C7FBC12C/確認序號：33551649727012/01110000000100100111/首部長度：7*4=28字節(jié)000000/保留：010010/標志位：URG/ACK/PSH/RST/SYN/FINACK：1SYN：116D0/窗口大小：58402A32/校驗和：108020000/緊急指針：0020405B401010402/選項字段：

MSS：05B4=1460字節(jié)05A6/源端口：14460050/目的端口：80C7FBC12C/發(fā)送序號：3355164972A3853DB8/確認序號：27434182965010/01010000000100000101/首部長度：5*4=20字節(jié)000000/保留：010000/標志位：URG/ACK/PSH/RST/SYN/FINACK：1FFFF/窗口大?。?55356DC6/校驗和：281020000/緊急指針：04.4.3可靠傳輸?shù)墓ぷ髟砝硐氲膫鬏敆l件有以下兩個特點：傳輸信道不產(chǎn)生差錯。不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù)，接收方總是來得及處理收到的數(shù)據(jù)。需要可靠傳輸協(xié)議做到：出現(xiàn)差錯時讓發(fā)送方重傳出現(xiàn)差錯的數(shù)據(jù)；接收方來不及處理收到的數(shù)據(jù)時，及時告訴發(fā)送方適當降低發(fā)送數(shù)據(jù)的速度。只討論可靠傳輸?shù)囊话阍?，并不具體針對某一層！?。“l(fā)送方如何知道發(fā)送成功還是失?。糠纸M丟失或遲到怎么辦？已經(jīng)發(fā)送的分組可以馬上丟棄么？如何區(qū)分重傳分組或新的分組？如何區(qū)分對哪個分組的確認？否定確認是否可以不用？Rdt1.0超時計時器的重傳時間設置多長比較合適？肯定確認(acknowledgement)否定確認(negativeacknowledgement)每發(fā)送完一個分組后啟動計時器應當比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一些對發(fā)送分組和確認分組編號必須暫時保留已發(fā)送的分組的副本，只有收到確認后才能清除超時自動重傳，通常只使用肯定確認m0ack0m1m1×m1ack1m0ack0ack0×m0m0丟棄ack0timeouttimeout

m1超時重傳

m0超時重傳Rdt1.0——停等協(xié)議（StopandWait）停等協(xié)議的主要問題是什么？傳輸效率低1Gb/s帶寬,15ms端到端傳播時延,1K字節(jié)分組信道利用率萬分之2.7；吞吐量33kB/s

網(wǎng)絡協(xié)議限制了物理資源的使用!TDRTTATD+RTTB分組確認tt分組確認TD=8kb/pkt10**9b/sec=8msL(packetlengthinbits)R(transmissionrate,bps)=如何解決？可以在等待確認的時間內(nèi)允許發(fā)送方連續(xù)發(fā)送，而不必等待確認分組的到達可以在等待確認的時間內(nèi)允許發(fā)送方連續(xù)發(fā)送，這種技術(shù)被稱為流水線或管道化技術(shù)（Pipelining）Rdt2.0——回退N幀協(xié)議（GO-Back-N，GBN）連續(xù)發(fā)送的數(shù)據(jù)中有一個被損壞了或丟失了，怎么辦？等待重傳B分組ttAACK接收方如何處理后續(xù)到達的正確分組呢？丟棄并且不發(fā)送確認，從出錯的分組開始全部重傳GBN累積確認（CumulativeAcknowledge）在分組n超時定時器到期之前收到對更高序號分組k的確認，則可認為n到k之間所有的分組都已經(jīng)收到?？梢圆槐貙γ總€分組都逐個確認，可以等待若干個分組按序到達后發(fā)送一個確認對某個分組的確認丟失了，也不會因為確認丟失而重傳這個分組例題：采用回退N幀協(xié)議，發(fā)送方已經(jīng)發(fā)送了0-7序號的分組，計時器超時，只收到0，3序號的確認分組，問需要重發(fā)哪幾個分組？需要重發(fā)4、5、6、7m0m1m2m3m0m1m0m1m2m2m3m3m1

×m2丟棄m3丟棄m1m1m2m2m3m3ack0timeouttimeoutack3m1超時重傳累積確認Go-Back-Nack2ack2

×GBN協(xié)議的主要問題是什么？一個分組的差錯可能引起大量正確接收（但失序）的分組重傳如何解決？僅重傳那些出錯的分組Rdt3.0——選擇性重傳協(xié)議（Selectiverepeat，SR）接收方將正確的分組接收緩存起來而不管其是否有序，直到所有丟失分組都被收到，才可以將一批分組按序交付給上層。發(fā)送方只重傳出錯的分組m0m1m2m3m0m1m0m1m2m2m3m3m1

×m1m1ack0timeouttimeoutack3m1超時重傳ack2ack1計時取消接收方緩沖區(qū)溢出，數(shù)據(jù)丟失如何解決？必須進行流量控制保證數(shù)據(jù)的完整性流水線技術(shù)對可靠數(shù)據(jù)傳輸帶來哪些影響？發(fā)送方如何確定哪些分組是可以發(fā)送的？維持一個發(fā)送窗口（sendingwindow）窗口內(nèi)的分組可以發(fā)送接收方如何確定哪些分組是可以接收？維持一個接收窗口（receivingwindow）窗口內(nèi)的分組可以接收允許發(fā)送但尚未發(fā)送不允許發(fā)送已發(fā)送并收到確認A的發(fā)送窗口01234567891617181920已發(fā)送但未收到確認151011121314允許接收不允許接收已發(fā)送并交付主機B的接收窗口01234567891617181920未按序收到151011121314如何使用窗口控制流量？滑動窗口012345678901234567890123456789012345678901234567890123456789×0123456789012340123456789012345678901234567891340123456789×13GBN協(xié)議——窗口示意圖0timeouttimeout0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567892401234567890123456789012345678901234567890123456789012345678901234567890123456789×01234567890123456789012345678901234567890123450123456789012345678901234567892012345678913SR協(xié)議——窗口示意圖00123456789452timeouttimeout可靠數(shù)據(jù)傳輸機制及用途總結(jié)機制用途和說明檢驗和用于檢測在一個傳輸分組中的比特錯誤。定時器用于檢測超時/重傳一個分組，可能因為該分組（或其ACK）在信道中丟失了。由于當一個分組被時延但未丟失（過早超時），或當一個分組已被接收方收到但從接收方到發(fā)送方的ACK丟失時，可能產(chǎn)生超時事件，所以接收方可能會收到一個分組的多個冗余拷貝。序號用于為從發(fā)送方流向接收方的數(shù)據(jù)分組按順序編號。所接收分組的序號間的空隙可使該接收方檢測出丟失的分組。具有相同序號的分組可使接收方檢測出一個分組的冗余拷貝。確認接收方用于告訴發(fā)送方一個分組或一組分組已被正確地接收到了。確認報文通常攜帶著被確認的分組或多個分組的序號。確認可以是逐個的或累積的，這取決于協(xié)議。否定確認接收方用于告訴發(fā)送方某個分組未被正確地接收。否定確認報文通常攜帶著未被正確接收的分組的序號。（通常并不發(fā)送否定確認）窗口、流水線發(fā)送方也許被限制僅發(fā)送那些序號落在一個指定范圍內(nèi)的分組。通過允許一次發(fā)送多個分組但未被確認，發(fā)送方的利用率可在停等操作模式的基礎上得到增加。我們很快將會看到，窗口長度可根據(jù)接收方接收和緩存報文的能力或網(wǎng)絡中的擁塞程度，或兩者情況來進行設置。4.4.4TCP可靠通信的具體實現(xiàn)

TCP的可靠傳輸機制用字節(jié)的序號進行控制。TCP所有的確認都是基于序號而不是基于報文段。TCP連接的每一端都必須設有兩個窗口——一個發(fā)送窗口和一個接收窗口。

TCP兩端的四個窗口經(jīng)常處于動態(tài)變化之中。TCP連接的往返時間RTT也不是固定不變的。需要使用特定的算法估算較為合理的重傳時間。1.TCP序號和確認號序號:報文段中第1個數(shù)據(jù)字節(jié)在字節(jié)流中的位置編號確認號:期望從對方收到下一個字節(jié)的序號累計應答問題：接收方如何處理失序報文段？回答：TCP規(guī)范沒有說明，由實現(xiàn)者自行選擇實現(xiàn):拋棄/緩存主機A主機BSeq=42,ACK=79,data=‘C’Seq=79,ACK=43,data=‘C’Seq=43,ACK=80用戶鍵入‘C’主機對接收到的‘C’回顯給出確認主機對收到的‘C’給出確認,

回顯‘C’時間簡單的telnet情況捎帶確認注意：TCP確認針對流中的字節(jié)而不是段。累計的含義表示，如果某一方使用5643作為確認號，那么它就已經(jīng)收到了一直到5642和這以前的所有字節(jié)。應當注意的是，這并不表示這一方已經(jīng)收到了5642個字節(jié)，因為第一個字節(jié)的編號不一定從0開始。累計確認的優(yōu)點：變長段方式下不會產(chǎn)生二義性確認丟失后不一定導致重傳累計確認的缺點：發(fā)送方不能獲得關(guān)于所有成功的段傳輸?shù)男畔?，假如前面尚有?shù)據(jù)未得到確認，尚有數(shù)據(jù)未得到確認，則后面的所有成功傳輸?shù)亩我驳貌坏酱_認。

考慮：假設主機A通過TCP連接向主機B連續(xù)發(fā)送兩個TCP報文段。第一個報文段的發(fā)送序號為90，第二個報文段的發(fā)送序號為110.1.第一個報文段中有多少數(shù)據(jù)？2.假設第一個報文段丟失第二個報文段到達主機B。那么主機B發(fā)送給A的確認報文中，確認序號應該是多少？字節(jié)流傳輸?shù)臓顟B(tài)分類2.以字節(jié)為單位的滑動窗口SendandackedSendandnotackedWaitingtobesentNotintheWindows前移不允許發(fā)送已發(fā)送并收到確認A的發(fā)送窗口=20允許發(fā)送的序號26272829303132333435363738394041424344454647484950515253545556B期望收到的序號前沿后沿前移收縮根據(jù)B給出的窗口值A構(gòu)造出自己的發(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ā)送。緩存和窗口的關(guān)系發(fā)送方的應用進程把字節(jié)流寫入TCP的發(fā)送緩存，接收方的應用進程從TCP的就收緩存中讀取字節(jié)流。要明確兩點：緩存空間和序號空間都是有限的，并循環(huán)使用；實際上緩存緩存或窗口中的字節(jié)數(shù)是非常大的。發(fā)送緩存最后被確認的字節(jié)發(fā)送應用程序發(fā)送緩存最后發(fā)送的字節(jié)發(fā)送窗口已發(fā)送TCP序號增大最后寫入的字節(jié)發(fā)送緩存用來暫時存放：1.發(fā)送應用程序傳送給發(fā)送方TCP準備發(fā)送的數(shù)據(jù)；2.TCP已經(jīng)發(fā)送出但尚未收到確認的數(shù)據(jù)。接收緩存接收應用程序已收到接收窗口TCP接收緩存下一個讀取的字節(jié)序號增大下一個期望收到的字節(jié)（確認號）按序到達的未按序到達的接收緩存用來暫時存放：1.按序到達的、但尚未被接收應用程序讀取的數(shù)據(jù)；2.未按需到達的數(shù)據(jù)；需要強調(diào)三點A的發(fā)送窗口并不總是和B的接收窗口一樣大（因為有一定的時間滯后）。發(fā)送方根據(jù)自身的狀況，根據(jù)接收到的窗口信息發(fā)送字節(jié)流，不一定要發(fā)送整個窗口大小的數(shù)據(jù)。TCP標準沒有規(guī)定對不按序到達的數(shù)據(jù)應如何處理。通常是先臨時存放在接收窗口中，等到字節(jié)流中所缺少的字節(jié)收到后，再按序交付上層的應用進程。TCP要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷。接收方可以在合適的時候發(fā)送確認，在自己有數(shù)據(jù)要發(fā)送時把確認信息捎帶上。接收方不應過分推遲發(fā)送確認，會導致不必要的重傳，TCP規(guī)定推遲時間不應超過05秒。若收到具有最大長度的報文段，則必須每隔一個報文段就要發(fā)送一個確認。捎帶確認實際上并不經(jīng)常發(fā)生，大多數(shù)應用程序不同時在兩個方向上發(fā)送數(shù)據(jù)。3.超時重傳時間的選擇重傳機制是TCP中最重要和最復雜的問題之一。TCP每發(fā)送一個報文段，就對這個報文段設置一次重傳計時器。只要計時器設置的重傳時間到但還沒有收到確認，就要重傳這一報文段。重傳計時器重傳計時器用來處理報文確認與等待重傳時間；重傳計時器的工作過程：95設定重傳計時器的時間值需要注意的幾個問題設定重傳計時器適當?shù)臅r間值對于協(xié)議至關(guān)重要。一個主機同時與其他兩個主機建立兩條TCP連接，那么它就需要分別為每個TCP連接啟動一個重傳計時器，不可能對不同的TCP連接使用一個重傳計時器；由于互聯(lián)網(wǎng)在不同時間段的用戶數(shù)量、流量與傳輸延遲變化也很大，因此即使是相同的兩個主機在不同時間建立的TCP連接，并且完成同樣的Web訪問操作，客戶端與服務器端之間的報文傳輸延遲也不會相同。在互聯(lián)網(wǎng)環(huán)境中為TCP連接確定合適的重傳定時器數(shù)值是很困難的，必然要選擇使用一種動態(tài)的自適應重傳方法。RFC2988“計算TCP重傳定時器”文檔詳細討論了這個問題。96計算重傳時間的方法——加權(quán)平均往返時間TCP保留了RTT的一個加權(quán)平均往返時間

RTTS（這又稱為平滑的往返時間）。第一次測量到RTT樣本時，RTTS值就取為所測量到的RTT樣本值。以后每測量到一個新的RTT樣本，就按下式重新計算一次RTTS：新的RTTS

(1

)(舊的RTTS)

(新的RTT樣本)式中，0

1。若很接近于零，表示RTT值更新較慢。若選擇接近于1，則表示RTT值更新較快。RFC2988推薦的值為1/8，即0.125。超時重傳時間RTO(RetransmissionTime-Out)RTO應略大于上面得出的加權(quán)平均往返時間RTTS。對于每個TCP連接都要維持一個RTT變量，它是當前到達目的結(jié)點在最佳估計往返延時值。自適應重傳定時基于往返時間（RTT），計算重傳時間的公式為：

Timeout=β×RTT其中，β為一個大于1的常數(shù)加權(quán)因子；RTT為估算的往返時間；往返時間RTT?往返時間的測量相當復雜TCP報文段1沒有收到確認。重傳（即報文段2）后，收到了確認報文段ACK。如何判定此確認報文段是對原來的報文段1的確認，還是對重傳的報文段2的確認？發(fā)送一個TCP報文段超時重傳TCP報文段收到ACK時間12往返時間RTT?是對哪一個報文段的確認？Karn

算法在計算平均往返時間RTT時，只要報文段重傳了，就不采用其往返時間樣本。這樣得出的加權(quán)平均平均往返時間RTTS

和超時重傳時間RTO就較準確。報文段每重傳一次，就把RTO增大一些：新的RTO

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

算法討論：α決定RTT對延遲變化的反應速度；當α接近1時，短暫的延遲變化對RTT不起作用；當α接近0時，RTT將緊緊跟隨延遲變化。β因子很難確定；當β接近1時，TCP能迅速檢測報文丟失，及時重傳，減少等待時間，但是可能引起很多重傳報文；當β太大時，重傳報文減少，但是等待確認的時間太長；作為折衷，TCP推薦β=2；以往返時間（RTT）為基礎的重傳超時可以是動態(tài)的。因此，使用最多的是設重傳時間為RTT的兩倍。102已知：收到了3個連接的確認報文段，它們比相應的數(shù)據(jù)報文段發(fā)送時間分別滯后26ms、32ms與24ms。假設：α=0.9。求：新的估計往返延時值為多少？

解：從題意中可以找出以下的已知條件：α=0.9，舊RTT=30ms，M1=26ms，M2=32ms，M3=24ms。根據(jù)公式可以計算出：RTT1=0.9×30+（1-0.9）×26≈29.6（ms）RTT2=0.9×29.6+（1-0.9）×32≈29.8（ms）RTT3=0.9×29.8+（1-0.9）×24≈29.3（ms）答案：新的往返延時估計值分別為29.6（ms）、

29.8（ms）與29.3（ms）。1034.選擇確認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é)塊的邊界信息。另外還需要兩個字節(jié)1個字節(jié)指明“SACK”選項。1個字節(jié)指明這個選項占用多少個字節(jié)。4.4.5TCP的流量控制

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é)）”。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=100B丟失！持續(xù)計時器

(persistencetimer)。假定接收端的TCP通告窗口大小為零。發(fā)送方的TCP就停止傳送報文，直到接收端的TCP發(fā)送確認并通告一個非零的窗口大小，這個確認可能會丟失。對方的TCP都在永遠地等待著對方，這就可能出現(xiàn)了死鎖；為了防止死鎖，TCP為每個連接使用一個堅持計時器(或持續(xù)計時器)。只要TCP連接的一方收到對方的零窗口通知，就啟動持續(xù)計時器。若持續(xù)計時器設置的時間到期，就發(fā)送一個零窗口探測報文段（僅攜帶1字節(jié)的數(shù)據(jù)），而對方就在確認這個探測報文段時給出了現(xiàn)在的窗口值。若窗口仍然是零，則收到這個報文段的一方就重新設置持續(xù)計時器。若窗口不是零，則死鎖的僵局就可以打破了。堅持計時器的值設置為重傳時間值，這個值增大到門限值通常設定為60秒。

2必須考慮傳輸效率如何控制發(fā)送方TCP報文段的發(fā)送時機:第一種機制是TCP維持一個變量，它等于最大報文段長度MSS。只要緩存中存放的數(shù)據(jù)達到MSS字節(jié)時，就組裝成一個TCP報文段發(fā)送出去。第二種機制是由發(fā)送方的應用進程指明要求發(fā)送報文段，即TCP支持的推送(push)操作。第三種機制是發(fā)送方的一個計時器期限到了，這時就把當前已有的緩存數(shù)據(jù)裝入報文段（但長度不能超過MSS）發(fā)送出去。如何控制接收方確認報文段的發(fā)送時機：糊涂窗口綜合癥：接收方發(fā)送只有1B的窗口更新報文。接收要等待一段時間，使得接收緩存已有足夠空間容納一個最大報文段，或緩存已有一半的空閑的空間。4.4.6TCP的擁塞控制

1.擁塞控制的一般原理在某段時間，若對網(wǎng)絡中某資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡的性能就要變壞——產(chǎn)生擁塞(congestion)。出現(xiàn)資源擁塞的條件：對資源需求的總和>可用資源若網(wǎng)絡中有許多資源同時產(chǎn)生擁塞，網(wǎng)絡的性能就要明顯變壞，整個網(wǎng)絡的吞吐量將隨輸入負荷的增大而下降。擁塞控制與流量控制的關(guān)系擁塞控制是一個全局性的過程，涉及到所有的主機、所有的路由器，以及與降低網(wǎng)絡傳輸性能有關(guān)的所有因素。擁塞控制就是防止過多的數(shù)據(jù)注入到網(wǎng)絡中，這樣可以使網(wǎng)絡中的路由器或鏈路不致過載流量控制往往指在給定的發(fā)送端和接收端之間的點對點通信量的控制。流量控制所要做的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來得及接收。擁塞控制所起的作用提供的負載吞吐量理想的擁塞控制實際的擁塞控制0死鎖（吞吐量=0）無擁塞控制擁塞輕度擁塞提供的負載：代表單位時間內(nèi)輸入給網(wǎng)絡的分組數(shù)目，也稱為輸入負載或網(wǎng)絡負載。吞吐量：代表單位時間內(nèi)從網(wǎng)絡輸出的分組數(shù)目。吞吐量達到飽和（輸入的某些分組被丟棄了）（吞吐量未達到飽和時就有輸入的分組被丟棄了）（吞吐量隨提供的負載的增大而下降）擁塞控制的一般原理擁塞控制是很難設計的，因為它是一個動態(tài)的（而不是靜態(tài)的）問題。當前網(wǎng)絡正朝著高速化的方向發(fā)展，這很容易出現(xiàn)緩存不夠大而造成分組的丟失。但分組的丟失是網(wǎng)絡發(fā)生擁塞的征兆而不是原因。開環(huán)控制和閉環(huán)控制開環(huán)控制方法就是在設計網(wǎng)絡時事先將有關(guān)發(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)的問題。2.幾種擁塞控制方法

慢開始和擁塞避免發(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ā)送方接收方發(fā)送M1

確認M1發(fā)送M2~M3

確認M2~M3發(fā)送M4~M7

確認M4~M7cwnd=1cwnd=2cwnd=4發(fā)送M8~M15cwnd=8…tt發(fā)送方每收到一個對新報文段的確認（重傳的不算在內(nèi)）就使cwnd

加1。輪次1輪次2輪次3傳輸輪次

(transmissionround)使用慢開始算法后，每經(jīng)過一個傳輸輪次，擁塞窗口cwnd

就加倍。一個傳輸輪次所經(jīng)歷的時間其實就是往返時間RTT?！皞鬏斴喆巍备訌娬{(diào)：把擁塞窗口cwnd

所允許發(fā)送的報文段都連續(xù)發(fā)送出去，并收到了對已發(fā)送的最后一個字節(jié)的確認。例如，擁塞窗口cwnd=4，這時的往返時間RTT就是發(fā)送方連續(xù)發(fā)送4個報文段，并收到這4個報文段的確認，總共經(jīng)歷的時間。設置慢開始門限狀態(tài)變量ssthresh慢開始門限ssthresh

的用法如下：當cwnd<ssthresh

時，使用慢開始算法。當cwnd>ssthresh

時，停止使用慢開始算法而改用擁塞避免算法。當cwnd=ssthresh

時，既可使用慢開始算法，也可使用擁塞避免算法。擁塞避免算法的思路是讓擁塞窗口cwnd

緩慢地增大，即每經(jīng)過一個往返時間RTT就把發(fā)送方的擁塞窗口cwnd

加1，而不是加倍，使擁塞窗口cwnd

按線性規(guī)律緩慢增長。當網(wǎng)絡出現(xiàn)擁塞時無論在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡出現(xiàn)擁塞（其根據(jù)就是沒有按時收到確認），就要把慢開始門限ssthresh

設置為出現(xiàn)擁塞時的發(fā)送方窗口值的一半（但不能小于2）。然后把擁塞窗口cwnd

重新設置為1，執(zhí)行慢開始算法。這樣做的目的就是要迅速減少主機發(fā)送到網(wǎng)絡中的分組數(shù)，使得發(fā)生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。2216慢開始和擁塞避免算法的實現(xiàn)舉例當TCP連接進行初始化時，將擁塞窗口置為1。圖中的窗口單位不使用字節(jié)而使用報文段。慢開始門限的初始值設置為16個報文段，即ssthresh=16?！俺朔p小”24681012141618200048122024擁塞窗口cwnd新的ssthresh

值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh

的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”傳輸輪次慢開始和擁塞避免算法的實現(xiàn)舉例發(fā)送端的發(fā)送窗口不能超過擁塞窗口cwnd

和接收端窗口rwnd

中的最小值。我們假定接收端窗口足夠大，因此現(xiàn)在發(fā)送窗口的數(shù)值等于擁塞窗口的數(shù)值。2216“乘法減小”24681012141618200048122024擁塞窗口cwnd新的ssthresh

值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh

的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”傳輸輪次慢開始和擁塞避免算法的實現(xiàn)舉例在執(zhí)行慢開始算法時，擁塞窗口cwnd

的初始值為1，發(fā)送第一個報文段M0。

2216“乘法減小”24681012141618200048122024擁塞窗口cwnd新的ssthresh

值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh

的初始值慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”傳輸輪次慢開始和擁塞避免算法的實現(xiàn)舉例發(fā)送端每收到一個確認，就把cwnd

加1。于是發(fā)送端可以接著發(fā)送M1和M2兩個報文段。2216“乘法減小”24681012141618200048122024擁塞窗口cwnd新的ssthresh

值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh

的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”傳輸輪次慢開始和擁塞避免算法的實現(xiàn)舉例接收端共發(fā)回兩個確認。發(fā)送端每收到一個對新報文段的確認，就把發(fā)送端的cwnd

加1?，F(xiàn)在cwnd

從2增大到4，并可接著發(fā)送后面的4個報文段。2216“乘法減小”24681012141618200048122024擁塞窗口cwnd新的ssthresh

值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh

的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”傳輸輪次慢開始和擁塞避免算法的實現(xiàn)舉例發(fā)送端每收到一個對新報文段的確認，就把發(fā)送端的擁塞窗口加1，因此擁塞窗口cwnd

隨著傳輸輪次按指數(shù)規(guī)律增長。2216“乘法減小”24681012141618200048122024擁塞窗口cwnd新的ssthresh

值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh

的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”傳輸輪次慢開始和擁塞避免算法的實現(xiàn)舉例當擁塞窗口cwnd

增長到慢開始門限值ssthresh

時（即當cwnd=16時），就改為執(zhí)行擁塞避免算法，擁塞窗口按線性規(guī)律增長。2216“乘法減小”24681012141618200048122024擁塞窗口cwnd新的ssthresh

值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh

的初始值慢開