第10章 傳輸層功能與協(xié)議

第1頁第10章傳輸層功能與協(xié)議本章概述本章的學習目標主要內(nèi)容第2頁本章概述傳輸層傳輸層對互聯(lián)網(wǎng)高層提供可靠的傳輸服務，對網(wǎng)絡層提供可靠的目的地站點信息，彌補了網(wǎng)絡層盡力傳輸?shù)牟蛔恪鬏攲拥臉酥緟f(xié)議TCP與網(wǎng)絡層IP協(xié)議成為TCP/IP的核心。安全套接層SSL在網(wǎng)絡通信中提供安全及數(shù)據(jù)完整性的一種安全協(xié)議，以保障在Internet上數(shù)據(jù)傳輸安全。實時傳輸協(xié)議（RTP）為數(shù)據(jù)提供了具有實時特征的端對端傳送服務，在組播或單播網(wǎng)絡服務下的交互式視頻音頻或模擬數(shù)據(jù)。本章全面研究傳輸層功能協(xié)議，安全套接層SSL協(xié)議的組成原理，RTP協(xié)議基本格式功能。第3頁本章的學習目標理解傳輸層服務功能和特點掌握傳輸層協(xié)議原理和格式理解SSL協(xié)議組成原理掌握SSL協(xié)議實現(xiàn)過程理解RTP協(xié)議理解RTCP協(xié)議第4頁主要內(nèi)容10.1傳輸層功能10.2SSL協(xié)議10.3實時應用程序傳輸協(xié)議RTP10.4本章小結(jié)10.1傳輸層功能在OSI參考模型中，傳輸層的職責是在兩個不同系統(tǒng)的進程之間提供一種交換數(shù)據(jù)的可靠機制，由于傳輸層僅關心會話實體之間的數(shù)據(jù)傳輸，所有它的協(xié)議都具有端到端的意義。在傳輸層不能再維持所提供質(zhì)量的情況下，它必須把這一事實明確地通知會話實體。也許，想像傳輸層的最好方法是把它看成一種安全保護罩，不管下面的基礎網(wǎng)絡發(fā)生什么事件，它都要負責照料傳輸?shù)臄?shù)據(jù)。第5頁傳輸服務大類傳輸服務有兩大類：面向連接的傳輸服務和無連接的傳輸服務；面向連接的傳輸服務與面向連接的網(wǎng)絡服務十分相似，兩者都向用戶提供連接的建立、維護和釋放。無連接的傳輸服務與無連接的網(wǎng)絡服務也十分相似。第6頁10.1.1OSI傳輸協(xié)議如果下層的網(wǎng)絡是不可靠的，那么就要使用稍微復雜一點的傳輸協(xié)議機制。為提供面向連接的傳輸服務，ISO定義了5類傳輸協(xié)議。它還定義了一個五連接的傳輸協(xié)議，盡管沒有一個OSI應用協(xié)議使用無連接傳輸服務。第7頁1.面向連接和無連接服務我們首先考察面向連接的傳輸服務COTS(Connection-OrientedTransportService)。有意設計得很簡單的COTS可使用戶得到一個易于使用的、可靠的傳輸服務。另一方面，用來提供COTS的傳輸協(xié)議都很復雜，因為它們要能應付不可靠的網(wǎng)絡。第8頁面向連接的傳輸服務僅含有4個服務元素：T-CONNECT，T-DATA，T-EXPEDITED-DATA和T-DISCONNECT。傳輸服務巧的用戶使用T-CONNECT與其對等實體建立全雙工的傳輸連接。在傳輸連接建立期間，兩個TS用戶和傳輸服務提供者可以協(xié)商服務質(zhì)量QOS參數(shù)和快速數(shù)據(jù)選項。第9頁圖10-1OSI模型中的傳輸協(xié)議第10頁COTS服務定義非常簡單。COTS僅是一個抽象的定義，而不是一個接口規(guī)范。接口規(guī)范中含有本地的處理原語和通信原語，例如，它可能包括n用戶使用什么手段連結(jié)到TSAP(傳輸服務訪問點)，TS用戶怎樣檢測從網(wǎng)絡層進入事件的到來等原語。第11頁CLTS僅提供一個服務元素T-UNIT-DATA。T-UNIT-DATA有4個參數(shù)：源傳輸?shù)刂?，目的地傳輸?shù)刂?，TS用戶數(shù)據(jù)和QOS。因為沒有連接建立階段，TS用戶不可能和其服務提供者協(xié)商QOS。在這種服務方式中，無法保證可靠的數(shù)據(jù)傳輸，需要靠上層進行適當?shù)牟铄e恢復。第12頁2.傳輸類ISO定義了五類面向連接的傳輸協(xié)議，從簡單的到最復雜的都有。在連接建立時，TE(傳輸實體)在主呼TS用戶請求的QOS基礎上，協(xié)商所使用的傳輸協(xié)議。當用戶和一些簡單的網(wǎng)絡實現(xiàn)打交道時，就可以使用一些復雜的傳輸協(xié)議，以便能提供更優(yōu)質(zhì)的服務。五類傳輸協(xié)議的定義與網(wǎng)絡服務的類型有關。第13頁ISO定義了三種類型的網(wǎng)絡服務（1）A型網(wǎng)絡服務（2）B型網(wǎng)絡服務（3）C型網(wǎng)絡服務基于三種類型的網(wǎng)絡服務。ISO定義了五類運輸協(xié)議。TP0類，簡單類；TP1類，基本差錯恢復類；TP2類，多路復用類；TP3類，差錯恢復與多路復用類；TP4類：差錯檢測與恢復類。0類和2類用于A型網(wǎng)絡，1類和3類用于B型網(wǎng)絡，4類用于C型網(wǎng)絡。第14頁3.傳輸協(xié)議數(shù)據(jù)單元傳輸協(xié)議數(shù)據(jù)單元（TPDU），每個TPDU有四個域組成：長度，固定參數(shù)，可變參數(shù)，數(shù)據(jù)。第15頁10.1.2傳輸層TCP/IP小的傳輸層用兩個協(xié)議來表示：TCP和UDP。在二者之中，UDP更為簡單。當安全性和可靠性不如大小和速度重要的時候，它提供了非順序的傳輸功能。但是，大多數(shù)應用需要可靠的端到端傳輸，因此在這個時候就需要使用TCP。第16頁TCP/IP協(xié)議棧中的傳輸協(xié)議定義了一系列到單個進程的概念連接，這些進程我們稱為協(xié)議端口，或者更簡單一些是端口。協(xié)議端口是單個進程使用來存儲數(shù)據(jù)的目標點(通常是一個緩沖區(qū))。進程和它們所對應的端口之間的接口是由主機的操作系統(tǒng)所提供的。第17頁IP是一個主機到主機的協(xié)議。這意味著它可以將包從一個物理網(wǎng)絡設備傳遞到另一個物理設備。TCP/IP的傳輸層協(xié)議是端到端協(xié)議，它可以工作在IP協(xié)議上。在傳輸開始的時候，從源端口將包傳輸給IP服務，然后通過IP服務最終傳輸?shù)侥繕硕丝谌鐖D10-3所示。第18頁圖10-3端口到端口的地址第19頁每個端口由傳輸層報文頭上所攜帶的一個正整數(shù)地址所定義。IP數(shù)據(jù)報所使用的是32比特的互連網(wǎng)絡地址。傳輸層幀所使用的進程端口地址是16位，它足夠支持多達65536(00000~65535)個端口。其中，端口號小于256的定義為常用端口，服務器一般都是通過常用端口號來識別的。第20頁任何TCP/IP實現(xiàn)所提供的服務都用1到1023之間的端口號，是由ICANN來管理的?？蛻舳酥恍璞ＷC該端口號在本機上是惟一的就可以了，客戶端口號因存在時間很短暫又稱臨時端口號。大多數(shù)TCP/IP實現(xiàn)給臨時端口號分配1024-5000之間的端口號。大于5000的端口號是為其他服務器預留的。第21頁1.用戶數(shù)據(jù)報協(xié)議用戶數(shù)據(jù)報協(xié)議(UDP)是兩個標準TCP/IP傳輸協(xié)議中較簡單的那個。它是一個端到端的傳輸層協(xié)議，僅僅為來自上層的數(shù)據(jù)增加端口地址、校驗和差錯控制以及長度信息。UDP所產(chǎn)生的包稱為用戶數(shù)據(jù)報如圖所示。源端口地址源端口地址是創(chuàng)建消息的應用程序的地址。

