數(shù)據(jù)通信與計(jì)算機(jī)網(wǎng)絡(luò)（第二版）課件：傳輸層

傳輸層9.1傳輸層提供的服務(wù)9.2傳輸控制協(xié)議TCP9.3一個(gè)SOCKET程序?qū)嵗?.4用戶數(shù)據(jù)報(bào)協(xié)議UDP9.1.1傳輸層概述傳輸層位于網(wǎng)絡(luò)體系結(jié)構(gòu)的第四層，是整個(gè)網(wǎng)絡(luò)體系結(jié)構(gòu)的核心部分之一。傳輸層的目標(biāo)是利用網(wǎng)絡(luò)層提供的服務(wù)向其用戶（應(yīng)用進(jìn)程）提供有效、可靠且價(jià)格合理的服務(wù)。9.1.1傳輸層概述在通信子網(wǎng)中沒有傳輸層，它只存在于通信子網(wǎng)以外的各主機(jī)中。9.1.1傳輸層概述如果將整個(gè)網(wǎng)絡(luò)體系結(jié)構(gòu)從網(wǎng)絡(luò)功能和用戶功能角度來劃分，傳輸層是網(wǎng)絡(luò)功能部分的最上層。9.1.2提供給高層的服務(wù)傳輸層位于收發(fā)兩端的主機(jī)上，以獨(dú)立的傳輸層實(shí)體存在，并通過相應(yīng)接口向上層提供服務(wù)9.1.3傳輸層要素傳輸層需要完成幾個(gè)工作：傳輸層尋址連接管理差錯(cuò)控制流量控制1．傳輸層尋址傳輸層對(duì)主機(jī)上的不同網(wǎng)絡(luò)進(jìn)程進(jìn)行了編號(hào)，用不同的數(shù)字區(qū)分不同的網(wǎng)絡(luò)進(jìn)程。傳輸層標(biāo)識(shí)網(wǎng)絡(luò)進(jìn)程的數(shù)字稱為傳輸層地址或端口號(hào)。通過該方法，傳輸層可以使多對(duì)進(jìn)程間的通信復(fù)用到一個(gè)網(wǎng)絡(luò)連接上，以此來完成多對(duì)應(yīng)用程序間的通信。2．連接管理通過連接管理，傳輸層保證了數(shù)據(jù)按順序、不重復(fù)地傳輸。傳輸層在發(fā)送數(shù)據(jù)之前需要先建立連接。在連接建立過程中，進(jìn)行初始序號(hào)協(xié)商和分配資源等工作。連接建立后，傳輸層才開始發(fā)送數(shù)據(jù)。在數(shù)據(jù)發(fā)送過程中，數(shù)據(jù)的序號(hào)在初始序號(hào)的基礎(chǔ)上依次遞增3．差錯(cuò)控制傳輸層一般使用確認(rèn)和超時(shí)重傳的機(jī)制保證數(shù)據(jù)正確傳輸。因?yàn)榫€路原因，數(shù)據(jù)在傳輸時(shí)可能出錯(cuò)；因?yàn)槁酚善髫?fù)載過重的原因，數(shù)據(jù)在傳輸時(shí)可能丟失。為使發(fā)送端知道數(shù)據(jù)是否正確傳輸，傳輸層實(shí)體使用確認(rèn)機(jī)制，接收端正確收到數(shù)據(jù)后向發(fā)送端回發(fā)確認(rèn)。4．流量控制與緩沖機(jī)制中間網(wǎng)絡(luò)負(fù)載過重造成數(shù)據(jù)丟失4．流量控制與緩沖機(jī)制接收緩沖區(qū)溢出造成數(shù)據(jù)丟失4．流量控制與緩沖機(jī)制為了防止發(fā)送方發(fā)送速度過快，加重網(wǎng)絡(luò)負(fù)擔(dān)或“淹沒”接收方，需要調(diào)整發(fā)送方的發(fā)送速度，稱為流量控制。與數(shù)據(jù)鏈路層類似，傳輸層會(huì)限制對(duì)發(fā)送緩沖區(qū)的使用，即使用滑動(dòng)窗口方法。不同的是，傳輸層會(huì)動(dòng)態(tài)調(diào)整可用發(fā)送緩沖區(qū)的大小，即使用可變大小的發(fā)送窗口9.1.4TCP/IP協(xié)議中的傳輸層TCP/IP協(xié)議棧的傳輸層包括兩個(gè)協(xié)議：UDP（UserDatagramProtocol，用戶數(shù)據(jù)報(bào)協(xié)議）和TCP（TransmissionControlProtocol，傳輸控制協(xié)議）。9.1.4TCP/IP協(xié)議中的傳輸層TCP是可靠的、面向連接的。TCP進(jìn)行傳輸層尋址、連接管理、差錯(cuò)控制和流量控制。如果IP分組的傳輸出現(xiàn)錯(cuò)誤、丟失或亂序，TCP會(huì)進(jìn)行處理，從而保證應(yīng)用程序得到的是可靠的數(shù)據(jù)。TCP與UDP相比提供了較多的功能，但是相對(duì)的報(bào)文格式和運(yùn)行機(jī)制也較為復(fù)雜。UDP是不可靠、無連接的，即在進(jìn)行數(shù)據(jù)傳輸之前不需要建立連接，而目的主機(jī)收到數(shù)據(jù)報(bào)后也不需要發(fā)回確認(rèn)。這種協(xié)議提供了一種高效的傳輸服務(wù)，用于一次傳輸少量數(shù)據(jù)報(bào)文的情況，其可靠性由應(yīng)用程序來提供。9.1.4TCP/IP協(xié)議中的傳輸層為了防止發(fā)送方發(fā)送速度過快，加重網(wǎng)絡(luò)負(fù)擔(dān)或“淹沒”接收方，需要調(diào)整發(fā)送方的發(fā)送速度，稱為流量控制。與數(shù)據(jù)鏈路層類似，傳輸層會(huì)限制對(duì)發(fā)送緩沖區(qū)的使用，即使用滑動(dòng)窗口方法。不同的是，傳輸層會(huì)動(dòng)態(tài)調(diào)整可用發(fā)送緩沖區(qū)的大小，即使用可變大小的發(fā)送窗口9.1.5端口當(dāng)信息包通過網(wǎng)絡(luò)層的傳輸?shù)竭_(dá)目的地后，如果目的計(jì)算機(jī)上有多個(gè)應(yīng)用程序正在同時(shí)運(yùn)行，應(yīng)該確定信息包上傳給哪個(gè)應(yīng)用程序。傳輸層可以通過協(xié)議端口（ProtocolPort，簡(jiǎn)稱端口）來標(biāo)識(shí)通信的應(yīng)用進(jìn)程。傳輸層通過端口與應(yīng)用層的應(yīng)用程序進(jìn)行信息交互，而應(yīng)用層的各種用戶進(jìn)程通過相應(yīng)的端口與傳輸層實(shí)體進(jìn)行信息交互。9.1.5端口常見的熟知端口號(hào)協(xié)議端口號(hào)關(guān)鍵字描述UDP42NAMESERVER主機(jī)名字服務(wù)器UDP53DOMAIN域名服務(wù)器UDP67BOOTPClient客戶端啟動(dòng)協(xié)議服務(wù)UDP68BOOTPServer服務(wù)器端啟動(dòng)協(xié)議服務(wù)UDP69TFTP簡(jiǎn)單文件傳輸協(xié)議UDP111RPC微系統(tǒng)公司RPCTCP20FTPData文件傳輸服務(wù)器（數(shù)據(jù)連接）TCP21FTPControl文件傳輸服務(wù)器（控制連接）TCP23Telnet遠(yuǎn)程終端服務(wù)器TCP25SMTP簡(jiǎn)單郵件傳輸協(xié)議TCP80HTTP超文本傳輸協(xié)議9.1.5端口通過SMTP進(jìn)行通信的主機(jī)9.2傳輸控制協(xié)議TCP特點(diǎn)：可靠的傳輸面向連接數(shù)據(jù)流式傳輸全雙工9.2.1TCP的報(bào)文格式

