《計算機網(wǎng)絡（第8版）》 課件 第5、6章 運輸層、應用層

運輸層的基本功能TCP、UDP協(xié)議第

5

章

運輸層運輸層協(xié)議概述運輸層?戶數(shù)據(jù)報協(xié)議

UDP可靠傳輸?shù)?作原理TCP

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

的流量控制TCP

的擁塞控制傳輸控制協(xié)議

TCP

概述TCP

的運輸連接管理TCP

報?段的?部格式運輸層運輸層概述運輸層的作?復?與分?TCP與UDP為什么需要運輸層??絡層最終解決的問題：?分組從?臺主機經(jīng)過?絡到達另?臺主機，即主機到主機間的通信。?絡層沒有解決的問題：??主機中誰發(fā)送的數(shù)據(jù)、誰接收數(shù)據(jù)？IP分組?序到達?的主機，接收進程如何處理？可靠傳輸問題。運輸層運輸層概述運輸層的作?復?與分?TCP與UDP為什么需要運輸層??從通信和信息處理的?度看，運輸層向它上?的應?層提供通信服務，它屬于?向通信部分的最?層，同時也是?戶功能中的最低層。只有位于?絡邊緣部分的主機的協(xié)議棧才有運輸層，??絡核?部分中的路由器在轉發(fā)分組時都只?到下三層的功能。運輸層運輸層概述運輸層的作?復?與分?TCP與UDP郵政?絡應?層運輸層?絡層數(shù)據(jù)鏈路層物理層?絡層數(shù)據(jù)鏈路層物理層應?層運輸層?絡層數(shù)據(jù)鏈路層物理層姓名姓名端?運輸層提供應?進程間的邏輯通信運輸層的作?進程之間的通信?“邏輯通信”的意思是“好像是這樣通信，但事實上并?真的這樣通信”：??從IP層來說，通信的兩端是兩臺主機。但“兩臺主機之間的通信”這種說法還不夠清楚；嚴格地講，兩臺主機進?通信就是兩臺主機中的應?進程互相通信；從運輸層的?度看，通信的真正端點并不是主機?是主機中的進程。也就是說，端到端的通信是應?進程之間的通信。運輸層運輸層概述運輸層的作?復?與分?TCP與UDP?絡層是為主機之間提供邏輯通信，?運輸層為應?進程之間提供端到端的邏輯通信?；ヂ?lián)?絡應?進程應?進程IP協(xié)議的作?范圍TCP和UDP協(xié)議的作?范圍?絡層和運輸層有明顯的區(qū)別運輸層運輸層概述運輸層的作?復?與分?TCP與UDP運輸層復?和分???在?臺主機中經(jīng)常有多個應?進程同時分別和另?臺主機中的多個應?進程通信。表明運輸層有?個很重要的功能：?復?(multiplexing)；分?

(demultiplexing)。?根據(jù)應?程序的不同需求，運輸層需要有兩種不同的運輸協(xié)議：?即?向連接的

TCP

；?連接的

UDP

。運輸層運輸層概述運輸層的作?復?與分?TCP與UDPTCP復?UDP復?端?發(fā)送?應?進程IP復?TCP報?段UDP?戶數(shù)據(jù)報IP數(shù)據(jù)報TCP分?UDP分?端?接收?應?進程IP分?TCP報?段UDP?戶數(shù)據(jù)報IP數(shù)據(jù)報應?層運輸層?絡層?運輸層向?層?戶屏蔽了下??絡核?的細節(jié)，使應?進程感覺在兩個運輸層實體之間有?條端到端的邏輯通信信道?；诙?的復?和分?運輸層復?和分?TCP與UDP（邏輯信道的差異性）?運輸層向?層?戶屏蔽了下??絡核?的細節(jié)，它使應?進程看?的就是好像在兩個運輸層實體之間有?條端到端的邏輯通信信道。運輸層運輸層概述運輸層的作?復?與分?TCP與UDP互聯(lián)?絡TCPUDPUDPTCP邏輯通信信道：可靠、UDP不可靠留?電話聯(lián)系TCP與UDP（邏輯信道的差異性）?運輸層的邏輯通信信道的差別：??當運輸層采??向連接的

TCP

協(xié)議時，盡管下?的?絡是不可靠的，但這種邏輯通信信道就相當于?條全雙?的可靠信道；當運輸層采??連接的

UDP

協(xié)議時，這種邏輯通信信道是?條不可靠信道；TCP靠譜，UDP不靠譜。運輸層運輸層概述運輸層的作?復?與分?TCP與UDP全雙?可靠信道數(shù)據(jù)?向連接的協(xié)議TCP協(xié)議不可靠信道?連接的協(xié)議UDP協(xié)議發(fā)送進程接收進程發(fā)送進程接收進程應?層運輸層可靠信道與不可靠信道數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)運輸層運輸層概述運輸層的作?復?與分?TCP與UDP運輸層運輸層概述運輸層的作?復?與分?TCP與UDP?結?????運輸層協(xié)議概述。為什么需要運輸層。異構計算機進程間的通信。TCP、UDP復?與解復??？煽啃诺琅c不可靠信道。運輸層上協(xié)議????戶數(shù)據(jù)報協(xié)議

UDP

(User

Datagram

Protocol)。傳輸控制協(xié)議

TCP

(Transmission

Control

Protocol)。運輸層傳送的數(shù)據(jù)單元

TPDU

(Transport

Protocol

Data

Unit)：??TCP

傳送的數(shù)據(jù)單位是

TCP

報?段(segment)；UDP

傳送的數(shù)據(jù)單位是

UDP

報?或?戶數(shù)據(jù)報。應?層TCPUDPIP各種?絡接?TCP/IP體系中的運輸層協(xié)議運輸層運輸層協(xié)議UDP和TCP特點典型應?IP與UDP的區(qū)別運輸層端?運輸層UDP和TCP協(xié)議特點?UDP協(xié)議：??????不需要先建?連接，提供?連接服務；協(xié)議數(shù)據(jù)單元為

UDP

報?或?戶數(shù)據(jù)報；收到

UDP

報?后，?需任何確認；UDP

不提供可靠交付；簡單、?持單播、多播、?播；適?于多媒體應?。運輸層運輸層協(xié)議UDP和TCP特點典型應?IP與UDP的區(qū)別運輸層端?UDP和TCP協(xié)議特點?TCP協(xié)議：??????提供?向連接的服務；傳送的數(shù)據(jù)單位協(xié)議是

TCP

報?段

(segment)；TCP

不提供?播或多播服務；收到TCP報?段后，需要確認；協(xié)議復雜、開銷?，占?較多的處理機資源；應?較多：萬維?、電?郵件、?件傳送等。運輸層運輸層協(xié)議UDP和TCP特點典型應?IP與UDP的區(qū)別運輸層端?域名解 動態(tài)主 路由析服務 機配置 選擇……萬維?WWW電?郵件?件傳送……DNS DHCP RIP…… HTTPSMTP

