TCP/IP协议问题透析

TCP/IP协议问题透析

Exhaustive Analysis of TCP/IP Protocol’s Deficiency

杨燚, 王钢

Yang YI, Wang Gang

（中科院计算所网络研发中心，北京市中关村科学院南路6号，100080）

 

摘要：本文从目前的需要出发，针对TCP/IP在无线和安全领域的应用展开论述，详细分析了TCP/IP在几个关键的地方存在的问题，并分别就慢速启动算法，初始窗口大小，初始窗口增加策略，RTO估计器，延迟响应，内核实现的不足和安全漏洞进行了研究，给出了一些建设性的解决办法，为今后的进一步研究奠定了一个基础

关键词：TCP；IP；慢速启动；RTO；延迟响应

中图分类号：TP393.4

Abstract

According to current needs and requirements, this thesis addresses TCP/IP’s application to wireless and secure area to discuss, it analyzes several problems about a few of critical parts within TCP/IP in details, simultaneously delves into slow start algorithm, initial window size, increasing policy of initial window, RTO estimator, delay acknowledgement, deficiency of kernel implementation and security leakage and gives some constructive solutions in order to further research to pave a basis.

1．           引言

随着计算机和通信技术的发展，人们能够越来越方便的实现信息的共享，TCP/IP协议使得世界上不同体系结构的计算机网络互连在一起形成一个全球性的广域网络Internet，这为各种信息的共享提供了便捷的途径，在Internet中的每一台计算机可以访问Internet上的其他任意一台计算机，好象它们在一个局域网内用双绞线或同轴电缆直接连接起来一样（不同之处是速度比局域网的慢）。现在TCP/IP协议已经非常流行并已经成为网络通信协议的事实上的标准。之所以会这样，关键在于TCP/IP能够适应不同的网络体系结构和不同的传输链路，并且为客户端-服务器模式提供了很好的支持，这已经成为网络应用程序的标准模式。这给人的感觉好象TCP/IP是完美无缺的，但事实正好相反，TCP/IP在性能和安全方面都有很大的缺点，尤其当它应用于无线通信和要求安全性很高的领域时，这些缺点就显得非常明显。

近来TCP/IP在无线通信中的应用日益增加，而且将来会有非常多的移动主机连接到Internet中，包括卫星链路在内的无线链路会越来越多。这使得我们需要深入研究TCP/IP在无线通信中存在的问题，另外在涉及到高度机密的领域，安全是特别重要的，因而TCP/IP的安全问题也要严肃审视。正是基于以上需求，本文对最流行的TCP/IP（着重于TCP和IP）实现做了认真的分析，指出了存在的问题，并对好些问题给出了解决对策。

本文的结构是这样安排的，第一部分是引言，第二部分对TCP性能方面的问题作了论述，分别就慢速启动算法，初始窗口大小，初始窗口增加策略，RTO估计器，延迟响应和内部实现进行了研究，并给出了解决措施。第三部分着眼于安全问题，指出一些安全漏洞，并为其中一些给出补救措施。最后一部分是结束语，提出将来的研究方向。

2．           TCP存在的性能问题

2．1  TCP/IP应用于无线链路时的缺陷

无线链路的特点是易受干扰、多径衰减的影响。信道通信行为会随时间和地理位置而变化，链路层差错控制对包一级的 QoS（Quality of Service）的影响也是随时间变化的。因而为固定网络开发的TCP无法很好的应用于移动通信和卫星等无线链路中。它的缺点就是缺乏网络自适应性。

在有线网络中，流量控制和资源分配策略都假定：底层的物理媒质是高度可靠的，但这对无线网不成立。所以在无线网中，这种策略不是有效的。在无线网上进行TCP传输，TCP认为包的丢失是由拥塞引起的，而实际上这样的包丢失可能是由于信道错误引起的包丢弃或网络延时而引发的，这导致TCP超时并启动拥塞控制算法，这显然不必要的减少了无线信道的吞吐率。

在无线信道上的传输性能可以通过使用链路层差错控制的新方法ARQ(Automatic Repeat Request)和前向错误纠正FEC（Forward Error Correction）来改善。ARQ用于传输要求高可靠性的数据，FEC用于传输时延敏感的数据流。变种的ARQ/FEC方案更适合于宽带无线网的传输，特别是在传输的数据流表现出不同的特色和QoS要求时。

在无线通信中还有一个问题就是当主机不断移动时，它可能离开其IP地址标识的那个区域，从而无法连接到网络中。解决主机移动性问题有一个最基本的难题是：主机的IP地址有双重意义，它既是对主机的唯一标识，又指示它所在位置。而移动主机的位置要经常变化，这意味着IP地址也应改变。因而目前的TCP/IP实现是无法解决该问题的。Mobile IP作为一种移动主机协议解决了这个问题。它解决这个问题的办法是：在主机标识到位置的最近映象可利用时，把IP地址的这两个意义分开。

移动主机协议的主要设计目标是不需要用户重新配置就可以改变访问点，这被称做操作透明性。移动主机协议设计的另一个目标是支持handoff（在连接保持时改变访问点叫handoff），但不会严重扰乱正在进行的数据传输。

许多建议的移动主机协议都有“two tier addrssing”结构，即一个移动主机在逻辑上关联两个IP地址；一个是本地地址，用作不变的主机标识，另一个地址反应它当前连接到Internet的点。这种结构由三个基本成分组成。

本地目录：一个数据库，可以是分布式的，它包含最新的两个地址空间之间的映象。

地址翻译代理：完成主机标识到实际目标地址的翻译，这涉及到查询本地目录或本地缓存。

转发代理：确保到达移动主机的包的目的地址字段有它恒定的本地地址。