TCP報(bào)文封裝在IP分組中，一個(gè)TCP報(bào)文分為兩個(gè)部分：首部和數(shù)據(jù)。TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部源端口和目的端口字段——各占2字節(jié)，分別標(biāo)識(shí)連接兩端的兩個(gè)通信的應(yīng)用進(jìn)程。

TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部發(fā)送序號(hào)：占4個(gè)字節(jié)。TCP對(duì)每一個(gè)字節(jié)進(jìn)行編號(hào)，在這個(gè)字段中給出的數(shù)字是本報(bào)文段所發(fā)送的數(shù)據(jù)部分的第一個(gè)字節(jié)的序號(hào)。

TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部接收序號(hào)：又稱作確認(rèn)序號(hào)，占4個(gè)字節(jié)。期望收到的下一個(gè)報(bào)文段的首部中的發(fā)送序號(hào)，同時(shí)確認(rèn)以前收到的報(bào)文。

TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部數(shù)據(jù)偏移：占4位，指出在TCP數(shù)據(jù)報(bào)內(nèi)實(shí)際的數(shù)據(jù)到TCP報(bào)文段的起始位置的距離?！皵?shù)據(jù)偏移”字段存儲(chǔ)的數(shù)值的單位是32位的字。

TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部保留字段與標(biāo)志位：占6位，設(shè)置的值為0，供功能擴(kuò)展使用，新的TCP版本有些位已被啟用。

TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部緊急比特位（URG）。當(dāng)為1時(shí)，表明此報(bào)文段為緊急數(shù)據(jù)段，需要馬上傳送出去，而不要按照原來的排隊(duì)順序來傳送，具有加速數(shù)據(jù)傳送的功能。

TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部確認(rèn)比特（ACK）：標(biāo)志著首部中“確認(rèn)序號(hào)”字段是否可用，當(dāng)設(shè)置此位為1時(shí)，確認(rèn)序號(hào)才有意義。

TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部緊迫比特（PSH）：為緊急報(bào)文段，當(dāng)為1時(shí)，表明請(qǐng)求遠(yuǎn)地目的主機(jī)的TCP要將本報(bào)文段立即向上傳遞給其應(yīng)用層進(jìn)行處理。

TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部復(fù)位比特RST(ReSeT)：當(dāng)為1時(shí)，表明TCP連接中出現(xiàn)嚴(yán)重差錯(cuò)，必須釋放連接，然后再重新建立運(yùn)輸連接。TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部同步比特（SYN）：在建立連接時(shí)使用，與ACK配合使用：當(dāng)SYN=1，ACK=0時(shí)，表明一個(gè)請(qǐng)求建立連接的報(bào)文段；若對(duì)方同意建立連接，則在發(fā)回的確認(rèn)報(bào)文段中會(huì)將SYN設(shè)置為1，ACK設(shè)置為1。

TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部終止比特FIN(FINal)：用來釋放一個(gè)連接。當(dāng)FIN

