理解可靠傳輸協(xié)議的設(shè)計(jì)理念掌握Tcp協(xié)議的強(qiáng)大功課件_第1頁(yè)
理解可靠傳輸協(xié)議的設(shè)計(jì)理念掌握Tcp協(xié)議的強(qiáng)大功課件_第2頁(yè)
理解可靠傳輸協(xié)議的設(shè)計(jì)理念掌握Tcp協(xié)議的強(qiáng)大功課件_第3頁(yè)
理解可靠傳輸協(xié)議的設(shè)計(jì)理念掌握Tcp協(xié)議的強(qiáng)大功課件_第4頁(yè)
理解可靠傳輸協(xié)議的設(shè)計(jì)理念掌握Tcp協(xié)議的強(qiáng)大功課件_第5頁(yè)
已閱讀5頁(yè),還剩71頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

---理解可靠傳輸協(xié)議的設(shè)計(jì)理念---掌握Tcp協(xié)議的強(qiáng)大功能傳輸層江西師范大學(xué)計(jì)算機(jī)學(xué)院萬(wàn)宇文1課程索引傳輸層的概念和提供的服務(wù)UDP協(xié)議的工作原理和協(xié)議細(xì)節(jié)可靠傳輸協(xié)議的原理和設(shè)計(jì)TCP協(xié)議的工作原理和協(xié)議細(xì)節(jié)2學(xué)習(xí)內(nèi)容傳輸層的概念和提供的服務(wù)UDP協(xié)議的工作原理和協(xié)議細(xì)節(jié)可靠傳輸協(xié)議的原理和設(shè)計(jì)TCP協(xié)議的工作原理和協(xié)議細(xì)節(jié)3傳輸層的概念傳輸層負(fù)責(zé)端(主機(jī))到端(主機(jī))之間的數(shù)據(jù)傳輸控制傳輸層依賴于網(wǎng)絡(luò)層的服務(wù),對(duì)應(yīng)用層提供傳輸服務(wù)應(yīng)用層傳輸層網(wǎng)絡(luò)層鏈路層物理層應(yīng)用層傳輸層網(wǎng)絡(luò)層鏈路層物理層4傳輸層與網(wǎng)絡(luò)層的關(guān)系網(wǎng)絡(luò)層為主機(jī)之間數(shù)據(jù)如何經(jīng)過路由器選路到達(dá)對(duì)方提供服務(wù)傳輸層加強(qiáng)了網(wǎng)絡(luò)層的服務(wù),在數(shù)據(jù)能到達(dá)對(duì)方的前提下,為數(shù)據(jù)的傳輸進(jìn)行控制,為進(jìn)程間進(jìn)行通信提供服務(wù)5因特網(wǎng)傳輸層提供的服務(wù)不可靠的(“盡力而為”),無(wú)序的傳輸(UDP)可靠(正確、按序)的端到端傳輸(TCP)面向連接的服務(wù)流量控制擁塞控制因特網(wǎng)上不能提供的服務(wù):實(shí)時(shí)性帶寬承諾可靠的廣播通信6應(yīng)用層傳輸層網(wǎng)絡(luò)層M主機(jī)2接收方HtHnsegmentM主機(jī)1MMM進(jìn)程3進(jìn)程4應(yīng)用層傳輸層網(wǎng)絡(luò)層應(yīng)用層傳輸層網(wǎng)絡(luò)層傳輸層的分用和復(fù)用分用:接收方傳輸層根據(jù)端口號(hào)分用到不通的應(yīng)用層進(jìn)程復(fù)用:發(fā)送方不同的應(yīng)用層進(jìn)程根據(jù)不同端口號(hào)復(fù)用到同一傳輸層中段傳輸層首部應(yīng)用層的數(shù)據(jù)傳輸層根據(jù)目的端口分用到不同應(yīng)用進(jìn)程7套接字的回顧源IP:C目標(biāo)IP:B源端口:x目標(biāo)端口:80源IP:C目標(biāo)IP:B源端口:y目標(biāo)端口:80源IP:A目標(biāo)IP:B源端口:x目標(biāo)端口:80Web客戶端主機(jī)AWeb服務(wù)器BWeb客戶端主機(jī)C客戶端A向服務(wù)器B端請(qǐng)求網(wǎng)頁(yè)源端口隨機(jī)從可用端口取,目標(biāo)端口為80C打開兩個(gè)瀏覽器,向B發(fā)送兩個(gè)網(wǎng)頁(yè)請(qǐng)求8學(xué)習(xí)內(nèi)容傳輸層的概念和提供的服務(wù)UDP協(xié)議的工作原理和協(xié)議細(xì)節(jié)可靠傳輸協(xié)議的原理和設(shè)計(jì)TCP協(xié)議的工作原理和協(xié)議細(xì)節(jié)9UDP協(xié)議概述“最簡(jiǎn)單的”Internet傳輸協(xié)議提供不可靠的數(shù)據(jù)傳輸,又稱“盡力而為的”的服務(wù),其本質(zhì)是寧缺勿濫,盡力傳輸U(kuò)DP協(xié)議允許:數(shù)據(jù)丟失應(yīng)用數(shù)據(jù)亂序到達(dá)無(wú)連接的協(xié)議在UDP收發(fā)雙方之間,無(wú)需握手建立連接每個(gè)UDP數(shù)據(jù)段的操作都互相獨(dú)立10UDP協(xié)議的首部源端口目的端口長(zhǎng)度校驗(yàn)和數(shù)據(jù)首部IP數(shù)據(jù)報(bào)數(shù)據(jù)首部UDP用戶數(shù)據(jù)報(bào)源端口和目標(biāo)端口定義發(fā)送方和接收方的通信進(jìn)程長(zhǎng)度字段定義UDP數(shù)據(jù)報(bào)的總長(zhǎng)度(包括首部和數(shù)據(jù))校驗(yàn)和用于數(shù)據(jù)傳輸?shù)牟铄e(cuò)檢查,UDP協(xié)議寧缺勿濫11UDP校驗(yàn)和查錯(cuò)機(jī)制注意:UDP查錯(cuò)的數(shù)據(jù)包括IP首部的12字節(jié),稱為偽首部,作為網(wǎng)絡(luò)層數(shù)據(jù)的冗余檢查,求和是按二進(jìn)制反碼運(yùn)算求和8字節(jié)UDP首部153.19.8.104171.3.14.1112字節(jié)偽首部7字節(jié)數(shù)據(jù)填充全0171510871315全0數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)全0校驗(yàn)和是網(wǎng)絡(luò)通信的查錯(cuò)方式之一,廣泛應(yīng)用于傳輸層和網(wǎng)絡(luò)層,發(fā)送方將需檢驗(yàn)的數(shù)據(jù)按照一定的大小求和,得到的和取反得到為校驗(yàn)碼12學(xué)習(xí)內(nèi)容傳輸層的概念和提供的服務(wù)UDP協(xié)議的工作原理和協(xié)議細(xì)節(jié)可靠傳輸協(xié)議的原理和設(shè)計(jì)TCP協(xié)議的工作原理和協(xié)議細(xì)節(jié)13可靠傳輸協(xié)議概述可靠傳輸協(xié)議保證數(shù)據(jù)能夠正確、按序的到達(dá)對(duì)方可靠傳輸協(xié)議可以用于數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層和應(yīng)用層可靠傳輸協(xié)議屬于網(wǎng)絡(luò)前10位的重要課題討論:如果物理信道100%可靠,還需要可靠傳輸協(xié)議嗎?14停止等待協(xié)議SW(stopandwait)停止等待協(xié)議,發(fā)送方每發(fā)送一個(gè)報(bào)文,必須收到對(duì)方的回復(fù)后才能發(fā)送發(fā)送下一個(gè)報(bào)文SW協(xié)議類似于非流水線作業(yè)方式可靠傳輸協(xié)議的討論從SW協(xié)議開始15可靠協(xié)議開始起步rdt_send():

