第5章傳輸層協(xié)議《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議2本章學(xué)習(xí)要求：掌握：用戶數(shù)據(jù)報協(xié)議UDP。掌握：傳輸控制協(xié)議TCP。了解：StreamControlTransmissionProtocolSCTP

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議35.1網(wǎng)絡(luò)環(huán)境中分布式進程通信的基本概念《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議4網(wǎng)絡(luò)層及以下的各層實現(xiàn)了網(wǎng)絡(luò)中主機之間的通信，但是數(shù)據(jù)通信不是最終的目的;計算機網(wǎng)絡(luò)最本質(zhì)的活動是分布在不同地理位置的主機之間的進程通信，以實現(xiàn)各種網(wǎng)絡(luò)服務(wù)功能;設(shè)置傳輸層的主要目的就是要實現(xiàn)分布式進程通信。

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議55.1.1單機系統(tǒng)中的進程通信方法

進程和進程通信是操作系統(tǒng)中的一個最基本的概念；程序是一個在時間上按照嚴格次序的前后相繼的操作序列，是一個靜態(tài)的概念；進程是一個動態(tài)的概念，它是一個程序?qū)δ硞€數(shù)據(jù)集的執(zhí)行過程；《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議6正在運行的進程叫做運行態(tài)；等待分配CPU的進程叫做就緒態(tài)；等待其他的條件的進程叫做等待態(tài)；進程狀態(tài)反映出進程執(zhí)行過程的變化；要保證系統(tǒng)正常地工作，操作系統(tǒng)必須對進程的創(chuàng)建、撤消與狀態(tài)轉(zhuǎn)換進行控制；從進程的觀點看，操作系統(tǒng)的核心則是控制和協(xié)調(diào)這些進程的運行，解決進程之間的通信?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議7在解決單機環(huán)境下操作系統(tǒng)的進程通信中：BSDUNIX引入了管道（pipe）、命名管道（namedpipe）和軟中斷信號（signal）機制；AT&TUNIX引入了消息（message）、共享存儲區(qū)（sharedmemory）和信號量（semaphore）等；UNIX系統(tǒng)的消息、共享存儲區(qū)和信號量統(tǒng)稱為進程通信（interprocesscommunication，IPC）機制；IPC機制也不適應(yīng)于網(wǎng)絡(luò)環(huán)境中的進程通信?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議85.1.2網(wǎng)絡(luò)環(huán)境中分布式進程通信的特點用一句最簡單的話去描述計算機網(wǎng)絡(luò)，那就是：

“計算機網(wǎng)絡(luò)是分布在不同地理位置的多臺獨立的計算機系統(tǒng)的集合”?！蔼毩⒌挠嬎銠C系統(tǒng)”意味著連網(wǎng)的每一臺計算機的操作與資源是由自己的操作系統(tǒng)所管理；用戶共享的網(wǎng)絡(luò)資源及網(wǎng)絡(luò)所能提供的服務(wù)功能最終是通過網(wǎng)絡(luò)環(huán)境中的分布式進程通信來實現(xiàn)的?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議9網(wǎng)絡(luò)環(huán)境中的進程通信與單機系統(tǒng)內(nèi)部的進程通信的主要區(qū)別：網(wǎng)絡(luò)中主機的高度自治性；不是在同一個主機系統(tǒng)之中，沒有一個統(tǒng)一的高層進行控制與管理；網(wǎng)絡(luò)中一臺主機對其他主機的

?活動狀態(tài)；

?位于其他主機系統(tǒng)中的各個進程狀態(tài)；

?這些進程什么時間參與網(wǎng)絡(luò)活動；

?希望與網(wǎng)絡(luò)中哪一臺主機的什么進程通信一概無從知道?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議101.網(wǎng)絡(luò)環(huán)境中分布式進程通信需要解決：進程命名與尋址方法多重協(xié)議的識別進程間相互作用的模式《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議112.網(wǎng)絡(luò)環(huán)境中進程標識在一臺計算機中，不同的進程用進程號或進程標識（processID）惟一地標識出來。網(wǎng)絡(luò)環(huán)境中完整的進程標識應(yīng)該是：

?本地主機地址-本地進程標識；

?遠程主機地址-遠程進程標識。進程地址也叫做端口號（portnumber）。

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議123.多重協(xié)議的識別UNIX操作系統(tǒng)的TCP/IP的傳輸層就有TCP協(xié)議和UDP協(xié)議；網(wǎng)絡(luò)環(huán)境中一個進程的全網(wǎng)惟一的標識需要一個三元組來表示：協(xié)議，本地地址，本地端口號。《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議13網(wǎng)絡(luò)環(huán)境中一個完整的進程通信標識需要一個五元組來表示：

協(xié)議本地地址本地端口號遠地地址遠地端口號在UNIX操作系統(tǒng)中:三元組又叫做半相關(guān)half-association

五元組叫做一個相關(guān)association《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議145.1.3進程間相互作用模式：Client/Server模型

1.Client/Server模型的基本概念

網(wǎng)絡(luò)中每臺聯(lián)網(wǎng)的計算機既為本地用戶提供服務(wù)，也為網(wǎng)絡(luò)的其他主機的用戶提供服務(wù);每臺聯(lián)網(wǎng)的計算機的硬件、軟件與數(shù)據(jù)資源應(yīng)該既是本地用戶可以使用的資源，也是網(wǎng)絡(luò)的其他主機的用戶可以共享的資源;每一項網(wǎng)絡(luò)服務(wù)都是對應(yīng)一個“服務(wù)程序”進程;