1時(shí)，表明此報(bào)文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放運(yùn)輸連接。TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部窗口：占2字節(jié)，用來控制對(duì)方發(fā)送的數(shù)據(jù)量，單位為字節(jié)。所設(shè)定的值既是自己的接收窗口，也是對(duì)方發(fā)送窗口的上限。TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部檢驗(yàn)和——占2字節(jié)。檢驗(yàn)和字段檢驗(yàn)的范圍包括首部和數(shù)據(jù)這兩部分。在計(jì)算檢驗(yàn)和時(shí)，要在TCP報(bào)文段的前面加上12字節(jié)的偽首部。檢驗(yàn)和(偽首部)偽首部既不向下傳送也不上交，第三個(gè)字段全為0，第四個(gè)字段是IP首部中的協(xié)議字段值，TCP協(xié)議的編號(hào)值為6，第五個(gè)字段給出整個(gè)TCP數(shù)據(jù)報(bào)的長(zhǎng)度。源IP地址06TCP長(zhǎng)度44112字節(jié)目的IP地址檢驗(yàn)和檢驗(yàn)和就是按照這個(gè)過渡的數(shù)據(jù)報(bào)格式進(jìn)行計(jì)算的。TCP的檢驗(yàn)和字段首先設(shè)置為0，并且當(dāng)數(shù)據(jù)長(zhǎng)度是奇數(shù)時(shí)數(shù)據(jù)字段附加填空一個(gè)0字節(jié)，檢驗(yàn)和算法是簡(jiǎn)單地將所有16位字以補(bǔ)碼形式相加，然后再對(duì)相加后的和取補(bǔ)，因此當(dāng)接收方對(duì)整個(gè)數(shù)據(jù)段，包括檢驗(yàn)和字段進(jìn)行運(yùn)算時(shí)，結(jié)果應(yīng)為0。接收端在收到報(bào)文段后，仍然要加上偽首部進(jìn)行檢驗(yàn)和的計(jì)算。在檢驗(yàn)和計(jì)算過程中，包括了偽首部，有助于檢測(cè)傳送的分組是否正確，但這樣做卻違反了協(xié)議的分層規(guī)則。TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部緊急指針：與緊急比特配合使用處理緊急情況，指出在本報(bào)文段中的緊急數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)。

TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部單字節(jié)選項(xiàng)：選項(xiàng)結(jié)束和無操作；多字節(jié)選項(xiàng)：最大報(bào)文段長(zhǎng)度、窗口擴(kuò)大因子以及時(shí)間戳

最大報(bào)文段長(zhǎng)度MSS（MaximumSegmentSize）

：定義可以被目的站接收的TCP報(bào)文段的最長(zhǎng)數(shù)據(jù)塊，定義了數(shù)據(jù)的最大長(zhǎng)度。這個(gè)字段是16位長(zhǎng)，因此這個(gè)值在0到65535之間。默認(rèn)值是536。最大數(shù)據(jù)長(zhǎng)度是在連接建立階段確定的，這個(gè)大小是由報(bào)文段的目的站而不是源站確定的。

TCP首部目的端口數(shù)據(jù)偏移檢驗(yàn)和選項(xiàng)（長(zhǎng)度可變）源端口發(fā)送序號(hào)緊急指針窗口接收序號(hào)（確認(rèn)號(hào)）保留FINSYNRSTPSHACKURG比特08162431填充20字節(jié)固定首部填充字段：這是為了使整個(gè)首部長(zhǎng)度是4字節(jié)的整數(shù)倍。9.2.2TCP的編號(hào)與確認(rèn)TCP協(xié)議是面向字節(jié)的。TCP將所要傳送的報(bào)文看成是字節(jié)組成的數(shù)據(jù)流，并使每一個(gè)字節(jié)對(duì)應(yīng)于一個(gè)序號(hào)。在連接建立時(shí)，雙方要商定初始序號(hào)。TCP每次發(fā)送的報(bào)文段的首部中的序號(hào)字段數(shù)值表示該報(bào)文段中的數(shù)據(jù)部分的第一個(gè)字節(jié)的序號(hào)。