可靠的數(shù)據(jù)傳輸處理函數(shù),處理完將數(shù)據(jù)交給下層udt_send():不可靠的數(shù)據(jù)傳輸處理函數(shù),將分組通過不可靠的信道傳到接收方rdt_rcv():可靠的數(shù)據(jù)接收處理函數(shù),deliver_data():向上層遞交數(shù)據(jù),由rdt調(diào)用16rdt1.0信道完全可靠前提:信道完全可靠數(shù)據(jù)不會(huì)出錯(cuò)數(shù)據(jù)不會(huì)亂序到達(dá),也不會(huì)丟失可靠協(xié)議本身無(wú)需做額外的處理17rdt2.0信道可能出錯(cuò)前提:信道可能在分組數(shù)據(jù)中出現(xiàn)位錯(cuò),但不會(huì)丟失討論:需要解決的問題,如何查錯(cuò),如何從錯(cuò)誤中恢復(fù)從錯(cuò)誤中恢復(fù)的辦法:糾錯(cuò)機(jī)制(代價(jià)太大)使用確認(rèn)(ACKs)和否認(rèn)(NAKs)機(jī)制:

當(dāng)接收方正確收到分組,則向發(fā)送方發(fā)送確認(rèn)信息,否則發(fā)送否認(rèn)信息,當(dāng)收到NAK時(shí),發(fā)送方重傳數(shù)據(jù)(發(fā)送方緩存數(shù)據(jù),提高效率)18rdt2.0的運(yùn)行(無(wú)錯(cuò)的情況)發(fā)送方FSM接收方FSM19rdt2.0運(yùn)行(出錯(cuò)的情況)發(fā)送方FSM接收方FSM20rdt2.0存在的設(shè)計(jì)缺陷ACK/NAK報(bào)文出錯(cuò)?發(fā)送方將不會(huì)知道接收端發(fā)生了什么!ACK/NAK本身必須增加查錯(cuò)機(jī)制討論:當(dāng)發(fā)送方發(fā)現(xiàn)ACK/NAK出錯(cuò)怎么辦?對(duì)ACK/NAK本身再發(fā)送ACK/NAK(不可行)直接重傳分組接收方可能收到重復(fù)分組重復(fù)分組的問題(接收方收到一個(gè)分組無(wú)法分清該分組是重傳的分組還是新的分組):21rdt2.1:信道出錯(cuò)的可靠協(xié)議改進(jìn)發(fā)送方給每個(gè)分組加上序號(hào)(sequencenumber)接收方丟棄重復(fù)分組,并再次對(duì)分組確認(rèn)討論:序號(hào)需要多少個(gè)?不用NAK,只用ACK是否可行,如何處理rdt2.1:只使用ACK,分組采用0/1循環(huán)編號(hào),接收方根據(jù)序號(hào)確定是否是重復(fù)分組22rdt2.1演示發(fā)送方接收方100101Ack0正確收到,發(fā)0號(hào)分組確認(rèn),期待1號(hào)分組發(fā)送0號(hào)分組正確收到0號(hào)分組確認(rèn),發(fā)送1號(hào)分組Ack01號(hào)分組出錯(cuò),發(fā)0號(hào)分組確認(rèn)1重發(fā)1號(hào)分組Ack1正確收到,發(fā)1號(hào)分組確認(rèn)11號(hào)確認(rèn)出錯(cuò),重發(fā)1號(hào)分組Ack1正確收到,判斷是重復(fù)分組,發(fā)1號(hào)分組確認(rèn)正確收到1號(hào)分組確認(rèn),發(fā)下一個(gè)0號(hào)分組23rdt3.0數(shù)據(jù)可能出錯(cuò)和丟失討論:誰(shuí)通過何種方式發(fā)現(xiàn)數(shù)據(jù)丟失?發(fā)現(xiàn)數(shù)據(jù)丟失后如何處理?發(fā)送方通過“超時(shí)”時(shí)間發(fā)現(xiàn)數(shù)據(jù)丟失.對(duì)發(fā)送的分組定義一個(gè)超時(shí)時(shí)間(定時(shí)器),若在超時(shí)時(shí)間里沒有收到ACK,則重傳該分組注意:數(shù)據(jù)超時(shí)并非一定丟失了如果分組(或ACK)僅僅被延遲了(沒有丟失)將導(dǎo)致重復(fù)分組,但使用序號(hào)機(jī)制可以控制思考:超時(shí)時(shí)間如何確定,固定的還是變化的?24rdt3.0演示1發(fā)送方接收方發(fā)送0號(hào)分組收到ACK0,發(fā)送分組1收到分組0,發(fā)送ACK0收到分組1,發(fā)送ACK1超時(shí),重傳分組1收到ACK1,發(fā)送分組0收到分組0,發(fā)送ACK0pkt0ACK0分組1丟失pkt1×發(fā)送方接收方收到分組0,發(fā)送ACK0發(fā)送0號(hào)分組pkt0收到分組0,發(fā)送ACK0ACK0收到ACK0,發(fā)送分組1pkt1數(shù)據(jù)丟失情況確認(rèn)丟失情況ACK1丟失×收到分組1,發(fā)送ACK1ACK1pkt1ACK1收到重復(fù)分組1,發(fā)送ACK1ACK1超時(shí),重傳分組1pkt1pkt0收到ACK1,發(fā)送分組0pkt025rdt3.0演示2發(fā)送方接收方數(shù)據(jù)超時(shí)未丟失情況pkt0發(fā)送0號(hào)分組pkt1收到ACK0,發(fā)送分組1ACK0收到分組0,發(fā)送ACK0ACK1收到分組1,重復(fù)分組,發(fā)送ACK1pkt1超時(shí),重傳分組1pkt0收到ACK1,發(fā)送分組0ACK0收到分組0,發(fā)送ACK0ACK1收到分組1,發(fā)送ACK1pkt0收到ACK1,重傳分組0收到ACK0,發(fā)送分組1收到分組0,重復(fù)分組,發(fā)送ACK026停止等待協(xié)議(rdt3.0)討論停等協(xié)議能否達(dá)到可靠傳輸?shù)哪康耐5葏f(xié)議一定能100%正常工作嗎?停止等待存在的性能問題例:1Gb/s鏈路,RTT=30ms,傳播1KB分組Ttransmit=8kb109b/sec=8us利用率=U==8us(30000+8)us