“服務(wù)程序”進程要為每一個獲準的網(wǎng)絡(luò)用戶請求執(zhí)行一組規(guī)定的動作，以滿足用戶網(wǎng)絡(luò)資源共享的需要;

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議15網(wǎng)絡(luò)環(huán)境中進程通信要解決的進程間相互作用的模式;在TCP/IP協(xié)議體系中，進程間的相互作用采用客戶/服務(wù)器(Client/Server)模型;客戶與服務(wù)器分別表示相互通信的兩個應(yīng)用程序的進程;客戶向服務(wù)器發(fā)出服務(wù)請求，服務(wù)器響應(yīng)客戶的請求，提供客戶機所需要的網(wǎng)絡(luò)服務(wù)?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議162.為什么要采用客戶機/服務(wù)器模型?網(wǎng)絡(luò)資源分布的不均勻性網(wǎng)絡(luò)資源分布的不均勻性表現(xiàn)在硬件、軟件和數(shù)據(jù)等三個方面;網(wǎng)絡(luò)資源分布的不均勻性是客觀存在的，同時也是網(wǎng)絡(luò)應(yīng)用系統(tǒng)設(shè)計者的設(shè)計思想的體現(xiàn);“資源共享”就是因為網(wǎng)絡(luò)不同結(jié)點之間在硬件配置、計算能力、存儲能力，以及數(shù)據(jù)分布等方面存在著差距與不均勻性；能力強、資源豐富的充當(dāng)服務(wù)器，能力弱或需要某種資源的成為客戶。《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議17網(wǎng)絡(luò)環(huán)境中進程通信的異步性

分布在不同主機系統(tǒng)中的進程什么時間發(fā)出通信請求，希望和哪一臺主機的哪一個進程通信，以及對方進程是否能接受通信請求是不確定的;網(wǎng)絡(luò)分布式進程之間不存在一個高層的調(diào)度與協(xié)調(diào);必須要建立一個體制，為準備通信的進程之間建立起連接，在進程交換數(shù)據(jù)的過程中維護連接，為數(shù)據(jù)交換提供同步?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議18客戶—一次進程通信中發(fā)起的一方；服務(wù)器—接受進程通信的請求，提供服務(wù)的一方；每一次通信由客戶進程隨機啟動；服務(wù)器進程處于等待狀態(tài)，及時響應(yīng)客戶服務(wù)請求?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議195.1.4進程通信中Client/Server模型實現(xiàn)方法客戶機/服務(wù)器模型的工作實質(zhì)是“請求驅(qū)動”；在網(wǎng)絡(luò)環(huán)境中，客戶進程發(fā)出請求完全隨機。在同一個時刻，可能有多個客戶進程向一個服務(wù)器發(fā)出服務(wù)請求；

為了實現(xiàn)服務(wù)器的功能，在服務(wù)器的設(shè)計中要解決服務(wù)器的：并發(fā)請求處理能力并發(fā)服務(wù)器的進程標識服務(wù)器安全《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議20解決服務(wù)器處理并發(fā)請求的基本方案：設(shè)計一個并發(fā)服務(wù)器；采用重復(fù)服務(wù)器的方法?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議21并發(fā)服務(wù)器（concurrentserver）并發(fā)服務(wù)器的核心是使用一個守護程序（daemon）；守護程序在系統(tǒng)啟動的時候隨之啟動，在沒有客戶的服務(wù)請求到達時，并發(fā)服務(wù)器處于等待狀態(tài);一旦客戶機的服務(wù)請求到達，服務(wù)器根據(jù)客戶的服務(wù)請求的進程號，去激活相應(yīng)的子進程，而服務(wù)器回到等待狀態(tài)；并發(fā)服務(wù)器叫做主服務(wù)器（master），把子服務(wù)器叫做從服務(wù)器（slave）；主服務(wù)器必須擁有一個全網(wǎng)公認的進程地址；網(wǎng)絡(luò)中的客戶進程可以根據(jù)服務(wù)器進程的公認地址，向服務(wù)器提出服務(wù)請求?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議22客戶與并發(fā)服務(wù)器建立傳輸連接的過程《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議23重復(fù)服務(wù)器（interativeserver）通過設(shè)置一個請求隊列來存儲客戶機的服務(wù)請求；服務(wù)器采用先來先服務(wù)的原則來順序處理客戶機的服務(wù)請求?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議24比較并發(fā)服務(wù)器：并發(fā)服務(wù)器可以處理多個客戶的服務(wù)請求；從服務(wù)器不依賴主服務(wù)器而獨立處理客戶服務(wù)請求；不同的從服務(wù)器可以分別處理不同的客戶的服務(wù)請求；系統(tǒng)的實時性好。重復(fù)服務(wù)器：處理客戶的服務(wù)請求的數(shù)量受到請求隊列長度的限制，但可以有效地控制請求處理的時間并發(fā)服務(wù)器適應(yīng)于面向連接的服務(wù)類型；重復(fù)服務(wù)器適應(yīng)于無連接的服務(wù)類型。

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議25討論主動啟動與服務(wù)器進程通信的程序叫做客戶；服務(wù)器是一個用來提供某種服務(wù)的，有特殊權(quán)限的專用程序；服務(wù)器程序在網(wǎng)絡(luò)中一臺計算機上運行，接受來自遠程客戶的服務(wù)請求，提供一種服務(wù)；服務(wù)器程序需要硬件配置較高的計算機和操作系統(tǒng)的支持；客戶/服務(wù)器是軟件設(shè)計中進程間相互作用關(guān)系的模型。

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議265.2傳輸層的基本功能