TCP的確認(rèn)是對(duì)接收到的數(shù)據(jù)的最高序號(hào)表示確認(rèn)。接收端返回的確認(rèn)號(hào)是已收到的數(shù)據(jù)的最高序號(hào)加1。因此確認(rèn)號(hào)表示接收端期望下次收到的數(shù)據(jù)中的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)。9.2.3TCP擁塞控制Internet的復(fù)雜性、網(wǎng)絡(luò)流量的不可預(yù)知及不可控性、網(wǎng)絡(luò)故障的不可避免性、算法不可能完美等等因素決定了網(wǎng)絡(luò)擁塞的不可避免。當(dāng)加載到某個(gè)網(wǎng)絡(luò)上的載荷超過其處理能力時(shí)，擁塞現(xiàn)象便會(huì)出現(xiàn)。TCP是端到端的可靠的、面向連接的服務(wù)。它必須解決三層以下的不可靠問題。一般的，TCP依靠確認(rèn)、超時(shí)重傳來保證可靠傳輸。然而，無節(jié)制的重傳造成第三層更加嚴(yán)重的擁塞后果。因此，TCP采用特定的算法，與IP協(xié)同作用，盡最大努力來避免擁塞或減緩擁塞的發(fā)生。9.2.3TCP擁塞控制為了同時(shí)反映網(wǎng)絡(luò)的問題，TCP依據(jù)兩個(gè)窗口來協(xié)同工作：接收方準(zhǔn)許的窗口（rwnd–receiverwindow）和擁塞窗口(cwnd-congestionwindow)。每個(gè)窗口都反應(yīng)了發(fā)送方可以傳輸?shù)淖止?jié)數(shù)。取兩個(gè)窗口的最小值作為可以發(fā)送的字節(jié)數(shù)。這樣，有效窗口便是發(fā)送方和接收方分別認(rèn)為合適的窗口中最小的那個(gè)。即： 發(fā)送的窗口大小=min(rwnd,cwnd)9.2.3TCP擁塞控制當(dāng)建立連接時(shí)，發(fā)送方將擁塞窗口大小初始化為該連接所用的最大數(shù)據(jù)段的長(zhǎng)度值。通常情況下，此時(shí)的擁塞控制窗口會(huì)小于接收窗口，然后發(fā)送一個(gè)最大長(zhǎng)度的數(shù)據(jù)段。如果該數(shù)據(jù)段在定時(shí)器超時(shí)之前得到了確認(rèn)，那么發(fā)送方會(huì)在原擁塞窗口的基礎(chǔ)上再增加一個(gè)數(shù)據(jù)段的字節(jié)值，使其為兩倍最大數(shù)據(jù)段的大小，然后發(fā)送兩個(gè)數(shù)據(jù)段。當(dāng)這些數(shù)據(jù)段中的每一個(gè)都被確認(rèn)后，擁塞窗口大小就再加倍。實(shí)際上，每次成功地得到確認(rèn)都會(huì)使擁塞窗口的大小加倍.9.2.3TCP擁塞控制TCP在執(zhí)行擁塞控制算法時(shí)除了接收窗口（rwnd）和擁塞窗口（cwnd）外還要設(shè)定一個(gè)參數(shù)，就是臨界值（threshold）。傳輸伊始，臨界值初始化為64KB。然后從一個(gè)最大數(shù)據(jù)段大小開始，逐漸增大擁塞窗口，如果發(fā)生數(shù)據(jù)傳輸超時(shí)，將臨界值設(shè)置為當(dāng)前擁塞窗口大小的1／2，并使擁塞窗口恢復(fù)為最大數(shù)據(jù)段的大小，重新開始慢啟動(dòng)過程。當(dāng)窗口增大到臨界值仍然沒有發(fā)生超時(shí)，也不能再按指數(shù)增大窗口，而是按線性增加(對(duì)每個(gè)字符組按最大數(shù)據(jù)段的值增加)。這一階段又稱為擁塞避免（CongestionAvoidance）。9.2.3TCP擁塞控制開始時(shí)擁塞窗口為64KB，但此時(shí)出現(xiàn)了超時(shí)，因此將臨界值設(shè)置為32KB，傳輸號(hào)0的擁塞窗口為1KB。之后擁塞窗口按指數(shù)規(guī)律增大直到臨界值(32KB)。并由此開始按線性規(guī)律增大。傳輸號(hào)13發(fā)生了定時(shí)器超時(shí)，臨時(shí)界值被設(shè)置為當(dāng)前窗口的1／2(當(dāng)前為40KB，因此1／2為20KB)，慢啟動(dòng)又從頭開始。傳輸號(hào)18前面四次傳輸每次均是按指數(shù)增量增大擁塞窗口，但這之后，窗口又將按線性增大。9.2.4顯式擁塞指示上述擁塞控制算法是建立在所有傳輸超時(shí)都是由于擁塞引起的這樣的假設(shè)基礎(chǔ)上的。它將網(wǎng)絡(luò)當(dāng)做一個(gè)黑匣子，根本不知道網(wǎng)絡(luò)中到底發(fā)生了什么情況。能否將網(wǎng)絡(luò)的狀態(tài)明確的“告知”連接的兩個(gè)端系統(tǒng)呢。2001年9月IETF網(wǎng)絡(luò)工作組發(fā)布了RFC3168--在IP中增加顯式擁塞指示（ECN-ExplicitCongestionnotification），旨在報(bào)告?zhèn)鬏斅窂缴系膿砣麪顩r。9.2.4顯式擁塞指示ECN功能涉及到IP數(shù)據(jù)報(bào)頭格式和TCP報(bào)頭格式定義的變化。在IPv4數(shù)據(jù)報(bào)頭中，RFC3168定義了新的TOS字段格式9.2.4顯式擁塞指示DS字段為區(qū)別服務(wù)碼點(diǎn)，是為IP數(shù)據(jù)報(bào)通過路由器時(shí)選擇不同類型的服務(wù)之用。位6和位7用于擁塞的顯示指示（ECNFIELD）。位狀態(tài)狀態(tài)名稱功能描述Bit6Bit700Not-ECT本數(shù)據(jù)包不使用ECN功能01ECT(1)數(shù)據(jù)包使用ECN功能傳輸10ECT(0)數(shù)據(jù)包使用ECN功能傳輸11CE路由器擁塞指示9.2.4顯式擁塞指示由主機(jī)和路由器協(xié)同完成的IP的ECN功能只是實(shí)現(xiàn)了傳輸路徑上的擁塞狀況指示，對(duì)擁塞的處理需要傳輸層協(xié)議的支持。對(duì)TCP而言，首先要確定連接的兩個(gè)端點(diǎn)都支持ECN；其次，接收端能對(duì)收到的CE數(shù)據(jù)包做出反應(yīng)以通知發(fā)送端；再次，發(fā)送端接到通知后，要對(duì)擁塞做出應(yīng)對(duì)。這將要求TCP增加三項(xiàng)功能：第一：在連接建立階段協(xié)商兩端點(diǎn)是否均支持ECN（ECN-Capable）；第二：在TCP報(bào)頭增加ECN-Echo(ECE)標(biāo)志，以使得接收端有能力通知發(fā)送端其收到了帶有CE標(biāo)志的數(shù)據(jù)包；第三：在TCP報(bào)頭增加擁塞窗口減小標(biāo)志CWR(CongestionWindowReduced)使得發(fā)送方能夠通知接收方已經(jīng)對(duì)出現(xiàn)的擁塞做出應(yīng)對(duì)。這里有必要說明的是，支持ECN功能的TCP源端在應(yīng)對(duì)擁塞時(shí)，仍然采用傳統(tǒng)的擁塞控制算法即：慢啟動(dòng)、擁塞避免、快速恢復(fù)等機(jī)制。9.2.4顯式擁塞指示TCP包頭部第13和14字節(jié)的新定義9.2.4顯式擁塞指示TCP實(shí)體是否支持ECN功能要靠連接建立階段雙方協(xié)商來確定。如果發(fā)起連接請(qǐng)求的一方稱為HostA，響應(yīng)的一方稱為HostB，連接協(xié)商支持ECN的過程如圖9.2.5TCP的差錯(cuò)控制TCP是一個(gè)可靠的運(yùn)輸層協(xié)議。這里的可靠指數(shù)據(jù)是按序的、沒有差錯(cuò)、也沒有任何一部分丟失或重復(fù)。TCP使用差錯(cuò)控制提供可靠性。1．差錯(cuò)檢測(cè)和糾正TCP中的差錯(cuò)檢測(cè)是通過三種簡(jiǎn)單工具來完成的：檢驗(yàn)和、確認(rèn)和超時(shí)。

