《电子技术应用》
您所在的位置:首页 > 通信与网络 > 设计应用 > 流控制传输协议与TCP协议的比较
流控制传输协议与TCP协议的比较
黄晓波,郑应平
同济大学 控制科学与工程系,上海200092
摘要: 通过SCTP与TCP协议的比较,分析了SCTP的优缺点,并且给出了仿真结果。
Abstract:
Key words :

摘   要: 通过SCTP与TCP协议的比较,分析了SCTP的优缺点,并且给出了仿真结果。
关键词: 流控制传输协议(SCTP)  会话初始协议(SIP)  队头阻塞

  随着网络多媒体业务的增多,传输控制协议(Transmission Control Protocol,TCP)和用户数据报协议(User Datagram Protocol,UDP)的局限性日益明显,为此互联网工程任务组(Internet Engineering Task Force,IEFT)的信令传输工作组(SIGTRAN)提出了一种新的面向多媒体通信的流控制传输协议(Stream Control Transmission Protocol,SCTP)[1],用于在IP网络上传输公共交换电话网(Public Switched Telephone Network,PSTN)信令消息[2]。
本文通过仿真比较了SCTP和TCP的性能。尤其对队头阻塞现象(Head of Line Blocking)进行了研究。为了能够进行公平比较,需要一个能够运行在TCP和SCTP上的应用层协议,这里选择了会话初始协议(Session Initiation Protocol,SIP)。
1  流控制传输协议的基本特性
1.1 TCP与SCTP的安全性比较
  TCP中的连接是指2个TCP端点通过3次握手过程建立的由一对传输层地址识别的传输通道。在SCTP中TCP的连接被引申为由4路握手建立的关联(association),SCTP 4路握手过程如图1所示。4路握手有效地保护了服务器不受拒绝服务攻击(Denial of Service,DoS)。

  TCP 3次握手是SYN Flooding存在的基础。攻击者向服务器发送大量的SYN报文,服务器在发出SYN-ACK应答报文后若无法收到客户端的ACK报文(第3次握手无法完成),服务器端将维护一个非常大的半连接列表,且要不断地对该列表中的IP进行SYN+ACK的重试,会消耗非常多的CPU时间和内存资源。服务器端将因为忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求,此时从客户角度来看,服务器失去了响应。
  而在一次SCTP 4路握手中,INIT消息的接收端不必保存任何状态信息或者分配任何资源,这样就可防范SYN Flooding等拒绝服务攻击。它在发送INIT-ACK消息时,采用了状态Cookie机制。该Cookie具有发送端建立自己状态所需的全部信息。INIT和INIT-ACK都必须包含建立初始状态所需的一组参数。交换完规定的这些消息之后,INIT的发送端以COOKIE-ECHO消息的方式发送回状态Cookie。接收端则根据所接收到的COOKIE-ECHO中的状态Cookie,完整地重建自己的状态,并回送COOKIE-ACK来确认关联已建立。COOKIE-ECHO和COOKIE-ACK都可将用户数据消息绑定到各自的包中。采用以上这种方式, 即使接收再多的INIT消息, 接收端也没有任何资源的消耗。
1.2 SCTP的多流特性
  SCTP的包格式如图2所示。每个连接可以包含多个流,每个流都通过它的流ID来确定。而流的个数在前面叙述的4路握手中定义。每个数据块都属于一个流;每个流都独立地递交给应用层。流的独立递交解决了TCP中存在的队头阻塞问题。当多个逻辑会话通过一个TCP连接传输时会发生如下现象:当网页中包含有图像时,图像和文本通过一个TCP连接传输。如果图像数据丢失,文本数据的传输就必须等待图像数据重传。这样,一个逻辑会话就会因为另一个逻辑会话的丢失而阻塞。该现象在http/1.1中常发生。当使用SCTP作为传输协议时,每个应用层级的会话都会被分配到各自的流中,这样,一个流中数据的丢失不会影响其他流的传输。

1.3 多宿主特性
  为了增强鲁棒性,服务器通常都装备多个网络接口。这样的服务器被称为多宿主服务器。在连接建立阶段,一个SCTP端能提供一个IP地址列表,其中一个地址作为主地址,正常情况下使用该地址作为传输数据的目的地址。一旦当前的主目的地址变为不可用,则终端将启用列表中的其他地址。