5.2.1傳輸層的端-端通信

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議275.2.2傳輸層協(xié)議的基本功能

1.傳輸層在協(xié)議層次結(jié)構(gòu)中的位置

傳輸層的目標是向應(yīng)用層應(yīng)用程序進程之間的通信，提供有效、可靠、保證質(zhì)量的服務(wù);傳輸層在網(wǎng)絡(luò)分層結(jié)構(gòu)中起著承上啟下的作用，通過執(zhí)行傳輸層協(xié)議，屏蔽通信子網(wǎng)在技術(shù)、設(shè)計上的差異和服務(wù)質(zhì)量的不足，向高層提供一個標準的、完善的通信服務(wù);從通信和信息處理的角度看，應(yīng)用層是面向信息處理的，而傳輸層是為應(yīng)用層提供通信服務(wù)的?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議282.傳輸協(xié)議數(shù)據(jù)單元傳輸層之間傳輸?shù)膱笪慕凶鰝鬏攨f(xié)議數(shù)據(jù)單元（TransportProtocolUnit，TPDU）；TPDU有效載荷是應(yīng)用層的數(shù)據(jù)。《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議295.2.3網(wǎng)絡(luò)服務(wù)與服務(wù)質(zhì)量QoS

服務(wù)（Service）網(wǎng)絡(luò)層次結(jié)構(gòu)中，各層之間有嚴格的依賴關(guān)系各層次的分工和協(xié)作集中地體現(xiàn)在相鄰層之間的界面上；服務(wù)是描述相鄰層之間關(guān)系的重要概念；網(wǎng)絡(luò)服務(wù)體現(xiàn)在低層向相鄰上層提供的一組操作；低層是服務(wù)提供者，高層是服務(wù)的用戶?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議30衡量服務(wù)質(zhì)量QoS的主要指標連接建立延遲/連接釋放延遲；連接建立/釋放失敗概率；傳輸時延；吞吐率；殘留誤碼率；傳輸失敗概率。

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議31連接建立延遲從傳輸服務(wù)用戶要求建立連接到收到連接確認之間所經(jīng)歷的時間；它包括了遠端傳輸實體的處理延遲；連接建立延遲越短，服務(wù)質(zhì)量越好。連接建立失敗的概率在最大連接建立延遲時間內(nèi)，連接未能建立的可能性；由于網(wǎng)絡(luò)擁塞，缺少緩沖區(qū)或其他原因造成的失敗。

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議32吞吐率吞吐率是在某個時間間隔內(nèi)測得的每秒鐘傳輸?shù)挠脩魯?shù)據(jù)的字節(jié)數(shù)；每個傳輸方向分別用各自的吞吐率來衡量。傳輸延遲傳輸延遲是指從源主機傳輸用戶發(fā)送報文開始到目的主機傳輸用戶接收到報文為止的時間；每個方向的傳輸延遲是不同的。《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議33殘余誤碼率殘余誤碼率用于測量丟失或亂序的報文數(shù)占整個發(fā)送的報文數(shù)的百分比；理論上殘余誤碼率應(yīng)為零，實際上它可能是一較小的值。安全保護安全保護為傳輸用戶提供了傳輸層的保護，以防止未經(jīng)授權(quán)的第三方讀取或修改數(shù)據(jù)。

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議34優(yōu)先級為傳輸用戶提供用以表明哪些連接更為重要的方法；當(dāng)發(fā)生擁塞事件時，確保高優(yōu)先級的連接先獲得服務(wù)?；謴?fù)功能當(dāng)出現(xiàn)內(nèi)部問題或擁塞情況下，傳輸層本身自發(fā)終止連接的可能性?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議35在討論傳輸層服務(wù)質(zhì)量參數(shù)時需要注意以下幾個問題：服務(wù)質(zhì)量參數(shù)是傳輸用戶在請求建立連接時設(shè)定的，表明希望值和最小可接受的值；傳輸層通過檢查服務(wù)質(zhì)量參數(shù)可以立即發(fā)現(xiàn)其中某些值是無法達到的，傳輸層可以不去與目的主機連接，而直接通知傳輸用戶連接請求失敗與失敗的原因；有些情況下，傳輸層發(fā)現(xiàn)不能達到用戶希望的質(zhì)量參數(shù)，但可以達到稍微低一些的要求，然后再請求建立連接；并非所有的傳輸連接都需要提供所有的參數(shù),大多數(shù)僅僅是要求殘余誤碼，而其他參數(shù)則是為了完善服務(wù)質(zhì)量而設(shè)置的?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議365.3用戶報文協(xié)議UDP

5.3.1UDP協(xié)議的主要特點