傳輸延遲實(shí)際的等待的時(shí)間=0.00027網(wǎng)絡(luò)協(xié)議限制了物理資源的利用!27滑動(dòng)窗口協(xié)議的討論發(fā)送方在沒有收到對(duì)方的ACK的時(shí)候可以發(fā)送多個(gè)數(shù)據(jù)包,類似于流水線作業(yè)方式發(fā)送方使用發(fā)送窗口限制沒收到確認(rèn)時(shí)允許發(fā)送的數(shù)據(jù)量序號(hào)的個(gè)數(shù)必須增加發(fā)送方和接收方需要增加緩存常見的兩種滑動(dòng)窗口協(xié)議:GBN(回退N步)和SR(選擇性重傳)28GBN的工作方式發(fā)送方:窗口不滿則發(fā)送至窗口滿,窗口滿則等待,收到確認(rèn)窗口向后移動(dòng),某個(gè)分組出錯(cuò)或丟失則重傳該分組及其后面所有已發(fā)送但未被確認(rèn)的分組接收方:對(duì)按序正確到達(dá)的分組確認(rèn),亂序或錯(cuò)誤的分組丟棄且發(fā)送最后一次正確收到的分組的確認(rèn)累積確認(rèn):發(fā)送方收到某個(gè)分組的確認(rèn)意味著該分組及之前所有分組接收方都正確收到29GBN的演示發(fā)送窗口為4發(fā)送方接收方pkt0發(fā)送0號(hào)分組pkt1發(fā)送1號(hào)分組pkt2ACK2收到分組2,發(fā)送ACK2ACK1收到分組1,發(fā)送ACK1pkt3發(fā)送2號(hào)分組分組丟失pkt2×pkt4收到ACK0,窗口后移,發(fā)送分組4收到分組0,發(fā)送ACK0ACK0發(fā)送3號(hào)分組,窗口滿pkt3pkt4pkt5分組2超時(shí),重傳分組2及分組3,4,5收到ACK1,發(fā)送分組5pkt5收到分組4,亂序丟棄,發(fā)送ACK1收到分組3,亂序丟棄,重發(fā)ACK1收到分組5,亂序丟棄,發(fā)送ACK1ACK1ACK1ACK1收到ACK2,發(fā)送分組630SR的工作方式討論:GBN存在的不足及改進(jìn)的方法?SR:選擇性重傳發(fā)送方某個(gè)分組出錯(cuò)或丟失只重傳該分組。接收方增加接收窗口(接收緩存),若收到的分組在接收窗口內(nèi)且亂序,緩存該分組,等到分組按序后一起提交,接收窗口的大小一般等于發(fā)送方發(fā)送窗口的大小31SR的演示發(fā)送窗口為4發(fā)送方接收方01234560120123456012pkt00123456012pkt40123456012pkt5pkt10123456012pkt2分組丟失×0123456012pkt301234560120123456012ACK00123456012ACK1分組2超時(shí).重傳分組20123456012pkt2012345601201234560120123456012ACK3ACK4ACK50123456012ACK20123456012亂序在窗口內(nèi),緩存并確認(rèn)32窗口大小和序號(hào)的關(guān)系GBN窗口的最大值等于序號(hào)的個(gè)數(shù)-1SR窗口的最大值等于序號(hào)的一半若SR窗口為3,序號(hào)為4,上述情況接收方無(wú)法判斷收到的序號(hào)為0的分組是重傳的0號(hào)分組還是新發(fā)送的0號(hào)分組。33本節(jié)小結(jié)可靠傳輸協(xié)議的總結(jié)查錯(cuò)機(jī)制序號(hào)機(jī)制確認(rèn)機(jī)制超時(shí)重傳機(jī)制緩存機(jī)制滑動(dòng)窗口機(jī)制定時(shí)器機(jī)制34學(xué)習(xí)內(nèi)容傳輸層的概念和提供的服務(wù)UDP協(xié)議的工作原理和協(xié)議細(xì)節(jié)可靠傳輸協(xié)議的原理和設(shè)計(jì)TCP協(xié)議的工作原理和協(xié)議細(xì)節(jié)35TCP協(xié)議TCP協(xié)議的設(shè)計(jì)理念TCP協(xié)議首部TCP協(xié)議的連接機(jī)制TCP協(xié)議的流量控制TCP協(xié)議的擁塞控制36TCP的設(shè)計(jì)理念TCP屬于傳輸層,實(shí)現(xiàn)面向連接的可靠的傳輸可靠的傳輸不能保證傳輸一定到達(dá)對(duì)方,但是能保證如果數(shù)據(jù)到達(dá)對(duì)方,一定按序正確TCP使用了可靠的設(shè)計(jì)理念序號(hào)機(jī)制、確認(rèn)機(jī)制、緩存機(jī)制、重傳機(jī)制、滑動(dòng)窗口機(jī)制TCP包含流量控制和擁塞控制機(jī)制注意:不同操作系統(tǒng)的TCP協(xié)議具體實(shí)現(xiàn)細(xì)節(jié)有所不同,但設(shè)計(jì)基本滿足RFC793,RFC258137TCP協(xié)議首部TCP首部20字節(jié)固定首部目的端口首部長(zhǎng)度檢驗(yàn)和選項(xiàng)(長(zhǎng)度可變)源端口序號(hào)緊急指針窗口確認(rèn)號(hào)保留FINSYNRSTPSHACKURG比特081624

