計算機網絡2014年9月國防科技學院第3章運輸層計算機網絡2應用層:包含大量應用普遍需要的協議，支持網絡應用FTP,SMTP,HTTP運輸層:

主機到主機數據傳輸，負責從應用層接收消息，并傳輸應用層的message，到達目的后將消息上交應用。TCP,UDP網絡層:從源到目的地數據報的選路IP,選路協議鏈路層:在鄰近網元之間傳輸數據PPP,以太網物理層:物理層負責將鏈路層幀中每一位(bit)從鏈路的一端傳輸到另一端。應用層運輸層網絡層鏈路層物理層TCP/IP五層模型3我們的目的:

理解運輸層服務依據的原理:Multiplexing(多路復用)/demultiplexing（多路分解）可靠數據傳輸flowcontrol（流量控制）congestioncontrol（擁塞控制）學習因特網中的運輸層協議：UDP:無連接傳輸TCP:面向連接傳輸TCP擁塞控制第3章:運輸層43.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數據傳輸的原理3.5面向連接的傳輸:TCP3.6擁塞控制的原則3.7TCP擁塞控制5在運行不同主機上應用進程之間提供邏輯通信運輸協議運行在端系統中發送方：將應用報文（messages）劃分為報文段（segments），傳向網絡層接收方：將段重新裝配為報文，傳向應用層應用程序可供使用的運輸協議不止一個因特網：TCP和UDP應用層運輸層網絡層數據鏈路層物理層網絡層數據鏈路層物理層應用層運輸層網絡層數據鏈路層物理層網絡層數據鏈路層物理層網絡層數據鏈路層物理層網絡層數據鏈路層物理層網絡層數據鏈路層物理層邏輯端到端傳輸運輸服務和協議動畫：多層通信實質6網絡層:

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

進程間的邏輯通信依賴、強化網絡層服務家庭類比:12個孩子向12個孩子發信進程=孩子應用報文=信封中的信主機=家庭運輸協議=Ann和Bill網絡層協議=郵政服務運輸層vs.網絡層7可靠的、按序的交付(TCP)擁塞控制流量控制連接建立不可靠、無序的交付:UDP差錯檢測不可用的服務:時延保證帶寬保證應用層運輸層網絡層數據鏈路層物理層網絡層數據鏈路層物理層應用層運輸層網絡層數據鏈路層物理層網絡層數據鏈路層物理層網絡層數據鏈路層物理層網絡層數據鏈路層物理層網絡層數據鏈路層物理層邏輯端到端傳輸因特網運輸層協議83.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數據傳輸的原理3.5面向連接的傳輸:TCP3.6擁塞控制的原則3.7TCP擁塞控制9應用層運輸層網絡層鏈路層物理層P1應用層運輸層網絡層鏈路層物理層應用層運輸層網絡層鏈路層物理層P2P3P4P1主機1主機2主機3=進程=套接字將接收到的段交付給相應的套接字（一路到多路，向上）在接收主機分解：從多個套接字收集數據，用首部封裝數據（多路到一路，向下）在發送主機復用:多路復用/多路分解10主機接收IP數據報每個數據報有源IP地址,目的IP地址每個數據報承載1個運輸層報文段每個段具有源、目的端口號

(回想:對特定應用程序的周知端口號)源端口#目的端口#32bits應用數據(報文)其他首部字段TCP/UDP報文段格式分解工作過程主機使用IP地址&端口號將報文段導向到相應的套接字11UDP套接字由二元組全面標識:(目的地IP地址,目的地端口號)當主機接收UDP段時:在段中檢查目的地端口號將UDP段定向到具有該端口號的套接字具有不同源IP地址和/或源端口號的IP數據報（目的IP地址和端口號相同）定向到相同的套接字無連接多路復用與分解12客戶機IP:BP2客戶機IP:AP1P1P3服務器IP:CSP:6428DP:9157SP:9157DP:6428SP:6428DP:5775SP:5775DP:6428SP提供了“返回地址”無連接多路復用與分解(續)=進程=套接字13TCP套接字由四元組（4-tuple）標識:源IP地址源端口號目的IP地址目的端口號接收主機使用這四個值來將段定向到適當的套接字服務器主機可能支持許多并行的TCP套接字：每個套接字由其自己的四元組標識Web服務器對每個連接的客戶機具有不同的套接字非持久HTTP將為每個請求具有不同的套接字面向連接多路復用與分解14客戶機IP:BP1客戶機IP:AP1P2P4服務器IP:CSP:9157DP:80SP:9157DP:80P5P6P3D-IP:CS-IP:AD-IP:CS-IP:BSP:5775DP:80D-IP:CS-IP:B面向連接多路復用與分解(續)=進程=套接字15客戶機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服務器=進程=套接字163.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數據傳輸的原理3.5面向連接的傳輸：TCP3.6擁塞控制的原則3.7TCP擁塞控制17“盡力而為”服務，UDP段可能：丟包對應用程序交付失序無連接在UDP發送方和接收方之間無握手每個UDP段的處理獨立于其他段為何要有UDP協議?無連接創建(它將增加時延)簡單：在發送方、接收方無連接狀態段首部小無擁塞控制:UDP能夠盡可能快地傳輸