目標端口地址目標端口地址是接收消息的應用程序的地址?？傞L度總長度定義了用戶數(shù)據(jù)報的總長度，以字節(jié)為單位。校驗和校驗和是使用在差錯控制中的16比特域。第22頁數(shù)據(jù)報文格式第23頁UDP僅僅提供一些在端到端傳輸中所必須的基本功能，并不提供任何順序或重新排序的功能。因此，當它報告一個錯誤的時候，它不能指出損壞的包(所以必須和ICMP配合使用)。UDP可以發(fā)現(xiàn)有一個錯誤發(fā)生了，ICMP接著可以通知發(fā)送者有一個用戶數(shù)據(jù)報被損壞和丟棄了。它們兩個都沒有能力指出哪一個包丟失了。UDP僅僅包含一個校驗和，并不包含ID或順序編號。第24頁2.傳輸控制協(xié)議傳輸控制協(xié)議(TCP)為應用程序提供了完整的傳輸層服務。TCP是一個可靠的流傳輸端到端協(xié)議。術語“流”在這里表示面向連接。在傳輸兩端可以傳輸數(shù)據(jù)之前必須先建立連接。通過創(chuàng)建這個連接，TCP在發(fā)送者和接收者之間建立了一條虛電路，這條電路在整個傳輸過程中都是有效的。TCP通過警告接收者即將有數(shù)據(jù)到達(連接建立)來開始一次傳輸，同時通過連接中斷來結(jié)束連接。通過這種方法，接收者就知道所期望的是整個傳輸，而不僅僅是一個包。第25頁TCP所提供的服務范圍要求段頭必須包含很多內(nèi)容如圖10-4所示。將TCP段式和UDP用戶數(shù)據(jù)報相比較可以顯示出這兩個協(xié)議的不同之處。TCP通過犧牲速度(連接必須被建立，確認必須被等待等等)來提供廣泛的可靠功能。UDP則由于較小的幀，比TCP更快，但是所付出的是可靠性的代價。第26頁圖10-4TCP段格式第27頁TCP格式中域的描述源端口地址源端口地址定義了源計算機上的應用程序。目標端口地址目標端口地址定義了目標計算機上的應用程序。順序編號用來標識從TCP發(fā)端向TCP收端發(fā)送的數(shù)據(jù)字節(jié)流，它表示在這個報文段中的的第一個數(shù)據(jù)字節(jié)。如果將字節(jié)流看作在兩個應用程序間的單向流動，則TCP用序號對每個字節(jié)進行計數(shù)。序號是32bit的無符號數(shù)，序號到達232－1后又從0開始。第28頁當建立一個新的連接時，SYN標志變1。序號字段包含由這個主機選擇的該連接的初始序號ISN（InitialSequenceNumber）。該主機要發(fā)送數(shù)據(jù)的第一個字節(jié)序號為這個ISN加1，因為SYN標志消耗了一個序號。第29頁確認編號32比特的確認編號是使用來確認接收其他通信設備數(shù)據(jù)的。這個編號只有在控制域(將在下文中解釋)中的ACK位設置之后才有效。在這種情況下，它定義了下一個期望到來的順序編號。第30頁報文頭長度(HLEN)4比特的HLEN域指出了TCP報文頭的長度，長度是以32比特的字為單位的。4比特可以定義多達15個字，這個數(shù)字乘以4后就可以得到報文頭中總共的字節(jié)數(shù)目。因此，報文頭中最多可以是60字節(jié)。由于報文頭最少需要20個字節(jié)，那么40字節(jié)可以保留給選項域使用。第31頁保留6比特的域控制6比特的控制域中每個比特都有獨立的功能。它或者可以定義為某個段的用途，或者可以作為其他域的有效標記。當URG位被設置的時候，它確認了緊急指針域的有效性。這個位和指針一起指明了段中的數(shù)據(jù)是緊急的。當ACK位被設置的時候，它確認了順序編號域的有效性。這兩者結(jié)合在一起，根據(jù)段類型的不同將具有不同的功能。第32頁PSH位用來通知發(fā)送者需要一個更高的產(chǎn)生率。如果可能的話，數(shù)據(jù)應該用更高的產(chǎn)生率發(fā)送入通道之中。重置位用在順序編號發(fā)生混淆的時候，進行連接重置。SYN位在以下三種類型的段中用來進行順序編號同步：連接請求，連接確認(ACK位被設置)，以及確認回應(ACK位被設置)。FIN位使用在三種類型段的連接終止中：終止請求，終止確認(ACK位被設置)。第33頁窗口窗口是一個16比特的域，定義了滑動窗口的大小。窗口大小是一個16bit字段，因而窗口大小最大為65535字節(jié)。TCP的流量控制由連接的每一端通過聲明的窗口大小來提供。窗口大小為字節(jié)數(shù)，起始于確認序號字段指明的值，這個值是接收端正期望接收的字節(jié)。第34頁校驗和校驗和是使用在差錯檢測中的16比特域。檢驗和覆蓋了整個的TCP報文段，TCP首部和TCP數(shù)據(jù)。這是一個強制性的字段，一定是由發(fā)端計算和存儲，并由收端進行驗證。TCP檢驗和的計算和UDP檢驗和的計算相似。第35頁緊急指針緊急指針這是報文頭中所必須的最后一個域。它的值只有在控制域的URG位被設置之后才有效。緊急指針是一個正的偏移量，和序號字段中的值相加表示緊急數(shù)據(jù)最后一個字節(jié)的序號。TCP的緊急方式是發(fā)送端向另一端發(fā)送緊急數(shù)據(jù)的一種方式。在這種情況下，發(fā)送者通知接收者段中的數(shù)據(jù)部分是緊急數(shù)據(jù)。第36頁選項和填充TCP報文頭中剩余部分定義了可選域。它們使用來傳送額外信息給接收者，或者用在定位中。最常見的可選字段是最長報文大小，又稱為MSS(MaximumSegmentSize)。每個連接方通常都在通信的第一個報文段（為建立連接而設置SYN標志的那個段）中指明這個選項。它指明本端所能接收的最大長度的報文段。第37頁3.關于端口號的約定TCP和UDP都具有端口號，用于標識數(shù)據(jù)交換的參與者。在接收方，IP協(xié)議標識符先于端口號進行檢查，而且TCP和UDP對端口號的使用是彼此獨立的。這就是說，同一個端口號可以有兩種不同的用途，若一個使用它為TCP服務，則另一個還可以將它用在UDP上。每個TCP段都包含源端和目的端的端口號，用于尋找發(fā)端和收端應用進程。這兩個值加上IP首部中的源端IP地址和目的端IP地址唯一確定一個TCP連接。第38頁socket有時，一個IP地址和一個端口號也稱為一個插口（socket）。這個術語出現(xiàn)在最早的TCP規(guī)范（RFC793）中，后來它也作為表示伯克利版的編程接口。插口對（socketpair）(包含客戶IP地址、客戶端口號、服務器IP地址和服務器端口號的四元組)可唯一確定互聯(lián)網(wǎng)絡中每個TCP連接的雙方。第39頁端口號端口號的選擇是很嚴格的，而且受到限制。端口號值0-255都由DOD(美國國防部)分配，它們稱為公用的端口號。例如文件傳輸FTP是21；終端連接Telnet是23；簡單郵件傳輸協(xié)議SMTP是25；域名字服務Domain是53；環(huán)球網(wǎng)服務WWW是80。任何使用這些端口號的應用程序都必須符合相應的已有明確定義的協(xié)議。許多操作系統(tǒng)都把這些公用端口號當作一些受保護的固定端口。這些端口號只能被具有特殊操作系統(tǒng)權(quán)限的進程使用。剩余的端口號才能被普通的進程使用。第40頁10.1.3 傳輸層的責任傳輸層所提供的服務類似于數(shù)據(jù)鏈路層。然而，數(shù)據(jù)鏈路層是設計來在單個網(wǎng)絡中傳數(shù)據(jù)的，而傳輸層在跨越許多網(wǎng)絡的互連網(wǎng)絡上提供這些服務。數(shù)據(jù)鏈路層控制物理層，而傳輸層控制所有三個低層。傳輸層協(xié)議所提供的服務可以被劃分為五大類：端到端傳遞，尋址，可靠傳遞，流量控制和復用。第41頁10.1.4 連接端到端的傳送可以采用兩種模式來完成：面向連接或無連接。在這兩種模式中，面向連接的模式更經(jīng)常使用。一個面向連接的協(xié)議在發(fā)送者和接收者之間，經(jīng)過互連網(wǎng)絡建立了一條虛電路或路徑。屬于一個消息的所有數(shù)據(jù)包將通過同一條路徑發(fā)送。對整個消息使用同一條路徑方便了確認過程和對損壞和丟失幀的重傳。面向連接的服務通常被認為是可靠的。面向連接傳輸有三個步驟：連接建立，數(shù)據(jù)傳輸和連接終止。第42頁1.連接建立在通信設備可以向?qū)Ψ桨l(fā)送數(shù)據(jù)之前，開始通信的設備必須首先決定交換數(shù)據(jù)的對方是否存在，同時必須找到一條經(jīng)過網(wǎng)絡路徑，數(shù)據(jù)才能沿著這條路徑發(fā)送。這個步驟稱為連接建立如圖10-5所示。對于TCP段每次建立都執(zhí)行特定的過程。第43頁（1）請求端（通常稱為客戶）發(fā)送一個SYN段指明客戶打算連接的服務器的端口，以及初始序號（ISN）。這個SYN段為報文段1。（2）服務器發(fā)回包含服務器的初始序號的SYN報文段作為應答。同時，將確認序號設置為客戶的ISN加1以對客戶的SYN報文段進行確認。一個SYN將占用一個序號。（3）客戶必須將確認序號設置為服務器的ISN加1以對服務器的SYN報文段進行確認（報文段3）。第44頁三次握手這三個報文段完成連接的建立。這個過程也稱為三次握手（three-wayhandshake）。發(fā)送第一個SYN的一端將執(zhí)行主動打開（activeopen）。接收這個SYN并發(fā)回下一個SYN的另一端執(zhí)行被動打開（passiveopen）。當一端為建立連接而發(fā)送它的SYN時，它為連接選擇一個初始序號。ISN隨時間而變化，因此每個連接都將具有不同的ISN。RFC793[Postel1981c]指出ISN可看作是一個32比特的計數(shù)器，每4ms加1。這樣選擇序號的目的在于防止在網(wǎng)絡中被延遲的分組在以后又被傳送，而導致某個連接的一方對它作錯誤的解釋。連接建立需要三個動作，稱為三次握手。第45頁圖10-5連接建立第46頁2.終止連接一旦所有的數(shù)據(jù)都傳送完畢，連接必須被終止如圖10-9所示。建立一個連接需要三次握手，而終止一個連接要經(jīng)過4次握手。這由TCP的半關閉（half-close）造成的。既然一個TCP連接是全雙工（即數(shù)據(jù)在兩個方向上能同時傳遞），因此每個方向必須單獨地進行關閉。這原則就是當一方完成它的數(shù)據(jù)發(fā)送任務后就能發(fā)送一個FIN來終止這個方向連接。當一端收到一個FIN，它必須通知應用層另一端幾經(jīng)終止了那個方向的數(shù)據(jù)傳送。發(fā)送FIN通常是應用層進行關閉的結(jié)果。第47頁收到一個FIN只意味著在這一方向上沒有數(shù)據(jù)流動。一個TCP連接在收到一個FIN后仍能發(fā)送數(shù)據(jù)。而這對利用半關閉的應用來說是可能的，盡管在實際應用中只有很少的TCP應用程序這樣做。正常關閉過程如圖10-6所示。首先進行關閉的一方（即發(fā)送第一個FIN）將執(zhí)行主動關閉，而另一方（收到這個FIN）執(zhí)行被動關閉。通常一方完成主動關閉而另一方完成被動關閉。第48頁圖10-6連接終止第49頁3.半關閉TCP提供了連接的一端在結(jié)束它的發(fā)送后還能接收來自另一端數(shù)據(jù)的能力，這就是所謂的半關閉。為了使用這個特性，編程接口必須為應用程序提供一種方式來說明半關閉的含義，即請求方已經(jīng)完成了數(shù)據(jù)傳送，因此發(fā)送一個文件結(jié)束（FIN）給響應端，但還想接收另一端發(fā)來的數(shù)據(jù)，直到響應端給請求方發(fā)來文件結(jié)束（FIN）。第50頁圖10-7TCP半關閉第51頁半關閉讓左方的客戶端開始半關閉，當然也可以由另一端開始。開始的兩個報文段和圖10-6：初始端客戶端發(fā)出的FIN，接著是另一端對這個FIN的ACK報文段。但后面就和圖10-7為接收半關閉的一方仍能發(fā)送數(shù)據(jù)。當收到半關閉的一端在完成它的數(shù)據(jù)傳送后，將發(fā)送一個FIN關閉這個方向的連接，這將傳送一個文件結(jié)束符給發(fā)起這個半關閉的應用進程。當對第二個FIN進行確認后，這個連接便徹底關閉了。第52頁沒有半關閉，需要其他的一些技術讓客戶通知服務器，客戶端已經(jīng)完成了它的數(shù)據(jù)傳送，但仍要接收來自服務器的數(shù)據(jù)。使用兩個TCP連接也可作為一個選擇，但使用半關閉的單連接更好。如果一方已經(jīng)關閉或異常終止連接而另一方卻還不知道，我們將這樣的TCP連接稱為半打開（Half-Open）的。任何一端的主機異常都可能導致發(fā)生這種情況。只要不打算在半打開連接上傳輸數(shù)據(jù)，仍處于連接狀態(tài)的一方就不會檢測另一方已經(jīng)出現(xiàn)異常。第53頁第54頁主要內(nèi)容10.1傳輸層功能10.2SSL協(xié)議10.3實時應用程序傳輸協(xié)議RTP10.4本章小結(jié)10.2SSL協(xié)議SSL(SecureSocketsLayer安全套接層)，及其繼任者傳輸層安全（TransportLayerSecurity，TLS）是為網(wǎng)絡通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。TLS與SSL在傳輸層對網(wǎng)絡連接進行加密。第55頁10.2.1SSL基本概念安全套接字層（SecureSocketLayer，SSL）屬于高層安全機制，保障在Internet上數(shù)據(jù)傳輸之安全，利用數(shù)據(jù)加密(Encryption)技術，可確保數(shù)據(jù)在網(wǎng)絡上之傳輸過程中不會被截取及竊聽，是在TCP基礎上提供一種可靠的端到端的安全服務，廣泛地用于Web瀏覽器與服務器之間的身份認證和加密數(shù)據(jù)傳輸。SSL協(xié)議位于TCP/IP協(xié)議與各種應用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持，如圖108所示。第56頁圖10-8SSL協(xié)議的層次第57頁1.SSL協(xié)議過程三元素SSL協(xié)議過程通過三個元素來完成：（1）握手協(xié)議SSL握手協(xié)議（SSLHandshakeProtocol），這個協(xié)議負責配置用于客戶機和服務器之間會話的加密參數(shù)。當一個SSL客戶機和服務器第一次開始通信時，它們在一個協(xié)議版本上達成一致，選擇加密算法和認證方式，并使用公鑰來生成共享密鑰。第58頁（2）記錄協(xié)議（SSLRecordProtocol），這個協(xié)議用于交換應用數(shù)據(jù)。應用程序消息被分割成可管理的數(shù)據(jù)塊，還可以壓縮，并產(chǎn)生一個MAC（消息認證代碼），然后結(jié)果被加密并傳輸。接收方接收數(shù)據(jù)并對它解密，校驗MAC，解壓并重新組合，把結(jié)果提供給應用程序協(xié)議。（3）警告協(xié)議警報協(xié)議（Alertprotocol），這個協(xié)議用于表示在什么時候發(fā)生了錯誤或兩個主機之間的會話在什么時候終止。第59頁2.SSL協(xié)議的服務SSL協(xié)議提供的服務歸納為三個方面。

