傳輸層協(xié)議要素

傳輸層協(xié)議要素第一頁，共八十二頁，編輯于2023年，星期日本章主要內(nèi)容 傳輸層的功能傳輸層協(xié)議要素Internet的傳輸層：用戶數(shù)據(jù)報(bào)協(xié)議（UDP）傳輸控制協(xié)議（TCP）BerkeleySockets第二頁，共八十二頁，編輯于2023年，星期日1傳輸層的功能傳輸層提供進(jìn)程－進(jìn)程的數(shù)據(jù)交付服務(wù)：為運(yùn)行在不同主機(jī)上的應(yīng)用進(jìn)程提供邏輯通信功能，使得從應(yīng)用程序看來這些主機(jī)是直接相連的。傳輸實(shí)體傳輸層上實(shí)現(xiàn)傳輸服務(wù)的硬件或軟件。傳輸實(shí)體可能位于操作系統(tǒng)內(nèi)核、單獨(dú)的用戶進(jìn)程內(nèi)、應(yīng)用程序庫中或網(wǎng)絡(luò)接口卡上。第三頁，共八十二頁，編輯于2023年，星期日網(wǎng)絡(luò)層、傳輸層和應(yīng)用層的關(guān)系第四頁，共八十二頁，編輯于2023年，星期日設(shè)置傳輸層的兩個(gè)目的為端系統(tǒng)上運(yùn)行的多個(gè)進(jìn)程提供多路復(fù)用和解多路復(fù)用的功能：多路復(fù)用（multiplex）：在源主機(jī)上，多個(gè)進(jìn)程的數(shù)據(jù)被封裝在不同的數(shù)據(jù)包中送入網(wǎng)絡(luò)；解多路復(fù)用（demultiplex）：在目的主機(jī)上，從數(shù)據(jù)包中取出的數(shù)據(jù)被交給相應(yīng)的進(jìn)程處理。為應(yīng)用進(jìn)程提供所需的數(shù)據(jù)傳輸服務(wù)：面向連接的服務(wù)無連接服務(wù)第五頁，共八十二頁，編輯于2023年，星期日傳輸層服務(wù)接口傳輸服務(wù)原語（transportserviceprimitives）：傳輸層向應(yīng)用程序提供的一組操作，以方便應(yīng)用程序調(diào)用傳輸層服務(wù)。在TCP/IP協(xié)議棧中，傳輸層服務(wù)接口稱為套接字（socket），是目前網(wǎng)絡(luò)應(yīng)用編程接口的工業(yè)標(biāo)準(zhǔn)。第六頁，共八十二頁，編輯于2023年，星期日2傳輸層協(xié)議要素傳輸層協(xié)議要解決的主要問題：編址：一個(gè)進(jìn)程必須顯式指出它要與之通信的另一個(gè)進(jìn)程。建立連接和釋放連接：由于數(shù)據(jù)包在穿過通信子網(wǎng)時(shí)會(huì)丟失、重傳、失序，這使得可靠地建立和釋放傳輸連接非常困難。流量控制和存儲(chǔ)管理。第七頁，共八十二頁，編輯于2023年，星期日2.1傳輸層編址為指明將數(shù)據(jù)包交給哪個(gè)進(jìn)程處理，每個(gè)進(jìn)程需要一個(gè)標(biāo)識(shí)。在網(wǎng)絡(luò)環(huán)境中標(biāo)識(shí)進(jìn)程的方法是為每個(gè)進(jìn)程指定一個(gè)傳輸?shù)刂?，源進(jìn)程向目的進(jìn)程的傳輸?shù)刂钒l(fā)送消息，目的進(jìn)程在自己的傳輸?shù)刂飞辖邮障?。傳輸?shù)刂肥莻鬏攲油ㄐ诺亩它c(diǎn)，其一般性的術(shù)語稱為傳輸服務(wù)訪問點(diǎn)（transportserviceaccesspoint，TSAP）。第八頁，共八十二頁，編輯于2023年，星期日TSAP、NSAP和傳輸實(shí)體的關(guān)系每個(gè)TSAP上綁定一個(gè)應(yīng)用進(jìn)程，應(yīng)用進(jìn)程通過各自的TSAP調(diào)用傳輸層服務(wù)。傳輸實(shí)體通過本地的NSAP調(diào)用網(wǎng)絡(luò)層服務(wù)，與遠(yuǎn)程的對(duì)等傳輸實(shí)體通信。第九頁，共八十二頁，編輯于2023年，星期日舉例第十頁，共八十二頁，編輯于2023年，星期日源進(jìn)程如何獲知目的進(jìn)程的TSAP？在客戶-服務(wù)器模式中，客戶進(jìn)程如何知道服務(wù)器進(jìn)程的TSAP？常用的標(biāo)準(zhǔn)服務(wù)：使用眾所周知的地址不常用的服務(wù)：使用進(jìn)程服務(wù)員需要特殊硬件的服務(wù)：使用目錄服務(wù)TSAP只是一種抽象，通?？捎梢粋€(gè)消息隊(duì)列實(shí)現(xiàn)。第十一頁，共八十二頁，編輯于2023年，星期日進(jìn)程服務(wù)員的使用第十二頁，共八十二頁，編輯于2023年，星期日2.2建立傳輸連接當(dāng)應(yīng)用程序要求傳輸層保持消息發(fā)送順序時(shí)，傳輸層必須提供面向連接的服務(wù)。所謂建立連接，就是在收發(fā)兩端為通信過程分配好資源，并初始化相關(guān)的數(shù)據(jù)結(jié)構(gòu)。在一個(gè)不可靠的網(wǎng)絡(luò)中可靠地建立傳輸連接是一件困難的事情。第十三頁，共八十二頁，編輯于2023年，星期日問題之一：過時(shí)消息的干擾重復(fù)的連接請求及響應(yīng)消息對(duì)正常的連接建立過程產(chǎn)生干擾。解決辦法之一：給每個(gè)連接指定一個(gè)連接標(biāo)識(shí)，每個(gè)主機(jī)記錄已用過的連接標(biāo)識(shí)。資源消耗大，不可靠。解決辦法之二：限制每個(gè)數(shù)據(jù)包的壽命。第十四頁，共八十二頁，編輯于2023年，星期日問題之二：起始序號(hào)的選取主機(jī)崩潰后可能丟失所有的狀態(tài)信息，包括每個(gè)連接上要分配的下一個(gè)TPDU序號(hào)。主機(jī)恢復(fù)工作后，新連接上的TPDU序號(hào)可能和過時(shí)連接上的序號(hào)相同，產(chǎn)生混淆。解決辦法之一：主機(jī)重啟后至少等待時(shí)間T再建立連接，確保崩潰前的分組均已消失。解決辦法之二：基于時(shí)鐘的起始序號(hào)選取算法每個(gè)主機(jī)使用一個(gè)時(shí)鐘，以二進(jìn)制計(jì)數(shù)器的形式工作，每隔ΔT計(jì)數(shù)器加1。當(dāng)一個(gè)連接建立時(shí)，以計(jì)數(shù)器當(dāng)前值的最低k位（TPDU的序號(hào)長度）作為起始的TPDU序號(hào)。該方法確保連接的起始序號(hào)隨時(shí)間單調(diào)增長。第十五頁，共八十二頁，編輯于2023年，星期日問題之三：序號(hào)的增長速度主機(jī)發(fā)送速度過快或過慢，都會(huì)導(dǎo)致主機(jī)崩潰前后的序號(hào)空間發(fā)生重疊。解決辦法：選取較小的ΔT，確保發(fā)送序號(hào)的增長速度不會(huì)超過起始序號(hào)的增長速度。選擇較長的TPDU序號(hào)，確保序號(hào)回繞的時(shí)間遠(yuǎn)大于T。第十六頁，共八十二頁，編輯于2023年，星期日第十七頁，共八十二頁，編輯于2023年，星期日問題之四：如何可靠地傳遞起始序號(hào)？可靠建立傳輸連接的三次握手算法第十八頁，共八十二頁，編輯于2023年，星期日2.3釋放傳輸連接不對(duì)稱釋放：任何一方釋放連接，連接即被釋放（即分配給連接的資源被回收）。第十九頁，共八十二頁，編輯于2023年，星期日釋放傳輸連接（續(xù)）對(duì)稱釋放：一條傳輸連接被看成是兩個(gè)方向上的單工連接，一方釋放連接只是表示它數(shù)據(jù)發(fā)完了，但它仍可以在另一個(gè)方向上接收數(shù)據(jù)。兩個(gè)方向均釋放連接，連接才能被釋放。第二十頁，共八十二頁，編輯于2023年，星期日兩軍問題第二十一頁，共八十二頁，編輯于2023年，星期日三次握手法釋放連接第二十二頁，共八十二頁，編輯于2023年，星期日三次握手法釋放連接（續(xù)）第二十三頁，共八十二頁，編輯于2023年，星期日三次握手法釋放連接（續(xù)）正常釋放：主動(dòng)方發(fā)出DR，響應(yīng)方收到一次DR。異常：主動(dòng)方發(fā)出DR，響應(yīng)方從未收到DR，形成半開的連接。異常處理：引入不活動(dòng)定時(shí)器，定時(shí)器超時(shí)（長時(shí)間未收到數(shù)據(jù)）后自動(dòng)釋放連接。引入啞TPDU，處理長時(shí)間沒有數(shù)據(jù)發(fā)送的情形。第二十四頁，共八十二頁，編輯于2023年，星期日2.4流量控制流量控制是一種由接收端控制發(fā)送速度的反饋機(jī)制，通常采用滑動(dòng)窗口機(jī)制實(shí)現(xiàn)。數(shù)據(jù)鏈路層和傳輸層上的滑動(dòng)窗口機(jī)制：數(shù)據(jù)鏈路層上的滑動(dòng)窗口機(jī)制采用固定緩沖區(qū)分配策略（緩沖區(qū)大小及數(shù)量都固定），這在傳輸層上做不到。數(shù)據(jù)鏈路層上發(fā)送端和接收端都必須緩存，而在傳輸層上有多種緩存方案可供選擇。第二十五頁，共八十二頁，編輯于2023年，星期日傳輸層上的緩存策略發(fā)送方緩存還是接收方緩存？若通信子網(wǎng)是不可靠的，發(fā)送方一般必須緩存，而接收方可以選擇：緩存：長時(shí)間、大數(shù)據(jù)量的通信業(yè)務(wù)，如文件傳輸不緩存：低速且數(shù)據(jù)量較小的交互式會(huì)話應(yīng)用若通信子網(wǎng)是可靠的，視接收方為連接預(yù)留的緩沖空間大小，發(fā)送方可以選擇：緩存：若接收方?jīng)]有預(yù)留足夠的緩沖空間不緩存：若接收方預(yù)留了足夠的緩沖空間第二十六頁，共八十二頁，編輯于2023年，星期日緩沖區(qū)分配方案各種緩沖區(qū)分配方案：以TPDU為單位還是以連接為單位分配？緩沖區(qū)大小固定還是可變？緩沖區(qū)靜態(tài)分配還是動(dòng)態(tài)分配？動(dòng)態(tài)緩沖區(qū)分配：發(fā)送端可以向接收端請求需要的緩沖區(qū)數(shù)量。接收端可以根據(jù)實(shí)際情況分配并動(dòng)態(tài)調(diào)整預(yù)留的緩沖空間，并顯式通知發(fā)送端。第二十七頁，共八十二頁，編輯于2023年，星期日動(dòng)態(tài)緩沖區(qū)分配示例第二十八頁，共八十二頁，編輯于2023年，星期日3用戶數(shù)據(jù)報(bào)協(xié)議UDP第二十九頁，共八十二頁，編輯于2023年，星期日UDP的服務(wù)UDP的主要作用是向應(yīng)用程序提供使用IP服務(wù)的接口，并利用端口號(hào)解復(fù)用多個(gè)應(yīng)用進(jìn)程。UDP只提供檢錯(cuò)功能，不負(fù)責(zé)出錯(cuò)重傳和流量控制等功能。UDP提供的是一種不可靠、無連接的服務(wù)。UDP的優(yōu)點(diǎn)：延遲?。翰恍枰⑦B接資源占用少：不需要維護(hù)狀態(tài)通信開銷小、包頭開銷小第三十頁，共八十二頁，編輯于2023年，星期日UDP的應(yīng)用之一：遠(yuǎn)程過程調(diào)用RPCRPC（remoteprocedurecall）的基本思想允許調(diào)用遠(yuǎn)程計(jì)算機(jī)上的過程，并使這種調(diào)用看起來象本地調(diào)用一樣，方便客戶-服務(wù)器應(yīng)用軟件的編寫。RPC的實(shí)現(xiàn)客戶進(jìn)程綁定到一個(gè)客戶樁（clientstub），服務(wù)器進(jìn)程綁定到一個(gè)服務(wù)器樁（serverstub）；客戶進(jìn)程調(diào)用客戶樁，參數(shù)通過壓棧的方式傳遞；客戶樁將參數(shù)封裝成一個(gè)消息，執(zhí)行一個(gè)系統(tǒng)調(diào)用發(fā)送消息；內(nèi)核通過調(diào)用傳輸層服務(wù)將消息發(fā)送到服務(wù)器樁；服務(wù)器樁用傳過來的參數(shù)調(diào)用服務(wù)器例程，將返回的結(jié)果封裝到一個(gè)消息中，執(zhí)行一個(gè)系統(tǒng)調(diào)用將消息發(fā)送給客戶樁；客戶樁將結(jié)果返回給客戶進(jìn)程。第三十一頁，共八十二頁，編輯于2023年，星期日RPC執(zhí)行過程第三十二頁，共八十二頁，編輯于2023年，星期日UDP的應(yīng)用之二：實(shí)時(shí)多媒體傳輸多媒體通信要求實(shí)時(shí)和按順序交付數(shù)據(jù)，但能容忍少量數(shù)據(jù)丟失。從本質(zhì)上說，TCP和UDP都不適合多媒體通信：TCP：可保證順序，但實(shí)時(shí)性不好（差錯(cuò)控制，擁塞控制）。UDP：實(shí)時(shí)性好，但不保證順序。目前的解決方案是在UDP上面再運(yùn)行一個(gè)RTP（RealTimeProtocol），解決包序維持等問題。第三十三頁，共八十二頁，編輯于2023年，星期日RTP的位置第三十四頁，共八十二頁，編輯于2023年，星期日RTP頭TheRTPheader.第三十五頁，共八十二頁，編輯于2023年，星期日4傳輸控制協(xié)議TCPTCP提供的服務(wù)TCP協(xié)議TCP段結(jié)構(gòu)TCP連接的建立和釋放TCP流量控制TCP擁塞控制無線TCP第三十六頁，共八十二頁，編輯于2023年，星期日4.1TCP提供的服務(wù)TCP協(xié)議被設(shè)計(jì)為在不可靠的網(wǎng)絡(luò)中提供可靠的、有序的字節(jié)流服務(wù)。UDP提供的是數(shù)據(jù)報(bào)服務(wù)：應(yīng)用程序的每一次輸出被封裝到一個(gè)UDP包中傳輸；每收到一個(gè)UDP包，接收端從包中取出數(shù)據(jù)交給應(yīng)用程序。因此，UDP保留報(bào)文的邊界。TCP提供的是字節(jié)流服務(wù)：應(yīng)用程序的每一次輸出被不加區(qū)分地放入發(fā)送緩沖區(qū)中，TCP實(shí)體將緩沖區(qū)中的數(shù)據(jù)劃分成不超過64KB的段，每一段封裝在一個(gè)IP包中傳輸。接收端從收到的TCP段中取出數(shù)據(jù)，按字節(jié)順序不加區(qū)分地放入接收緩沖區(qū)中，在適當(dāng)?shù)臅r(shí)候交給應(yīng)用程序。因此，TCP不保留報(bào)文的邊界。第三十七頁，共八十二頁，編輯于2023年，星期日TCP不保留報(bào)文的邊界(a)Four512-bytesegmentssentasseparateIPdatagrams.(b)The2048bytesofdatadeliveredtotheapplicationinasingleREADCALL.第三十八頁，共八十二頁，編輯于2023年，星期日TCP服務(wù)模型TCP使用連接進(jìn)行通信。每條TCP連接有兩個(gè)端點(diǎn)（稱套接口，socket）：每個(gè)套接口使用一對(duì)整數(shù)<host,port>來標(biāo)識(shí)，其中host是主機(jī)的IP地址，port是該主機(jī)上TCP的端口號(hào)（TSAP）。如<18.26.0.36,1069>和<128.10.2.3,25>唯一標(biāo)識(shí)一條TCP連接。由于TCP使用兩個(gè)端點(diǎn)來識(shí)別連接，因此一個(gè)套接口可以用于多個(gè)連接，如服務(wù)器進(jìn)程可以在一個(gè)套接口上同時(shí)為很多客戶進(jìn)程服務(wù)。TCP連接是全雙工的，數(shù)據(jù)可以在兩個(gè)方向上同時(shí)傳輸。TCP連接是點(diǎn)到點(diǎn)的，即每條連接只能有兩個(gè)端點(diǎn)，所以TCP不支持多播或廣播。第三十九頁，共八十二頁，編輯于2023年，星期日端口與服務(wù)小于1024的端口號(hào)稱為眾所周知的端口號(hào)，保留給標(biāo)準(zhǔn)服務(wù)使用。UNIX使用一個(gè)Internet守護(hù)進(jìn)程inetd監(jiān)聽連接請求：系統(tǒng)啟動(dòng)時(shí)只有inetd在多個(gè)端口上監(jiān)聽連接請求。當(dāng)對(duì)某個(gè)服務(wù)的連接請求到來時(shí)，inetd創(chuàng)建該服務(wù)的一個(gè)守護(hù)進(jìn)程為客戶服務(wù)。inetd從一個(gè)配置文件中獲悉它要監(jiān)聽的端口號(hào)，因此管理員可以讓系統(tǒng)在繁忙的端口（如80）上使用永久的守護(hù)進(jìn)程，而讓inetd監(jiān)聽其余的端口。第四十頁，共八十二頁，編輯于2023年，星期日4.2TCP協(xié)議TCP的傳輸單元稱為段（segment）。TCP段的組成：20字節(jié)的固定頭（可能的）選項(xiàng)頭零個(gè)或多個(gè)數(shù)據(jù)字節(jié)（每個(gè)字節(jié)都有一個(gè)32比特的序號(hào)）TCP使用滑動(dòng)窗口協(xié)議傳輸數(shù)據(jù)。第四十一頁，共八十二頁，編輯于2023年，星期日（1）TCP段結(jié)構(gòu)第四十二頁，共八十二頁，編輯于2023年，星期日TCP偽頭結(jié)構(gòu)第四十三頁，共八十二頁，編輯于2023年，星期日MaximumSegmentSize（MSS）MSS指TCP段允許攜帶的最大載荷長度，受IP包數(shù)據(jù)域長度的限制：若IP包的最大長度為L，則MSS=L?20（IP固定頭）?20（TCP固定頭）為避免數(shù)據(jù)報(bào)分片和重組的開銷，也有人提出基于路徑MTU設(shè)置MSS：MSS=MTU?40以太網(wǎng)的MTU為1500，所以常見的MSS=1460字節(jié)第四十四頁，共八十二頁，編輯于2023年，星期日重要的TCP選項(xiàng)MSS：建立連接時(shí)，每個(gè)主機(jī)可以聲明自己能夠接受的MSS。該選項(xiàng)缺省為536字節(jié)（所有路由器實(shí)現(xiàn)必須支持576字節(jié)的IP包）。窗口比例因子（windowscale）：建立連接時(shí)，雙方可以協(xié)商一個(gè)窗口比例因子。實(shí)際接收窗口大小=windowsize*2^windowscale。選擇重傳：最初的TCP實(shí)現(xiàn)采用gobackn滑動(dòng)窗口協(xié)議。后來引入NAK，允許接收端在選項(xiàng)中指明要重發(fā)的段。第四十五頁，共八十二頁，編輯于2023年，星期日（2）建立和釋放TCP連接TCP使用三次握手建立連接：H1發(fā)送SYN=1、ACK=0的TCP段，給出自己的起始連接序號(hào)x。H2發(fā)送SYN=1、ACK=1的TCP段，給出自己的起始連接序號(hào)y，并對(duì)x進(jìn)行確認(rèn)。H1發(fā)送SYN=0、ACK=1的TCP段，對(duì)y進(jìn)行確認(rèn)。起始序號(hào)采用基于時(shí)鐘的方法確定，?T=4μs。第四十六頁，共八十二頁，編輯于2023年，星期日釋放TCP連接TCP采用對(duì)稱釋放法釋放連接：H1發(fā)送FIN=1的TCP段；H2發(fā)送確認(rèn)，一個(gè)方向的連接釋放。H2發(fā)送FIN=1的TCP段；H1發(fā)送確認(rèn)，另一個(gè)方向的連接釋放。中間兩個(gè)TCP段也可以合成一個(gè)。第四十七頁，共八十二頁，編輯于2023年，星期日SYN-Flood攻擊TCP實(shí)現(xiàn)的問題：服務(wù)器在收到SYN段后，發(fā)送SYN+ACK段；若未收到ACK段，服務(wù)器超時(shí)后重試；服務(wù)器等待一段時(shí)間（稱SYN超時(shí)）后丟棄未完成的連接，SYN超時(shí)的典型值為30秒~120秒。