31填充38TCP的首部細(xì)節(jié)1TCP首部20字節(jié)固定首部目的端口首部長(zhǎng)度檢驗(yàn)和選項(xiàng)(長(zhǎng)度可變)源端口序號(hào)緊急指針窗口確認(rèn)號(hào)保留FINSYNRSTPSHACKURG比特081624

31填充源端口和目的端口字段——各占2字節(jié)。端口是傳輸層與應(yīng)用層的服務(wù)接口,類似一個(gè)地址標(biāo)識(shí)。傳輸層的復(fù)用和分用功能都要通過端口才能實(shí)現(xiàn)。39TCP的首部細(xì)節(jié)2TCP首部20字節(jié)固定首部目的端口首部長(zhǎng)度檢驗(yàn)和選項(xiàng)(長(zhǎng)度可變)源端口序號(hào)緊急指針窗口確認(rèn)號(hào)保留FINSYNRSTPSHACKURG比特081624

31填充序號(hào)字段——占4字節(jié)。TCP連接中傳送的數(shù)據(jù)流中的每一個(gè)字節(jié)都編上一個(gè)號(hào)。序號(hào)字段的值指的是本報(bào)文段所發(fā)送的數(shù)據(jù)的第一個(gè)字節(jié)的編號(hào)40TCP的首部細(xì)節(jié)3TCP首部20字節(jié)固定首部目的端口首部長(zhǎng)度檢驗(yàn)和選項(xiàng)(長(zhǎng)度可變)源端口序號(hào)緊急指針窗口確認(rèn)號(hào)保留FINSYNRSTPSHACKURG比特081624