Mobile IP解决方案满足操作透明目标而且也支持handoff，但是它只是对慢速移动的主机是优化的。若主机经常移动，它就变的效率极其低下。Mobile IP要求移动主机无论在什么时候移动到一个新的外部代理（Foreign Agent），都应该通知给本地代理。在修改信息阶段，包被转发到旧的位置，因而不会扰乱活动的数据传输。类似的，在路由优化阶段，尽管相应的主机已经获得一个新的绑定，数据传输也不会被打断。这些延迟的影响会随着handoff出现的频率的增加而增加。修改信息是由Internet和本地代理负责的。这个负担与移动主机的数量成比例而与产生的流量无关。随着移动主机越来越普遍，蜂窝越来越小，这可能是一个问题。

Cellular IP不同于它，Cellular IP提供了一个跟蜂窝电话差不多的框架，该框架能够把操作从小的办公系统扩展到大的校园网和区域网。每一个都使用同样的Cellular IP，只是有不同的本地管理设备环境。Cellular IP协议有一个有效的本地本地管理和搜索方案，这可以避免对闲着的用户的跟踪，因而可以降低无线访问网络的负载。

2．2          TCP慢速启动算法的延迟响应策略和设置的初始窗口大小降低了TCP的性能

慢启动算法在传输开始时和发生拥塞时开始启动。许多TCP实现在连接空闲某一段时间（1个往返时间）之后也使用。慢速启动算法的主要目的是，用来决定可利用的网络带宽，阻止发送方发送大量的数据淹没中间网关从而引起数据丢失。从这一点来讲，它是很好的，但是慢速启动算法使得TCP在慢速启动期间不能很好的利用网络带宽，特别是对于那些链路的带宽时延乘积较小的链路和RTT（Round-trip Time）较大的链路(如卫星网)。TCP的延迟响应算法一直被证明是有损于TCP的性能的。慢速启动算法经常是以大量的报文段丢失而终止的，这显然损害了TCP的性能。

降低慢启动对性能影响的方法是：采用一个合适的SSTHRESH(Slow Start Thresh，慢启动阈值)，使得慢启动结束不会出现大量的报文段的丢失。这就需要估计合适的SSTHRESH，同时采用不同于标准的慢速启动算法的cwnd（Congestion Window,拥塞窗口）的增加策略。

另一种方法是，使用大的初始cwnd，增加初始的cwnd的大小对较短的数据流和低带宽网络最为有利。慢启动算法把初始cwnd设置为1，这使得发送方必须等待接收方延迟响应计时器的时间才能收到接收方的响应来发送新的数据段。这显然严重降低了连接带宽的利用率。假如首先使用一个较大的窗口IW（Initial Window），在发生超时重传时才设置为1。这样做就能提高慢启动开始时的网路带宽利用率。

W_I = min ( 4 * MSS, max ( 2 * MSS, 4380 ))

其中W_I为初始窗口大小，MSS(Maxium Segment Size)为网络能够传输的最大数据单元的字节数，这样做的好处是缩减了到达接收方报告的窗口尺寸所需要的时间。采用了大的初始窗口后，慢启动所需时间将变为：

慢启动时间 = R ( log₂W_A - log₂W_I )    (不采用延迟响应，每一个报文段都响应)

慢启动时间 ~= 2R ( log₂W_A - log₂W_I )    (采用延迟响应，每2个报文段给出1个响应)

（其中W_A为接收方报告的窗口大小）这对于大数据量的块传输没多大影响，因为随着传输长度的增加，慢启动对总体性能的影响会降低。

如果MSS=1024，则W_I =4，将节省3RTT和一个延迟响应时间（因为不采用大的初始窗口时，cwnd=1；另外，因为cwnd=1时，接收端需要等待延迟响应超时才发送响应）。

但增加W_I也有缺点，在高度拥塞的环境下，这可能增加TCP连接的报文段丢失。它也会引起共享的高度拥塞的瓶径竞争TCP连接上的报文丢失。

在慢启动过程中，cwnd一直增加到接收方报告的窗口大小或发送方检测到网络拥塞。慢速启动算法的窗口增加策略是，每收到一个ACK（响应报文段），cwnd增加一个报文段的长度，如果接收端对接收到的每一个报文段都发送ACK，假设往返时间RTT为一不变的数，并且cwnd增加过程中没有发生拥塞，那么慢启动所需时间就是：

慢启动所需时间=Rlog₂W_A

其中R为往返时间RTT，W_A为接收方报告的窗口大小。

如果把响应的数量正好减少一半，那么cwnd到达需要的时间就会翻倍。即：

慢启动所需时间=2Rlog₂W_A

因而TCP所采用的延迟响应策略也影响了慢启动，即减慢cwnd的增加速度，从而影响了TCP的性能，尽管它提供了优点（减少了ACK数量，可以减少中间网关和目的地所需要的资源和处理时间。大部分TCP实现都采用了延迟响应。这对于大数据量的块传输是有优点的）。使用受限字节计数(Limited Byte Counting)算法可以减轻延迟响应对TCP性能的影响，使用LBC，cwnd增加的数量基于每一个ACK覆盖的新的数据段的数量而不是一个常数。但LBC有个问题就是，在基于丢失恢复的慢速启动阶段，对cwnd的增加有点冒进。由于在丢失恢复的慢启动间LBC传输额外的不必要的报文段，所以ABC（Appropriate Byte Counting）比LBC更合适。另外ABC增加了吞吐率。SABC(the Scaled version of ABC)对cwnd的增加提供了更好的粒度控制。

2．3          TCP协议的重传超时计时器存在的问题