FTP……UDPTCPIP5368520802521UDP和TCP協(xié)議典型應?運輸層運輸層協(xié)議UDP和TCP特點典型應?IP與UDP的區(qū)別運輸層端?UDP和TCP協(xié)議典型應?運輸層運輸層協(xié)議UDP和TCP特點典型應?IP與UDP的區(qū)別運輸層端?應?應?層協(xié)議運輸層協(xié)議名字轉換DNS（域名系統(tǒng)）UDP?件傳送TFTP（簡單?件傳送協(xié)議）UDP路由選擇協(xié)議RIP（路由信息協(xié)議）UDPIP地址配置DHCP（動態(tài)主機配置協(xié)議）UDP?絡管理SNMP（簡單?絡管理協(xié)議）UDP遠程?件服務器NFS（?絡?件系統(tǒng)）UDPIP電話專?協(xié)議UDP流式多媒體通信專?協(xié)議UDP多播IGMP（?際組管理協(xié)議）UDP電?郵件SMTP（簡單郵件傳送協(xié)議）TCP遠程終端接?TELNET（遠程終端協(xié)議）TCP萬維?HTTP（超?本傳送協(xié)議）TCP?件傳送FTP（?件傳送協(xié)議）TCP注意兩點?運輸層的UDP?戶數(shù)據(jù)報與?際層的IP數(shù)據(jù)報有很?區(qū)別：?IP數(shù)據(jù)報要經(jīng)過互聯(lián)?中許多路由器的存儲轉發(fā)；UDP?戶數(shù)據(jù)報是在運輸層的端到端抽象的邏輯信道中傳送的。?TCP報?段是在運輸層抽象的端到端邏輯信道中傳送的：這種信道是可靠的全雙?信道；這種信道不知道究竟經(jīng)過了哪些路由器，?這些路由器也根本不知道上?的運輸層是否建?了TCP連接。運輸層運輸層協(xié)議UDP和TCP特點典型應?IP與UDP的區(qū)別運輸層端?為什么需要“運輸層的端?”??區(qū)分哪些進程復?、分?運輸層；不同操作系統(tǒng)的計算機的應?進程互相通信，就必須?統(tǒng)?的?法對TCP/IP體系的應?進程進?標志，不能?進程標識標志：???運?在計算機中的進程是?進程標識符來標志的；因為在互聯(lián)?上使?的計算機的操作系統(tǒng)種類很多，不同的操作系統(tǒng)使?不同格式的進程標識符；雙?不知道對?的進程，只知道對?提供什么功能。運輸層運輸層協(xié)議UDP和TCP特點典型應?IP與UDP的區(qū)別運輸層端?需要解決的問題?????由于進程的創(chuàng)建和撤銷都是動態(tài)的，發(fā)送??乎?法識別其他機器上的進程。有時我們會改換接收報?的進程，但并不需要通知所有發(fā)送?。我們往往需要利??的主機提供的功能來識別終點，?不需要知道實現(xiàn)這個功能的進程。解決這個問題的?法就是在運輸層使?協(xié)議端?號

(protocol

portnumber)。通信的終點是應?進程，但可以把端?想象是通信的終點，只要把要傳送的報?交到?的主機的?的端?，剩下的?作（即最后交付?的進程）由

TCP

來完成。運輸層運輸層協(xié)議UDP和TCP特點典型應?IP與UDP的區(qū)別運輸層端?為什么需要“運輸層的端?”運輸層運輸層協(xié)議UDP和TCP特點典型應?IP與UDP的區(qū)別運輸層端??通信的終點是“功能”，不是進程，不關?什么進程提供的功能：??客戶瀏覽器：IE、Chrom、Firefox?（都有瀏覽??的功能）服務器軟件：IIS、Apache、Nginx？（都能提供WWW服務）?例如，銀?業(yè)務：??1號窗?對公業(yè)務；2號窗?個?業(yè)務；不關?具體是哪個業(yè)務員辦理業(yè)務（那是操作系統(tǒng)的事）。?端???個

16

位端?號進?標志：端?號只具有本地意義，即端?號只是為了標志本計算機應?層中的各進程；兩個計算機中的進程要互相通信，不僅必須知道對?的

IP

地址（為了找到對?的計算機），?且還要知道對?的端?號（為了找到對?計算機中的應?進程）。IP地址運輸層8053IP地址運輸層端?端?Web服務DNS服務瀏覽器DNS查詢互聯(lián)?絡端?22+?的端?不可達端?兩?類端??服務器端使?的端?號：??熟知端?，數(shù)值?般為

0~1023（全世界都知道的）；登記端?號，數(shù)值為

1024~49151，給沒有熟知端?號的應?程序使?的。使?這個范圍的端?號必須在

IANA

登記，以防?重復。?客戶端使?的端?號：???稱為短暫端?號，數(shù)值為

49152~65535，留給客戶進程暫時使?；當服務器進程收到客戶進程的報?時，就知道了客戶進程所使?的動態(tài)端?號。通信結束后，這個端?號可供其他客戶進程以后使?。運輸層運輸層協(xié)議UDP和TCP特點典型應?IP與UDP的區(qū)別運輸層端?UDPTCPIPFTPDNSTFTPRPC111

53HTTPSHTTPTelnetSNMP(trap)SNMPSMTP69 161 162 25 21 20 23 80 443保存有常?的熟知端?號的?件：??linux中的/etc/servicesWindows中的C:\Windows\System32\drivers\etc\services常?熟知端?號（類似110、120、119等）運輸層運輸層協(xié)議UDP和TCP特點典型應?IP與UDP的區(qū)別運輸層端??結?運輸層兩個協(xié)議TCP、UDP概述：????TCP傳輸數(shù)據(jù)單位；UDP傳輸數(shù)據(jù)單位；UDP?戶數(shù)據(jù)報與IP數(shù)據(jù)報的區(qū)別；邏輯信道的概念。???UDP與TCP的區(qū)別。TCP與UDP典型應?。端?的作?與分類：?常?的熟知端?。運輸層運輸層協(xié)議UDP和TCP特點典型應?IP與UDP的區(qū)別運輸層端??戶數(shù)據(jù)報協(xié)議

UDP?UDP

只在

IP

的數(shù)據(jù)報服務之上增加了很少?點的功能：??復?和分?的功能；差錯檢測的功能。?雖然

UDP

?戶數(shù)據(jù)報只能提供不可靠的交付，但

UDP

在某些??有其特殊的優(yōu)點。運輸層UDP協(xié)議UDP主要特點使?場景報?格式檢驗和計算UDP實例UDPIPUDPIPIPIPIPUDP

的主要特點????不需要建?連接：減少開銷和發(fā)送數(shù)據(jù)之前的時延；盡最?努?交付：即不保證可靠交付；?向報?的：?次交付?個完整的報?，保留原始報?的邊界；沒有擁塞控制：?絡出現(xiàn)擁塞不會降低源主機的發(fā)送速率；????對某些實時應?是很重要的。?持多種交互通信：?持?對?、?對多、多對?和多對多的交互通信。?部開銷?：8