（1）用戶和服務器的合法性認證

（2）加密數(shù)據(jù)以隱藏被傳送的數(shù)據(jù)

（3）維護數(shù)據(jù)的完整性

第60頁SSL連接（connection)，一個連接是一個提供一種合適類型服務的傳輸（OSI分層的定義）。SSL的連接是點對點的關系。連接是暫時的，每一個連接和一個會話關聯(lián)。一個SSL會話是在客戶與服務器之間的一個關聯(lián)。會話由HandshakeProtocol創(chuàng)建。會話定義了一組可供多個連接共享的密碼安全參數(shù)。會話用以避免為每一個連接提供新的安全參數(shù)所需昂貴的協(xié)商代價。第61頁10.2.2SSL協(xié)議過程握手協(xié)議是客戶機和服務器用SSL連接通信時使用的第一個子協(xié)議，握手協(xié)議包括客戶機與服務器之間的一系列消息。SSL中最復雜的協(xié)議就是握手協(xié)議。該協(xié)議允許服務器和客戶機相互驗證，協(xié)商加密和MAC算法以及保密密鑰，用來保護在SSL記錄中發(fā)送的數(shù)據(jù)。握手協(xié)議是在應用程序的數(shù)據(jù)傳輸之前使用的。每個握手協(xié)議包含以下三個字段，如圖10-9所示。Type：表示10種消息類型之一。Length：表示消息長度字節(jié)數(shù)。Content：與消息相關的參數(shù)。第62頁圖10-9握手協(xié)議的格式第63頁SSL握手協(xié)議包含四個階段，第一個階段建立安全能力；第二個階段服務器鑒別和密鑰交換；第三個階段客戶鑒別(可選的)和密鑰交換；第四個階段完成握手協(xié)議。第64頁1.建立安全能力SSL握手協(xié)議第一個階段建立安全能力，如圖10-13所示。第65頁ClientHello客戶發(fā)送CilentHello信息（1）客戶端可以支持的SSL最高版本號（2）一個用于生成主秘密的32字節(jié)的隨機數(shù)(32位時間戳+28字節(jié)隨機序列)。（3）一個確定會話的會話ID。（4）一個客戶端可以支持的密碼套件列表(CipherSuite)。（5）一個客戶端可以支持的壓縮算法列表。第66頁ServerHello服務器用ServerHello信息應答客戶（1）一個SSL版本號。取客戶端支持的最高版本號和服務端支持的最高版本號中的較低者。（2）一個用于生成主秘密的32字節(jié)的隨機數(shù)。（客戶端一個、服務端一個）（3）會話ID（4）從客戶端的密碼套件列表中選擇的一個密碼套件（5）從客戶端的壓縮方法的列表中選擇的壓縮方法第67頁客戶端服務端知道了下列內(nèi)容（1）SSL版本（2）密鑰交換、信息驗證和加密算法（3）壓縮方法（4）有關密鑰生成的兩個隨機數(shù)。第68頁2.服務器鑒別與密鑰交換服務器啟動SSL握手第2階段，是本階段所有消息的唯一發(fā)送方，客戶機是所有消息的唯一接收方，如圖10-11所示。該階段分為四個步驟。（1）證書：服務器將數(shù)字證書和到根CA整個鏈發(fā)給客戶端，使客戶端能用服務器證書中的服務器公鑰認證服務器。消息包含一個X.509證書，或者一條證書鏈。（2）服務器密鑰交換（可選）：服務器發(fā)送server_key_exchange消息，此項目是可選的，有些情況下可以不需要，只有當服務器的證書沒有包含必需的數(shù)據(jù)的時候才發(fā)送此消息。消息包含簽名，被簽名的內(nèi)容包括兩個隨機數(shù)以及服務器參數(shù)，這里視密鑰交換算法而定。（3）證書請求：服務器發(fā)送certificate_request消息，服務端可能會要求客戶自身進行驗證。非匿名server可以向客戶請求一個證書包含證書類型。（4）服務器握手完成：服務器發(fā)送server_hello_done，然后等待應答，意味著第二階段的結(jié)束，第三階段開始的信號。第69頁圖10-11服務器鑒別與密鑰交換第70頁這個方法中，服務器在它的第一個信息中，發(fā)送了RSA加密/解密公鑰證書。不過，因為預備主秘密是由客戶端在下一個階段生成并發(fā)送的，所以第二個信息是空的。注意，公鑰證書會進行從服務器到客戶端的驗證。當服務器收到預備主秘密時，它使用私鑰進行解密。服務端擁有私鑰是一個證據(jù)，可以證明服務器是一個它在第一個信息發(fā)送的公鑰證書中要求的實體。第71頁3.客戶機鑒別與密鑰交換第72頁圖10-13客戶機鑒別與密鑰交換第73頁客戶收到server_done消息后，它根據(jù)需要檢查服務器提供的證書，并判斷server_hello的參數(shù)是否可以接受，如果都沒有問題的話，發(fā)送一個或多個消息給服務器。客戶機啟動SSL握手第3階段，是本階段所有消息的唯一發(fā)送方，服務器是所有消息的唯一接收方。如圖10-16所示，該階段分為三個步驟。（1）證書（可選）：為了對服務器證明自身，客戶要發(fā)送一個證書信息，這是可選的，在IIS中可以配置強制客戶端證書認證。如果服務器請求證書的話，則客戶首先發(fā)送一個certificate消息，若客戶沒有證書，則發(fā)送一個no_certificate警告（2）客戶機密鑰交換（Pre-master-secret）：這里客戶端將預備主密鑰發(fā)送給服務端，注意這里會使用服務端的公鑰進行加密。（3）證書驗證（可選），對預備秘密和隨機數(shù)進行簽名，證明擁有（1）證書的公鑰。客戶發(fā)送一個certificate_verify消息，其中包含一個簽名，對從第一條消息以來的所有握手消息的MAC值()進行簽名。第74頁圖10-14加密預備主密鑰第75頁這種情況，除非服務器在階段二明確請求，否則沒有證書信息?？蛻舳嗣荑€交換方法包括階段二收到的由RSA公鑰加密的預備主密鑰，如圖10-17所示。階段三之后，客戶要有服務器進行驗證，客戶和服務器都知道預備主密鑰。第76頁4.完成客戶機啟動SSL握手第四階段，使服務器結(jié)束，如圖10-15所示。該階段分為四個步驟，前2個消息來自客戶機，后2個消息來自服務器。第77頁圖10-15建立起一個安全的連接第78頁第四階段建立起一個安全的連接?？蛻舭l(fā)送一個change_cipher_spec消息，并且把協(xié)商得到的CipherSuite拷貝到當前連接的狀態(tài)之中。然后，客戶用新的算法、密鑰參數(shù)發(fā)送一個finished消息，這條消息可以檢查密鑰交換和鑒別過程是否已經(jīng)成功。其中包括一個校驗值，對所有以來的消息進行校驗。服務器同樣發(fā)送change_cipher_spec消息和finished消息。握手過程完成，客戶和服務器可以交換應用層數(shù)據(jù)。第79頁10.2.3SSL記錄層協(xié)議SSL記錄層協(xié)議限定了所有發(fā)送和接收數(shù)據(jù)的打包，它提供了通信、身份認證功能，是一個面向連接的可靠傳輸協(xié)議，如TCP/IP提供安全保護。