超时时间值的确定对TCP协议的性能有严重的影响。RTO(Retransmisiion Timeout)值是一个包发送出去到发送者认为该包已经丢失需要被重传所经历的时间，发生超时重传这一事件叫timeout。RTO是对RTT(Round-trip time)的上限值的推测值，RTT是从一个包离开发送者到发送者接收到接收者发送的对该包的响应所经历的时间。在发生包超时前一直由REXMT(Retransmission timer state)维持一时间值。RTO是REXMT的初始值。重传超时计时器就是指REXMT和RTO。

       太乐观的超时器经常过早的超时，这会引起不必要的流量，降低一个连接的有效吞吐率。同时超时也会引发拥塞控制，这又导致了端到端的吞吐率的进一步恶化。而太保守的重传计时器会导致丢失包重传前有一段很长的空闲时间，这也会降低性能，对于交互式请求—响应型的连接这是非常明显的，它也会在发送者用完窗口时影响块数据的传输。

       目前，绝大多数TCP实现使用的估计RTO的算法（这也是最流行的TCP实现版本 TCP-Lite——4.4 BSD-Lite中的TCP实现所使用的估计算法）是：

              DELTA_L = RTT_Sample – SRTT_L

              SRTT_L = SRTT_L + 1/8 * DELTA_L

              RTTVAR_L = RTTVAR_L + 1/4 * ( | DELTA_L | - RTTVAR_L )

              RTO_L = MAX ( SRTT_L + 4 * RTTVAR_L, 2ticks)

       其中RTO_L要在完成每一个新的RTT测量后修改。SRTT(Smoothed RTT)称作平滑RTT估计器。SRTT_L是一个低通过滤器，它能以固定的加权因子7/8（SRTT_L = SRTT_L + 1/8 * DELTA_L = 7/8 * SRTT_L + 1/8 * RTT_Sample ）记忆连接的RTT历史。DELTA_L是最新的RTT_Sample与当前的SRTT_L的差。RTTVAR是平滑的RTT偏差的估计器。利用RTTVAR，RTO可以解释RTT的变化。也是一个低通过滤器，它能以固定的加权因子3/4（RTTVAR_L = RTTVAR_L + 1/4 * ( | DELTA_L | - RTTVAR_L ) = 3/4 * RTTVAR_L + 1/4 * | DELTA_L |）记忆连接的RTT偏差的历史。1/8和1/4是估计器增益，4是RTT偏差权重。

       REXMT和RTO都是用时钟滴答来计量的，一个时钟滴答一般为1秒的几分之一，这与操作系统有关，时钟滴答也称作计时器粒度。RTO_L最小为两个时钟滴答，因为TCP-Lite中一个时钟滴答为500毫秒，而实际的计时中，一个时钟滴答可能是0到500毫秒的任何值，所以就用两个时钟滴答。TCP-Lite为每一个TCP连接都分别维护一个REXMT，当一个报文段被发送并REXMT没有变化时，就初始化RTO_L。当对最老的报文段的响应到达并有很多老的报文段时，REXMT重新用于初始化RTO_L。

       RTO最小值对Lite_Xmit_Timer（即TCP-Lite中实现的重传超时计时器）的性能有严重的影响；如果计时器粒度为100毫秒或更低，其性能会更进一步提高。另外在一些情况下，RTT取样率大大地影响Lite_Xmit_Timer的性能，当RTT取样率高时并TCP发送者负载较大时，估计器增益的选择和偏差权重的选择变得特别关键。而且这两个值的取值应该依赖于RTT取样率。

       TCP的操作和性能很大程度上取决于路径特性：如可利用带宽、端到端时延、包丢弃模式。理想情况下，一个设计的很好的重传计时器应当能在任何端到端路径上都执行的很好。但是在Internet上，路径的特性随时间的变化非常大。从上面的分析，我们可以看出，Lite_Xmit_Timer存在一些问题，一些问题已经严重影响了TCP的性能。Lite_Xmit_Timer的4个重要的问题是：

1． 当RTT下降时有预测的错误。在计算RTTVAR_L时，使用的是DELTA_L的绝对值，这会导致当RTT下降时RTO却增加。也就是说，它会导致连接的RTT已经下降到SRTT以下（即DELTA_L变成负值）后，RTO还增加。在这种情况下给人的感觉好象是RTT增加了同样幅度的值后对RTO的影响。这导致RTO过高预测了RTT，因而需要花费一段时间才能变到合理的水平。

2． 固定的增益和偏差权重不合适。Lite_Xmit_Timer在定义时基于这样的假定，对每个flight(即一个RTT时间内能够传送的报文段数)，只有一个段被计时，估计器和偏差都调整到适应于这种情况。但是如果RTT采样率较高（也即对每一个flight，不只计时一个报文段）并且发送方负载较大时，固定的增益和权重是失败的。问题在于在这种情况下，偏差权重太低无法使RTO达到足够的水平，估计器增益也太高。这会导致RTTVAR_L变化的特别快，因而RTO_L很快会变到RTT，这显然太激进。

3． REXMT_Restart Bug。REXMT实现的问题是，当一个响应最老的报文段的响应到达时，它会被RTO_L重新初始化，而还有更多的段等待响应。这无法解释最老的报文段的生存期。因而发生第一次超时前，REXMT是RTO_L与最老报文段的生存期的和。这使得REXMT严重保守。

4． 计时器粒度。由于RTO是对RTT上限的预测，所以计时器粒度越高（即一个时钟滴答的时间较长），RTO就越不精确，就越保守。因而需要一个低粒度计时器。TCP-Lite的500毫秒的计时器粒度是不够的。一般地，在最坏情况下，RTT的数量级大概为几百毫秒，因而计时器粒度应当为10毫秒或几十毫秒。另外500毫秒的计时器实际上抵消了一些确定RTO的公式带来的优化。