個字節(jié)，?

TCP

的

20

個字節(jié)的?部要短。運輸層UDP協(xié)議UDP主要特點使?場景報?格式檢驗和計算UDP實例什么是“?向報?的

UDP”?發(fā)送?

UDP

對應?程序交下來的報?，添加?部后就向下交付IP

層：?應?層交給

UDP

多?的報?，UDP

就照樣發(fā)送，即?次發(fā)送?個報?；UDP

對應?層交下來的報?，既不合并，也不拆分，保留這些報?的邊界。?接收?UDP去除UDP報??部，原封不動地交付上層的應?進程，?次交付?個完整的報?。運輸層UDP協(xié)議UDP主要特點使?場景報?格式檢驗和計算UDP實例UDP

是?向報?的??應?層產(chǎn)?數(shù)據(jù)交給UDP，UDP打包并直接送到?絡層。應?程序必須選擇合適??的報?：??若報?太?，UDP

把它交給

IP

層后，IP

層在傳送時可能要進?分?，這會降低

IP

層的效率；若報?太短，UDP

把它交給

IP

層后，會使

IP

數(shù)據(jù)報的?部的相對?度太?，這也降低了

IP

層的效率。應?層報?應?層報?UDP?部IP數(shù)據(jù)報數(shù)據(jù)部分IP?部應?層運輸層?絡層運輸層UDP協(xié)議UDP主要特點使?場景報?格式檢驗和計算UDP實例UDP

是?向報?的運輸層UDP協(xié)議UDP主要特點使?場景報?格式檢驗和計算UDP實例UDP公?包UDP公?包互聯(lián)?絡從公?包中取出全部?件將全部?件塞?公?包中?絡不可靠地傳輸公?包UDP

的主要特點（多對?）運輸層UDP協(xié)議UDP主要特點使?場景報?格式檢驗和計算UDP實例P1P2P3P4P5abcxy不可靠的信道

a x b x c y請注意：運輸層之間的這條虛線不是?條連接應?進程復?分?應?層端?運輸層應?層端?運輸層應?進程H1H2UDP協(xié)議的使?場景?可以重復請求信息的情況下：?例如：RIP，DNS，DHCP等。???次性傳?量數(shù)據(jù)的應?（?向報?的）實時應?：?IP電話、視頻會議等。?多媒體應?。運輸層UDP協(xié)議UDP主要特點使?場景報?格式檢驗和計算UDP實例UDP

的?部格式（語法、語義）偽?部源端??的端??度檢驗和源IP地址?的IP地址017UDP?度數(shù)據(jù)IP?部UDP?部數(shù)據(jù)44112字節(jié)字節(jié)122222UDP?戶數(shù)據(jù)報IP數(shù)據(jù)數(shù)據(jù)報發(fā)送在前運輸層UDP協(xié)議UDP主要特點使?場景報?格式檢驗和計算UDP實例偽?部??偽?部不是UDP真實?部，僅僅是為了計算檢驗和。可以理解為UDP的兩次檢查：???次是對IP地址進?檢驗，確認該IP分組是發(fā)送給本機的；?次是對端?號和數(shù)據(jù)進?檢驗，確認交給哪個進程并且數(shù)據(jù)是?誤的。?發(fā)送?：????增加偽?部，UDP?部檢驗和填充0；數(shù)據(jù)部分填充0?4字節(jié)整數(shù)倍；計算機檢驗和，偽?部+?部+數(shù)據(jù)；?部填上檢驗和；刪除偽?部，發(fā)送UDP數(shù)據(jù)報。?接收?：???增加偽?部；計算機檢驗和，偽?部+?部+數(shù)據(jù)；檢驗和全1?差錯，否則丟棄或上交應?進程（附上錯誤警告）。運輸層UDP協(xié)議UDP主要特點使?場景報?格式檢驗和計算UDP實例10 10010110111010111001011011101101取反檢驗和01101001000100101001100100010011153.19：3918700001000011010008.104：21521010101100000011171.3：43779000011100000101114.11：359500000000000100010和17：17000000000000111115：1500000100001111111087：1087000000000000110113：13000000000000111115：1500000000000000000（檢驗和）：00101010001000101data：215730101001101010100data：213320100100101001110data：187660100011100000000data和0（填充）：18176計算UDP檢驗和的例?04101715108713150datadatadatadatadatadatadata0偽?部UDP?部數(shù)據(jù)?進制反碼運算求和將得出的結果求反碼InternetProtocolVersion4,Src:,Dst:

UserDatagramProtocol,SrcPort:53831,DstPort:

53SourcePort:

53831DestinationPort:

53Length:39Checksum:

0xd491DomainNameSystem

(query)應?層DNS運輸層UDP?絡層IP協(xié)議抓取UDP?戶數(shù)據(jù)報（DNS查詢）運輸層UDP協(xié)議UDP主要特點使?場景報?格式檢驗和計算UDP實例?結運輸層UDP協(xié)議UDP主要特點使?場景報?格式檢驗和計算UDP實例?UDP的功能：??復?和分?；差錯檢測功能。???UDP的主要特點。UDP?部格式。UDP檢驗和計算：?偽?部。傳輸控制協(xié)議

TCP

概述?TCP

是?向連接的：???TCP

連接只能有兩個端點，TCP

連接是點對點的（?對?）；TCP

提供可靠交付的服務；TCP

提供全雙?通信。??向字節(jié)流：??TCP

中的“流”(stream)指的是流?或流出進程的字節(jié)序列；?向字節(jié)流的含義是：雖然應?程序和

TCP

的交互是?次?個數(shù)據(jù)塊，但

TCP

把應?程序交下來的數(shù)據(jù)看成僅僅是?連串?結構的字節(jié)流。運輸層TCP協(xié)議?向連接的概念?向字節(jié)流的概念TCP連接的概念傳輸控制協(xié)議

TCP

概述??TCP

不保證接收?應?程序所收到的數(shù)據(jù)塊和發(fā)送?應?程序所發(fā)出的數(shù)據(jù)塊具有對應??的關系。接收?應?程序收到的字節(jié)流必須和發(fā)送?應?程序發(fā)出的字節(jié)流完全?樣。運輸層TCP協(xié)議?向連接的概念?向字節(jié)流的概念TCP連接的概念?個?向連接的概念??向連接的電路交換（物理層保證可靠）：?通信雙?之間必須有?條物理連接的通路（直接相連），且被通信雙?獨享，數(shù)據(jù)按序發(fā)送并按序接收。?向連接的虛電路（?絡層保證可靠）：?通信雙?采?復?技術，逐段占?物理通路，每段物理通路可被多對通信使?，分組按序發(fā)送并按序接收。?向連接TCP（運輸層協(xié)議保證可靠）：?采?協(xié)議的?法（確認、序號、重傳），確保通信雙?有?條全雙?的、可靠的邏輯信道（事實上，提供服務的IP數(shù)據(jù)報是不可靠的），字節(jié)按序發(fā)送并按序接收（但?絡層IP數(shù)據(jù)報并不?定按序到達）。運輸層TCP協(xié)議?向連接的概念?向字節(jié)流的概念TCP連接的概念TCP54TCP18 17 161514212019876H109H131211H0123發(fā)送TCP報?段從接收緩存讀取字節(jié)把字節(jié)寫?發(fā)送緩存加上TCP?部構成TCP報?段字節(jié)流字節(jié)流發(fā)送?接收?應?進程應?進程xH表示TCP報?段的?部表示序號為x的數(shù)據(jù)字節(jié)TCP