31填充確認(rèn)號(hào)字段——占4字節(jié),是期望收到對(duì)方的下一個(gè)報(bào)文段的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)。注意:當(dāng)有數(shù)據(jù)要發(fā)送給對(duì)方時(shí),順便確認(rèn),當(dāng)沒有數(shù)據(jù)發(fā)給對(duì)方時(shí),單獨(dú)發(fā)一個(gè)確認(rèn)報(bào)文。41TCP的首部細(xì)節(jié)4TCP首部20字節(jié)固定首部目的端口首部長(zhǎng)度檢驗(yàn)和選項(xiàng)(長(zhǎng)度可變)源端口序號(hào)緊急指針窗口確認(rèn)號(hào)保留FINSYNRSTPSHACKURG比特081624

31填充首部長(zhǎng)度——占4bit,它作為一個(gè)二進(jìn)制數(shù)字,表示TCP報(bào)文段的首部包含的總的字節(jié)數(shù)(即20個(gè)固定首部長(zhǎng)度加不固定的可選首部長(zhǎng)度),計(jì)算單位按照4個(gè)字節(jié)為單位,如1100表示首部為12*4=48字節(jié)。該字段限制了TCP的首部最大值為60字節(jié)保留字段——占6bit,保留為今后協(xié)議的擴(kuò)展使用,目前置為0。42TCP的首部細(xì)節(jié)4TCP首部20字節(jié)固定首部目的端口首部長(zhǎng)度檢驗(yàn)和選項(xiàng)(長(zhǎng)度可變)源端口序號(hào)緊急指針窗口確認(rèn)號(hào)保留FINSYNRSTPSHACKURG比特081624