REXMT问题是基于heartbeat timer的，heartbeat timer每500毫秒过期并触发一个特定的中断例程修改每个活动的TCP连接的REXMT（即减少一个时钟滴答）。它这样做不考虑REXMT实际上是否到达0。仅增加heartbeat timer的频度会增加有价值的处理器资源的开销，使它用于处理无意义的中断。这对于繁忙的服务器是一个很大的问题。它实际也是定义RTO_L最小值的理由。另外一个理由是，一个时钟滴答的REXMT的值可能在0~1个时钟滴答的任何时间过期。

为了解决Lite_Xmit_Timer的这些问题，对RTO的估计可采用一种新的算法：

              DELTA_E = RTT_Sample - SRRT_E

              FLIGHT_E = MAX ( SSTHRESH, CWND / 2 ) + 1

              GAIN_E = 1 / FLIGHT_E, 如果RTT采样率为1

                            2 / FLIGHT_E, 如果RTT采样率为2

                            1 / 3, 如果在每个RTT内RTT取样为1

              VARGAIN_E = GAIN_E, 如果 ( DELTAR_E – RTTVAR_E ) >= 0

                                   GAIB_E ** 2, 如果 ( DELTAR_E – RTTVAR_E ) < 0

              SRTT_E = SRTT_E + GAIN_E * DELTA_E

              RTTVAR_E = RTTVAR_E + VARGAIN_E * ( DELTAR_E – RTTVAR_E ),如果DELTA_E >= 0

                                 RTTVAR_E                                                        ,如果DELTA_E < 0

              RTO_E = MAX ( ( SRTT_E + ( 1 / VARGAIN_E ) * RTTVAR_E ), RTT_Sample + 2ticks )

上面用的计时器我们称之为Eifel_Xmit_Timer。为了避免Lite_Xmit_Timer的问题一，在Eifel_Xmit_Timer中定义RTTVAR_E在DELTA_E<0时保持不变。这样，RTO_E只跟SRTT_E一样快的减少。这样，对RTTVAR定义的细微变化就导致了在RTT下降时RTO不会出现尖峰。为了避免Lite_Xmit_Timer的第二个问题，在Eifel_Xmit_Timer中去掉了恒定的估计器增益。对SRTT_E和RTTVAR_E的每一个的增益都随发送端的负载变化，而且也依赖于RTT采样率。如果每个RTT内多于一个报文段被计时，这样的思想就有助于把整个权值1平均分配到每个flight的RTT取样上，即把两个估计器的记忆限制到一个RTT上。取样率为2，指的是延迟响应，即每收到两个报文段发送一个响应。把偏差权重定义为估计器增益的倒数使得它也随发送方的负载变化。在RTT一直长时间保持恒定然后突然增加的情况下，它能保证RTO_E是SRTT_E和DELTA_E的和。其中FLIGHT_E的定义加1是因为一个拥塞避免周期中第一个flight的报文段数量为SSTHRESH+1或CWND/2。

在Lite_Xmit_Timer中，还有一个问题，当RTT增加时，RTO_L也增加，但RTO_L的增加会在每一个flight的报文段发送到一半途中就结束增加，然后在flight的后一半报文段发送期间迅速下降。这显然在发送方最大负载较小时成了一个问题：在每一个flight结束时，RTO_L的值变得非常接近于RTT。为了避免这个问题，在Eifel_Xmit_Timer中定义了RTTVAR_E的增益在RTTVAR_E下降时为GAIN_E的平方。同时我们使用与发送方负载成反比的GAIN_E为增益。这样就使得在每一个flight的后半部分报文段发送期间，RTO_E的值保持平滑而不至于急剧下降。

RTO的最小值对于保护不合理的超时是有必要的，那时可能RTT非常接近于甚至低于计时器粒度。在其他情况下RTO的最小值是没有意义的。当使用heartbeat timer时，RTO最小值必须是两个时钟滴答。另外不要让RTO降到低于最近的RTT取样是合理的。这实际是定义RTO最小值的动机。它在FreeBSD操作系统中已经实现。

对于Lite_Xmit_Timer的第三个问题，在Eifel_Xmit_Timer中通过仅仅在一个动态的数据结构中存储每一个报文段的时间戳就消除了。这样我们就总是能通过下列公式：

REXMT_E = RTOE – 最老报文段的生存期

精确确定REXMT。

在一个连接的flight中没有足够的报文段触发快速重传算法的情况下，也就是说重传必须依赖于重传计时器时，REXMT_E和REXMT_L相比能够大大改善端到端连接的性能。

通过大量的实验数据已经证明Eifel_Xmit_Timer的性能比Lite_Xmit_Timer性能更好，而且在前面提到的那些情况下，Eifel_Xmit_Timer解决了Lite_Xmit_Timer存在的所有问题。当然Eifel_Xmit_Timer在付诸使用前，还需要在各种环境下进行测试。

总之，在优化端到端的重传计时器时要注意以下问题：

1． 低于SRTT的RTT采样不应当用于修改RTTVAR；

2． 估计器的增益和偏差权重应当依赖于采样率

3． 如果每一个段被计时来测量RTT，即使用时间戳可选项，那么估计器的增益和偏差权重需要因发送端的负载而变化。

2．4  TCP协议的RTO估计和带宽估计策略的不足

       对于传输协议，它可利用的当前网络状况的信息越多，就能够越有效的用网络传输数据。在Internet中，传输协议要经常对连接进行测量来产生对网络特性的估计。两个最基本的估计问题是RTO计时器的设定和连接的可利用带宽的估计。对于RTO的估计，估计器的性能主要取决于它的最小值，计时器粒度的影响不大。带宽的估计现在都实现的远没期望的好，因而有必要开发一种新的算法来改善。

       如果发生了包丢失，说明网络出现了拥塞，因而发送者应该等待比最大的RTT更长的时间再发送包，这样可以使拥塞有更多的时间从网络中流出。如果RTT一过，发送者就重传，那重传也会被丢失，但稍后发送则能成功。在标准的TCP实现中，RTO估计器的缺陷是：