?向流的概念TCP連接TCP

連接像?條管道，把字節(jié)可靠地按序傳送到?的進程..TCPTCPTCP連接從接收緩存讀取數(shù)據(jù)塊向發(fā)送緩存寫?字節(jié)塊發(fā)送?接收?應?進程應?進程發(fā)送緩存接收緩存報?段報?段報?段…端?端?TCP

?向流的概念?????TCP

不關?應?進程?次把多?的報?發(fā)送到

TCP

緩存；TCP

對連續(xù)的字節(jié)流進?分段，形成

TCP

報?段；TCP

根據(jù)對?給出的窗?值和?絡擁塞程度決定報?段應包含多少個字節(jié)；TCP

可把?的數(shù)據(jù)塊劃分短?些再傳送；TCP

也可等待積累有?夠多的字節(jié)后再構成報?段發(fā)送出去。不是物理連接TCP

的連接：套接字?TCP把連接作為最基本的抽象：????每?條

TCP

連接有兩個端點；TCP

連接的端點不是主機，不是主機的IP

地址，不是應?進程，也不是運輸層的協(xié)議端?；TCP

連接的端點叫做套接字

(socket)

或插?；端?號拼接到

(contatenated

with)

IP

地址即構成了套接字。運輸層TCP協(xié)議?向連接的概念?向字節(jié)流的概念TCP連接的概念套接字

socket

=

(IP地址

:

端?號)TCP

連接

::=

{socket1,

socket2}={(IP1:port1)，(IP2:

port2)}??同?個

IP

地址可以有多個不同的TCP

連接；同?個端?號也可以出現(xiàn)在多個不同的

TCP

連接中。物流的連接

::={(寄件?通信地址

:

寄件?)，(收件?通信地址:

收件?)}套接字的?個不同含義?????應?編程接? API 稱為

socket

API,

簡稱為

socket。socket

API

中使?的?個函數(shù)名也叫作

socket。調?

socket

函數(shù)的端點稱為

socket。調?

socket

函數(shù)時其返回值稱為

socket

描述符，簡稱為

socket。在操作系統(tǒng)內核中連?協(xié)議的

Berkeley

實現(xiàn)，稱為

socket

實現(xiàn)。運輸層TCP協(xié)議?向連接的概念?向字節(jié)流的概念TCP連接的概念?結?TCP的主要特點：???TCP是?向連接的；TCP提供可靠交付；TCP提供全雙式通信；TCP是?向字節(jié)流的。?TCP的連接：?套接字的概念。運輸層TCP協(xié)議?向連接的概念?向字節(jié)流的概念TCP連接的概念IP

?絡不可靠?類似于?絡購物：??物流運輸?絡不可靠；可靠的買賣由買賣雙?保證。運輸層可靠傳輸原理停?等待協(xié)議?差錯情況有差錯情況?動重傳ARQ利?率流?線傳輸連續(xù)ARQ協(xié)議TCPIPTCPIPIPIPIPIP：物流不可靠TCP：買家和賣家保證可靠理想的傳輸條件特點?理想的傳輸條件有以下兩個特點：??傳輸信道不產(chǎn)?差錯；不管發(fā)送?以多快的速度發(fā)送數(shù)據(jù)，接收?總是來得及處理收到的數(shù)據(jù)。???在這樣的理想傳輸條件下，不需要采取任何措施就能夠實現(xiàn)可靠傳輸。實際的?絡都不具備以上兩個理想條件。必須使??些可靠傳輸協(xié)議，在不可靠的傳輸信道實現(xiàn)可靠傳輸。運輸層可靠傳輸原理停?等待協(xié)議?差錯情況有差錯情況?動重傳ARQ利?率流?線傳輸連續(xù)ARQ協(xié)議停?等待協(xié)議???“停?等待”就是每發(fā)送完?個分組就停?發(fā)送，等待對?的確認。在收到確認后再發(fā)送下?個分組（TCP報?段）。全雙?通信的雙?既是發(fā)送?也是接收?。為了討論問題的?便：??僅考慮

A

發(fā)送數(shù)據(jù)，

B

接收數(shù)據(jù)并發(fā)送確認；A

稱為發(fā)送?，?

B

稱為接收?。運輸層可靠傳輸原理停?等待協(xié)議?差錯情況有差錯情況?動重傳ARQ利?率流?線傳輸連續(xù)ARQ協(xié)議?差錯????A

發(fā)送完分組

M1，暫停發(fā)送；

等待B的確認(ACK)；B

收到了

M1

，向

A

發(fā)送

ACK；A

收到了對

M1

的確認后，發(fā)送下?個分組 M2。收到ACK繼續(xù)發(fā)送確認M1確認M2t停?發(fā)送等待ACKM1ACK1ACK2ABM2t運輸層可靠傳輸原理停?等待協(xié)議?差錯情況有差錯情況?動重傳ARQ利?率流?線傳輸連續(xù)ARQ協(xié)議有差錯情況?在接收?

B

會出現(xiàn)兩種情況：??B

接收

M1

時檢測出了差錯，就丟棄

M1，其他什么也不做；M1

在傳輸過程中丟失了，這時

B

當然什么都不知道，也什么都不做。?如何保證

B

正確收到了

M1

呢？???解決?法：超時重傳；A

為每?個已發(fā)送的分組都設置超時計時器；A

在超時計時器到期之前收到了相應的確認，撤銷該超時計時器，繼續(xù)發(fā)送下?個分組

M2

。運輸層可靠傳輸原理停?等待協(xié)議?差錯情況有差錯情況?動重傳ARQ利?率流?線傳輸連續(xù)ARQ協(xié)議注意?點????A在發(fā)送完?個分組后，必須暫時保留已發(fā)送的分組的副本；分組和確認分組都必須進?編號。這樣才能明確是哪?個發(fā)送出去的分組收到了確認，?哪?個分組還沒有收到確認；超時計時器設置的重傳時間應當?數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更??些。超時重傳時間設置問題：??不能太?；也不能太短。運輸層可靠傳輸原理停?等待協(xié)議?差錯情況有差錯情況?動重傳ARQ利?率流?線傳輸連續(xù)ARQ協(xié)議丟失M1超時重發(fā)M1確認M1ACK1停?發(fā)送等待ACKAB丟棄出錯M1超時重發(fā)M1確認M1ACK1停?發(fā)送等待ACK時間AB時間 時間 時間超時重傳報時?間錯誤≥