31填充特殊標(biāo)記(Flag),每個(gè)標(biāo)記占一個(gè)bit.有特殊約定。URG——緊急比特標(biāo)記,當(dāng)URG置為1時(shí),表明緊急指針字段有效。通知本報(bào)文段中有緊急數(shù)據(jù),應(yīng)盡快傳送,緊急數(shù)據(jù)的優(yōu)先級(jí)要高。ACK——只有當(dāng)ACK置為1時(shí),確認(rèn)號(hào)字段才有效。正常情況下只有第一次握手時(shí)ACK=043TCP的首部細(xì)節(jié)5TCP首部20字節(jié)固定首部目的端口首部長(zhǎng)度檢驗(yàn)和選項(xiàng)(長(zhǎng)度可變)源端口序號(hào)緊急指針窗口確認(rèn)號(hào)保留FINSYNRSTPSHACKURG比特081624

31填充PSH(PuSH)——推送比特,接收方收到推送比特置1的報(bào)文段,就盡快地將該報(bào)文段的數(shù)據(jù)交付給接收應(yīng)用進(jìn)程,而不再等到整個(gè)緩存都填滿了后再向上交付。RST(ReSeT)——復(fù)位比特,當(dāng)RST1時(shí),表明TCP連接中出現(xiàn)嚴(yán)重差錯(cuò)(如由于主機(jī)崩潰或其他原因),必須強(qiáng)行釋放連接,屬于單方面強(qiáng)行斷開連接。44TCP的首部細(xì)節(jié)6TCP首部20字節(jié)固定首部目的端口首部長(zhǎng)度檢驗(yàn)和選項(xiàng)(長(zhǎng)度可變)源端口序號(hào)緊急指針窗口確認(rèn)號(hào)保留FINSYNRSTPSHACKURG比特081624

31填充SYN——同步比特,SYN置為1,表示這是一個(gè)連接請(qǐng)求報(bào)文。正常情況下只有第一次握手和第二次握手時(shí)SYN等于1,其余都等于0。FIN(Final)——終止比特,用來(lái)正常釋放一個(gè)連接。當(dāng)FIN1時(shí),表明此報(bào)文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢,并請(qǐng)求對(duì)方釋放連接,當(dāng)對(duì)方確認(rèn)后,會(huì)釋放發(fā)送緩存。45TCP的首部細(xì)節(jié)7TCP首部20字節(jié)固定首部目的端口首部長(zhǎng)度檢驗(yàn)和選項(xiàng)(長(zhǎng)度可變)源端口序號(hào)緊急指針窗口確認(rèn)號(hào)保留FINSYNRSTPSHACKURG比特081624

31填充窗口字段——占2字節(jié)。窗口字段是流量控制的關(guān)鍵,用來(lái)控制對(duì)方發(fā)送窗口的大小,單位為字節(jié)。接收方根據(jù)自身的緩存大小確定自己的接收窗口大小,然后通知對(duì)方以確定對(duì)方的發(fā)送窗口的上限。檢驗(yàn)和——占2字節(jié)。檢驗(yàn)和字段檢驗(yàn)的范圍包括首部和數(shù)據(jù)這兩部分。在計(jì)算檢驗(yàn)和時(shí),要在TCP報(bào)文段的前面加上12字節(jié)的偽首部。46TCP的首部細(xì)節(jié)8TCP首部20字節(jié)固定首部目的端口首部長(zhǎng)度檢驗(yàn)和選項(xiàng)(長(zhǎng)度可變)源端口序號(hào)緊急指針窗口確認(rèn)號(hào)保留FINSYNRSTPSHACKURG比特081624

31填充緊急指針字段——占16bit。緊急指針指出在本報(bào)文段中的緊急數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)。選項(xiàng)字段——長(zhǎng)度可變。TCP只規(guī)定了一種選項(xiàng),即最大報(bào)文段長(zhǎng)度

MSS(MaximumSegmentSize)。MSS告訴對(duì)方TCP:“我的緩存所能接收的報(bào)文段的數(shù)據(jù)字段的最大長(zhǎng)度是MSS個(gè)字節(jié)。47TCP的首部細(xì)節(jié)9TCP首部20字節(jié)固定首部目的端口首部長(zhǎng)度檢驗(yàn)和選項(xiàng)(長(zhǎng)度可變)源端口序號(hào)緊急指針窗口確認(rèn)號(hào)保留FINSYNRSTPSHACKURG比特081624