l       在测量与重传的包相关的RTT时有二义性

l       每个往返只重传一个丢失的包的保守的RTO策略

l       很难选择一个初始的估计

l       在拥塞期间不能迅速跟踪增加的RTT。

这些问题都已经得到了解决。SACK（Selective Acknowledgement）解决了第二个问题。Jacobson引入了对RTT差值的EWMA估计(即TCP-Lite的估计器对RTT差值的估计算法)，从而使TCP RTO估计更好。这些已经在BSD版的TCP（即现在最流行的TCP版本）中实现。但是BSD版的TCP实现仍然有一些限制：

1． 适应性的RTT和RTT差值估计器只能在一个往返用新测量的值修改一次。因此它们非常慢速的适应于网络状况的变化。

2． 测量使用500毫秒的时钟粒度，那必然产生粗略的估计。

3． 结果RTO估计有一个大的最小值1秒，这使它必然保守。

随着高精度的时钟的出现和时间戳可选项的利用，这3个限制可以被消除。但如何对这些新的能力更好的确定RTO估计器呢？

对于BSD版的TCP实现，因为在任何时间内只对一个报文段和它的响应计时，所以每RTT时间内仅对RTO和RTTVAR修改一次。所有的测量都使用时钟粒度。RTO被限定在RTOmin和RTOmax间，在BSD实现中，时钟粒度G=0.5秒，RTOmin=2G=1秒，RTOmax=64秒。因为测量使用时钟粒度是非常粗略的，所以RTOmin没有设置为0。

对RTO估计器的实现的3个常建议的变化是：

1． 为每一个段的RTT计时，而不是仅对一个flight做一个RTT计时。

2． 使用较小的时钟粒度。

3． 降低RTOmin，以便花费更少的时间等待超时。

RTOmin的设置对RTO估计器性能的好坏有非常重要的影响。一般RTOmin被设置成两个时钟滴答，原因是一个时钟滴答可能是0~G秒的任何一个时间。但这样的设置是保守的，因为实际的BSD实现使用的超时在0.5到1秒之间。而对于G=1毫秒的情况，这样的RTOmin又显的太大，也会产生重要的影响。

时钟粒度越粗略，它就无法监视RTT的变化，而时钟精度越精密，估计器就越能反应变化。

坏的超时反应了RTT比RTO小的多或RTO小于或略大于RTT。坏的超时的影响：它不仅使有用的吞吐率遭受损失，而且更严重的是把SSTHRESH减半，开始一个新的慢启动。另外因为TCP要发送重传的包，除非使用TCP时间戳可选项，否则它不能安全的测出那些包的RTT，因此为了改进它的中断的RTT估计使TCP能够适应它的RTT估计需要花很长时间。

解决这一坏的超时问题的方法是：如果TCP使用了时间戳可选项，它能够记住上一次重传的SSTHRESH和cwnd，从而能够在发现超时没有必要时恢复它们。如果没有时间戳或SACK，可采用下列启发式思想：无论什么时候，当由于RTO引起TCP重传时，测量△T，它是从重传开始到收到ACK的时间间隔，如果△T比迄今测量的RTT的最小值都小，那么可以推断ACK已经在重传发送之前就被传送，那么超时就是坏的，若ACK来在最小超时之后，说明超时可能是必要的。

TCP在不知道网路带宽的情况下，必须形成对带宽的一个估计。具体做法是指数级增加发送速率直到出现包丢失。包丢失表明发送速率太大，因而速率减半，以更保守的方式增加。如果我们用SSTHRESH能够给出连接的可利用的带宽的精确估计，拥塞避免用于探测另外的带宽，即以保守的线性增加的方式增加cwnd，就可以提高带宽的利用率。

 

2．5  TCP应用于非对称的网络中性能严重降低

在现代的网络中，带宽不对称是经常的，即在一个方向上的带宽跟在另一个方向上的带宽差一个或几个数量级。这样在高带宽方向上，TCP的传输性能将会大大受到在相反方向上的响应包的延迟的影响而锐减。卫星链路就是非对称的，下行带宽要比上行带宽宽的多。

如果从接收端到发送端的带宽非常有限，那么一个响应可能要在接收端的传输点经历很长的排队时延，这会减慢TCP发送端的发送处理，降低吞吐率。因而在非对称的网络中，TCP连接的下行流就受到影响，尤其是在上行流已经占用了很大部分的带宽的情况下，几乎没有剩余的带宽供响应（ACK）利用，从而更恶化了下行传输。

解决这些问题的方法有：

1． 在每一个连接的上行流管理一个包队列。这使得各响应有平等的机会被传输而不被多个大的数据包延迟。

2． 慢启动后延迟响应。即在慢启动后缩减响应的数量，对几个包发送一个响应。这在慢速启动前是不可取的，因为cwnd的增加依赖于每一个响应，延迟响应就意味着cwnd增加速度放慢，这会降低连接的性能。因此在cwnd较小时，响应频率高一些，而在cwnd较大时响应频率低一些就可以。

3． 响应过滤，也是一种延迟响应的方法，但它取决于发送方发送的速度，发送的快，返回的响应就少，发送的慢，返回的响应就多。而且响应是预先产生，在发送方发送速度快时就把原生成的响应修改为对现在的数据段的响应，因而称其为过滤。

4． 依赖于拥塞窗口响应，即接收方跟踪发送方的cwnd，然后根据cwnd决定响应的速度。

5． 头压缩，因为发送的好多包都有很多相同的字段值，因而可以对两边的协议做一修改，使得接收端发送的响应只有少量的不相同的数据，然后在发送端自动恢复。这样就可以节省带宽。

