流控制传输协议与TCP协议的比较

随着网络多媒体业务的增多，传输控制协议(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数据包交给传输层的时间，T₂表示到达接收方应用层的时间，则T_d＝T₂－T₁为所要测定的延迟时间。
进行如下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