31填充填充字段——這是為了使整個(gè)首部長(zhǎng)度是4字節(jié)的整數(shù)倍。從而保證首部長(zhǎng)度字段的有效性和計(jì)算檢驗(yàn)和的有效性48TCP的數(shù)據(jù)編號(hào)與確認(rèn)序號(hào)基于字節(jié)隨機(jī)生成初始序號(hào),之后每個(gè)字節(jié)都對(duì)應(yīng)一個(gè)編號(hào),序號(hào)是發(fā)送數(shù)據(jù)的第一個(gè)字節(jié)的編號(hào)確認(rèn)號(hào)是期望對(duì)方發(fā)送的下一個(gè)數(shù)據(jù)的第一個(gè)字節(jié)的編號(hào),即對(duì)方下一個(gè)報(bào)文段的序號(hào)TCP的確認(rèn)屬于累積確認(rèn),亂序到達(dá)的數(shù)據(jù)會(huì)緩存思考:TCP屬于GBN還是SR49TCP的三次握手建立連接AB第一次握手:A隨機(jī)初始化自己的序號(hào)SN(A),確認(rèn)號(hào)為0,初始化A的接收窗口大小,SYN=1表示希望和B做朋友第二次握手:B隨機(jī)初始化自己的序號(hào)SN(B),確認(rèn)號(hào)為A第一次握手的序號(hào)加1,表示向A作確認(rèn),初始化B的接收窗口大小,SYN=1,表示希望和A做朋友第三次握手:A對(duì)B作確認(rèn),SYN=0,ACK=1,確認(rèn)號(hào)為B第二次握手的序號(hào)加150TCP的三次握手示例發(fā)送SYN,請(qǐng)求建立連接(seq=100ctl=SYN)HostAHostB1發(fā)送SYN、ACK(seq=300ack=101ctl=SYN、ACK)23發(fā)送ACK(seq=101ack=301ctl=ACK)51TCP釋放連接的過程異常釋放ABRST=1ACK正常釋放ABFIN=1ACK…FIN=1ACK52TCP四次斷開示例發(fā)送FIN,請(qǐng)求斷開連接(seq=101,ack=301,ctl=FIN,ACK)HostAHostB1發(fā)送ACK(seq=301,ack=102ctl=ACK)24發(fā)送ACK(seq=102,ack=302ctl=ACK)Seq=91

10ByteSeq=2965ByteAck=1013發(fā)送FIN,請(qǐng)求斷開連接(seq=301,ack=102ctl=FIN,ACK)53TCP狀態(tài)圖54TCP的重傳機(jī)制原則:當(dāng)數(shù)據(jù)超時(shí)則需要重傳問題:超時(shí)時(shí)間如何規(guī)定、如何提高效率?可靠傳輸協(xié)議需要對(duì)分組設(shè)置超時(shí)時(shí)間,超時(shí)時(shí)間應(yīng)當(dāng)動(dòng)態(tài)地隨著網(wǎng)絡(luò)的有效帶寬和擁塞程度不斷的變化網(wǎng)絡(luò)的擁塞程度可以通過往返時(shí)延RTT來(lái)衡量TCP的超時(shí)時(shí)間計(jì)算公式EstimatedRTT=(1-x)*EstimatedRTT+x*SampleRTT(x=1/8)Timeout=EstimatedRTT+4*DeviationDeviation=(1-x)*Deviation+x*|SampleRTT-EstimatedRTT|Timeout=β*EstimatedRTT(β=2)--某些TCP實(shí)現(xiàn)的方法55重傳的進(jìn)一步討論Karn算法(背景:往返時(shí)間有時(shí)很難估計(jì))對(duì)重傳的數(shù)據(jù)不計(jì)算RTT,timeout=2*timeout;快速重傳提高效率當(dāng)連續(xù)收到三個(gè)重復(fù)的冗余確認(rèn)則重傳對(duì)方期望收到的分組56TCP的流量控制接收方:明確地通過TCP首部的窗口字段發(fā)送接收窗口大小,從而限制發(fā)送方發(fā)送窗口的最大值發(fā)送方:保證發(fā)送窗口大小不超過對(duì)方發(fā)送地接收窗口的大小思考:TCP的接收緩存是主機(jī)的所有TCP連接共享還是每個(gè)TCP連接獨(dú)占?(需實(shí)驗(yàn)驗(yàn)證)57TCP流量控制示例HostAHostB123Seq=300,ack=101,win=3Seq=100,1ByteAck=104,win=1Seq=101,1B,win=3Seq=102,1B,win=3Seq=103,1B,win=3Seq=10403接收方的緩沖區(qū)0132發(fā)送窗口大小為3通報(bào)窗口大小為1緩沖區(qū)滿應(yīng)用程序讀取了1個(gè)數(shù)據(jù)段實(shí)際發(fā)送窗口大小變?yōu)?通報(bào)窗口大小為3TCP流量控制的特殊情況1特殊場(chǎng)景:TCP連接的兩端A和B,B接收緩存滿,B此時(shí)無(wú)任何數(shù)據(jù)需要發(fā)送給A問題:當(dāng)A發(fā)送數(shù)據(jù)給B時(shí),B發(fā)送確認(rèn),其中接收窗口大小為0,B的緩存逐漸出現(xiàn)空間,但A無(wú)法獲得這一信息,使得A無(wú)法發(fā)送任何數(shù)據(jù)給B解決辦法:當(dāng)收到接收窗口為0的報(bào)文,A繼續(xù)發(fā)送一個(gè)字節(jié)的數(shù)據(jù)(一般響應(yīng)一個(gè)持續(xù)定時(shí)器后在再發(fā)送),獲得B確認(rèn)報(bào)文中最新的接收窗口大小59TCP流量控制的特殊情況2愚笨窗口綜合癥當(dāng)接收端交互式應(yīng)用每次讀取一個(gè)字節(jié)數(shù)據(jù)時(shí),或者發(fā)送端每次只發(fā)送一個(gè)字節(jié)數(shù)據(jù),將會(huì)使得TCP的工作效率很低。解決辦法:接收端如果接收緩存很小時(shí),會(huì)等待一段時(shí)間(500ms)等緩存大到一定程度再發(fā)送接收窗口給發(fā)送端(Clark策略),提高效率發(fā)送端如果發(fā)送的數(shù)據(jù)很小,第一次會(huì)照常發(fā)送,后面的會(huì)等待一定時(shí)間(500ms)等發(fā)送數(shù)據(jù)較大時(shí)再放入Tcp段中發(fā)送。(Nagle算法)60TCP的擁塞控制機(jī)制討論:什么是擁塞?為什么需要擁塞控制?誰(shuí)應(yīng)該負(fù)責(zé)擁塞控制?路由器還是TCP的發(fā)送端和接收端?如何發(fā)現(xiàn)擁塞,發(fā)現(xiàn)擁塞后該如何處理?如何保證效率?61TCP的擁塞控制思想使用擁塞窗口cwnd控制發(fā)送窗口大小發(fā)送窗口的上限值