这些方法在一定程度上都可改善非对称网络的下行传输的性能，但由于涉及到的修改工作的复杂程度各不相同，我们需要从中筛选一种较好的。第4中方法就比较好，因为它仅需要修改接收端，并且实现起来也不复杂。那么如何在接收端估算发送端的cwnd呢？方法是：由于只要RTT比发送端发送窗口内的数据段发送所需时间大很多的话，TCP发送端是完全可能在一个RTT时间内发送接近于窗口内的包数的包的。这样接收端就可以通过计算在RTT内接收到的包数来估计发送端cwnd的大小，这里又涉及到RTT的估计。对于RTT的估计，下面列出了几种方法：

1． 如果接收端也在发送数据包，那么RTT可以从接收端的TCP发送进程获得。

2． 在建立TCP连接时，通过计时SYN（SYN报文段），SYNACK(SYN报文段响应)来估算RTT。这是对RTT的粗略估计。

3． 接收端的ICMP发送带时间戳的echo请求，导致发送端的ICMP发送echo响应，那么RTT的值就可从请求与收到的响应的时间间隔估算。

4． 通过使用TCP时间戳可选项（这最初是由TCP发送端来估算RTT的）。发送端在每一个数据段设置一个时间戳，接收端在响应中回送那个时间戳。这样发送端仅做减法就可以精确估算RTT。

方法1依赖于应用程序，如果应用程序没有要发送的数据包，方法就不可用。另外，由于带宽不对称，发送上行流的发送端测量的RTT要比发送下行流的发送端测量的RTT要大。方法2只在连接开始时测量RTT，而RTT是随时间变化的，因而使用从连接开始时测量的1次或2次值是不够的。方法3需要发送另外的包，但开销是合理的，而且几乎所有的主机都响应echo请求，因而它可以很容易地使用。方法4要求两边都支持TCP时间戳可选项，而旧的实现不支持这一特色（TCP时间戳可选项在将来会成为标准）。另外有时发送端没有数据要发送，因而接收端就不可能收到时间戳响应。

对RTT的估计可以采用方法1，在终端没有数据要发送再时采用方法3 。

根据测量的cwnd——est_cwnd，采用的响应策略：

ppa = 1,                       当est_cwnd <= min_ack_per_win

               MIN ( FLOOR (est_cwnd / min_ack_per_win), max_packets_per_ack ), 其他

其中ppa(the numbers of packets per acknowledge)是每一个ACK响应的包数)，min_ack_per_win = 3，max_packets_per_ack大于5。限制每一个ACK响应的包数有两个原因：

1． 每一个ACK响应的包数大会意味着接收端会抑制许多传输机会，这会降低吞吐率。

2． 如果每一个ACK响应的包数较大，每个响应将响应许多包。这可能会导致发送端发出迸发包，从而导致网络中包丢失。

这种对TCP的改进非常简单，但却能提高TCP在非对称网络中的传输性能，在卫星这种高代价的链路中，它是非常好的提高性能的一种方法。

2．6  基于TCP/IP协议实现的路由器的拥塞控制机制的缺憾

TCP/IP的设计基于这样一个假定：best-effort，即所有应用是协作的，采用相同的端到端拥塞控制机制，路由器采用简单的先来先服务调度算法和尾部丢弃缓存管理算法。但现在一些应用不采用协作方式，如基于UDP的声音、视频应用就是非拥塞响应的，还有一些应用为获的更多带宽而不使用端到端的拥塞控制机制。这样就需要路由器来增强自身的拥塞控制机制。针对这个问题，已经提出好多方法。我们来看看这些方法的优点和不足。

随机提前检测(Random Early Detection)缓存管理方法的缺点是它以相同的概率丢弃所有连接的数据报，这对未获取公平带宽的连接是不利的。

先来先服务调度算法对应于连接的缓存占用量分配带宽，因而它不能有效控制非拥塞响应的连接对带宽的过度占用。

公平排队调度算法可以隔离和保护TCP连接，限制非拥塞响应连接对别的连接的影响，但它只能给排队连接公平分配带宽。因此，还需要配合采用FBD(Fair Buffer Drop)缓存管理算法来限制非拥塞响应连接的数据报在网络拥塞时过度的占用缓存，来保证TCP连接公平地占用缓存。

       尾部丢弃算法是缓存占满时，路由器丢弃每个新接收的数据包。它的优点是实现非常简单，但缺点是网络拥塞时，路由器丢弃突发而来的数据报，使链路利用率急剧下降。

       随机提前检测算法使路由器设置两个缓存门限参数low和high，把拥塞控制过程分为正常运行、拥塞避免和拥塞控制三个阶段。随机提前检测路由器将计算平均缓存队列长度，如果平均缓存队列长度小于low，为正常运行阶段，路由器不丢弃数据包；若平均队列长度超过low但小于high就为拥塞避免阶段，路由器就按照一个随平均缓存长度递增的概率丢弃每个接收到的数据包，如果平均缓存队列长度进一步增加并超过high，则为拥塞控制阶段，路由器将丢弃每个新接收到的数据包。

       尾部丢弃算法和随机提前检测算法对各数据包采用相同的丢弃策略，当存在非拥塞响应连接时，它们不能有效隔离和保护TCP连接。这样非拥塞响应连接将阻止TCP连接的数据包排队，而使公平排队调度算法难以发挥作用。

       因此有必要对各个连接分别进行缓存管理，即路由器按照各连接分配缓存，当缓存占满时，根据各连接占用缓存情况，对各连接的数据包采用不同的丢弃策略，这样，一方面可以限制连接过分使用缓存，如网络拥塞时丢弃非拥塞响应连接的数据包来保证TCP连接能公平使用缓存；另一方面路由器仅丢弃少量数据包，可使连接利用率保持相对稳定。

2．7  操作系统内部的保守的TCP/IP协议的实现