UDP:用戶數據報協議18常用于流媒體應用程序丟包容忍速率敏感其他UDP應用DNSSNMP經UDP的可靠傳輸:在應用層增加可靠性應用程序特定的差錯恢復！源端口#目的端口#32bits應用數據(報文)UDP段格式長度檢查和UDP段的長度，包括首部，以字節計checksum：校驗和，檢查和

UDP報文段結構19發送方:將段內容處理為16比特整數序列檢查和:段內容的加法(反碼和)發送方將檢查和放入UDP檢查和字段接收方:計算接收的段的檢查和核對計算的檢查和是否等于檢查和字段的值:NO–

檢測到差錯YES–

無差錯檢測到。雖然如此，還可能有差錯嗎？目的:

在傳輸的段中檢測“差錯”(如比特翻轉)

UDP檢查和20注意當數字作加法時，最高位進比特位的進位需要加到結果中例子:兩個16-bit整數相加1111001100110011011101010101010101110111011101110111101110111011110010100010001000011回卷和檢查和檢查和例子計算步驟:

求和，回卷，求反213.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數據傳輸的原理3.5面向連接的傳輸3.6擁塞控制的原則3.7TCP擁塞控制22在應用層、運輸層、數據鏈路層的重要性網絡中需解決的最重要的10個問題之一!不可靠信道的特點決定了可靠數據傳輸協議的復雜性可靠數據傳輸的原理23發送側接收側rdt_send():

calledfromabove,(e.g.,byapp.).Passeddatatodelivertoreceiverupperlayerudt_send():

calledbyrdt,totransferpacketoverunreliablechanneltoreceiverrdt_rcv():

calledwhenpacketarrivesonrcv-sideofchanneldeliver_data():

calledbyrdttodeliverdatatoupper可靠數據傳輸：描述函數熟悉24我們將:逐漸遞增地研究可靠數據傳輸協議(rdt)的發送方和接收方僅考慮單向數據傳輸但控制信息將在兩個方向流動！使用有限狀態機(FSM)來定義發送方和接收方狀態1狀態2引起狀態變遷的事件狀態變遷所采取的行動狀態:

當位于這個“狀態時”，下個狀態惟一地由下個事件決定事件動作事件^有限狀態機描述方法253.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數據傳輸的原理rdt1.0，rdt2.0，rdt3.0協議3.5面向連接的傳輸3.6擁塞控制的原則3.7TCP擁塞控制26底層信道完全可靠無比特差錯無分組丟失發送方、接收方具有各自的FSM:發送方將數據發向底層信道接收方從底層信道讀取數據Waitforcallfromabovepacket=make_pkt(data)udt_send(packet)rdt_send(data)extract(packet,data)deliver_data(data)Waitforcallfrombelowrdt_rcv(packet)發送方接收方

rdt1.0:完全可靠信道上的可靠數據傳輸27

Rdt2.0:具有比特差錯的信道具有比特差錯的底層信道有比特差錯無分組丟失數據出錯后處理方式檢錯重傳rdt2.0新增加機制（與rdt1.0比較）檢錯反饋：ACK,NAK重傳28等待來自上面的調用snkpkt=make_pkt(data,checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt)&&

notcorrupt(rcvpkt)rdt_rcv(rcvpkt)&&isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt)&&

isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt)&&