RTT；發(fā)送?需要緩存數(shù)據(jù)；必須對數(shù)報據(jù)?編丟號失。出現(xiàn)差錯（發(fā)送的報?出錯或丟失）出現(xiàn)差錯（確認丟失）A

在超時計時器到期后重傳

M1。如果

B

?收到了重傳的分組

M1：丟棄這個重復的分組

M1；向A

發(fā)送確認。丟失M1超時重發(fā)M1ACK1時間時間停?發(fā)送等待ACKABACK1丟棄M1確認M1丟棄M1超時重發(fā)M1確認M1ACK1時間時間停?發(fā)送等待ACKABM2ACK1重復確認收到丟棄?B

對分組

M1

的確認遲到了。??B

丟棄重復的

M1，并重傳確認分組。A

會收到重復的確認：收下后就丟棄。出現(xiàn)差錯（確認遲到）?動重傳請求ARQ????通常A

最終總是可以收到對所有發(fā)出的分組的確認；如果

A

不斷重傳分組但總是收不到確認，就說明通信線路太差，不能進?通信；使?上述的確認和重傳機制，我們就可以在不可靠的傳輸?絡上實現(xiàn)可靠的通信；上述傳輸協(xié)議常稱為?動重傳請求

ARQ：??AutomaticRepeat

reQuest；意思是重傳的請求是?動進?的，接收?不需要請求發(fā)送?重傳某個出錯的分組。運輸層可靠傳輸原理停?等待協(xié)議?差錯情況有差錯情況?動重傳ARQ利?率流?線傳輸連續(xù)ARQ協(xié)議分組確認分組確認TDRTTTD+RTT+

TAAB停?等待協(xié)議的優(yōu)點是簡單，缺點是信道利?率太低tt信道利?率信道利?率：U

=TDTD+RTT+

TA停?等待協(xié)議要點????停?等待。發(fā)送?每次只發(fā)送?個分組。在收到確認后再發(fā)送下?個分組。編號。對發(fā)送的每個分組和確認都進?編號。?動重傳請求。發(fā)送?為每個發(fā)送的分組設置?個超時計時器。若超時計時器超時，發(fā)送?會?動重傳分組。簡單，但信道利?率太低。運輸層可靠傳輸原理停?等待協(xié)議?差錯情況有差錯情況?動重傳ARQ利?率流?線傳輸連續(xù)ARQ協(xié)議分組AB確認tt?由于信道上?直有數(shù)據(jù)不間斷地傳送，信道的利?率?。收到確認之前，發(fā)送?連續(xù)發(fā)出多個分組?流?線傳輸就是發(fā)送?可連續(xù)發(fā)送多個分組，不必每發(fā)完?個分組就停頓下來等待對?的確認。這樣可使信道上?直有數(shù)據(jù)不間斷地傳送。流?線傳輸連續(xù)ARQ協(xié)議?基本思想：?????發(fā)送窗?內的分組都可連續(xù)發(fā)送出去，?需等待對?的確認。即發(fā)送??次可以發(fā)出多個分組；使?滑動窗?協(xié)議控制發(fā)送?和接收?所能發(fā)送和接收的分組的數(shù)量和編號；每收到?個確認，發(fā)送?就把發(fā)送窗?向前滑動；接收??般采?累積確認的?式；采?回退N（Go-Back-N）?法進?重傳。運輸層可靠傳輸原理停?等待協(xié)議?差錯情況有差錯情況?動重傳ARQ利?率流?線傳輸連續(xù)ARQ協(xié)議當使?流?線傳輸時，連續(xù)ARQ協(xié)議和滑動窗?協(xié)議：限制連續(xù)發(fā)送數(shù)據(jù)的量123456789101112待發(fā)送的分組發(fā)送窗?（可發(fā)送的分組）收到?個確認后發(fā)送窗?向前滑動已經(jīng)發(fā)送并收到確認的分組?接收?采?累積確認：???對按序到達的最后?個分組發(fā)送確認；優(yōu)點：容易實現(xiàn)，即使確認丟失也不必重傳；缺點：不能向發(fā)送?反映出接收?已經(jīng)正確收到的所有分組的信息。連接ARQ協(xié)議原理?發(fā)送?發(fā)送了前

5

個分組，第

3

個分組丟失，接收?對收到1、2分組發(fā)出確認，發(fā)送??法知道3、4、5的下落，只好把這三個分組再重傳?次。123456789101112發(fā)送3、4、5、6、7，等待確認其中3、4、5是第?次發(fā)送分組1收、到2對、發(fā)分3送、組窗42、?的5確發(fā)認送完畢?Go-back-N（回退

N）：表示需要再退回來重傳已發(fā)送過的

N

個分組。當通信線路質量不好時，連續(xù)ARQ

協(xié)議會帶來負?的影響。Go-back-N（回退

N）對?內容連續(xù)ARP協(xié)議停?等待協(xié)議發(fā)送的分組數(shù)量?次發(fā)送多個分組?次發(fā)送?個分組傳輸控制滑動窗?協(xié)議停?、等待確認單獨確認、累積確認單獨確認重傳計時器每個發(fā)送的分組每個發(fā)送的分組序號每個發(fā)送的分組每個發(fā)送的分組重傳回退N，多個分組?個分組?結：連續(xù)ARQ

協(xié)議與停?等待協(xié)議對?運輸層可靠傳輸原理停?等待協(xié)議?差錯情況有差錯情況?動重傳ARQ利?率流?線傳輸連續(xù)ARQ協(xié)議TCP

報?段的?部格式?????TCP

報?段?部的前20個字節(jié)是固定的；后?有

4n

字節(jié)是根據(jù)需要?增加的選項；TCP

?部的最??度是

20

字節(jié)；TCP

是?向字節(jié)流的，但

TCP

的數(shù)據(jù)單元是報?段；TCP

報?段分為?部和數(shù)據(jù)兩部分，TCP

的全部功能體現(xiàn)在?部中各字段的作?。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCP報?段?部格式（語法、語義）0 816 24

31源端

??的端

?序

號確認

號數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針選

項（?度可變）填

充發(fā)送在前TCP?部TCP數(shù)據(jù)部分IP?部IP數(shù)據(jù)報的數(shù)據(jù)部分TCP?部20字節(jié)固定部分32位運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCP報?段?部格式（源端?、?的端?）0 816 24

31源端

??的端

?序

號確認

號數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針選

項（?度可變）填

充TCP?部20字節(jié)固定部分32位源端?和?的端?：各占

2

字，是運輸層與應?層的服務接?。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCP報?段?部格式（序號、確認號）0 816 24

31源端

??的端

?序

號（seq）確

認

號（ack）數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針選

項（?度可變）填