报文处理的时间开销是由报文的大小决定的。大报文的处理时间主要决定于数据接触操作所消耗的时间，如拷贝和计算校验和，因为这些操作必须应用于每一个数据字节。小的报文只有少数几个数据字节，因而大部分处理时间用于非数据接触操作，如数据结构处理、错误检查、网络缓存管理、操作系统函数和特定协议的处理等。数据接触操作开销时间随报文的大小呈线性变化，而非数据接触操作开销的时间相对稳定。对于大报文，校验和的计算要占据整个报文处理时间的将近一半。现在的固定网络传输介质的可靠性是非常高的，同时在协议的每一层都有数据出错处理，这显得有点重复。另外经过大量的实验数据证明，在不计算校验和的情况下，网络的工作状况仍然非常好，因而有必要降低甚至消除大部分校验和处理。消除大部分校验和处理而不牺牲可靠性是能够很大程度上改善吞吐率的。对于非数据接触操作的时间开销是很难削减的，因为该时间几乎遍布于所有的操作，因此要实现这种开销时间的节省需要优化许多不同的机制。分段也会导致更多的非数据接触时间开销。对于大的报文段，网络缓存管理也需要较大的开销，因为在大部分TCP/IP实现中，采用了BSD版的网络缓存管理方法，即使用mbuf结构进行内存分配，每一个只有128个字节，如果数据报大的话，可能需要调用好多次mbuf结构的内存分配算法，才能容纳下大的数据报，因而要消耗较多的时间。如果采用更好的网络缓存管理办法，如采用较大的mbuf，在一定程度上能够降低非数据接触操作的时间开销，提高TCP/IP协议的性能。

3．基于TCP/IP协议网络的安全问题

由于TCP/IP协议一开始的实现主要目的是用于科学研究的，所以很少考虑安全性方面的东西。但随着其应用的普及，它已经成为了Internet网络通信协议的标准。它不仅用于一些要求安全性很高的军事领域，而且也应用于商业领域。因而对其安全性的要求越来越高。现在虽然已经出台好多安全性方面的解决方案，但它们大部分都是治标不治本。我们从TCP/IP协议本身来看它的安全漏洞，以便为我们的预防提供参考。

基于TCP/IP协议的网络存在的安全问题包含：运行协议的操作系统的网络安全漏洞，防火墙自身也存在安全性问题，网络内部的用户的威胁，TCP/IP协议簇本身存在老多安全隐患。下面我们从各协议层来看存在的安全漏洞：

1． 链路层存在的安全漏洞：我们知道，在以太网中，信道是共享的，任何主机发送的每一个以太网帧都会到达别的与该主机处于同一网段的所有主机的以太网接口，一般地，CSMA/CD协议使以太网接口在检测到数据帧不属于自己时，就把它忽略，不会把它发送到上层协议（如ARP、RARP层或IP层）。如果我们对其稍做设置或修改，就可以使一个以太网接口接收不属于它的数据帧。例如有的实现可以使用杂错接点，即能接收所有数据帧的机器节点。解决该漏洞的对策是：网络分段、利用交换器，动态集线器和桥等设备对数据流进行限制、加密（采用一次性口令技术）和禁用杂错接点。

2． 网络层漏洞：几乎所有的基于TCP/IP的机器都会对ICMP echo请求进行响应。所以如果一个敌意主机同时运行很多个ping命令向一个服务器发送超过其处理能力的ICMP echo请求时，就可以淹没该服务器使其拒绝其他的服务。另外，ping命令可以在得到允许的网络中建立秘密通道从而可以在被攻击系统中开后门进行方便的攻击，如收集目标上的信息并进行秘密通信等。解决该漏洞的措施是拒绝网络上的所有ICMP echo响应。

3． IP漏洞：IP包一旦从网络中发送出去，源IP地址就几乎不用，仅在中间路由器因某种原因丢弃它或到达目标端后，才被使用。这使得一个主机可以使用别的主机的IP地址发送IP包，只要它能把这类IP包放到网络上就可以。因而如果攻击者把自己的主机伪装成被目标主机信任的友好主机，即把发送的IP包中的源IP地址改成被信任的友好主机的IP地址，利用主机间的信任关系（Unix网络软件的开发者发明的术语）和这种信任关系的实际认证中存在的脆弱性（只通过IP确认），就可以对信任主机进行攻击。注意，其中所说的信任关系是指一个被授权的主机可以对信任主机进行方便的访问。所有的r*命令都采用信任主机方案，所以一个攻击主机把自己的IP改为被信任主机的IP，就可以连接到信任主机并能利用r*命令开后门达到攻击的目的。解决这个问题的一个办法是，让路由器拒绝接收来自网络外部的IP地址与本地某一主机的IP地址相同的IP包的进入。

4． ARP欺骗：ARP协议在对IP地址进行解析时，利用ARP缓存（也叫ARP表）来做。ARP缓存的每一条目保存有IP地址到物理地址的映射。如果在ARP表中没有这样的对应条目，ARP协议会广播ARP请求，获得对应于那个IP地址的物理地址，并把该对应关系加入到ARP表中。ARP表中的每一个条目都有一个计时器，如果计时器过期，该条目就无效，因而被从缓存中删除。显然，如果攻击者暂时使用不工作的主机的IP地址，就可以伪造IP-物理地址对应关系对，把自己伪装成象那个暂时不使用的主机一样。克服此问题的方法是，让硬件地址常驻内存，并可以用ARP命令手工加入（特权用户才可以那样做）；也可以通过向RARP服务器询问来检查客户的ARP欺骗。因为RARP服务器保留着网络中硬件地址和 IP的相关信息。