corrupt(rcvpkt)等待ACK或NAK等待來自下面的調用發送方接收方rdt_send(data)L發送方發出1個分組，等待接收方響應后再繼續發送。（類似rdt2.0）停等協議

rdt2.0:FSM描述29等待來自上面的調用snkpkt=make_pkt(data,checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt)&&

notcorrupt(rcvpkt)rdt_rcv(rcvpkt)&&isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt)&&

isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt)&&

corrupt(rcvpkt)等待ACK或NAK等待來自下面的調用rdt_send(data)L

rdt2.0:無差錯時的操作30等待來自上面的調用snkpkt=make_pkt(data,checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt)&&

notcorrupt(rcvpkt)rdt_rcv(rcvpkt)&&isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt)&&

isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt)&&

corrupt(rcvpkt)等待ACK或NAK等待來自下面的調用rdt_send(data)L

rdt2.0:有差錯時的情況31如果ACK/NAK受損，將會出現何種情況？發送方不知道在接收方會發生什么情況！不能只是重傳：可能導致重復（duplicate）處理重復（序號機制）:發送方對每個分組增加序列號如果ACK/NAK受損，發送方重傳當前的分組接收方丟棄(不再向上交付)重復的分組

rdt2.0有重大的缺陷!32等待來自上面的調用0sndpkt=make_pkt(0,data,checksum)udt_send(sndpkt)rdt_send(data)等待ACK或NAK0udt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||isNAK(rcvpkt))sndpkt=make_pkt(1,data,checksum)udt_send(sndpkt)rdt_send(data)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||isNAK(rcvpkt))rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt)

等待來自上面的調用1等待ACK或NAK1LL

rdt2.1:發送方,處理受損的ACK/NAK33等待來自下面的調用0sndpkt=make_pkt(NAK,chksum)udt_send(sndpkt)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq0(rcvpkt)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq1(rcvpkt)

extract(rcvpkt,data)deliver_data(data)sndpkt=make_pkt(ACK,chksum)udt_send(sndpkt)等待來自上面的調用1rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq0(rcvpkt)extract(rcvpkt,data)deliver_data(data)sndpkt=make_pkt(ACK,chksum)udt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)sndpkt=make_pkt(ACK,chksum)udt_send(sndpkt)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq1(rcvpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)sndpkt=make_pkt(ACK,chksum)udt_send(sndpkt)sndpkt=make_pkt(NAK,chksum)udt_send(sndpkt)

rdt2.1:接收方,處理受損的ACK/NAK34發送方:序號seq#加入分組中兩個序號seq.#’s(0,1)將夠用.(為什么?)必須檢查是否收到的ACK/NAK受損狀態增加一倍狀態必須“記住”是否“當前的”分組具有0或1序號接收方:必須檢查是否接收到的分組是冗余的狀態指示是否0或1是所期待的分組序號seq#注意:接收方不能知道是否它的最后的ACK/NAK在發送方已經接收OK

rdt2.1:討論35與rdt2.1一樣的功能，僅使用ACK代替NAK,接收方對最后正確接收的分組發送ACK接收方必須明確地包括被確認分組的序號在發送方重復的ACK導致如同NAK相同的動作：重傳當前分組

rdt2.2:一種無NAK的協議36等待來自上面的調用0sndpkt=make_pkt(0,data,checksum)udt_send(sndpkt)rdt_send(data)udt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||

isACK(rcvpkt,1))rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt,0)

等待ACK0發送方FSM片段等待來自下面的調用0rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq1(rcvpkt)extract(rcvpkt,data)deliver_data(data)sndpkt=make_pkt(ACK1,chksum)udt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||

has_seq1(rcvpkt))udt_send(sndpkt)接收方FSM片段L

rdt2.2:發送方,接收方片段37

rdt3.0:具有差錯和丟包的信道具有差錯和丟包的底層信道有比特差錯有分組丟失現有機制（檢錯、反饋、重傳、序號）還不夠增加定時機制：發送方等待ACK一段“合理的”時間如在這段時間沒有收到ACK則重傳如果分組(或ACK)只是延遲(沒有丟失)，重傳將是冗余的，但序號的使用已經處理了該情況38sndpkt=make_pkt(0,data,checksum)udt_send(sndpkt)start_timerrdt_send(data)等待ACK0rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||isACK(rcvpkt,1))等待來自上面的調用1sndpkt=make_pkt(1,data,checksum)udt_send(sndpkt)start_timerrdt_send(data)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt,0)

rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||isACK(rcvpkt,0))rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt,1)

stop_timerstop_timerudt_send(sndpkt)start_timertimeoutudt_send(sndpkt)start_timertimeoutrdt_rcv(rcvpkt)等待來自上面的調用0等待ACK1Lrdt_rcv(rcvpkt)LLL

rdt3.0發送方39無丟包時的運行分組丟失發送方發送方接收方接收方

rdt3.0運行情況40ACK丟失過早超時發送方發送方接收方接收方

rdt3.0運行情況41rdt3.0能夠工作，但性能不太好例子:1Gbps鏈路,15ms端到端傳播時延,1KB分組:Ttransmit=8kb/pkt10**9b/sec=8microsecUsender:利用率

–

發送方用于發送時間的比率每30msec1KB分組->經1Gbps

鏈路有33kB/sec吞吐量網絡協議限制了物理資源的使用!L(packetlengthinbits)R(transmissionrate,bps)=

rdt3.0的性能42傳輸分組的第一個比特,t=0發送方接收方RTT

傳輸分組的最后一個比特,t=L/R分組第一個比特到達傳輸最后一個比特到達,發送ACKACK到達，發送下一個分組,t=RTT+L/R

rdt3.0:停等協議的運行43流水線:發送方允許發送多個、“傳輸中的”,還沒有應答的報文段序號的范圍必須增加發送方和/或接收方設有緩沖流水線協議的兩種形式:

回退N幀法（Go-Back-N）,選擇性重傳（SR）,流水線協議44傳輸第一個分組比特,t=0發送者接收者RTT傳輸最后一個比特,t=L/R第一個分組比特到達分組最后一個比特到達,發送ACKACK到達,發送下一個分組,t=RTT+L/R第二個分組最后比特到達,發送ACK第三個分組最后比特到達,發送ACK利用率增加3倍!流水線協議:增加利用率45滑動窗口協議Go-Back-N和選擇重傳都是滑動窗口協議發送方和接收方都具有一定容量的緩沖區（即窗口），允許發送站連續發送多個幀而不需要等待應答發送窗口就是發送端允許連續發送的幀的序號表，發送端可以不等待應答而連續發送的最大幀數稱為發送窗口的尺寸接收窗口是接收方允許接收的幀的序號表，凡落在接收窗口內的幀，接收方都必須處理，落在接收窗口外的幀被丟棄。接收方每次允許接收的幀數稱為接收窗口的尺寸46特征：累計ACK，全部重傳ACK(n):確認所有的（包括序號n）的分組-“累計ACK”若超時，重傳窗口中的未被確認的第一個分組n及所有更高序號的分組

Go-Back-N發送窗口尺寸為N；接收窗口尺寸為1。1234567891011……發送窗口接收窗口1234567891011……簡單來說：位于發送窗口內的分組才允許被發送，位于接收窗口內的分組才能被接收，關鍵是窗口如何滑動。47

Go-Back-N正常傳輸時（示意）動畫48

Go-Back-N丟失幀時（示意）49

Go-Back-N理解累計ACK和回退N個重傳發送方發送窗口滑動的條件：收到1個確認分組超時重傳時，回退N個重傳，通常重傳多個分組接收方接收窗口滑動的條件：收到期望序號的分組累計ACKs：s為期望收到的下一分組序號對失序分組的處理：丟棄，重發（已按序接收分組的）ACKGo-Back-N不足：（效率明顯高于停等協議）但仍有不必要重傳的問題50發送方接收方

GBN例子（書）51特征：獨立ACK，重傳單個分組獨立ACK:對每個分組使用單獨的確認需N個定時器，若某個分組超時，則重傳該分組接收窗口為N，對非按序到達的分組進行緩存選擇重傳SR發送窗口尺寸為N；接收窗口尺寸為N。1234567891011……發送窗口接收窗口1234567891011……52選擇重傳的操作53選擇重傳的理解理解單獨ACK和單個分組重傳發送方發送窗口滑動的條件：收到最低位置分組的確認超時重傳時，僅重傳超時的單個分組接收方接收窗口滑動的條件：收到最低位置的分組單獨ACK對失序分組的處理：接收窗口內緩存，發對應ACK；接收窗口外丟棄54例子:序號:0,1,2,3窗口長度=3接收方：在(a)和(b)兩種情況下接收方沒有發現差別!在(a)中不正確地將新的冗余的當為新的，而在(b)中不正確地將新的當作冗余的問題:

序號長度與窗口長度有什么關系?回答：窗口長度小于等于序號空間的一半選擇重傳:困難的問題55機制用途和說明檢驗和用于檢測在一個傳輸分組中的比特錯誤。定時器用于檢測超時/重傳一個分組，可能因為該分組（或其ACK）在信道中丟失了。由于當一個分組被時延但未丟失（過早超時），或當一個分組已被接收方收到但從接收方到發送方的ACK丟失時，可能產生超時事件，所以接收方可能會收到一個分組的多個冗余拷貝。序號用于為從發送方流向接收方的數據分組按順序編號。所接收分組的序號間的空隙可使該接收方檢測出丟失的分組。具有相同序號的分組可使接收方檢測出一個分組的冗余拷貝。確認接收方用于告訴發送方一個分組或一組分組已被正確地接收到了。確認報文通常攜帶著被確認的分組或多個分組的序號。確認可以是逐個的或累積的，這取決于協議。否定確認接收方用于告訴發送方某個分組未被正確地接收。否定確認報文通常攜帶著未被正確接收的分組的序號。窗口、流水線發送方也許被限制僅發送那些序號落在一個指定范圍內的分組。通過允許一次發送多個分組但未被確認，發送方的利用率可在停等操作模式的基礎上得到增加。我們很快將會看到，窗口長度可根據接收方接收和緩存報文的能力或網絡中的擁塞程度，或兩者情況來進行設置。可靠數據傳輸機制及用途總結563.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數據傳輸的原理3.5面向連接的傳輸：TCP3.6擁塞控制的原則3.7TCP擁塞控制57RobertE.KahnVintonG.Cerf羅伯特·卡恩溫頓·瑟夫

2004年圖靈獎TCP/IP協議發明者58全雙工數據:同一連接上的雙向數據流MSS:最大報文段長度MTU:最大傳輸單元面向連接:

在進行數據交換前，初始化發送方與接收方狀態，進行握手(交換控制信息),流量控制:發送方不能淹沒接收方擁塞控制:抑止發送方速率來防止過分占用網絡資源點到點:一個發送方,一個接收方連接狀態與端系統有關，不為路由器所知

可靠、有序的字節流流水線:TCP擁塞和流量控制設置滑動窗口協議發送和接收緩沖區

TCP概述59源端口#目的端口#32bits應用層數據(變長)序號確認號接收窗口緊急數據指針檢查和FSRPAU首部長度未用選項(變長)URG:緊急數據(一般不用)ACK:ACK序號有效PSH:立即提交數據(一般不用)RST,SYN,FIN:連接建立(建立和拆連)接收方允許的字節數對數據字節計數(并非對報文段計數!)因特網檢查和(同UDP一樣)

TCP報文段結構60序號:報文段中第1個數據字節在字節流中的位置編號確認號:期望從對方收到下一個字節的序號累計應答主機A主機BSeq=42,ACK=79,data=‘C’Seq=79,ACK=43,data=‘C’Seq=43,ACK=80用戶鍵入‘C’主機對接收到的‘C’回顯給出確認主機對收到的‘C’給出確認,

回顯‘C’時間簡單的telnet情況捎帶確認

TCP序號和確認號61問題:如何設置TCP超時值?應大于RTT但RTT是變化的太短:過早超時不必要的重傳太長:對報文段的丟失響應太慢問題:如何估計RTT?SampleRTT:

從發送報文段到接收到ACK的測量時間忽略重傳SampleRTT會變化,希望估計的RTT“較平滑”平均最近的測量值,并不僅僅是當前SampleRTT

TCP往返時延(RTT)的估計與超時62EstimatedRTT=(1-)*EstimatedRTT+*SampleRTT指數加權移動平均(Exponentialweightedmovingaverage)過去的樣本指數級衰減來產生影響典型值:=0.125

TCP往返時延估計與超時(續)63