2．受損傷的報(bào)文段3．丟失的報(bào)文段

與受損報(bào)文段的情況完全一樣。

4．重復(fù)的報(bào)文段

當(dāng)含有同樣序號(hào)的分組作為另一個(gè)收到的報(bào)文段到達(dá)時(shí)，目的TCP只要丟棄這個(gè)分組就行了。

5．失序的報(bào)文段TCP使用IP數(shù)據(jù)報(bào)的服務(wù)，而IP數(shù)據(jù)報(bào)是不可靠的無連接網(wǎng)絡(luò)層協(xié)議。TCP對(duì)失序的報(bào)文段不確認(rèn)，直到收到所有它以前的報(bào)文段為止。6．丟失的確認(rèn)在TCP的確認(rèn)機(jī)制中，丟失的確認(rèn)甚至不會(huì)被源TCP發(fā)現(xiàn)，TCP使用累計(jì)確認(rèn)系統(tǒng)。9.2.6TCP的定時(shí)機(jī)制重發(fā)機(jī)制是TCP協(xié)議中最重要和最復(fù)雜的問題之一。

關(guān)鍵在于如何設(shè)置定時(shí)器的時(shí)間，定時(shí)器的時(shí)間應(yīng)該等于數(shù)據(jù)報(bào)文段往返時(shí)延，也就是等于從數(shù)據(jù)發(fā)出到收到對(duì)方確認(rèn)所經(jīng)歷的時(shí)間。TCP采用了一種自適應(yīng)算法來計(jì)算重發(fā)超時(shí)時(shí)間。這種算法把每次每個(gè)報(bào)文段發(fā)出的時(shí)間和收到此報(bào)文段確認(rèn)的時(shí)間都記錄下來，兩時(shí)間之差稱為報(bào)文段的往返時(shí)延。9.2.6TCP的定時(shí)機(jī)制TCP所面臨的是完全不同的情況。發(fā)送者和接收者之間要跨過若干個(gè)網(wǎng)絡(luò)，經(jīng)過n個(gè)路由器。不但其網(wǎng)絡(luò)環(huán)境是復(fù)雜的，而且網(wǎng)絡(luò)狀況還在不斷地變化之中，并且，同一個(gè)連接內(nèi)的不同報(bào)文段還可能選擇不同的路由。其確認(rèn)返回所需時(shí)間的概率密度函數(shù)接近于圖中所示的曲線。記錄每一個(gè)報(bào)文段發(fā)出的時(shí)間，以及收到相應(yīng)的確認(rèn)報(bào)文段的時(shí)間。這兩個(gè)時(shí)間之差就是報(bào)文段的往返時(shí)延。將各個(gè)報(bào)文段的往返時(shí)延樣本加權(quán)平均，就得出報(bào)文段的平均往返時(shí)延