Min[rwnd,cwnd]分組超時(shí)意味著擁塞,分組收到確認(rèn)則意味著網(wǎng)絡(luò)未擁塞擁塞則少發(fā)(擁塞窗口減小),沒擁塞則多發(fā)(擁塞窗口增加)在網(wǎng)絡(luò)未知的情況下?lián)砣翱趶淖钚¢_始,收到確認(rèn)擁塞窗口大小增加為提高效率,開始窗口增加速度快,到了一定階段窗口增加速度變慢62TCP的擁塞窗口舉例246810121416182022004812162024傳輸次數(shù)擁塞窗口cwnd進(jìn)入擁塞避免發(fā)生超時(shí)指數(shù)規(guī)律增長(zhǎng)線性規(guī)律增長(zhǎng)ssthresh=16慢啟動(dòng)慢啟動(dòng)擁塞避免擁塞避免更新后的ssthresh=12進(jìn)入擁塞避免63快恢復(fù)算法當(dāng)發(fā)送端收到連續(xù)三個(gè)重復(fù)的確認(rèn)時(shí),就執(zhí)行“乘法減小”算法,把慢開始門限ssthresh減半,直接進(jìn)入擁塞避免階段242468101214161820220048121620傳輸輪次擁塞窗口cwnd收到3個(gè)重復(fù)的確認(rèn)執(zhí)行快重傳算法慢開始“乘法減小”擁塞避免“加法增大”TCPReno版本TCPTahoe版本(已廢棄不用)ssthresh的初始值擁塞避免“加法增大”新的ssthresh值慢開始快恢復(fù)64TCP擁塞控制總結(jié)兩個(gè)階段慢啟動(dòng)階段---乘法增擁塞避免階段--加法增一個(gè)閾值定義了慢啟動(dòng)階段和擁塞避免階段的分界點(diǎn)超時(shí)發(fā)生時(shí)閾值變成超時(shí)的窗口大小的一半回到慢啟動(dòng) 思考:假設(shè)TCP的擁塞窗口被設(shè)置為18KB,并且出現(xiàn)了一個(gè)超時(shí),如果接下來(lái)的四次傳輸都正確的話,則擁塞窗口將是多大?假設(shè)最大數(shù)據(jù)段長(zhǎng)度為1KB。65TCP定時(shí)器retransmissiontimer(重傳定時(shí)器)每個(gè)發(fā)送未被確認(rèn)的分組都需要啟動(dòng)該定時(shí)器persistencetimer(持續(xù)定時(shí)

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論