RTT估計的例子64設置超時間隔EstimtedRTT

加“安全余量”EstimatedRTT大變化->更大的安全余量首先估算EstimatedRTT與SampleRTT之間差值有多大:

TimeoutInterval=EstimatedRTT+4*DevRTTDevRTT=(1-)*DevRTT+

*|SampleRTT-EstimatedRTT|(典型地,=0.25)

然后估算超時值:

TCP往返時延估計與超時(續)65TCP在IP不可靠服務的基礎上創建可靠數據傳輸服務流水線發送報文段累計確認TCP使用單個重傳計時器重傳被下列事件觸發:超時事件重復ACK

TCP可靠數據傳輸66TCP可靠傳輸屬于滑動窗口方法發送方收到累計ACK，窗口向又滑動（1個或多個報文段）單個重傳計時器，超時僅則重傳導致超時的報文段快速重傳：冗余ACK

接收方對收到的報文段進行緩存收到任何報文段時，均發出正確的累計確認

TCP可靠數據傳輸67主機ASeq=100,20bytesdataACK=100時間過早超時的情況主機BSeq=92,8bytesdataACK=120Seq=92,8bytesdataSeq=92超時ACK=120主機ASeq=92,8bytesdataACK=100loss超時丟失確認的情況主機BXSeq=92,8bytesdataACK=100時間Seq=92超時SendBase=100SendBase=120SendBase=120Sendbase=100

TCP:重傳的情況68主機ASeq=92,8bytesdataACK=100丟包超時累計確認情況主機BXSeq=100,20bytesdataACK=120時間SendBase=120

TCP重傳情況(續)69超時間隔常常相對較長:重傳丟失報文段以前有長時延通過冗余ACK，檢測丟失的報文段發送方經常一個接一個的發送報文段如果報文段丟失，將會收到很多重復ACK如果對相同數據，發送方收到3個ACK,假定被確認的報文段以后的報文段丟失了:快速重傳:

在定時器超時之前重傳快速重傳70TCP連接的接收方有1個接收緩沖區:匹配速度服務:發送速率需要匹配接收方應用程序的提取速率應用進程可能從接收緩沖區讀數據緩慢發送方發送數據太快，導致接收方來不及接收時，需進行流量控制流量控制

TCP流量控制71

TCP流控:工作原理TCP流控通過接收窗口字段實現接收方計算緩存區的剩余空間，即接收窗口大小RcvWindow=RcvBuffer-[LastByteRcvd-LastByteRead]接收方通過TCP首部的接收窗口字段反饋給發送方發送方根據接收窗口字段來限制發送窗口大小，以保證接收方緩存不溢出

72

TCP連接管理TCP是面向連接的協議，TCP連接的建立和釋放是每次TCP傳輸中必不可少的過程。TCP的傳輸連接包括三個狀態連接建立數據傳輸連接釋放73第一次握手過程：注：SYN：同步序列編號(SynchronizeSequenceNumber)SEQ:序列號(SequenceNumber),表示當前數據傳輸字節的編號為X。———————————————————————————————————①

SYN＝1

，SEQ＝X第一次握手：連接請求報文請求建立連接目前字節編號：X下一次編號：X＋1SEQ＝X：身份標識Client客戶機（A）Server服務器（B）建立連接（三次握手）74第二次握手過程：①SYN＝1，SEQ＝X②

SYN＝1

，SEQ＝Y,ACK＝X+1

注：SYN：同步序列編號(SynchronizeSequenceNumbers)SEQ:序列號(SequenceNumber)ACK：確認編號(AcknowledgementNumber)第二次握手：確認報文第一次握手：連接請求報文請求建立連接目前字節編號：Y下一次編號：Y＋1SEQ＝Y：身份標識對（SYN）同步序號請求的應答Client客戶機（A）Server服務器（B）建立連接（三次握手）75①SYN＝1，SEQ＝X②

SYN＝1，SEQ＝Y,

ACK＝X+1

第三次握手過程對（SYN）同步序號請求的應答第二次握手確認報文客戶機A的身份標識第一次握手：連接請求報文③

SEQ＝X+1,ACK＝Y+1第三次握手：確認報文Client客戶機（A）Server服務器（B）建立連接（三次握手）76①SYN＝1，SEQ＝X②