充TCP?部20字節(jié)固定部分32位?序號：

4

字節(jié)，指是本報?段所攜帶數(shù)據(jù)的第?個字節(jié)的序號：??也稱為報?段序號；范圍

[

0,

232

–

1

]，序號增加到232

–

1后，下?個序號回到0。?確認號：4

字節(jié)，是期望收到對?的下?個報?段中數(shù)據(jù)的第?個字節(jié)的序號。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCP報?段?部格式（數(shù)據(jù)偏移）0 816 24

31源端

??的端

?序

號確認

號數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針選

項（?度可變）填

充TCP?部20字節(jié)固定部分32位數(shù)據(jù)偏移（即?部?度）：占

4

位，它指出

TCP

報?段的數(shù)據(jù)起始處距離

TCP

報?段的起始處有多遠?！皵?shù)據(jù)偏移”的單位是

32

位字（以

4

字節(jié)為計算單位），最?60字節(jié)。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCP報?段?部格式（緊急、確認）0 816 24

31源端

??的端

?序

號確認

號數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針選

項（?度可變）填

充TCP?部20字節(jié)固定部分32位緊急

URG：當

URG

=

1

時，緊急指針字段有效，此報?段中有緊急數(shù)據(jù)，應盡快傳送。確認ACK：只有當ACK

=

1

時確認號字段才有效。當ACK

=

0

時，確認號?效。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCP報?段?部格式（推送、復位）0 816 24

31源端

??的端

?序

號確認

號數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針選

項（?度可變）填

充TCP?部20字節(jié)固定部分32位推送

PSH：收到

PSH

=

1

的報?段，發(fā)送??即發(fā)送，接收?盡快上交接收應?進程。復位

RST：當

RST

=

1

時，表明

TCP

連接中出現(xiàn)嚴重差錯，必須釋放連接，然后再重新建?運輸連接。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCP報?段?部格式（同步、終?）0 816 24

31源端

??的端

?序

號確認

號數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針選

項（?度可變）填

充TCP?部20字節(jié)固定部分32位同步

SYN：同步SYN

=

1表示這是?個連接請求或連接接受報?。終?

FIN：?來釋放?個連接。FIN

=

1

表明此報?段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放運輸連接。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCP報?段?部格式（窗?）0 816 24

31源端

??的端

?序

號確認

號數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針選

項（?度可變）填

充TCP?部20字節(jié)固定部分32位?窗?字段：占

2

字節(jié)，讓對?設置發(fā)送窗?的依據(jù)，單位為字節(jié)：??[0,

216

–

1

]之間的整數(shù)；告訴對?，從本報?段?部中的確認號算起，接收??前允許對?發(fā)送的數(shù)據(jù)量；運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCP報?段?部格式（檢驗和）0 816 24

31源端

??的端

?序

號確認

號數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針選

項（?度可變）填

充TCP?部20字節(jié)固定部分32位檢驗和：占

2

字節(jié)。檢驗和字段檢驗的范圍包括?部和數(shù)據(jù)這兩部分。在計算檢驗和時，要在

TCP

報?段的前?加上

12

字節(jié)的偽?部。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCP報?段?部格式（緊急指針）0 816 24

31源端

??的端

?序

號確認

號數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針選

項（?度可變）填

充TCP?部20字節(jié)固定部分32位?緊急指針字段：占

16

位，指出在本報?段中緊急數(shù)據(jù)共有多少個字節(jié)，放在本報?段數(shù)據(jù)的最前?（緊急數(shù)據(jù)的最后?個字節(jié)）：URG

=

1

時有效。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCP報?段?部格式（選項）0 816 24

31源端

??的端

?序

號確認

號數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針選

項（?度可變）填

充TCP?部20字節(jié)固定部分32位選項字段：?度可變。TCP

最初只有?種選項，即最?報?段?度MSS。MSS

告訴對?

TCP：“我的緩存所能接收的報?段的數(shù)據(jù)字段的最??度是

MSS

個字節(jié)?！盡SS

(Maximum

Segment

Size)：是TCP

報?段中的數(shù)據(jù)字段的最??度。數(shù)據(jù)字段加上

TCP

?部才等于整個的

TCP

報?段。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充為什么要規(guī)定MSS?提升傳輸效率：???MSS太?，效率太低；MSS太?，IP層需要分?，只要有??出錯，TCP需要重傳；MSS盡可能?些，只要在IP層不分?即可；最佳的MSS很難選擇。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充其他選項???窗?擴?選項：占3字節(jié)，其中有?個字節(jié)表示移位值S。新的窗?值等于TCP?部中的窗?位數(shù)增?到

(16

+

S)，相當于把窗?值向左移動S位后獲得實際的窗???，S

≤

14。時間戳選項：占

10

字節(jié)，其中最主要的字段時間戳值字段（4

字節(jié)）和時間戳回送回答字段（4

字節(jié)）。選擇確認選項：告訴發(fā)送?收到的連續(xù)的字節(jié)塊。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充其他選項：時間戳選項??計算往返時延：發(fā)送把發(fā)送時間放?timestamp，確認報?把該時間戳復制到timestamp

echo字段，并在timestamp放?確認時間。防?序號回繞：232的序號空間對于?帶寬很容易消耗完。1字節(jié)1字節(jié)4字節(jié)4字節(jié)kind=8length=10timestamptimestamp

echo運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充其他選項：時間戳選項TCPOption-Timestamps:TSval830150137,TSecr0Kind:TimeStampOption

(8)Length:

10Timestampvalue:830150137Timestampechoreply:

0運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCPOption-Timestamps:TSval905704537,TSecr830150137Kind:TimeStampOption

(8)Length:

10Timestampvalue:

905704537Timestampechoreply:

830150137Mac-mini:~$ssh-pxxx-luserxx

202.xxx.xxx.xxx其他選項：時間戳選項TCPOption-Timestamps:TSval830150207,TSecr905704537Kind:TimeStampOption

(8)Length:

10Timestampvalue:

830150207Timestampechoreply:

905704537運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充TCP報?段?部格式（選項）0 816 24

31源端

??的端

?序

號確認

號數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針選

項（?度可變）填

充TCP?部20字節(jié)固定部分32位填充字段：這是為了使整個?部?度是

4

字節(jié)的整數(shù)倍。接收端如何判斷哪些是填充字節(jié)？運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充?結?固定?部?度20字節(jié)：????源端?、?的端?；序號、確認號；數(shù)據(jù)偏移（?部?度）；SYN、ACK、FIN、URG、PSH、RST；窗?、檢驗和、緊急指針。?選項最?40字節(jié)：時間戳選項、窗?擴?、選擇確認

。運輸層TCP報?格式源端??的端?序號、確認號數(shù)據(jù)偏移六個控制位窗?、檢驗和緊急指針選項、填充窗?、序號、確認、重傳TCP