在SSL中所有數(shù)據(jù)被封裝在記錄中。一個記錄由兩部分組成：記錄頭和非零長度的數(shù)據(jù)。記錄頭可以是2字節(jié)或3字節(jié)（當有填充數(shù)據(jù)時使用）。SSL握手層協(xié)議的報文要求必須放在一個SSL記錄層的記錄里，但應用層協(xié)議的報文允許占用多個SSL記錄來傳送。第80頁記錄協(xié)議在客戶機和服務器握手成功后使用，即客戶機和服務器鑒別對方和確定安全信息交換使用的算法后，進入SSL記錄協(xié)議，記錄協(xié)議向SSL連接提供兩個服務：保密性：使用握手協(xié)議定義的秘密密鑰實現(xiàn)完整性：握手協(xié)議定義了MAC，用于保證消息完整性第81頁第82頁主要內(nèi)容10.1傳輸層功能10.2SSL協(xié)議10.3實時應用程序傳輸協(xié)議RTP10.4本章小結(jié)10.3RTP：實時應用程序傳輸協(xié)議

實時傳輸協(xié)議RTP在多點傳送（多播）或單點傳送（單播）的網(wǎng)絡服務上，提供端對端的網(wǎng)絡傳輸功能，適合傳輸實時數(shù)據(jù)。RTP為交互式音頻、視頻等具有實時特性的數(shù)據(jù)提供端到端的傳送服務。在IP網(wǎng)絡上，一般在UDP之上運行RTP協(xié)議。如果支持它的網(wǎng)絡能提供組播功能，則RTP也可用組播將數(shù)據(jù)送給多個目的用戶。RTP包括兩個關系十分密切的子協(xié)議，實時傳輸協(xié)議（RTP）用于傳輸實時數(shù)據(jù)。實時控制協(xié)議（RTCP）：用于監(jiān)視網(wǎng)絡的服務質(zhì)量，并傳遞與會者會話中的信息。第83頁10.3.1RTP術語RTP會話（RTPsession）：RTP傳輸服務使用者之間的連接被稱為RTP會話，就每一個會話參加者而言，會話由一對傳輸層地址（即一個網(wǎng)絡層地址加上兩個端口地址，一個端口為RTP報文的發(fā)送/接收所占用，另一個端口為RTCP報文的發(fā)送/接收所占用）標識。第84頁10.3.2RTP使用場景（RTPUseScenarios）RTP運行于IP和UDP之上，并且遵循RFC3551所描述的音頻和視頻的配置文件中的約定。1.簡單多播音頻會議（SimpleMulticastAudioConference）2.音頻和視頻會議（AudioandVideoConference）3.混頻器和轉(zhuǎn)換器（MixersandTranslators）4.分層編碼（LayeredEncodings）第85頁10.3.3RTP（實時傳輸協(xié)議）RTP協(xié)議（RealTimeProtocol）提供具有實時特征的、端到端的數(shù)據(jù)傳送服務，可用來傳送聲音和運動圖像數(shù)據(jù)。在這項數(shù)據(jù)傳送服務中包含了裝載數(shù)據(jù)的標識符、序列計數(shù)、時戳和傳送監(jiān)視。通常RTP的協(xié)議元是用UDP協(xié)議元來裝載的，并利用UDP的復用和校驗和來實現(xiàn)RTP的復用。第86頁RTP沒有提供任何確保按時傳送數(shù)據(jù)的機制，也沒有提供任何質(zhì)量保證的機制，因而要實現(xiàn)服務質(zhì)量必須由下層網(wǎng)絡來提供保證。同樣必須注意的是，RTP不保證數(shù)據(jù)包按序號傳送，即使在下層網(wǎng)絡能