SYN＝1，SEQ＝Y,

ACK＝X+1

③

SEQ＝X+1,ACK＝Y+1請求確認確認三次握手過程：一個請求，兩個確認數據連接已建立Client客戶機（A）Server服務器（B）建立連接（三次握手）77①SYN＝？

，SEQ＝1000②

SYN＝？

，SEQ＝？,

ACK＝？

③

SEQ＝？,ACK＝2002三次握手過程：一個請求，兩個確認數據Client客戶機（A）Server服務器（B）練習78步驟1:

客戶機向服務器發送TCPFIN控制報文段步驟2:

服務器收到FIN，用ACK回答。關閉連接，發送FIN步驟3:

客戶機收到FIN,用ACK答進入“超時等待”

–將對接收到的FIN進行確認步驟4:

服務器接收ACK，連接關閉客戶FIN服務器ACKACKFIN關閉關閉已關閉超時等待釋放連接793.1運輸層服務3.2復用與分解3.3無連接傳輸:UDP3.4可靠數據傳輸的原理3.5面向連接的傳輸:TCP3.6擁塞控制的原則3.7TCP擁塞控制80擁塞(Congestion):當大量的分組進入網絡，超出了網絡的處理能力時，會引起網絡局部或整體性能下降，這種現象稱為擁塞。不加控制的擁塞甚至導致整個網絡癱瘓。不同于流量控制!表現:丟包(路由器緩沖區溢出)長時延(路由器緩沖區中排隊)網絡中的前10大問題之一!擁塞控制原理81擁塞控制起的作用提供的負載吞吐量理想的擁塞控制擁塞死鎖（吞吐量=0）無擁塞控制實際的擁塞控制輕度擁塞082兩個發送方,兩個接收方一個路由器,無限緩沖區不重傳擁塞時時延增大可達到最大吞吐量無限的共享式輸出鏈路緩沖主機Alin

:原始數據主機Blout擁塞的原因與開銷:情況183一個路由器，有限緩沖區發送方重傳丟失的數據分組有限的共享式輸出鏈路緩存主機Alin

:原始數據主機Bloutl‘in

:原始數據＋重傳數據擁塞的原因與開銷:情況284通常:(吞吐量)僅當丟失丟包時，需要“完美的”重傳:遲延的分組（而不是丟失）的重傳使得比(同完美情況相比)更大linlout=linlout>linlout擁塞的“代價”:

比額定的“吞吐量”做更多的工作(重傳)不必要重傳:鏈路承載分組的多個拷貝擁塞的原因與開銷:情況2(續)85四個發送者多跳路徑超時/重傳lin問題:

隨著和的增加將發生什么情況?lin有限的共享式輸出鏈路緩存主機Alin

原始數據主機Bloutl‘in

:原始數據,＋重傳數據擁塞的原因與開銷:情況386另一個擁塞的“開銷”:

當分組丟失時,任何用于傳輸該分組的上游傳輸能力都被浪費!HostAHostBlout擁塞的原因與開銷:情況3(續)87端到端的擁塞控制不能從網絡得到明確的反饋從端系統根據觀察到的時延和丟失現象推斷出擁塞這是TCP所采用的方法網絡輔助的擁塞控制路由器為端系統提供反饋一個bit指示一條鏈路出現擁塞(SNA,DECnet,TCP/IPECN,ATM)指示發送方按照一定速率發送控制擁塞的兩類方法（直接的和間接的）:擁塞控制方法88案例(網絡輔助):ATMABR擁塞控制ATM(AsynchronousTransferMode)異步傳輸模式一種結合了電路交換與分組交換各自優點的技術以53字節固定長度的信元為傳輸單元業務：CBR固定速率，ABR可用速率等:ABR可用速率業務模式（“彈性服務”）若發送方的路徑“欠載”:發送方應該使用可用的帶寬若發送方的路徑擁塞:發送方被抑制到最小保證速率89通信過程簡要描述發送方沿（建立好連接的）路徑上不斷傳輸數據信元和管理信元，到達接收方接收方將管理信元（內容修改調整后）研路徑返回（反饋）到發送方案例:ATMABR擁塞控制90采取網絡輔助的擁塞控制（包括多種機制）RM信元中的特定bit：NIbit速率無增長(