RTT。每測(cè)量到一個(gè)新的往返時(shí)延樣本，就按下式重新計(jì)算一次平均往返時(shí)延RTT：平均往返時(shí)延RTT

(舊的RTT)

(1

)

(新的往返時(shí)延樣本)在上式中，0

1，通常

取7/8。往返時(shí)延的自適應(yīng)算法計(jì)時(shí)器的重傳時(shí)間RTO計(jì)時(shí)器的重傳時(shí)間應(yīng)略大于上面得出的RTT，即：

RTO

RTT這里

是個(gè)大于1的系數(shù)。若取

很接近于1，發(fā)送端可及時(shí)地重傳丟失的報(bào)文段，因此效率得到提高。但若報(bào)文段并未丟失而僅僅是增加了一點(diǎn)時(shí)延，那么過早地重傳反而會(huì)加重網(wǎng)絡(luò)的負(fù)擔(dān)。因此TCP原先的標(biāo)準(zhǔn)推薦將

值取為2。計(jì)時(shí)器的重傳時(shí)間RTO1988年，Jacobson提出一種動(dòng)態(tài)的確定超時(shí)重發(fā)時(shí)間的方法，他提出β的變化要與確認(rèn)到達(dá)時(shí)間的概率密度函數(shù)的標(biāo)準(zhǔn)偏差大致成比例，并建議采用平均偏差作為對(duì)標(biāo)準(zhǔn)偏差的粗略估計(jì)。計(jì)時(shí)器的重傳時(shí)間RTO在這種算法中，需要保存另一個(gè)修正因子D（RTT與M之間的偏差），按照下列公式進(jìn)行計(jì)算RTO：

