摘 要: 通過SCTP與TCP協(xié)議的比較,分析了SCTP的優(yōu)缺點,并且給出了仿真結(jié)果。
關(guān)鍵詞: 流控制傳輸協(xié)議(SCTP) 會話初始協(xié)議(SIP) 隊頭阻塞
隨著網(wǎng)絡多媒體業(yè)務的增多,傳輸控制協(xié)議(Transmission Control Protocol,TCP)和用戶數(shù)據(jù)報協(xié)議(User Datagram Protocol,UDP)的局限性日益明顯,為此互聯(lián)網(wǎng)工程任務組(Internet Engineering Task Force,IEFT)的信令傳輸工作組(SIGTRAN)提出了一種新的面向多媒體通信的流控制傳輸協(xié)議(Stream Control Transmission Protocol,SCTP)[1],用于在IP網(wǎng)絡上傳輸公共交換電話網(wǎng)(Public Switched Telephone Network,PSTN)信令消息[2]。
本文通過仿真比較了SCTP和TCP的性能。尤其對隊頭阻塞現(xiàn)象(Head of Line Blocking)進行了研究。為了能夠進行公平比較,需要一個能夠運行在TCP和SCTP上的應用層協(xié)議,這里選擇了會話初始協(xié)議(Session Initiation Protocol,SIP)。
1 流控制傳輸協(xié)議的基本特性
1.1 TCP與SCTP的安全性比較
TCP中的連接是指2個TCP端點通過3次握手過程建立的由一對傳輸層地址識別的傳輸通道。在SCTP中TCP的連接被引申為由4路握手建立的關(guān)聯(lián)(association),SCTP 4路握手過程如圖1所示。4路握手有效地保護了服務器不受拒絕服務攻擊(Denial of Service,DoS)。
TCP 3次握手是SYN Flooding存在的基礎(chǔ)。攻擊者向服務器發(fā)送大量的SYN報文,服務器在發(fā)出SYN-ACK應答報文后若無法收到客戶端的ACK報文(第3次握手無法完成),服務器端將維護一個非常大的半連接列表,且要不斷地對該列表中的IP進行SYN+ACK的重試,會消耗非常多的CPU時間和內(nèi)存資源。服務器端將因為忙于處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求,此時從客戶角度來看,服務器失去了響應。
而在一次SCTP 4路握手中,INIT消息的接收端不必保存任何狀態(tài)信息或者分配任何資源,這樣就可防范SYN Flooding等拒絕服務攻擊。它在發(fā)送INIT-ACK消息時,采用了狀態(tài)Cookie機制。該Cookie具有發(fā)送端建立自己狀態(tài)所需的全部信息。INIT和INIT-ACK都必須包含建立初始狀態(tài)所需的一組參數(shù)。交換完規(guī)定的這些消息之后,INIT的發(fā)送端以COOKIE-ECHO消息的方式發(fā)送回狀態(tài)Cookie。接收端則根據(jù)所接收到的COOKIE-ECHO中的狀態(tài)Cookie,完整地重建自己的狀態(tài),并回送COOKIE-ACK來確認關(guān)聯(lián)已建立。COOKIE-ECHO和COOKIE-ACK都可將用戶數(shù)據(jù)消息綁定到各自的包中。采用以上這種方式, 即使接收再多的INIT消息, 接收端也沒有任何資源的消耗。
1.2 SCTP的多流特性
SCTP的包格式如圖2所示。每個連接可以包含多個流,每個流都通過它的流ID來確定。而流的個數(shù)在前面敘述的4路握手中定義。每個數(shù)據(jù)塊都屬于一個流;每個流都獨立地遞交給應用層。流的獨立遞交解決了TCP中存在的隊頭阻塞問題。當多個邏輯會話通過一個TCP連接傳輸時會發(fā)生如下現(xiàn)象:當網(wǎng)頁中包含有圖像時,圖像和文本通過一個TCP連接傳輸。如果圖像數(shù)據(jù)丟失,文本數(shù)據(jù)的傳輸就必須等待圖像數(shù)據(jù)重傳。這樣,一個邏輯會話就會因為另一個邏輯會話的丟失而阻塞。該現(xiàn)象在http/1.1中常發(fā)生。當使用SCTP作為傳輸協(xié)議時,每個應用層級的會話都會被分配到各自的流中,這樣,一個流中數(shù)據(jù)的丟失不會影響其他流的傳輸。
1.3 多宿主特性
為了增強魯棒性,服務器通常都裝備多個網(wǎng)絡接口。這樣的服務器被稱為多宿主服務器。在連接建立階段,一個SCTP端能提供一個IP地址列表,其中一個地址作為主地址,正常情況下使用該地址作為傳輸數(shù)據(jù)的目的地址。一旦當前的主目的地址變?yōu)椴豢捎茫瑒t終端將啟用列表中的其他地址。
2 仿真實驗
采用Network Simulator(ns-2)作為仿真平臺。試驗使用的網(wǎng)絡拓撲結(jié)構(gòu)如圖3所示,節(jié)點1和節(jié)點6之間是TCP連接,除了節(jié)點4和5之間帶寬為1.7Mbps外,其余有直接相連的2個節(jié)點之間帶寬均為10Mbps,這樣路由4、5之間成為整個網(wǎng)絡的瓶頸。若所有直接相連的節(jié)點間延遲均設(shè)定為15ms,使得2個SIP端點間的總傳輸延遲為45ms,相當于北京到紐約的2個SIP端點的傳輸延遲。設(shè)T1表示發(fā)送方SIP數(shù)據(jù)包交給傳輸層的時間,T2表示到達接收方應用層的時間,則Td=T2-T1為所要測定的延遲時間。
進行如下3種情況的實驗。
(1)在無競爭環(huán)境下,分別采用TCP和SCTP作為傳輸層協(xié)議在節(jié)點2和7之間傳輸SIP消息。在該情況下,不存在競爭,丟包是因為發(fā)送端發(fā)送速度過快而路由緩沖區(qū)有限引起。設(shè)定傳輸速度為1.7Mbps×78%=1.326Mbps,這是因為在傳輸速度為瓶頸速度的78%時,隊頭阻塞產(chǎn)生的效果最為明顯。當設(shè)定的傳輸速度超過1.4Mbps時,可以發(fā)現(xiàn)系統(tǒng)變得不穩(wěn)定,平均延遲急劇增大。而當設(shè)定的傳輸速度低于0.85Mbps時,基本上沒有丟包現(xiàn)象產(chǎn)生,也就觀察不到隊頭阻塞現(xiàn)象。統(tǒng)計結(jié)果如表1所示。(2)在無競爭環(huán)境下,當把傳輸速度逐漸減小至1.7Mbps×50%=0.85Mbps時,該情況下沒有丟包現(xiàn)象,人為設(shè)定路由器的隨機丟包概率。通過路由4的丟包率改變(分別為0.2%和0.3%)來獲得2組數(shù)據(jù),數(shù)據(jù)統(tǒng)計信息如表2所示。(3)在存在TCP競爭的環(huán)境下,分2次進行:①只有一個TCP連接參與競爭,節(jié)點1、6之間使用TCP傳輸一個巨大的文件來和節(jié)點2、7之間的SIP傳輸競爭,SIP傳輸速度為1.7Mbps×40%=0.68Mbps。②參與競爭的TCP連接為2個,節(jié)點1、6和節(jié)點3、8之間使用TCP傳輸一個巨大的文件來和節(jié)點2、7之間的SIP傳輸競爭,SIP傳輸速度為1.7Mbps×30%=0.51Mbps,數(shù)據(jù)的統(tǒng)計信息如表3所示。
3 試驗數(shù)據(jù)分析
表1、2、3是仿真試驗的結(jié)果。在每個仿真中,為避免慢啟動影響試驗結(jié)果,在計算平均延遲時忽略前1 000個數(shù)據(jù)包。另外需要說明的是,3個表中的置信區(qū)間均指SCTP和TCP的延遲差置信水平為95%的置信區(qū)間。
如表1所示,SCTP和TCP的延遲差置信水平為95%的置信區(qū)間為(-7.01,0.16),該區(qū)間包括0。這表明該情況下隊頭阻塞不是引起延遲的重要因素。因為SCTP具備隊頭阻塞避免的能力,但是二者的延遲相差不大。
分析在隨機丟包情況下的隊頭阻塞行為。如表2所示,路由2丟包率為0.2%時,SCTP和TCP的延遲差置信水平為95%的置信區(qū)間為(-10.37,5.01);路由2丟包率為0.3%時,置信區(qū)間為(-14.22,7.92),2個區(qū)間都包括0。這表明,從統(tǒng)計意義上來說,在這2種情況下隊頭阻塞依然不是引起延遲的重要因素。雖然SCTP具備隊頭阻塞避免能力,但是SCTP的平均延遲與TCP的平均延遲相比,并沒有較大改善。
從表3可以看出,當TCP和SCTP共存時,SCTP和TCP的延遲差置信水平為95%的置信區(qū)間不包括0。這說明該情況下,SCTP因為避免了隊頭阻塞,而比TCP有更低的延遲。毫無疑問,隊頭阻塞所導致的傳輸性能下降與丟包率成正比,因而只有在負荷較大,擁塞發(fā)生較多導致網(wǎng)絡丟包率較高的情況下(在表3的試驗中,最大延遲甚至達到1 863ms),隊頭阻塞才會成為影響傳輸性能的重要因素。然而,在這種情況下,即使是擁有避免隊頭阻塞功能的SCTP,也無法提供令人滿意的傳輸延遲。
4 結(jié) 論
SCTP有很多優(yōu)于TCP的地方。SCTP使服務器有效地避免了DoS攻擊;SCTP的“多宿主機”特性提高了關(guān)聯(lián)的網(wǎng)絡級容錯能力;SCTP面向消息;SCTP既支持有序傳輸也支持無序傳輸。然而,仿真試驗表明,在一般的網(wǎng)絡環(huán)境下SCTP的隊頭阻塞避免機制并未給其性能帶來很大提升。在適合信令傳輸?shù)木W(wǎng)絡環(huán)境下,SCTP和TCP的平均延遲從統(tǒng)計意義上說沒有太大區(qū)別。而在網(wǎng)絡丟包率較高的(接上頁)
情況下, SCTP比TCP的性能只是稍有提高。SCTP采用了和TCP一樣的基于窗口的擁塞控制機制,理論上并不適合作為信令傳輸?shù)膿砣刂茩C制,因而將來還需要研究更適合于信令傳輸?shù)膿砣刂茩C制??傮w而言,SCTP較TCP更能滿足高性能傳輸?shù)囊螅S著IP網(wǎng)絡的迅猛發(fā)展,SCTP一定會有更廣闊的應用空間。
參考文獻
1 Stewart R.Stream Control Transmission Protocol.RFC 2960,2000
2 Coene L,Pastor J.Telephony Signaling Transport over SCTP Applicability Statement.IETF Internet Draft(Work in progress),2002
3 Rosenberg J.SIP:Session Initiation Protocol.RFC 3261,2002
4 Rosenberg J,Schulzrinne H,Camarillo G.The Stream Control Transmission Protocol as a Transport for the Session Initiation Protocol.IETF Internet Draft(Work in progress),2002