5． 路由欺骗：在路由协议中，主机利用重定向报文来改变或优化路由。如果一个路由器发送非法的重定向报文，就可以伪造路由表，错误引导非本地的数据报。另外，各个路由器都会定期向其相邻的路由器广播路由信息，如果使用RIP特权的主机的520端口广播非法路由信息，也可以达到路由欺骗的目的。解决这些问题的办法有，通过设置主机忽略重定向信息可以防止路由欺骗；禁止路由器被动使用RIP和限制被动使用RIP的范围。

6． DNS欺骗：网络上的所有主机都信任DNS服务器，如果DNS服务器中的数据被攻击者破坏，就可以进行DNS欺骗。

7． 拦截TCP连接：攻击者可以使TCP连接的两端进入不同步状态，入侵者主机向两端发送伪造的数据包。冒充被信任主机建立TCP连接，用SYN淹没被信任的主机，并猜测3步握手中的响应（建立多个连接到信任主机的TCP连接，获得初始序列号ISN(Initial Serial Number)和RTT，然后猜测响应的ISN，因为序列号每隔半秒加64000，每建立一个连接加64000）。预防方法：使所有的r*命令失效，让路由器拒绝来自外面的与本地主机有相同的IP地址的包。RARP查询可用来发现与目标服务器处在同一物理网络的主机的攻击。另外ISN攻击可通过让每一个连接的ISN随机分配配合每隔半秒加64000来防止。

8． 使用TCP SYN报文段淹没服务器。利用TCP建立连接的3步骤的缺点和服务器端口允许的连接数量的限制，窃取不可达IP地址作为源IP地址，使得服务器端得不到ACK而使连接处于半开状态，从而阻止服务器响应响应别的连接请求。尽管半开的连接会被过期而关闭的，但只要攻击系统发送的spoofed SYN请求的速度比过期的快就可以达到攻击的目的。这种攻击的方法一直是一种重要的攻击ISP（Internet Service Provider）的方法，这种攻击并不会损害服务，而是使服务能力削弱。解决这种攻击的办法是，给Unix内核加一个补丁程序或使用一些工具对内核进行配置。一般的做法是，使允许的半开连接的数量增加，允许连接处于半开状态的时间缩短。但这些并不能从根本上解决这些问题。实际上在系统的内存中有一个专门的队列包含所有的半开连接，这个队列的大小是有限的，因而只要有意使服务器建立过多的半开连接就可以使服务器的这个队列溢出，从而无法响应其他客户的连接请求。

4．结束语

TCP/IP协议的两个最重要的协议是TCP协议和IP协议，我们着重从TCP协议入手分析了它的慢速启动算法，延迟响应和固定增益与偏差权值的RTO估计器等对TCP性能的影响，提出了一些应对措施，另外，就安全问题也作了详细分析，对大部分问题给出了预防对策。虽然这些应对措施和解决策略中的一些可能是权宜之策，但在很大程度上，他们确实能够解决目前所面临的问题。在文中描述的那个新的RTO估计器没有在广泛的环境中经过大量的实验论证，因而距离正式使用还有待更进一步的研究和改进。在将来，移动主机和无线链路会迅速增加，而目前对TCP/IP的大量研究主要基于固定的有线网络，因而对TCP/IP在无线应用中的研究是一个非常有挑战性的工作，我们下一步要做的工作就是在这方面的研究，主要是给出整体的解决方案。

参考文献：

[1] George Xylomeros and George C. Polyzos. Internet Protocol Performance over Networks with Wireless Links, IEEE NETWORK, Vol. 13, No. 4, July/Aug 1999.

[2] Chris Hayes and Shawn Ostermann. An Evaluation of TCP with Larger Initial Windows, Computer Communication Review, Vol. 38, No. 3, July 1998.

[3] 赵季中, 宋政湘, 齐勇. 对基于TCP/IP协议的几个网络安全问题的分析与讨论, 计算机应用研究, 第17卷, 第5期, 2000.5.

[4] 陈依群, 顾尚杰, 诸鸿文. 一个基于连接的增强拥塞控制机制, 计算机研究与发展, 第37卷, 第3期, 2000.3.

[5] Jeong Geun Kim and Marwan M. Krunz. Bandwidth Allocation in Wireless Networks with Guaranteed Packet-Loss Performance, IEEE/ACM Transaction on Networking, June 2000, Vol. 8, No. 3.

[6] Jonathan Kay and Joseph Pasquale. Profiling and Reducing Processing Overheads in TCP/IP, IEEE/ACM Transaction on Networking, December 1996, Vol. 4, No. 6.

[7] Reiner Ludwig and Keith Sklower. The Eifel Retransmission Timer, Computer Communication Review, Vol. 30, No. 3, July 2000.

[8] Ivan Tam Ming-chit, Du jinsong and Weiguo Wang. Improving TCP Performance Over Asymmetric Networks, Computer Communication Review, Vol. 30, No. 3, July 2000.

[9] Andras G. Valko. Cellular IP:A New Approach to Internet Host Mobility, Computer Communication Review, Vol. 29, No. 1, January 1999.

[10]  Macro de Vivo, Gabriela O. De Vivo and Germinal Isern. Internet Vulnerabilities Related to TCP/IP and T/TCP, Computer Communication Review, Vol. 29, No. 1, January 1999.

[11]  Mark Allman. TCP Byte Counting Refinements, Computer Communication Review, Vol. 29, No. 3, July 1999.

[12]  Mark Allman and Vern Paxson. On Estimating End-to-End Network Path Properties, Proceedings of ACM/SIGCOMM’99 CONFERENCE, Computer Communication Review, Vol. 29, No. 4, October 1999.

[13]  RFC 2581 TCP Congestion Control, April 1999.

[14]  RFC 2018 TCP Selective Acknowledgement Options, October 1996.

[15]  RFC 2582 The New Reno Modification to TCP’s Fat Recovery Algorithm,April 1999.