可靠傳輸?shù)膶崿F(xiàn)?TCP連接的兩個端點都有兩個窗?：??發(fā)送窗?：準備發(fā)送的數(shù)據(jù)和已發(fā)送但未收到確認的數(shù)據(jù)。接收窗?：按序到達但未被應?程序接收的數(shù)據(jù)、不按序到達的數(shù)據(jù)。???TCP

兩端的四個窗?經(jīng)常處于動態(tài)變化之中。TCP

的可靠傳輸機制?字節(jié)的序號進?控制。TCP

所有的確認都是基于序號?不是基于報?段的。TCP連接的往返時間

RTT

不是固定不變的，需要使?特定的算法估算較為合理的重傳時間。運輸層可靠傳輸?shù)膶崿F(xiàn)加權平均往返時間發(fā)送確認的時機超時重傳時間選擇確認2647272846454142432930 31 323334353637394048493850 51445253545556已發(fā)送并收到確認允許發(fā)送的序號不允許發(fā)送A的發(fā)送窗?

=

20B

期望收到的序號后沿前移前移收縮??A

收到了

B

的確認報?段：窗?值

20

字節(jié)，確認號為

31。根據(jù)這兩個數(shù)據(jù)，A

就構造出??的發(fā)送窗?。A

可以把落?發(fā)送窗?中的序號字節(jié)?次連續(xù)性全部發(fā)送出去：邊發(fā)送邊接收確認。TCP

標準強烈不贊成發(fā)送窗?前沿向后收縮前沿以字節(jié)為單位的滑動窗?264727284645414243293940484930 31 32 33 34 35 36 37 3850 51445253545556已發(fā)送并收到確認允許發(fā)送但未發(fā)送不允許發(fā)送P1A的發(fā)送窗?位置不變已發(fā)送但未收到確認P2P3可?窗?31343537已發(fā)送確認并交付主機不允許接收未按序收到 允許接收B的接收窗????P3

–

P1

=

A

的發(fā)送窗?（?稱為通知窗?）；P2

–

P1

=

已發(fā)送但尚未收到確認的字節(jié)數(shù)；P3

–

P2

=

允許發(fā)送但尚未發(fā)送的字節(jié)數(shù)（?稱為可?窗?）。B收到31，發(fā)送確認33收到確認3326272829303132333738364038394041424344454647484950515253545556A

發(fā)送了11字節(jié)的數(shù)據(jù)以字節(jié)為單位的滑動窗?時間2647272846454142432930313233 3435363739404849503851445253 545556已發(fā)送并收到確認不允許發(fā)送P1已發(fā)送但未收到確認P2P3A

的發(fā)送窗?已滿，有效窗?為

0收到確認33????A

的發(fā)送窗?內的序號都已?完，由于未收到確認，必須停?發(fā)送。A

的發(fā)送窗?并不總是和

B

的接收窗??樣?。未按序到達的數(shù)據(jù)應如何處理：臨時存放在接收窗?中。接收?必須有累積確認的功能，這樣可以減?傳輸開銷。以字節(jié)為單位的滑動窗?接收?發(fā)送確認的時機??接收?可以在合適的時候發(fā)送確認，也可以在??有數(shù)據(jù)要發(fā)送時把確認信息順便捎帶上。注意兩點：??第?，接收?不應過分推遲發(fā)送確認，否則會導致發(fā)送?不必要的重傳；第?，捎帶確認實際上并不經(jīng)常發(fā)?，因為?多數(shù)應?程序很少同時在兩個?向上發(fā)送數(shù)據(jù)。運輸層可靠傳輸?shù)膶崿F(xiàn)加權平均往返時間發(fā)送確認的時機超時重傳時間選擇確認發(fā)送緩存發(fā)送窗?最后被確認的字節(jié)序號增?發(fā)送應?程序最后被發(fā)送的字節(jié)發(fā)送?的應?進程把字節(jié)流寫?

TCP

的發(fā)送緩存已發(fā)送發(fā)送窗?通常只是發(fā)送緩存的?部分TCP發(fā)送應?程序傳送給發(fā)送?

TCP

準備發(fā)送的數(shù)據(jù)；TCP

已發(fā)送出但尚未收到確認的數(shù)據(jù)以及等待進?發(fā)送窗?的數(shù)據(jù)發(fā)送緩存的作?已收到接收緩存接收窗?下?個期望收到的字節(jié)（確認號）序號增?下?個讀取的字節(jié)接收應?程序接收?的應?進程從

TCP的接收緩存中讀取字節(jié)流TCP按序到達的、但尚未被接收應?程序讀取的數(shù)據(jù)；不按序到達的數(shù)據(jù)以及未進?到接收窗?的數(shù)據(jù)接收緩存的作??點注意???第?，A

的發(fā)送窗?是由

B

的接收窗?設置的，但在同?時刻，A的發(fā)送窗?并不總是和

B

的接收窗??樣?；第?，TCP

通常對不按序到達的數(shù)據(jù)是先臨時存放在接收窗?中，等到字節(jié)流中所缺少的字節(jié)收到后，再按序交付上層的應?進程。第三，TCP要求接收?必須有累積確認的功能，這樣可以減?傳輸開銷：???接收?不應過分推遲發(fā)送確認，確認推遲的時間不應超過0.5秒；若收到?連串具有最??度的報?段，則必須每隔?個報?段就發(fā)送?個確認；捎帶確認實際上并不經(jīng)常發(fā)?，因為?多數(shù)應?程序很少同時在兩個?向上發(fā)送數(shù)據(jù)。?TCP

的通信是全雙?通信，通信雙?都有發(fā)送窗?和接收窗?。運輸層可靠傳輸?shù)膶崿F(xiàn)加權平均往返時間發(fā)送確認的時機超時重傳時間選擇確認TCP

超時重傳時間設置???超時重傳時間設置得太短，引起過多的不必要的重傳，?絡負荷增?。超時重傳時間設置得過?，?絡的空閑時間增?，?絡傳輸效率降低。TCP

采?了?種?適應算法：??它記錄?個報?段發(fā)出的時間，以及收到相應的確認的時間；這兩個時間之差就是報?段的往返時間

RTT。運輸層可靠傳輸?shù)膶崿F(xiàn)加權平均往返時間發(fā)送確認的時機超時重傳時間選擇確認加權平均往返時間???TCP

保留了

RTT

的?個加權平均往返時間

RTTS（這?稱為平滑的往返時間）。第?次測量到

RTT

樣本時，RTTS

值就取為所測量到的

RTT

樣本值。以后每測量到?個新的

RTT

樣本，就按下式重新計算?次RTTS：新的

RTTS

=

（1

-

α）×

（舊的RTTS）+

α

×

（新的RTT樣本）???式中，0≤α≤1。若

α

接近于零，表示

RTT

值更新較慢。若選擇

α

接近于

1，則表示

RTT

值更新較快。RFC2988推薦的

α

值為

1/8，即

0.125。運輸層可靠傳輸?shù)膶崿F(xiàn)加權平均往返時間發(fā)送確認的時機超時重傳時間選擇確認超時重傳時間