SYN-Flood攻擊：攻擊者采用偽造的源IP地址，向服務(wù)器發(fā)送大量的SYN段，并且不會(huì)發(fā)出第三個(gè)ACK段。服務(wù)器為維護(hù)一個(gè)非常大的半連接表而消耗很多的資源，并導(dǎo)致請求隊(duì)列溢出，無法處理正?？蛻舻倪B接請求。第四十八頁，共八十二頁，編輯于2023年，星期日端口掃描掃描程序利用與目標(biāo)機(jī)器建立或釋放TCP連接過程中獲得的響應(yīng)消息來收集信息。典型的TCP端口掃描過程如下：發(fā)送端向目標(biāo)端口發(fā)送TCP連接請求（SYN=1）。若收到SYN=1、ACK=1的TCP段，表明該目標(biāo)端口上有服務(wù)在監(jiān)聽，否則表明沒有服務(wù)在運(yùn)行。發(fā)送端向目標(biāo)端口發(fā)送釋放連接的請求（FIN=1）。缺點(diǎn)：掃描行為被日志記錄大多數(shù)防火墻會(huì)過濾由外部主動(dòng)發(fā)起的TCP連接請求第四十九頁，共八十二頁，編輯于2023年，星期日TCP半程掃描TCP半程掃描過程如下：向目標(biāo)端口發(fā)送SYN段若收到SYN+ACK段，表明有服務(wù)在監(jiān)聽發(fā)送RST=1的TCP段（復(fù)位連接）優(yōu)點(diǎn)：不會(huì)被日志記錄（不是一個(gè)完整的TCP連接過程）缺點(diǎn)：仍然可能被防火墻過濾第五十頁，共八十二頁，編輯于2023年，星期日FIN掃描FIN掃描過程如下：發(fā)送端向目標(biāo)端口發(fā)送釋放連接的請求（FIN=1）。若收到ACK=1、RST=1的TCP段，表明目標(biāo)端口上沒有服務(wù)在監(jiān)聽；若沒有響應(yīng)表明有服務(wù)在監(jiān)聽。（RFC973的規(guī)定）優(yōu)點(diǎn)：防火墻不會(huì)過濾缺點(diǎn)：有些系統(tǒng)的實(shí)現(xiàn)不符合RFC973規(guī)定，如在Microsoft的TCP實(shí)現(xiàn)中，總是返回ACK=1、RST=1的TCP段。第五十一頁，共八十二頁，編輯于2023年，星期日（3）TCP的流量控制TCP使用滑動(dòng)窗口協(xié)議進(jìn)行數(shù)據(jù)傳輸：發(fā)送方每發(fā)送一個(gè)段后，啟動(dòng)一個(gè)定時(shí)器；接收方收到后返回一個(gè)包含確認(rèn)序號(hào)的段，確認(rèn)序號(hào)指出接收方準(zhǔn)備接收的下一個(gè)字節(jié)序號(hào)；發(fā)送方定時(shí)器超時(shí)后重發(fā)這個(gè)段。TCP采用可變長度的滑動(dòng)窗口進(jìn)行流量控制：接收方在返回給發(fā)送方的段中報(bào)告接收窗口的大?。═CP頭中的windowsize域），該字段表示發(fā)送方從確認(rèn)序號(hào)開始可以發(fā)送的字節(jié)數(shù)。第五十二頁，共八十二頁，編輯于2023年，星期日可變長滑動(dòng)窗口示例當(dāng)窗口為0時(shí)一般必須停止發(fā)送，但以下兩種情況例外：可以發(fā)送緊急數(shù)據(jù)，例如終止在遠(yuǎn)端計(jì)算機(jī)上的運(yùn)行進(jìn)程?？梢园l(fā)送一個(gè)1字節(jié)的段，以觸發(fā)一個(gè)包含接收窗口大小的響應(yīng)。第五十三頁，共八十二頁，編輯于2023年，星期日零窗口通告和堅(jiān)持定時(shí)器當(dāng)發(fā)送端收到零窗口通告時(shí)，啟動(dòng)一個(gè)堅(jiān)持定時(shí)器（persistencetimer）。定時(shí)器超時(shí)后，發(fā)送端發(fā)送一個(gè)零窗口探測報(bào)文段（序號(hào)為上一個(gè)段中最后一個(gè)字節(jié)的序號(hào)）。接收端在響應(yīng)的報(bào)文段中通告當(dāng)前窗口大小。若發(fā)送端仍然收到零窗口通告，重新啟動(dòng)定時(shí)器。第五十四頁，共八十二頁，編輯于2023年，星期日傳輸效率的考慮發(fā)送端：TCP并不要求發(fā)送端在收到應(yīng)用程序的數(shù)據(jù)后就立即發(fā)送。發(fā)送端可以將數(shù)據(jù)存放在發(fā)送緩沖區(qū)中，等累積到一定數(shù)量之后再組成TCP段發(fā)送，以提高傳輸效率。接收端：TCP也不要求接收端在收到數(shù)據(jù)后立即發(fā)送確認(rèn)。接收端可以推遲一小段時(shí)間，以便將確認(rèn)捎帶在一個(gè)返回的數(shù)據(jù)段中。第五十五頁，共八十二頁，編輯于2023年，星期日糊涂窗口綜合癥（sillywindowsyndrome）接收方不斷發(fā)送具有微小增量窗口的通告，引起發(fā)送方不斷發(fā)送小數(shù)據(jù)分組，導(dǎo)致大量帶寬浪費(fèi)。當(dāng)收發(fā)雙方的處理速度嚴(yán)重失衡時(shí)會(huì)出現(xiàn)這種現(xiàn)象。第五十六頁，共八十二頁，編輯于2023年，星期日接收方啟發(fā)式策略接收端避免糊涂窗口綜合癥的策略：通告零窗口之后，僅當(dāng)窗口大小顯著增加之后才發(fā)送更新的窗口通告。顯著增加：窗口大小達(dá)到緩沖區(qū)空間的一半或者一個(gè)MSS，取兩者的最小值。實(shí)現(xiàn)該策略的兩種手段：TCP對(duì)收到的報(bào)文段進(jìn)行確認(rèn)，但要等到窗口大小滿足以上策略要求時(shí)再通告新的窗口大小。當(dāng)窗口大小不滿足以上策略時(shí)，推遲發(fā)送確認(rèn)。（TCP標(biāo)準(zhǔn)推薦采用推遲確認(rèn)）第五十七頁，共八十二頁，編輯于2023年，星期日推遲確認(rèn)推遲確認(rèn)的優(yōu)點(diǎn)：能夠降低通信量。推遲確認(rèn)的缺點(diǎn)：當(dāng)確認(rèn)延遲太大時(shí)，會(huì)導(dǎo)致不必要的重傳。TCP使用確認(rèn)的到達(dá)時(shí)間來估計(jì)往返時(shí)間，推遲確認(rèn)造成估計(jì)值的混亂。TCP標(biāo)準(zhǔn)規(guī)定：推遲確認(rèn)的時(shí)間限度最多為500ms。接收方至少每隔一個(gè)報(bào)文段使用正常方式進(jìn)行確認(rèn)。第五十八頁，共八十二頁，編輯于2023年，星期日發(fā)送方啟發(fā)式策略發(fā)送方避免糊涂窗口綜合癥的策略：發(fā)送方應(yīng)積聚足夠多的數(shù)據(jù)，以防止發(fā)送太短的報(bào)文段。發(fā)送方TCP應(yīng)該等待多長時(shí)間？如等待時(shí)間不夠，報(bào)文段會(huì)太短。如等待時(shí)間過久，應(yīng)用程序的時(shí)延會(huì)太長。更重要的是，TCP不知道應(yīng)用程序會(huì)不會(huì)在最近的將來生成更多的數(shù)據(jù)。第五十九頁，共八十二頁，編輯于2023年，星期日Nagle算法Nagle算法：當(dāng)應(yīng)用數(shù)據(jù)到來時(shí)，組成一個(gè)TCP段發(fā)送（那怕只有一個(gè)字節(jié)）。在收到確認(rèn)之前，后續(xù)到來的數(shù)據(jù)放到緩沖區(qū)中，等到數(shù)據(jù)足以填滿一個(gè)最大長度的段，或上一次傳輸?shù)拇_認(rèn)到來（取兩者的最小時(shí)間），用一個(gè)TCP段將緩存的字節(jié)全部發(fā)走。Nagle算法的優(yōu)點(diǎn)：適應(yīng)不同的網(wǎng)絡(luò)延時(shí)、不同的MSS以及不同應(yīng)用程序速度的組合情況。常規(guī)情況下不會(huì)降低網(wǎng)絡(luò)的吞吐量。第六十頁，共八十二頁，編輯于2023年，星期日流量控制的總結(jié)接收端使用顯式的窗口通告來通知可用的緩存空間大小。接收端在發(fā)送了零窗口通告后，僅當(dāng)窗口大小顯著增加后，才發(fā)送更新的窗口通告。發(fā)送端使用Nagle算法確定發(fā)送時(shí)機(jī)，并使用接收窗口來限制發(fā)送的數(shù)據(jù)量。第六十一頁，共八十二頁，編輯于2023年，星期日（4）TCP擁塞控制TCP擁塞控制的基本思想是讓每一個(gè)發(fā)送方根據(jù)自己感知的網(wǎng)絡(luò)擁塞程度來調(diào)整發(fā)送速度：如果發(fā)送方感覺到從它到目的節(jié)點(diǎn)的路徑上沒什么擁塞，就增加發(fā)送速度；如果感覺到有擁塞，就降低發(fā)送速度。問題：發(fā)送方如何知道從它到目的節(jié)點(diǎn)的路徑上發(fā)生了擁塞？當(dāng)發(fā)送方檢測到擁塞時(shí)，采用什么算法來調(diào)整發(fā)送速率？發(fā)送方如何限制發(fā)送速率？第六十二頁，共八十二頁，編輯于2023年，星期日如何檢測擁塞？TCP利用段的超時(shí)事件來檢測擁塞，即當(dāng)發(fā)送端發(fā)送的某個(gè)段發(fā)生了超時(shí)，就認(rèn)為網(wǎng)絡(luò)中出現(xiàn)了擁塞。采用這種假設(shè)的原因是：對(duì)于端系統(tǒng)而言，擁塞表現(xiàn)為確認(rèn)不能按時(shí)到達(dá)。對(duì)于固定（有線）網(wǎng)絡(luò)而言，超時(shí)大多是由擁塞造成的。第六十三頁，共八十二頁，編輯于2023年，星期日如何限制發(fā)送速率？TCP使用擁塞窗口和發(fā)送窗口一起限制發(fā)送速率：接收窗口反映接收端的緩沖能力擁塞窗口反映網(wǎng)絡(luò)當(dāng)前的處理能力發(fā)送窗口等于接收窗口和擁塞窗口的較小值第六十四頁，共八十二頁，編輯于2023年，星期日如何調(diào)整發(fā)送速率？TCP擁塞控制算法包括三個(gè)部分：加性增/乘性減原則慢啟動(dòng)算法快速重傳和快速恢復(fù)機(jī)制第六十五頁，共八十二頁，編輯于2023年，星期日加性增/乘性減（AIMD）乘性減（multiplicativedecrease）：每發(fā)生一次超時(shí)，就將當(dāng)前擁塞窗口減半（最小不低于1個(gè)MSS）。因此，當(dāng)發(fā)送端持續(xù)出現(xiàn)超時(shí)時(shí)，擁塞窗口按指數(shù)遞減，以顯著減少通信量。加性增（additiveincrease）：當(dāng)擁塞窗口內(nèi)的段都在預(yù)定的時(shí)間內(nèi)被確認(rèn)（沒有超時(shí)發(fā)生）時(shí)，擁塞窗口增大一個(gè)MSS。在實(shí)際操作時(shí)，每當(dāng)收到一個(gè)確認(rèn)，就在擁塞窗口上加一個(gè)增量。若擁塞窗口用CongWin表示，則每次收到一個(gè)確認(rèn)后，擁塞窗口的增量Δ按如下公式計(jì)算：Δ=MSS×（MSS/CongWin）。第六十六頁，共八十二頁，編輯于2023年，星期日慢啟動(dòng)（slowstart）在剛建立的TCP連接上，發(fā)送端以一個(gè)MSS作為擁塞窗口的初始值。每當(dāng)收到一個(gè)確認(rèn)，就將擁塞窗口增加1個(gè)MSS，直至發(fā)生超時(shí)。因此，初始階段擁塞窗口是按指數(shù)增長的。第六十七頁，共八十二頁，編輯于2023年，星期日慢啟動(dòng)在兩種情況下使用連接剛建立的時(shí)候超時(shí)后重新啟動(dòng)數(shù)據(jù)傳輸?shù)臅r(shí)候，因?yàn)檫@時(shí)通常有一個(gè)較大的接收窗口：當(dāng)一個(gè)TCP段丟失后，接收端在某個(gè)時(shí)間點(diǎn)后不再發(fā)送確認(rèn)（零窗口通告除外），也不再接收新的數(shù)據(jù)。發(fā)送端在發(fā)送完規(guī)定數(shù)量的數(shù)據(jù)段后停下來等待確認(rèn)，至超時(shí)發(fā)生；這期間沒有數(shù)據(jù)發(fā)送。在此期間，接收方應(yīng)用程序可能取走大部分甚至全部的數(shù)據(jù)，并通告一個(gè)較大的接收窗口。第六十八頁，共八十二頁，編輯于2023年，星期日擁塞避免1）發(fā)生超時(shí)時(shí)，將當(dāng)前擁塞窗口的一半作為擁塞閾值。2）將擁塞窗口初始化為1個(gè)MSS，使用慢啟動(dòng)發(fā)送。3）當(dāng)擁塞窗口達(dá)到閾值時(shí)，按照加性增繼續(xù)增加擁塞窗口（稱擁塞避免），直至發(fā)生超時(shí)，回到1）。4）若在擁塞窗口達(dá)到閾值前就發(fā)生了超時(shí)，回到1）。第六十九頁，共八十二頁，編輯于2023年，星期日快速重傳試圖區(qū)分是單純的段丟失還是擁塞，并加快丟失段的重發(fā)：接收方對(duì)于每個(gè)到達(dá)的TCP段都要給予響應(yīng)。對(duì)于未按正常順序到達(dá)的段，接收并緩存，然后發(fā)送一個(gè)重復(fù)確認(rèn)（將上一次發(fā)過的確認(rèn)信息再發(fā)一次）。發(fā)送方在收到3個(gè)重復(fù)確認(rèn)后開始重傳丟失的段。接收方收到重傳的數(shù)據(jù)段后，對(duì)已正確接收的數(shù)據(jù)發(fā)送累積確認(rèn)。若發(fā)送方在收到3個(gè)重復(fù)確認(rèn)前發(fā)生超時(shí)，按超時(shí)事件處理。第七十頁，共八十二頁，編輯于2023年，星期日快速恢復(fù)發(fā)送端在收到3個(gè)重復(fù)確認(rèn)后進(jìn)入擁塞避免階段（而不是慢啟動(dòng)階段）。具體來說，當(dāng)發(fā)送端收到少于3個(gè)重復(fù)確認(rèn)時(shí)，擁塞窗口和擁塞閾值均不變。當(dāng)收到第3個(gè)重復(fù)確認(rèn)時(shí)，將擁塞閾值設(shè)為擁塞窗口的一半，并令擁塞窗口等于擁塞閾值，此后擁塞窗口按線性增長。第七十一頁，共八十二頁，編輯于2023年，星期日TCP擁塞控制算法的仿真結(jié)果第七十二頁，共八十二頁，編輯于2023年，星期日（5）TCP重傳定時(shí)器TCP主要使用超時(shí)來觸發(fā)重傳：TCP實(shí)體每發(fā)送一個(gè)TCP段，就啟動(dòng)一個(gè)重傳定時(shí)器，定時(shí)器超時(shí)后重發(fā)該段。重傳定時(shí)器的值對(duì)TCP的性能影響很大：該值設(shè)置太大，導(dǎo)致較長的端到端延遲。該值設(shè)置太小，導(dǎo)致許多不必要的重傳；更為嚴(yán)重的是會(huì)啟動(dòng)擁塞控制機(jī)制，導(dǎo)致發(fā)送速率急劇下降。問題：重傳定時(shí)器的值（超時(shí)間隔）設(shè)為多長合適？第七十三頁，共八十二頁，編輯于2023年，星期日RoundTripTime（RTT）直觀上考慮，超時(shí)間隔應(yīng)與TCP段的平均來回時(shí)間及方差有關(guān)。來回時(shí)間的估算：TCP對(duì)每條連接維護(hù)一個(gè)變量RTT，這是對(duì)來回時(shí)間的估計(jì)值。在發(fā)送了一個(gè)段后啟動(dòng)重傳定時(shí)器，若在超時(shí)前得到確認(rèn)，終止定時(shí)器，計(jì)算出當(dāng)前的來回時(shí)間M。根據(jù)以下公式修正RTT值，其中α是比例因子：

RTT=α*RTT+(1-α)*M第七十四頁，共八十二頁，編輯于2023年，星期日RTT的平均偏差TCP實(shí)體維護(hù)另一個(gè)變量D，它是來回時(shí)間的測量值與估計(jì)值之間的偏差。當(dāng)?shù)玫絉TT的最新估計(jì)值