RTT=αRTT+(1-α)MD=αD+(1-α)|RTT-M|RTO=RTT+4D其中，修正D的α與用于修正RTT的值可以相同也可以不同（有些程序中選擇α=3/4）9.2.7TCP的傳輸連接管理TCP是面向連接的，在進(jìn)行數(shù)據(jù)通信之前需要在兩臺(tái)主機(jī)間建立連接，通信完畢后要釋放連接。TCP以連接為單位對(duì)數(shù)據(jù)的傳輸進(jìn)行統(tǒng)一管理。TCP在為數(shù)據(jù)分配序號(hào)時(shí)對(duì)一個(gè)連接中的數(shù)據(jù)統(tǒng)一編號(hào)，不同連接的數(shù)據(jù)編號(hào)不相關(guān)；在分配緩存和計(jì)時(shí)器等資源時(shí)，也以連接為單位進(jìn)行分配。傳輸層連接管理的主要工作包括傳輸連接的建立和釋放。1．TCP連接的建立TCP在連接建立階段主要完成下面工作：（1）決定雙方的初始序號(hào)。（2）每一方確定對(duì)方的存在（可正常工作）。（3）雙方協(xié)商一些參數(shù)（如最大TCP段長(zhǎng)度、最大窗口等）。（4）對(duì)一些傳輸過程中需要用到的資源（如收發(fā)緩沖區(qū)、記錄狀態(tài)的變量等）進(jìn)行分配。1．TCP連接的建立TCP采用“三次握手”方式來建立連接，這種方式可以有效地防止已失效的連接請(qǐng)求報(bào)文段突然傳送到接收端。2．連接的釋放當(dāng)雙方數(shù)據(jù)傳送結(jié)束后，需要釋放目前的連接。TCP在連接釋放過程中釋放如緩存等資源，同時(shí)不再繼續(xù)收發(fā)數(shù)據(jù)。TCP的連接釋放采用對(duì)稱的釋放方式，即雙方都需要釋放連接，并且雙方任意一方都可以發(fā)出釋放連接的請(qǐng)求。連接的釋放需要逐步完成，首先停止一方對(duì)另一方的數(shù)據(jù)傳輸，然后再停止反方向上的數(shù)據(jù)傳輸。2．連接的釋放一般來說，連接釋放的過程采用“四次握手”的方式。第一次握手：當(dāng)一方將停止數(shù)據(jù)傳輸時(shí)，需向?qū)Ψ桨l(fā)出釋放連接的請(qǐng)求。第二次握手：對(duì)方收到此請(qǐng)求后，會(huì)發(fā)送確認(rèn)報(bào)文段。發(fā)出請(qǐng)求的一方收到確認(rèn)報(bào)文段后停止數(shù)據(jù)傳輸。此時(shí)，連接是“半關(guān)閉”的，即另一方仍可發(fā)送數(shù)據(jù)。第三次握手：當(dāng)另一方要停止數(shù)據(jù)傳輸時(shí)，也需發(fā)出釋放連接的請(qǐng)求。第四次握手：收到釋放連接請(qǐng)求的一方回發(fā)確認(rèn)報(bào)文段。當(dāng)收到確認(rèn)報(bào)文段后，整個(gè)連接釋放完畢。2．連接的釋放TCP連接的釋放過程3．連接復(fù)位TCP可以請(qǐng)求將一條連接復(fù)