RTO??RTO

應略?于加權平均往返時間

RTTS。RFC

2988

建議使?下式計算

RTO：RTO =RTTS+4×

RTTD??RTTD

是

RTT

的偏差的加權平均值；第?次測量時，RTTD

值取為測量到的

RTT

樣本值的?半，在以后的測量中，則使?下式計算

RTTD：新的

RTTD

=(1

-

β)×

(舊的RTTD)+

β

×

|

RTTS

-

新的RTT樣本

|β

是個?于

1

的系數(shù)，其推薦值是

1/4，即

0.25。運輸層可靠傳輸?shù)膶崿F(xiàn)加權平均往返時間發(fā)送確認的時機超時重傳時間選擇確認??TCP

報?段

1

沒有收到確認。重傳（即報?段

1）后，收到了確認報?段ACK1。如何判定此確認報?段是對原來的報?段

1

的確認，還是對重傳的報?段

1

的確認？發(fā)送M1重傳M1ACK1ACK1Rt哪個RTT？TTRTTt???Karn

算法：只要報?段重傳了，不采?其往返時間樣本。新的問題：?當時延突然增?了很多時，?段時間內，TCP可能重傳很多報?段;根據(jù)

Karn

算法，不考慮重傳的報?段的往返時間樣本的話，超時重傳時間就?法更新。往返時間

(RTT)

的測量相當復雜報?段每重傳?次，就把

RTO

增??些：???系數(shù)

γ

的典型值是

2

。當不再發(fā)?報?段的重傳時，才根據(jù)報?段的往返時延更新平均往返時延

RTT

和超時重傳時間

RTO

的數(shù)值。實踐證明，這種策略較為合理。新的

RTO

= γ×

（舊的RTO）修正的

Karn

算法運輸層可靠傳輸?shù)膶崿F(xiàn)加權平均往返時間發(fā)送確認的時機超時重傳時間選擇確認選擇確認?問題：?若收到的報?段?差錯，只是未按序號，中間還缺少?些序號的數(shù)據(jù)，那么能否設法只傳送缺少的數(shù)據(jù)?不重傳已經(jīng)正確到達接收?的數(shù)據(jù)？答案：選擇確認

SACK (Selective

ACK)

就是?種可?的處理?法。運輸層可靠傳輸?shù)膶崿F(xiàn)加權平均往返時間發(fā)送確認的時機超時重傳時間選擇確認1501 … 30003501 … 4500確認號

=

1000L1=

1501R1=

3001L2=

3501R2=

4501連續(xù)的字節(jié)流0 … 999第1個字節(jié)塊第2個字節(jié)塊??接收?收到了和前?的字節(jié)流不連續(xù)的兩個字節(jié)塊。如果這些字節(jié)的序號都在接收窗?之內，那么接收?就先收下這些數(shù)據(jù)，但要把這些信息準確地告訴發(fā)送?，使發(fā)送?不要再重復發(fā)送這些已收到的數(shù)據(jù)。接收到的字節(jié)流序號不連續(xù)的問題選擇確認運輸層可靠傳輸?shù)膶崿F(xiàn)加權平均往返時間發(fā)送確認的時機超時重傳時間選擇確認0 816 24

31源端

??的端

?序

號確認

號數(shù)據(jù)偏移保留URGACKPSHRSTSYNFIN窗

?檢驗

和緊急指

針允許SACK填

充TCP?部20字節(jié)固定部分32位??雙?建?

TCP

連接時，在

TCP

?部的選項中加上“允許

SACK”的選項。?部選項的?度最?有

40

字節(jié)，指明?個字節(jié)塊?掉

8

字節(jié)，因此在選項中最多只能指明

4

個字節(jié)塊的邊界信息（另?個字節(jié)?于指明是什么選項）。?結?可靠傳輸?shù)膶崿F(xiàn)：???滑動窗?機制；發(fā)送窗?、接收窗?；確認、序號、重傳。??發(fā)送緩存、接收緩存：超時重傳時間選擇：?RTO =RTTS+4×

RTTDKarn

算法。?新的

RTO =γ×（舊的RTO

）選擇確認。運輸層可靠傳輸?shù)膶崿F(xiàn)加權平均往返時間發(fā)送確認的時機超時重傳時間選擇確認TCP

的流量控制??利?滑動窗?實現(xiàn)流量控制：接收?的接收能?來限制發(fā)送?的發(fā)送能?。TCP

的傳輸效率。運輸層TCP流量控制死鎖問題TCP傳輸效率糊涂窗?綜合癥送速率不要也不要使?絡發(fā)?擁塞。利?滑動窗seq=

1,DATAseq=

101,DATAseq=

201,DATAACK=1,ack=201,rwnd=300seq=

301,DATAseq=

401,DATAseq=

201,DATAACK=1,ack=501,rwnd=100ABA發(fā)送序號1~100，還可發(fā)送300字節(jié)A發(fā)送序號101~200，還可發(fā)送200字節(jié)允許A發(fā)送序號201~500，共300字節(jié)A發(fā)送序號301~400，還可發(fā)送100字節(jié)A發(fā)送序號401~500，停?發(fā)送A超時重傳，不能發(fā)送新數(shù)據(jù)允許A發(fā)送序號501~600，共100字節(jié)讓發(fā)送?的發(fā)

seq

=

501,DATA太快，既要讓接收?A來發(fā)送得序及號接501收~6，00，停?發(fā)送ACK=1,ack=601,rwnd=0?機制在

TCP

連不接允許上A實發(fā)送現(xiàn)數(shù)流據(jù)量控制。

ACK：確認標志ack：確認號seq：序號每個TCP報?攜帶100字節(jié)數(shù)據(jù)丟失！流量控制（A發(fā)B收，B的接收窗?為400字節(jié)）流量控制（A發(fā)B收，B的接收窗?為400字節(jié)）A發(fā)送序號1~100，還可發(fā)送300字節(jié)A發(fā)送序號101~200，還可發(fā)送200字節(jié)允許A發(fā)送序號201~500，共300字節(jié)A發(fā)送序號301~400，還可發(fā)送100字節(jié)A發(fā)送序號401~500，停?發(fā)送A超時重傳，不能發(fā)送新數(shù)據(jù)允許A發(fā)送序號501~600，共100字節(jié)A發(fā)送序號501~600，停?發(fā)送不允許A發(fā)送數(shù)據(jù)

ACK：確認標志ack：確認號seq：序號每個TCP報?攜帶100字節(jié)數(shù)據(jù)seq=

1,DATAseq=

101,DATAseq=

201,DATAACK=1,ack=201,rwnd=300seq=

301,DATAseq=

401,DATAseq=

201,DATAACK=1,ack=501,rwnd=100seq=

501,DATAACK=1,ack=601,rwnd=0AB丟失！丟失！ACK=1,ack=201,rwnd=300seq=

301,DATAseq=

401,D