UDP是一種無連接的、不可靠的傳輸層協(xié)議；在完成進程到進程的通信中提供了有限的差錯檢驗功能；設(shè)計比較簡單的UDP協(xié)議的目的是希望以最小的開銷來達到網(wǎng)絡(luò)環(huán)境中的進程通信目的；進程發(fā)送的報文較短，同時對報文的可靠性要求不高，那么可以使用UDP協(xié)議?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議375.3.2UDP的基本工作過程UDP用戶數(shù)據(jù)報傳輸過程中的封裝與拆封

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議38UDP基本工作過程描述UDP數(shù)據(jù)報的發(fā)送和接收通過UDP端口實現(xiàn)端口是一個可讀寫的結(jié)構(gòu)，具有內(nèi)部的報文緩沖區(qū)數(shù)據(jù)報發(fā)送UDP軟件將用戶數(shù)據(jù)封裝在UDP數(shù)據(jù)報中轉(zhuǎn)交給IP軟件，進行IP封裝和轉(zhuǎn)發(fā)數(shù)據(jù)報的接收IP層接收到UDP數(shù)據(jù)報，提交給UDP軟件的各端口端口判斷該報文的目的端口號是否與當(dāng)前端口匹配若匹配成功，將該數(shù)據(jù)報保存到相應(yīng)端口的接收隊列中；（若隊列已滿，則丟棄該數(shù)據(jù)報）若未匹配，則丟棄該數(shù)據(jù)報，同時向源端發(fā)送“端口不可達”的ICMP包《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議39UDP報文傳輸隊列《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議40UDP的復(fù)用和分用《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議415.3.3UDP端口號TCP/IP協(xié)議族中用端口號來標識進程；端口號是在0到65535之間的整數(shù)；客戶程序隨機選取的臨時端口號；每一種服務(wù)器程序被分配了確定的全局一致的熟知端口號；每一個客戶進程都知道相應(yīng)的服務(wù)器進程的熟知端口號。《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議42UDP使用的熟知端口號《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議435.3.4UDP數(shù)據(jù)報格式《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議44SourcePort—16位。源端口是可選字段。當(dāng)使用時，它表示發(fā)送程序的端口，同時它還被認為是沒有其它信息的情況下需要被尋址的答復(fù)端口。如果不使用，設(shè)置值為0。DestinationPort—16位。目標端口在特殊因特網(wǎng)目標地址的情況下具有意義。Length—16位。該用戶數(shù)據(jù)報的八位（字節(jié)）長度，包括協(xié)議頭和數(shù)據(jù)。長度最小值為8，最長長度為65515（IP的最大長度65535減去20）。Checksum—16位。IP協(xié)議頭、UDP協(xié)議頭和數(shù)據(jù)位，最后用0填補的信息假協(xié)議頭總和。如果必要的話，可以由兩個八位（字節(jié)）復(fù)合而成。注意：計算校驗和時，在UDP用戶數(shù)據(jù)報之前要增加12字節(jié)的偽頭部。Data—

包含上層數(shù)據(jù)信息。《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議45UDP檢驗和的檢驗范圍：偽頭部

UDP頭應(yīng)用層數(shù)據(jù)偽頭部只在計算校驗和時起作用，是臨時的，不用于傳輸?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議46偽頭部：偽報頭并非UDP數(shù)據(jù)報中實際的有效成分偽報頭是一個虛擬的數(shù)據(jù)結(jié)構(gòu)：其中的信息是從數(shù)據(jù)報所在IP分組頭的分組頭中提取的使用偽報頭是為了驗證UDP數(shù)據(jù)報是否正確地傳到了目的系統(tǒng)中偽報頭的采用在一定程度上違反了網(wǎng)絡(luò)結(jié)構(gòu)分層的原則《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議47《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議48《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議49Answerthefollowingquestions:a.WhatistheminimumsizeofaUDPdatagram?b.WhatisthemaximumsizeofaUDPdatagram?c.WhatistheminimumsizeoftheprocessdatathatcanbeencapsulatedinaUDPdatagram?d.WhatisthemaximumsizeoftheprocessdatathatcanbeencapsulatedinaUDPdatagram?《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議50Q&A:ThefollowingisadumpofaUDPheaderinhexadecimalformat. CB84000D001C001Ca.Whatisthesourceportnumber?b.Whatisthedestinationportnumber?c.Whatisthetotallengthoftheuserdatagram?d.Whatisthelengthofthedata?e.Isthepacketdirectedfromaclienttoaserverorviceversa?《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議51SolutionThesourceportnumberisthefirstfourhexadecimaldigits(CB8416),whichmeansthatthesourceportnumberis52100.Thedestinationportnumberisthesecondfourhexadecimaldigits(000D16),whichmeansthatthedestinationportnumberis13.Thethirdfourhexadecimaldigits(001C16)definethelengthofthewholeUDPpacketas28bytes.Thelengthofthedataisthelengthofthewholepacketminusthelengthoftheheader,or28–8=20bytes.Sincethedestinationportnumberis13(well-knownport),thepacketisfromtheclienttotheserver.《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議525.4傳輸控制協(xié)議TCP

5.4.1TCP協(xié)議的主要特點

TCP是一種面向連接的、可靠的傳輸層協(xié)議；全雙工通信；TCP協(xié)議建立在不可靠的網(wǎng)絡(luò)層IP協(xié)議之上，IP不能提供任何可靠性機制，TCP的可靠性完全由自己實現(xiàn)；TCP采用的最基本的可靠性技術(shù)是：

確認與超時重傳；