2  仿真实验
  采用Network Simulator(ns-2)作为仿真平台。试验使用的网络拓扑结构如图3所示,节点1和节点6之间是TCP连接,除了节点4和5之间带宽为1.7Mbps外,其余有直接相连的2个节点之间带宽均为10Mbps,这样路由4、5之间成为整个网络的瓶颈。若所有直接相连的节点间延迟均设定为15ms,使得2个SIP端点间的总传输延迟为45ms,相当于北京到纽约的2个SIP端点的传输延迟。设T1表示发送方SIP数据包交给传输层的时间,T2表示到达接收方应用层的时间,则Td=T2-T1为所要测定的延迟时间。
进行如下3种情况的实验。


  (1)在无竞争环境下,分别采用TCP和SCTP作为传输层协议在节点2和7之间传输SIP消息。在该情况下,不存在竞争,丢包是因为发送端发送速度过快而路由缓冲区有限引起。设定传输速度为1.7Mbps×78%=1.326Mbps,这是因为在传输速度为瓶颈速度的78%时,队头阻塞产生的效果最为明显。当设定的传输速度超过1.4Mbps时,可以发现系统变得不稳定,平均延迟急剧增大。而当设定的传输速度低于0.85Mbps时,基本上没有丢包现象产生,也就观察不到队头阻塞现象。统计结果如表1所示。(2)在无竞争环境下,当把传输速度逐渐减小至1.7Mbps×50%=0.85Mbps时,该情况下没有丢包现象,人为设定路由器的随机丢包概率。通过路由4的丢包率改变(分别为0.2%和0.3%)来获得2组数据,数据统计信息如表2所示。(3)在存在TCP竞争的环境下,分2次进行:①只有一个TCP连接参与竞争,节点1、6之间使用TCP传输一个巨大的文件来和节点2、7之间的SIP传输竞争,SIP传输速度为1.7Mbps×40%=0.68Mbps。②参与竞争的TCP连接为2个,节点1、6和节点3、8之间使用TCP传输一个巨大的文件来和节点2、7之间的SIP传输竞争,SIP传输速度为1.7Mbps×30%=0.51Mbps,数据的统计信息如表3所示。

3  试验数据分析
  表1、2、3是仿真试验的结果。在每个仿真中,为避免慢启动影响试验结果,在计算平均延迟时忽略前1 000个数据包。另外需要说明的是,3个表中的置信区间均指SCTP和TCP的延迟差置信水平为95%的置信区间。
  如表1所示,SCTP和TCP的延迟差置信水平为95%的置信区间为(-7.01,0.16),该区间包括0。这表明该情况下队头阻塞不是引起延迟的重要因素。因为SCTP具备队头阻塞避免的能力,但是二者的延迟相差不大。
  分析在随机丢包情况下的队头阻塞行为。如表2所示,路由2丢包率为0.2%时,SCTP和TCP的延迟差置信水平为95%的置信区间为(-10.37,5.01);路由2丢包率为0.3%时,置信区间为(-14.22,7.92),2个区间都包括0。这表明,从统计意义上来说,在这2种情况下队头阻塞依然不是引起延迟的重要因素。虽然SCTP具备队头阻塞避免能力,但是SCTP的平均延迟与TCP的平均延迟相比,并没有较大改善。
  从表3可以看出,当TCP和SCTP共存时,SCTP和TCP的延迟差置信水平为95%的置信区间不包括0。这说明该情况下,SCTP因为避免了队头阻塞,而比TCP有更低的延迟。毫无疑问,队头阻塞所导致的传输性能下降与丢包率成正比,因而只有在负荷较大,拥塞发生较多导致网络丢包率较高的情况下(在表3的试验中,最大延迟甚至达到1 863ms),队头阻塞才会成为影响传输性能的重要因素。然而,在这种情况下,即使是拥有避免队头阻塞功能的SCTP,也无法提供令人满意的传输延迟。
4  结  论
  SCTP有很多优于TCP的地方。SCTP使服务器有效地避免了DoS攻击;SCTP的“多宿主机”特性提高了关联的网络级容错能力;SCTP面向消息;SCTP既支持有序传输也支持无序传输。然而,仿真试验表明,在一般的网络环境下SCTP的队头阻塞避免机制并未给其性能带来很大提升。在适合信令传输的网络环境下,SCTP和TCP的平均延迟从统计意义上说没有太大区别。而在网络丢包率较高的(接上页)
情况下, SCTP比TCP的性能只是稍有提高。SCTP采用了和TCP一样的基于窗口的拥塞控制机制,理论上并不适合作为信令传输的拥塞控制机制,因而将来还需要研究更适合于信令传输的拥塞控制机制。总体而言,SCTP较TCP更能满足高性能传输的要求,随着IP网络的迅猛发展,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

此内容为AET网站原创,未经授权禁止转载。