流量控制?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議53TCP協(xié)議與其他協(xié)議的層次關(guān)系《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議545.4.2TCP的端口號分配和Socket地址TCP常用的熟知端口號《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議555.4.3TCP報文段格式《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議56TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充源端口和目的端口字段——各占2字節(jié)。端口是運輸層與應(yīng)用層的服務(wù)接口。運輸層的復(fù)用和分用功能都要通過端口才能實現(xiàn)?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議57TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充序號字段——占4字節(jié)。TCP連接中傳送的數(shù)據(jù)流中的每一個字節(jié)都編上一個序號。序號字段的值則指的是本報文段所發(fā)送的數(shù)據(jù)的第一個字節(jié)的序號?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議58TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充確認號字段——占4字節(jié)，是期望收到對方的下一個報文段的數(shù)據(jù)的第一個字節(jié)的序號。《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議59TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充數(shù)據(jù)偏移——占4bit，它指出TCP報文段的數(shù)據(jù)起始處距離TCP報文段的起始處有多遠?！皵?shù)據(jù)偏移”的單位不是字節(jié)而是32bit字（4字節(jié)為計算單位）?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議60TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充保留字段——占6bit，保留為今后使用，但目前應(yīng)置為0?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議61TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充緊急比特URG——當(dāng)URG1時，表明緊急指針字段有效。它告訴系統(tǒng)此報文段中有緊急數(shù)據(jù)，應(yīng)盡快傳送(相當(dāng)于高優(yōu)先級的數(shù)據(jù))。《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議62TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充確認比特ACK——只有當(dāng)ACK1時確認號字段才有效。當(dāng)ACK0時，確認號無效?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議63TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充推送比特PSH(PuSH)——接收TCP收到推送比特置1的報文段，就盡快地交付給接收應(yīng)用進程，而不再等到整個緩存都填滿了后再向上交付。《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議64TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充復(fù)位比特RST(ReSeT)——當(dāng)RST1時，表明TCP連接中出現(xiàn)嚴重差錯（如由于主機崩潰或其他原因），必須釋放連接，然后再重新建立運輸連接?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議65TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充同步比特SYN——同步比特SYN置為1，就表示這是一個連接請求或連接接受報文?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議66TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充終止比特FIN(FINal)——用來釋放一個連接。當(dāng)FIN1時，表明此報文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放運輸連接?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議67TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充窗口字段——占2字節(jié)。窗口字段用來控制對方發(fā)送的數(shù)據(jù)量，單位為字節(jié)。TCP連接的一端根據(jù)設(shè)置的緩存空間大小確定自己的接收窗口大小，然后通知對方以確定對方的發(fā)送窗口的上限?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議68TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充檢驗和——占2字節(jié)。檢驗和字段檢驗的范圍包括首部和數(shù)據(jù)這兩部分。在計算檢驗和時，要在TCP報文段的前面加上12字節(jié)的偽首部?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議69TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充緊急指針字段——占16bit。緊急指針指出：在本報文段中緊急數(shù)據(jù)共有多少個字節(jié)（緊急數(shù)據(jù)放在本報文段數(shù)據(jù)的最前面）。

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議70TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充選項字段——長度可變。MSS是TCP報文段中的數(shù)據(jù)字段的最大長度。數(shù)據(jù)字段加上TCP首部才等于整個的TCP報文段?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議71TCPOptionsUsedtoextendTCPfunctionalityDefinedTCPoptions:EndofOptionListNoOperationMaximumSegmentSizeTCPWindowScaleSelectiveAcknowledgement(SACK)TCPTimestamps《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議72EndOfOptionListandNoOperationEndofOptionListAsingleoctetwiththeoptionkindsetto0,whichindicatesthatnootheroptionsfollowNoOperationAsingleoctetwiththeoptionkindsetto1,whichisusedbetweenTCPoptionsfor4-bytealignment《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議73AMultiple-OctetTCPoptionOptionKindOptionLengthOptionoctets...《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議74IPTCPSegmentIPMTUMSSTCPMaximumSegmentSize《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議75OptionKindOptionLengthMaximumSegmentSize=2=4MaximumSegmentSizeOption■OptionKindSetto2(0x02)toindicatetheMSSoptionkind.■OptionLengthSetto4(0x04)toindicatethatthesizeoftheentireMSSoptionis4bytes.■MaximumSegmentSizeTwobytesthatindicatetheMSSofreceivedsegments.ForIPdatagramssentonanEthernetnetworksegmentusingEthernetIIencapsulation,theMSSis1460(anIPMTUof1500minus40bytesforminimum-sizedIPandTCPheaders).《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議76TCPWindowScaleOptionOptionKindOptionLengthShiftCount=3=3■ShiftCountOnebytethatindicatesthescalingfactorastheexponentof2.Forexample,foraShiftCountof5,thescalingfactoris2^5,or32.SelectiveAcknowledgmentOptionTwodifferentTCPoptions:■TheSelectiveAcknowledgment(SACK)-Permittedoptiontonegotiatetheuseofselectiveacknowledgmentsduringtheconnectionestablishmentprocess■TheSACKoptiontoindicatethenoncontiguousdata(非相鄰數(shù)據(jù)或不連續(xù)數(shù)據(jù))blocksthathavebeenreceived《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議78SACKPermittedOptionOptionKindOptionLength=4=2TheSACK-PermittedoptionissentinsegmentswiththeSYNflagsetandindicatesthattheTCPpeercanreceiveandinterpret（/explain）theTCPSACKoptionwhendataisflowingontheconnection.《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議79SACKOptionOptionKindOptionLengthLeftEdgeof1stBlockRightEdgeof1stBlockLeftEdgeof2ndBlockRightEdgeof2ndBlock...=5TheSACKoptionissentasneededinsegmentsoftheopenconnectionwiththeACKflagset.《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議80TCPTimestampsOptionOptionKindOptionLengthTsValueTsEchoReply=8=10《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議81TCP首部20字節(jié)固定首部目的端口數(shù)據(jù)偏移檢驗和選項（長度可變）源端口序號緊急指針窗口確認號保留FINSYNRSTPSHACKURG比特08162431填充填充字段——這是為了使整個首部長度是4字節(jié)的整數(shù)倍?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議82EXAMPLE：TCPFrameFragmentTCP:-----TCPheader-----TCP:TCP:Sourceport=4704TCP:Destinationport=23(Telnet)TCP:Sequencenumber=399TCP:Acknowledgmentnumber=738299106TCP:Dataoffset=20bytesTCP:Flags=18TCP:..0.....=(Nourgentpointer)TCP:...1....=AcknowledgmentTCP:....1...=PushTCP:.....0..=(Noreset)TCP:......0.=(NoSYN)TCP:.......0=(NoFIN)TCP:Window=512TCP:Checksum=43E2(correct)《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議83TCP:NoTCPoptionsTCP:[1byte(s)ofdata]TCP:Telnet:-----Telnetdata-----ADDRHEXASCII0000104002608C06384102608C115176AAAA.@.`..8A.`..Qv..00100300000008004500002903190000FF06......E..)......00206EB6243500C3243800D0126000170000n.$5..$8...`....0030018F2C018CE25018020043E200005300..,...P...C...S.004001FFFD03....《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議84Q&A:SupposeaTCPconnectionistransferringafileof5,000bytes.Thefirstbyteisnumbered10,001.Whatarethesequencenumbersforeachsegmentifdataaresentinfivesegments,eachcarrying1,000bytes?《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議85《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議865.4.4TCP傳輸連接建立與連接釋放TCP傳輸連接建立過程示意圖

連接請求報文SYN應(yīng)答報文SYN+ACK建立傳輸連接確認報文ACK《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議87Note:ASYNsegmentcannotcarrydata,butitconsumesonesequencenumber.ASYN+ACKsegmentcannotcarrydata,butdoesconsumeonesequencenumber.AnACKsegment,ifcarryingnodata,consumesnosequencenumber.Onthecontrary,ifcarryingdata,consumessequencenumber.《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議88ATCPconnectioncanoptionallybemaintainedthroughtheperiodicexchangeofaTCPkeepalivesegment,whichisanACKsegmentcontainingnodata.TCPConnectionMaintenance《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議89TCP在傳輸連接釋放過程中4次握手過程《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議905.4.5小段小段是小于MSS（最大段長度）的TCP段。（Telnet會話過程，有些時候會出現(xiàn)1個有效字節(jié)40個包頭（IP頭+TCP頭）的這樣低效的包，增加網(wǎng)絡(luò)負擔(dān)從而影響網(wǎng)絡(luò)性能。）Nagle算法是：如果發(fā)送方發(fā)送小的數(shù)據(jù)報時,沒有收到上一次發(fā)送的應(yīng)答，那么將暫時緩沖這個數(shù)據(jù)。笨拙窗口綜合癥：一次接收/處理一字節(jié)，接收窗口以一字節(jié)前進的現(xiàn)象。（接收方通過不發(fā)送新的窗口尺寸來避免，除非窗口至少是一個MSS，或者是最大的接收窗口尺寸的一半；發(fā)送方通過發(fā)布的接收窗口尺寸至少達到MSS

才發(fā)送來避免）

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議91Nagle’sAlgorithmissimple:1.ThesendingTCPsendsthefirstpieceofdataitreceivesfromthesendingapplicationprogramevenifitisonly1byte.2.Aftersendingthefirstsegment,thesendingTCPaccumulatesdataintheoutputbufferandwaitsuntileitherthereceivingTCPsendsanacknowledgmentoruntilenoughdatahasaccumulatedtofillamaximum-sizesegment.Atthistime,thesendingTCPcansendthesegment.3.Step2isrepeatedfortherestofthetransmission.Segment3issentimmediatelyifanacknowledgmentisreceivedforsegment2,orifenoughdatahaveaccumulatedtofillamaximum-sizesegment.《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議92TCP高效與可靠的相關(guān)算法滑動窗口慢開始算法：一次增加一MSS(在每收到一個對新的報文段的確認后，將擁塞窗口增加至多一個MSS的數(shù)值)。(達到擁塞閥值后)擁塞避免算法：累次增加(+1，線性增加)，倍次減少(乘1/2)。快重傳算法：規(guī)定發(fā)送端只要一連收到三個重復(fù)的ACK即可斷定有分組丟失了，就應(yīng)立即重傳丟失的報文段而不必繼續(xù)等待為該報文段設(shè)置的重傳計時器的超時?？旎謴?fù)算法：累次增加《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議93往返時延的自適應(yīng)算法

記錄每一個報文段發(fā)出的時間，以及收到相應(yīng)的確認報文段的時間。這兩個時間之差就是報文段的往返時延。將各個報文段的往返時延樣本加權(quán)平均，就得出報文段的平均往返時延

RTT。每測量到一個新的往返時延樣本，就按下式重新計算一次平均往返時延RTT：平均往返時延RTT

(舊的RTT)(1

)(新的往返時延樣本)(7-2)在上式中，0

1?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議94慢開始算法的原理在主機剛剛開始發(fā)送報文段時可先將擁塞窗口cwnd設(shè)置為一個最大報文段MSS的數(shù)值。在每收到一個對新的報文段的確認后，將擁塞窗口增加至多一個MSS的數(shù)值。用這樣的方法逐步增大發(fā)送端的擁塞窗口cwnd，可以使分組注入到網(wǎng)絡(luò)的速率更加合理?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議95TCP連接的狀態(tài)TCP原理與技術(shù)一條TCP連接在其生命期內(nèi)會經(jīng)歷一系列的狀態(tài)。這些狀態(tài)有：LISTEN：正在等待一個來自任何遠程TCP和端口的連接請求。SYN－SENT：在已經(jīng)發(fā)出一個連接請求后正在等待一個匹配的連接請求SYN－RECEIVED：在已經(jīng)收到并發(fā)出了一個連接請求后等待 一個證實連接請 求的確認。ESTABLISHED：一個打開的連接。通過此連接接收到的數(shù)據(jù)能夠被傳遞到用戶。 該狀態(tài)是此連接的數(shù)據(jù)傳輸階段的正常狀態(tài)。FIN－WAIT－1：或正在等待一個針對先前發(fā)送的連接終止請求的確認。FIN－WAIT－2：正在等待一個來自遠程TCP的連接終止請求。CLOSE－WAIT：正在等待一個來自本地用戶的連接終止請求CLOSING：正在等待一個來自遠程TCP的連接終止請求的確認。LAST－ACK：正在等待一個先前發(fā)往遠程TCP的連接終止請求的確認（包括對 其連接終止請求的確認）TIME－WAIT：等足夠的時間以確保遠程TCP接收到了其連接終止請求的確認CLOSED：根本不存在連接的狀態(tài)。《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議96TCP連接的建立過程TCP原理與技術(shù)

TCPA

TCPB1.CLOSE LISTEN2.SYN-SENT→<SEQ=100><CTL=SYN> →SYN-RECEIVED3.ESTABLISHED←<SEQ=300><ACK=101><CTL=SYN,ACK> ←SYN-RECEIVED4.ESTABLISHED→<SEQ=101><ACK=301><CTL=ACK> →ESTABLISHED5.ESTABLISHED→<SEQ=101><ACK=301><CTL=ACK><DATA> →ESTABLSHED說明：

TCPA、B在初始時分別是處于CLOSED和LISTEN狀態(tài)。A端首先發(fā)送一個SEQ＝100的初始化序列，SYN置位，占用一個序列號；B端在收到該請求后，發(fā)送一個序列號為300，確認號為101的段，這個段的SYN、ACK均置位，說明B端的初始發(fā)送序列號為300，同時又確認了A的SEQ＝100的段，A在收到了B的應(yīng)答后，對其初始序列號確認，來響應(yīng)B的初始化序列，然后A就可以發(fā)送事件了。其中第2、3、4行，稱之為“三次握手”《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議97TCP連接的關(guān)閉過程TCP原理與技術(shù)

TCPA TCPB1.ESTABLISHED ESTABLISHED2.（關(guān)閉）

FIN-WAIT-1→<SEQ=100><ACK=300><CTL=FIN,ACK> …CLOSE-WAIT3.FIN-WAIT-2←<SEQ=300><ACK=101><CTL=ACK> ←CLOSE-WAIT4. （關(guān)閉）

TIME-WAIT←<SEQ=300><ACK=101><CTL=FIN,ACK> ←LAST-ACK5.TIME-WAIT→<SEQ=101><ACK=301><CTL=ACK> →CLOSED6.（2MSL）關(guān)閉TCPA啟動TCP關(guān)閉某連接的，TCPB收到一個FIN段，進入CLOSEWAIT狀態(tài)。在第3行中，如果TCPB還有數(shù)據(jù)要發(fā)送，在報頭之后，會有數(shù)據(jù)，同時對TCPA發(fā)來的FIN確認（FIN占用一個序列號）。發(fā)送完數(shù)據(jù)后，在第4行，TCPB再發(fā)送一個FIN段，在沒有收到確認之前是LAST－ACK（等待發(fā)往遠程TCP的FIN的確認）狀態(tài)。第5行中，TCPB在收到了它發(fā)出的FIN的確認后，進入CLOSED狀態(tài)，TCPA在超時時間到后，自動關(guān)閉。下面是完整的狀態(tài)變遷圖《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議98《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議99TCP的有限狀態(tài)機TCP有限狀態(tài)機的圖中每一個方框都是TCP可能具有的狀態(tài)。每個方框中的大寫英文字符串是TCP標準所使用的TCP連接狀態(tài)名。狀態(tài)之間的箭頭表示可能發(fā)生的狀態(tài)變遷。箭頭旁邊的字，表明引起這種變遷的原因，或表明發(fā)生狀態(tài)變遷后又出現(xiàn)什么動作。圖中有三種不同的箭頭。粗實線箭頭表示對客戶進程的正常變遷。粗虛線箭頭表示對服務(wù)器進程的正常變遷。另一種細線箭頭表示異常變遷。

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議100TCP

的

有

限

狀

態(tài)

機CLOSEDESTABLISHEDLISTENCLOSE_WAITFIN_WAIT_1SYN_RCVDFIN_WAIT_2CLOSINGTIME_WAITSYN_SENTLAST_ACK主動打開被動打開被動關(guān)閉主動關(guān)閉起點被動打開主動打開發(fā)送SYN同時打開收到SYN，發(fā)送SYN,ACK收到ACK數(shù)據(jù)傳送階段關(guān)閉發(fā)送FIN關(guān)閉發(fā)送FIN關(guān)閉發(fā)送FIN收到RST收到SYN發(fā)送SYN,ACK關(guān)閉或超時收到ACK收到SYN,ACK發(fā)送ACK收到ACK收到ACK收到FIN發(fā)送ACK收到FIN,ACK

發(fā)送ACK收到FIN發(fā)送ACK同時關(guān)閉收到FIN發(fā)送ACK發(fā)送SYN定時經(jīng)過兩倍報文段壽命后關(guān)閉《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議1015.4.5TCP流量與擁塞控制TCP的數(shù)據(jù)編碼與確認

擁塞控制：隨機早期檢測RED算法（如圖所示）：當(dāng)隊列長度處在給定的最小閾值和最大閾值之間時，按相應(yīng)的概率，選擇性的丟棄被標記的數(shù)據(jù)包。《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議103TCP協(xié)議是面向字節(jié)的。

TCP協(xié)議把所要傳輸?shù)膱笪亩慰闯墒且粋€一個字節(jié)組成的數(shù)據(jù)流，并且要為每一個字節(jié)分配一個序號。TCP每次所發(fā)送的報文段的頭部中的序號值表示的是該報文段數(shù)據(jù)部分的第一個字節(jié)的序號。全雙工通信，捎帶確認的方法。TCP有3種基本機制來控制報文段發(fā)送的方法：1)控制最大段長度（MSS）2)TCP支持的推送（PUSH）操作3)發(fā)送端維持一個計時器《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議104TCP窗口概念

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議105窗口與TCP的流量控制《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議1065.4.6TCP差錯控制差錯檢測和糾正檢驗和確認超時針對的幾種情況受損傷的報文段丟失的報文段重復(fù)的報文段亂序的報文段丟失的確認《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議107傳輸出錯報文段的處理超時重傳《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議108丟失的報文段

《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議109確認丟失《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議1105.4.7TCP的計時器為了實現(xiàn)TCP協(xié)議的功能，TCP使用了4種計時器：重傳計時器、堅持計時器、保持計時器和時間等待計時器。重傳計時器為了控制丟失的或丟棄的報文段，TCP使用了處理報文段的確認的等待重傳時間的重傳計時器。堅持計時器TCP為每一個連接使用一個堅持計時器；當(dāng)發(fā)送方的TCP收到一個窗口大小為零的確認時，就需要啟動堅持計時器;當(dāng)堅持計時器期限到時，發(fā)送方的TCP就發(fā)送一個特殊的探測報文段?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議111保持計時器保持計時器又叫做激活計時器，它是用來防止在兩個TCP之間的連接處以長時期空閑。時間等待計時器時間等待計時器是在連接終止期間使用的；當(dāng)TCP關(guān)閉一個連接時，它并不認為這個連接馬上就真正地關(guān)閉了。在時間等待期間中，連接還處于一種過渡狀態(tài)；時間等待計時器的值通常設(shè)置為一個報文段的壽命期待值的兩倍?！毒W(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議112SCTPisanewtransport-layerprotocol.SCTPisamessage-oriented,reliableprotocolthatcombinesthebestfeaturesofUDPandTCP.Itpreservesthemessageboundariesandatthesametimedetectslostdata,duplicatedata,andout-of-orderdata.Italsohascongestioncontrolandflowcontrolmechanisms.5.6StreamControlTransmissionProtocol(SCTP)《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議1131.Process-to-processcommunication:SCTPusesallwell-knownportsintheTCPspace.TablelistssomeextraportnumbersusedbySCTP.SCTPServices《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議1142.MultipleStreamsEachconnectionbetweenaTCPclientandaTCPserverinvolvesonesinglestream.

Theproblemwiththisapproachisthatalossatanypointinthestreamblocksthedeliveryoftherestofthedata.Thiscanbeacceptablewhenwearetransferringtext;itisnotwhenwearesendingreal-timedatasuchasaudioorvideo.

SCTPallowsmultistreamserviceineachconnection,whichiscalledassociationinSCTPterminology.Ifoneofthestreamsisblocked,theotherstreamscanstilldelivertheirdata.Theideaissimilartomultiplelanesonahighway.Eachlanecanbeusedforadifferenttypeoftraffic.《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議1153.Multihoming(多重連接)ATCPconnectioninvolvesonesourceandonedestinationIPaddress.Thismeansthatevenifthesenderorreceiverisamultihomedhost(connectedtomorethanonephysicaladdresswithmultipleIPaddresses),onlyoneoftheseIPaddressesperendcanbeutilizedduringtheconnection.AnSCTPassociationsupportsmultihomingservice.《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議116LetusfirstdiscussthegeneralfeaturesofSCTPandthencomparethemwiththoseofTCP.SCTPFEATURESTransmissionSequenceNumber(TSN):TheunitofdatainTCPisabyte.DatatransferinTCPiscontrolledbynumberingbytesusingasequencenumber.TheunitofdatainSCTPisadatachunk（數(shù)據(jù)塊）.DatatransferinSCTPiscontrolledbynumberingthedatachunks.SCTPusesatransmissionsequencenumber(TSN)tonumberthedatachunks.StreamIdentifier(SI):InTCP,thereisonlyonestreamineachconnection.InSCTP,theremaybeseveralstreamsineachassociation（關(guān)聯(lián)）.EachstreaminSCTPneedstobeidentifiedusingaSI.《網(wǎng)絡(luò)協(xié)議分析及應(yīng)用》第5章傳輸層協(xié)議117St