信息天堂

理解和使用ICMP协议

随着本讲座开始接触涉及路由的层，我们必须暂时停一下。我们需要关注一下最容易误解的协议:ICMP(互联网控制消息协议 )。经理人和网络管理员如果计划制定防火墙决策就要了解ICMP协议的真正用途，而且网络管理员要能够使用ICMP协议的知识全面理解路由问题。

　　既然IP网络不可靠并且不能保证信息传递，因此当发生问题时通知发送人是很重要的。ICMP协议是一种提供有关阻止数据包传递的网络故障问题反馈信息的机制。 它让TCP等上层协议能够意识到数据包没有送达目的地，ICMP协议提供一种查出灾难性问题的方法。这些灾难性的问题包括“TTL exceeded”(超过生存时间)和“需要分更多的数据段”等。ICMP协议不报告IP校验失败等常见的问题。这是因为我们假定TCP或者其它可靠的协议能够处理这类数据包损坏的问题。而且，如果我们使用UDP等不可靠的协议，我们就不应理会较小数量的数据损失。

　　反之，网络问题需要立即报告。例如，如果IP TTL值(IP生存时间)将达到零，这就可能是网络的某个部分发生了路由环路问题，这样将没有任何数据包能发送到目的地。端点系统需要了解这些类型的故障。ICMP是一种发送各种消息报告网络状态的协议，而非仅仅是简单的ping(联通性测试程序)。回应请求（echo request）仅是ICMP协议提供的众多消息之一。Ping信息可以被过滤掉。但是，大多数ICMP消息类型是IP、TCP和其它协议正常运行所需要的。永远不要相信ICMP协议是邪恶的并且简单的封锁这个协议。

　　ICMP协议本身非常复杂。每一种类型的ICMP消息也称“主要类型（major type）”拥有自己的“子类型编码（minor codes）”。ICMP协议工作在第3层，因此，它能够在互联网上路由。一个ICMP数据包实际上就是一个IP数据部分包含ICMP协议数据的IP数据包。每一个ICMP消息都将包含引发这条ICMP消息的数据包的完全IP包头，这样，端点系统就会知道实际上哪一个数据包没有发送到目的地。另外引发此ICMP消息的数据包的前8个字节也将包括在内，这通常是TCP或者UDP包头。

　　简略的说，ICMP协议消息包含永远不会变化的三个字段，随后是ICMP数据，然后是引发此消息的源IP数据包包头。不会变化的三个字段中，前8个字节包含ICMP类型(主要类型)、第二个字段包含了类型代码、第三个字段是ICMP消息校验值。

　　我们需要认识到，ICMP协议在某些情况下不会发送错误信息。ICMP不会对ICMP信息做出响应。如果ICMP回应其它ICMP消息，这些消息的数量会爆炸性增长而演变为一场ICMP消息风暴。为了防止出现广播风暴，ICMP消息也不会回应一个广播或者多播地址。

　　最有用的ICMP数据包类型“目标不可达”（类型三）的消息。错误消息一般由路由器生成，并且发送给数据包的来源。大多数错误信息还将发送给与发送的数据包有关的应用程序。在这种情况下，TCP协议将广泛使用ICMP协议。我们在后面将很快看到这种情况。

在IPv4协议中最常用的ICMP消息类型有以下几种:

　　•回显应答(类型0)和回显请求(类型8):这是Ping程序发送的信息。

　　•目标不可达(类型3)

　　•源抑制(类型4):这是一种用于通知发送者路由器或者主机出现阻塞现象的ICMP消息，发送者需要降低发送速度。

　　•重定向(类型5):这个消息用来向可以访问两台路由器的主机说“请使用另一台路由器”。我们在此系列讲座中未来的路由问题中再详细讨论这个问题。

　　•路由器信息应答(类型9)和路由器信息请求(类型10)

　　•超时(类型11):这个消息有两种用途。第一，当超过IP生存期时向发送系统发出错误信息。第二，如果分段的IP数据报没有在某种时限内重新组合，这个消息将通知发送系统。

　　当然，上述各种类型的消息中都包含子类型代码。类型三消息“目标不可达”本身有15个子类型代码。我们就不提供每一项的细节了。但是，ICMP协议中有一项非常重要的应用要依靠类型三的消息。

　　路径最大传输单元(PMTU)是各种协议用来寻找整条路径中支持的最大的MTU(最大传输单元)的机制，小于此限制的数据可以不用分段。发送者在其本地接口设置最大的数据包规格，然后，在IP包头中使用DF(不要分段)的标记发出数据包。如果有问题发送者就会收到第三种类型的ICMP错误信息，其子类型代码是“要求分段，但是已经设置了DF标记”。当发生这种情况是，发送者知道它必须要减小发送数据的规格。如果没有返回错误信息，这就表明MTU的设置没有问题。

　　在查找PMTU时的主要问题是人们常封锁ICMP协议，阻止这个报错信息传递到发送数据的主机。这种情况很多时候发生在你设法连接的远程站点。假如你向一台Web服务器发送一个请求，但是，一个空白页却不断出现。在虚拟专用网连接上的人们经常会看到这种情况，这是因为由于有的虚拟专用网封装的额外的文件头，它们的MTU比通常的容量要小一些。当远程Web服务器向虚拟专用网用户发送其要求的内容时，如果数据包太大，用户前面最后的路由跳数需要为这个数据分段。如果发送方设置DF标记之后，它能做的一切就是通知发送者必须发送较小的数据包。但是，发送者封锁了ICMP协议，因此这个网站将永远不会看到这种ICMP信息。不过一个好消息是大多数TCP协议的执行都是智能化的。如果它们一直得不到发送数据的许可，它们会自己以较小的分段尺寸发送数据。但是，如果你使用某些流行的、操作方便的操作系统，这种机制并没实现。

　　简言之，封锁ICMP协议对于成功地运行网络是有害的。这不仅会破坏ping，事实上，如果ICMP协议不工作，许多协议都将不能完全发挥作用。

　　小结

　　ICMP包括许多种类型的用于各种用途的数据包，每一种类型都有子类型代码，用于指明这些消息类型的具体内容。

　　查找路径最大传输单元能够让规格正确的数据包在各种数据包容量的链路上传送。

　　ICMP对于恰当的路由和数据包传递是非常重要的，你只能封锁你不需要的那一些消息。

IP协议介绍

本文将介绍理解路由问题所需要的IP协议知识。互联网上的大多数东西都使用IP协议。与以太网不同，了解这个协议对于理解网络在更大范围的应用非常重要。在以后发表的文章中，这个讲座将介绍TCP和UDP协议、路由理论、然后再深入研究具体的路由协议。

　　IP协议直接位于2层数据链路层之上，负责生成发往目的地的数据报。IP协议原来在RFC 791中定义，后来进行了修改并且进行了多次重新修订。但是，IP协议的基本设计思想仍没有变。IP层不提供任何类型的流量控制或者排序功能。这些功能留给上层。我们将使用“数据报” (datagram)这个词汇指一个完整的IP信息，使用“数据包”(packet)这个词汇指一个单个的IP数据包。

　　IP协议负责接收和发送指定IP地址数据包。但是，IP协议并不保证数据传递的可靠性。在IP协议层中没有“重试一下”的概念。由于各种原因，数据包有可能出现丢失、损坏、重复、不按照顺序传递或者延迟等问题。IP协议还负责处理IP选项并且以ICMP错误和控制消息等方式提供反馈信息。

　　IP数据报头有20个字节长，紧接在2层报头后面(因为IP协议是第3层协议)。IP数据部分包含一个完整的TCP或者UDP数据包等一切其它的信息，如下面的图表所示。还要指出的是，如果使用IP选项，IP数据报头可以超过20个字节。

　　IP协议的目标很简单:生成发往目的地的数据报，而且除了把这个数据包发送到下一跳路由器之外，不需要担心任何事情。实际上，IP协议很复杂，否则，IP数据报头就不需要那么多的字段。认真研究IP数据报头是非常重要的。这些字段从第一个字节开始的含义是:

　　•版本:使用的IP协议的版本。IPv4数据包将把这个字段设置为“4”。

　　•报头长度:以4个字节的倍数的方式说明报头的长度。因为很少使用IP选项功能。因此，你很可能你看到它的值将是“5”，意味着报头的长度是5个4字节，也就是20个字节。

　　•服务类型:这个字段很少使用。但是，在理论上，这个字段旨在向路由器提供转发队列中特定IP数据报优先级顺序信息。主要用于提高服务质量。主机可以选择设置各种选项，如低延迟、高数据吞吐量或者高可靠性等。大多数路由器都忽略这些选项。

　　•总长度:以字节为单位具体说明包括报头在内的整个IP数据包的总长度。因为这个字段有16位，所以IP数据包长度限制在65K之内。这个数字定义的是字段所在的IP数据包，而不是整个IP数据报的长度。

　　•IP数据报ID:有时候称作“段标识符”。这个标识符用来确定一个具体的IP数据包属于哪一个IP数据报。如果IP协议需要把多个单个的IP数据包组合成一个IP数据报，这个字段是必要的。

　　•标志:DF(不分片)位在这个字段中用来指示路由器不要把IP数据包分段。这里也可以使用MF(更多地分片)标识。

　　•段内偏移量:原来数据报中的分段的偏移量，用64位的块表示。

　　•生存时间(TTL):IP数据包在被销毁之前包含的跳数。生存时间是为了避免无法发送的数据包永远在互联网上流动。

　　•协议类型:具体指明下一个协议。也就是在IP数据包的数据部分中将遇到的报头。

　　•头校验和:一个报头的校验和，而不是数据的校验和。

　　•IP源:原来发送数据包的主机的IP地址。

　　•IP目的地:IP数据包目的地主机的IP地址。

当路由器收到一个IP数据包的时候，路由器首先要检查这个数据包的目的地。如果这台路由器有一个通向目的地的路由，这台路由器将减少这个数据包的TTL，重新计算校验和，然后再把这个数据包发出去。如果出现错误，将会发出相应的ICMP错误通知，这个数据包将被丢弃。IP协议就是以这种最简单的方式工作的:它遇到每一个数据包都要重复上述的步骤。

　　IP分段对于IP功能是非常重要的，它提供了这些报头字段的真正含义。并非每一个发送数据包的物理网络都能够接受同样大小的数据包。各种各样的2层帧格式允许同时发送不同大小的数据。允许的最大的MTU是65KB，最小的是68字节。RFC 1122规定，所有的主机必须能够重新组合最多为576字节的数据报，但实际上是应该能够重新组合与系统接口的MTU规格相同的数据报。

　　当在互联网上发送一个IP数据报的时候，你不知道沿着每一个2层链路前进的MTU将发生什么情况。你可能通过以太网连接自己的ISP。但是，你正在设法访问的远程站点也许是在一个ISDN链路上。因此，你的IP数据包在到达最后一个跳点之前必须要分段。分段可能需要进行多次。如果我们要向一个通过ISDN连接的远程站点发送一个2000个字节的数据包，我们原来可能把这个数据包分段以便符合我们的1500个字节的链路要求。但它大于576字节(ISDN的MTU)。因此，在到达ISDN链路之前的最后一个路由器必须还要对这个数据包分段。

　　应该知道，IP不是一个可靠的协议。因此，如果任何IP分段在传输的路径中丢失，整个数据报必须要重新发送。IP没有办法要求得到数据报中丢失的特定部分。因此，当出现错误时，其结果是重新发送该数据报所有的分段。有时候，阻塞的路由器不得不丢弃一些数据包。如果被丢弃的数据包恰巧是一个65KB数据报的一部分，那么，整个数据报必须要重新发送。TCP或者其它上层协议一般都知道一个完整的数据报是否全丢失了，并且能够要求重新发送。然而，TCP协议不能告诉你一个数据报的片段是否丢失了，因为IP收到数据报将是不完整的，并且永远不会向上层TCP协议发送这个数据报。如果TCP协议从来没有收到这个数据报，这个数据报最终将被重新发送。显然，65K数据包的一小部分的丢失对于缓解一个阻塞的链路并没有什么帮助，而是会引起更严重的阻塞。UDP应用程序发送时的大小一般不超过576字节，这有两个原因。第一，MTU小于576字节的链路并不多，因此，这个IP数据报将不会分段。第二，要记住，576是所有采用IP协议的端点系统的特殊数字:它们必须能够把数据报重新组合为这个大小。配置有限内存的设备对于处理大于这个规格的数据可能会遇到困难，因此，这个做法值得推荐。

　　假设我们是一台主机，我们想发送一个1550个字节的数据报(1530个字节的数据+20个字节的报头)。但是，我们的MTU是1500个字节。我们必须要分为两个数据包发送，相关的IP报头看起来是这样的:

　　• fragment 0, offset = 0, size = 1480, MF位设置.

　　• fragment 1, offset = 1480, size = 50

　　分段中的IP ID和IP地址总是与原来IP数据报中内容是一样的。但是，报头的校验值、偏离量和字段长度肯定要发生变化。当另一方收到第一个数据包并且看到这个数据包是一个分段的时候，另一方将等待获得其它的分段，并且把这些分段重新组合在一起，然后再发送给上层协议。

　　在这个数据报发出之后，假如在IP标志中没有设置DF字节，我们就不会听到任何有关这个数据报的消息。但是，如果这个链路的某一个地方的MTU是400字节会发生什么情况呢?在可以发送1480字节的数据包之前，这个链路中的路由器会先对这个数据包分段。上一篇教程的MTU路径可用来解决中间路由器为数据包分段的问题。分段要耗费时间和宝贵的路由器资源。我们避免过度分段的主要原因就是因为过度分段将不可避免地引起通信的延迟。

　　对数据包的重新组合总是在最后的目的地完成。因此，中间路由器不需要存储IP数据报。这也意味着IP数据包能够在不同的路径上单独地路由，而不会引起混乱。这是一个需要理解的重要的概念。这将使IP协议有多种用途。无论接收方以什么顺序收到这个数据包，接收方都能够根据IP报头中的分段偏移量字段重新把数据报组合起来。

　　现在，我们理解了分段。我们发现分段提出了这样一个问题:IP真的与数据链路层无关吗?

　　小结

　　IP协议是不可靠的。当IP数据包丢失的时候，要更高一层的协议认识到数据包的丢失并且要求重新发送。

　　路由器在每一次发送IP数据包的时候都必须要重新计算IP报头的校验值。

　　IP分段能够让路由器延迟发送一个数据包或者在多个链路上发送数据包。端点系统将能过重新组合整个IP数据报。

TCP协议介绍

仅仅介绍为了让你理解下一篇关于TCP协议的讲座所需的知识。经过本文的学习你会了解一些TCP相关的术语，理解TCP包头的各组成部分，然后，我们将在后面一篇文章中重点讲解TCP协议常见的一些问题，包括TCP窗口可伸缩性问题、阻塞和TCP连接机制等问题。

　　我们有时候听到人们提到“TCP/IP协议栈”。这意味着他们在谈论1至4层和7层的问题，TCP协议位于第四层。其代表的含义是传输控制协议(Transmission Control Protocol)。还记得IP协议那篇文章中的协议头的构成吗?当一个数据包被封装之后，第三层当然有个IP协议头，紧接着就是这个TCP协议头。TCP协议头成为了IP协议头中的“数据”。就像其它协议都有自己的术语一样，TCP协议也有自己的专门术语，如以太网帧、IP数据报和现在的TCP段等。你可以把它们都当作数据包。但是，当它们之间在进行通讯的时候，一定要使用正确的术语。

　　TCP协议是一种端对端的协议。使用TCP没有任何广播或类似的概念。要用TCP协议与另一台计算机通信，两台机之间必须像打电话一样连接在一起，每一端都都为通话做好准备。“流传输”(Stream delivery)是谈到TCP时的另一个常用词语。这个短语的含义是TCP协议主要用来处理数据流，可以正确处理乱序的数据包。TCP协议甚至还允许存在丢失的或者损坏的数据包，最终它可以再次得到这些数据包。你很可能听一位程序员在谈论“流”的概念。他指的是这样一个事实:数据到底是在什么时候发送的是很难说清楚的，你也可以在TCP流中发送非结构化数据。TCP协议以它自己的方式缓存数据。不过，其缓存过程对程序员和用户是透明的。

　　TCP协议每发送一个数据包将会收到一个确认信息。这种发送/应答模式是提供可靠的协议的唯一方法:你必须让对方知道你否收到了数据。当然，这也会造成一些性能损失，而人们需要改善系统效率不高的状况。所以引入了“捎带确认（piggybacking ACKs）”的方法。TCP协议之所以是全双工的就是因为这个“捎带确认”信息，因为它允许双方同时发送数据。这是通过在当前的数据包中携带以前收到的数据的确认信息方式实现的。从提高网络利用率的角度看，这比单纯发送一个通知对方“信息已收到”的数据包要好得多。最后，还有一个批量确认的概念：也即一次确认一个以上的数据包，表示“我收到了包括这个数据包在内的全部数据包”。

　　在IP协议中，我们处理的单个数据包是一个更大的数据报的一部分。请记住，一个TCP段就是一个单个的TCP数据包。TCP是一个数据流，因此，除了“连接”之外，没有任何需要真正担心的其它概念。最大报文段长度(MSS)是在连接的时候协商的，但是，它总是在不断地改变。默认的最大报文段长度是536字节，这是576字节(IP协议保证的最小数据包长度)减去用于IP头的20个字节和用于TCP头的20个字节以后的长度。TCP协议要设法避免在IP级别上的分段。因此，TCP协议总是从536字节开始的。

　　TCP协议最有魅力的功能仍然保留着。这就是滑动窗口协议。这个窗口实际上是已经发出的“没有签收确认的”数据总数。这个窗口可以根据意愿放大和缩小。这是很有趣的。下一讲将介绍这方面的内容。

　　一个TCP数据包的头是20个字节，就像一个IP数据包一样。如果使用一些选项，IP和TCP数据包头都可以放大。TCP头不包含IP地址，它仅需要知道要连接哪一个端口。不过，你不要被这弄晕了。TCP工作时要一直跟踪状态表中的端对端的连接。这个状态表包含IP地址和端口。这就是说，只是TCP头不需要IP信息，因为它来自于IP头。

　　把一个数据包设想为一个字节跟着一个字节的数据流是很容易的。很多人都想要一个显示TCP头的表格。但是，这常会把事情搞乱。TCP头从第一位开始依次是下面这些内容:

　　•源端口，16位:用于这次连接的本地TCP端口。

　　•目的地端口，16位:通讯目标机器的TCP端口。

　　•序列号，32位:用来跟踪数据包顺序的号码。

　　•确认编号，32位:我们确认的以前收到的序列号。

　　•头长度，4位:报头中的32位字(words)的数量。如果不使用选项，这个值设定为5。

　　•保留，6位:为将来的使用保留的字节。

　　•标记，一共6位:每一个标记一个字节(开或者关)

　　-URG:紧急字段指针。

　　-ACK:本数据包是(或者包含)一个确认信息。

　　-PSH:推送功能(没有使用)。

　　-RST:重置，或者中断本次连接。

　　-SYN:同步数据包，也就是开始连接。

　　-FIN:最后一个数据包，开始挂断序列。

　　•窗口尺寸，16位:从接收方将收到的确认字段开始。

　　•校验和，16位:TCP头和数据的校验和。

　　•应急指针，16位:指向跟在URG数据后面的数据的序列号的偏移值。

　　•选项:MSS、窗口比例等等。我们在关于TCP协议的下一讲中将重点介绍这个部分。

　　TCP连接的两端使用两对IP地址和端口识别这个连接，并且向监听这个端口的应用程序发送数据。

现在我们来介绍一下TCP协议的运行问题，因为我们对TCP协议实际上是什么样子知道的并不多。

　　我们说过，TCP协议在能够发送数据之前就建立起了“连接”。要实现这个连接，启动TCP连接的那一方首先将发送一个SYN(回忆一下在上一篇文章中讲到的TCP包头格式)数据包。这只是一个不包含数据的数据包，然后，打开SYN标记。如果另一方同时在它收到SYN标记的端口通话，它将发回一个SYN+ACK:SYN和ACK标志位都被打开，并将ACK(确认)编号字段设定为刚收到的那个数据包的顺序号字段的值。接下来，连接发起方为了表示收到了这个SYN+ACK信息，会向发送方发送一个最终的确认信息（ACK包）。这种SYN、SYN+ACK、ACK的步骤被称为TCP连接建立时的“三次握手”。在这之后，连接就建立起来了。这个连接将一直保持活动状态，直到超时或者任何一方发出一个FIN(结束)信号。

　　任何一方都可以关闭一个TCP连接，要求双方发送一个FIN信号关闭自己的通讯频道。一方可以在另一方之前关闭，或者双方同时关闭TCP连接。因此，当一方发送一个FIN信号时，另一方可发送“FIN+ACK”，开始关闭自己一方的通信并且确认收到了第一个FIN信号。发送第一个FIN信号的人接下来再发送一个“FIN+ACK”信息，确认收到第二个FIN信号。另一方就知道这个连接已经关闭了，并且关闭了自己的连接。发送第一个FIN的人没有办法收到最后一个ACK信号的确认信息。这时它会进入“TIME_WAIT”(等待时间)状态并启动一个定时器，防止另一方没有收到ACK信息并且认为连接仍是打开的。一般来说，这个状态会持续1至2分钟。

　　现在，我们来讨论第一个问题。如果有人(假如一个黑客)在你的Web服务器上留下一个半开或者半关的连接，那就是一个坏消息。每一个连接都要消耗内存，打开数千个虚假的TCP连接可能导致服务器瘫痪。当然，你实际上不可能在不影响TCP正常工作的情况下调整TCP定时器。如果你听说过TCP SYN 攻击的话，那就是这个意思。为了防止出现这种情况，大多数操作系统都要限制半开连接的数量。例如，Linux默认的限制一般是256个。

　　我们前面提过将讨论关于持续流控制问题，现在我们就来讨论这个问题。TCP中实现它的机制是TCP滑动窗口机制。TCP协议使用“重新发送与正向ACK”来保证数据传输的可靠性。发送方将等待一段时间，如果没有收到其发送的数据包的ACK确认信息，发送方就要重新发送。顺便说一下，TCP协议中有许多定时器。这只是其中一个定时器。ACK的概念对于流控制是非常重要的，因为TCP滑动窗口协议使TCP的往复确认变得更有效率。如果TCP要发送一个数据包并且等待每一个ACK确认信息，它实际上就把数据吞吐量削减了一半。

摘 要：TCP是针对固定网络设计的一种传输协议，其错误控制机制是基于将所有丢包原因都归结于网络拥塞的假设。这种错误控制机制在有线网络上获得了很大的成功；但由于移动计算环境有着明显不同于有线网络环境的特点，如较高的位出错率、可用带宽小、衰减信道等，因此针对传统有线网络设计的TCP协议，其性能受到了很大影响。本文对目前移动计算环境下TCP协议的一些主要改进方案进行了综述，在对这些方案进行分类的基础上，对其优缺点进行了分析，并且对这些方案进行了比较。最后，提出了进一步研究的方向。

1. 引言

互联网最初源于美国国防部的ARPANET计划。在上世纪60年代中期，正是冷战的高峰，美国国防部希望有一个命令和控制网络能够在核战争的条件下幸免于难，而传统的电路交换的电话网络则显得太脆弱。国防部指定其下属的高级研究计划局（ARPA）解决这个问题，此后诞生的一个新型网络便称为ARPANET，其最大特点是采用无连接的端到端包交换服务。随后ARPANET开始与美国国家科学基金会（NSF）建成的NSFNET及加拿大、欧洲和太平洋地区的网络互联。到了80年代中期，人们开始把互联的网络称为互联网。

早在70年代中期，ARPA为了实现异种网络之间的互联与互通，推出了TCP/IP体系结构和协议规范。时至今日，TCP/IP协议也成为最流行的网际互联协议，并由单纯的TCP/IP协议发展成为一系列以IP为基础的TCP/IP协议簇。TCP／IP协议簇为互联网提供了基本的通信机制。

互联网采用的是无连接的端到端数据包交换，提供“尽力而为”（best effort）服务模型的设计机制。这种机制的最大优势是设计简单，可扩展性强。互联网在过去的十几年中经历了爆炸式的增长，这已经充分证明了这种设计机制的成功。然而这种优势并不是没有代价的，随着互联网用户数量的膨胀，网络的拥塞问题也越来越严重。例如由于队列溢出，互联网路由器会丢弃约10%的数据包。据统计，互联网上95%的数据流使用的是TCP/IP协议，因此，互联网上主要的互连协议TCP/IP的拥塞控制（congestion control）机制对控制网络拥塞具有特别重要的意义。拥塞控制是确保互联网鲁棒性（robustness）的关键因素，也是各种管理控制机制和应用（如多媒体通信中QoS控制、区分服务（differentiated services））的基础，因此关于互联网的拥塞控制问题一直是网络研究的一个热点。

TCP是目前Internet上使用最广泛的一种传输协议，根据MCI的统计，Internet上总字节数的95％及总数据包数的90％使用TCP协议传输[25]。TCP的目的是为了解决Internet的稳定性、异质性（接受端缓冲区大小、网络带宽及延迟等）、各流之间享用带宽的公平性、使用效率及拥塞控制等问题，从而为Internet提供可靠、健壮（robust）的端到端通讯。Internet近十年来的迅猛发展已证明TCP协议在设计上是成功的。

但是，TCP是为固定主机及有线网络设计的一种滑动窗口协议，它在位出错率（bit rate error，BER）很低、丢包的主要原因是网络拥塞的传统网络上的成功在移动计算环境下受到了巨大的挑战。移动计算带来的新问题主要是无线链路传输的可靠性、移动操作的特点以及对效率进行评估的性能尺度等。因此，对TCP协议的改进已经成为近几年网络通讯领域的一个研究热点。

本文第二部分对网络拥塞的基本概念进行了简要介绍；第三部分TCP的拥塞控制机制及有线网络环境下的改进进行了介绍；第四部分分析了TCP在移动计算环境下的缺点及其需要增加的功能；第五部分对增强移动环境下TCP的技术方案进行了分类介绍，分析了各自的优缺点，并对这些方案进行了比较。最后进行了总结，并提出了有待进一步研究的一些热点方向。

2. 网络拥塞的基本概念

2.1 拥塞的基本概念和互联网模型

当网络中存在过多的数据包时，网络的性能就会下降，这种现象称为拥塞。在网络发生拥塞时，会导致吞吐量下降，严重时会发生“拥塞崩溃”（congestion collapse）现象。一般来说，拥塞崩溃发生在网络负载的增加导致网络效率的降低的时候。最初观察到这种现象是在1986年10月，在这个过程中，LBL与UC Berkeley之间的吞吐量从32kbps下降到了40bps。Floyd总结出拥塞崩溃主要包括以下几种：传统的崩溃、未传送数据包导致的崩溃、由于数据包分段造成的崩溃、日益增长的控制信息流造成的崩溃等。

 

图1：网络负载与吞吐量及响应时间的关系

对于拥塞现象，我们可以进一步用图1来描述。当网络负载较小时，吞吐量基本上随着负载的增长而增长，呈线性关系，响应时间增长缓慢。当负载达到网络容量时，吞吐量呈现出缓慢增长，而响应时间急剧增加，这一点称为Knee。如果负载继续增加，路由器开始丢包，当负载超过一定量时，吞吐量开始急剧下降，这一点称为Cliff。拥塞控制机制实际上包含拥塞避免（congestion avoidance）和拥塞控制（congestion control）两种策略。前者的目的是使网络运行在Knee附近，避免拥塞的发生；而后者则是使得网络运行在Cliff的左侧区域。前者是一种“预防”措施，维持网络的高吞吐量、低延迟状态，避免进入拥塞；后者是一种“恢复”措施，使网络从拥塞中恢复过来，进入正常的运行状态.

拥塞现象的发生和前面提到的互联网的设计机制有着密切关系，我们对这种设计机制作一个简单的归纳：

1. 数据包交换（packet switched）网络：与电路交换（circuit switched）网络相比，由于包交换网络对资源的利用是基于统计复用（statistical multiplexing）的，因此提高了资源的利用效率。但在基于统计复用的情况下，很难保证用户的服务质量（quality of service，QoS），并且很容易出现数据包“乱序”的现象，对乱序数据包的处理会大大增加拥塞控制的复杂性。
2. 无连接（connectionless）网络：互联网的节点之间在发送数据之前不需要建立连接，从而简化了网络的设计，网络的中间节点上无需保留和连接有关的状态信息。但无连接模型很难引入接纳控制（admission control），在用户需求大于网络资源时难以保证服务质量；此外，由于对数据发送源的追踪能力很差，给网络安全带来了隐患；无连接也是网络中出现乱序数据包的主要原因。
3. “尽力而为”的服务模型：不对网络中传输的数据提供服务质量保证。在这种服务模型下，所有的业务流被“一视同仁”地公平地竞争网络资源，路由器对所有的数据包都采用先来先处理（First Come First Service，FCFS）的工作方式，它尽最大努力将数据包包送达目的地。但对数据包传递的可靠性、延迟等不能提供任何保证。这很适合Email、Ftp、WWW等业务。但随着互联网的飞速发展，IP业务也得到了快速增长和多样化。特别是随着多媒体业务的兴起，计算机已经不是单纯的处理数据的工具。这对互联网也就相应地提出了更高的要求。对那些有带宽、延迟、延迟抖动等特殊要求的应用来说，现有的“尽力而为”服务显然是不够的。

2.2 拥塞产生的原因

拥塞发生的主要原因在于网络能够提供的资源不足以满足用户的需求，这些资源包括缓存空间、链路带宽容量和中间节点的处理能力。由于互联网的设计机制导致其缺乏“接纳控制”能力，因此在网络资源不足时不能限制用户数量，而只能靠降低服务质量来继续为用户服务，也就是“尽力而为”的服务。

 

图2（a） 图2（b）

拥塞虽然是由于网络资源的稀缺引起的，但单纯增加资源并不能避免拥塞的发生。例如增加缓存空间到一定程度时，只会加重拥塞，而不是减轻拥塞，这是因为当数据包经过长时间排队完成转发时，它们很可能早已超时，从而引起源端超时重发，而这些数据包还会继续传输到下一路由器，从而浪费网络资源，加重网络拥塞。事实上，缓存空间不足导致的丢包更多的是拥塞的“症状”而非原因。另外，增加链路带宽及提高处理能力也不能解决拥塞问题，例如，图2（a）中，四个节点之间的链路带宽都是19.2kbps，传输某个文件需要用时5分钟；当第一个节点和第二个节点之间的链路带宽提高到1Mbps时（如图2（b）所示），传输完该文件所需时间反而大大增加到了7个小时！这是因为在路由器R1中，数据包的到达速率远远大于转发的速率，从而导致大量数据包被丢弃，源端的发送速度被抑止，从而使得传输时间大大增加。即使所有链路具有同样大的带宽也不能解决拥塞问题，例如图3中，

所有链路带宽都是1Gbps，如果A和B同时向C以1Gbps的速率发送数据，则路由器R的输入速率为2Gbps，而输出速率只能为1Gbps，从而产生拥塞。
单纯地增加网络资源之所以不能解决拥塞问题，是因为拥塞本身是一个动态问题，它不可能只靠静态的方案来解决，而需要协议能够在网络出现拥塞时保护网络的正常运行。目前对互联网进行的拥塞控制主要是依靠在源端执行的基于窗口的TCP拥塞控制机制。网络本身对拥塞控制所起的作用较小，但近几年这方面的研究已经成了一个新的热点。

3. TCP拥塞控制及其改进

3.1 TCP拥塞控制机制介绍

基于源端的拥塞控制策略中，使用最为广泛的是TCP协议中的拥塞控制策略，TCP协议是目前互联网中使用最为广泛的传输协议。根据MCI的统计，互联网上总字节数的95％及总数据包数的90％使用TCP协议传输。

早期的TCP协议只有基于窗口的流控制（flow control）机制而没有拥塞控制机制，因而易导致网络拥塞。1988年Jacobson针对TCP在网络拥塞控制方面的不足，提出了“慢启动”（Slow Start）和“拥塞避免”（Congestion Avoidance）算法。1990年出现的TCP Reno版本增加了“快速重传 ”（Fast Retransmit）、“快速恢复”（Fast Recovery）算法，避免了网络拥塞不严重时采用“慢启动”算法而造成过度减小发送窗口尺寸的现象，这样TCP的拥塞控制就主要由这4个核心算法组成。

TCP协议的目的是为上层应用提供可靠的服务，其主要特征在于：

1. 确保各流享用带宽的公平性。
2. 动态发现当前可利用的带宽。
3. 拥塞避免及控制机制以避免拥塞崩溃（congestion collapse）的发生。

标准版本的TCP使用基于窗口的的和式增加积式减小（Additive Increase Multiplicative Decrease，AIMD）方式控制发送速率，以保证稳定性及带宽享用的公平性。

错误控制机制是一个可靠传输协议的关键部分。它对协议的性能有很大的影响，包括吞吐量、能量消耗及可靠性。错误控制通常包括错误检测和错误恢复两部分。为了保证数据传输的可靠性，TCP要求接受端在正确接收到数据段（data segment）后向发送端发送一个确认包，确认包中包含了期望接收到的下一个数据段的序号。TCP发送端通过监测确认包的序号来检测是否发生了错误。如果发生超时或者发送端收到一定数量（通常是3个）重复的确认包，则认为传输过程中发生了错误，数据段被丢弃。由于有线网络的位出错率很低（例如光纤的BER通常只有10－12[22]），因此TCP假设丢包是由于网络拥塞引起的。在错误恢复处理过程中，TCP重传丢弃的数据段、减小发送端窗口大小并且在超时情况下重置超时时钟。

最初的TCP协议只有基于窗口的流控制（flow control）机制而没有拥塞控制机制。流控制作为接受方管理发送方发送数据的方式，用来防止接受方可用的数据缓存空间的溢出。流控制是一种局部控制机制，其参与者仅仅是发送方和接收方，它只考虑了接收端的接收能力，而没有考虑到网络的传输能力；而拥塞控制则注重于整体，其考虑的是整个网络的传输能力，是一种全局控制机制。正因为流控制的这种局限性，从而导致了拥塞崩溃现象的发生。

1986年初，Jacobson开发了现在在TCP应用中的拥塞控制机制。运行在端节点主机中的这些机制使得TCP连接在网络发生拥塞时回退（back off），也就是说TCP源端会对网络发出的拥塞指示（congestion notification）（例如丢包、重复的ACK等）作出响应。1988年Jacobson针对TCP在控制网络拥塞方面的不足，提出了“慢启动”（Slow Start）和“拥塞避免”（Congestion Avoidance）算法。1990年出现的TCP Reno版本增加了“快速重传 ”（Fast Retransmit）、“快速恢复”（Fast Recovery）算法，避免了网络拥塞不严重时采用“慢启动”算法而造成过大地减小发送窗口尺寸的现象，这样TCP的拥塞控制就由这4个核心部分组成。近几年又出现TCP的改进版本如NewReno和选择性应答（selective acknowledgement，SACK）等。正是这些拥塞控制机制防止了今天网络的拥塞崩溃。

TCP拥塞控制四个主要过程（如图4（a）和（b）所示）简要介绍如下：

1. 慢启动阶段：早期开发的TCP应用在启动一个连接时会向网络中发送大量的数据包，这样很容易导致路由器缓存空间耗尽，网络发生拥塞，使得TCP连接的吞吐量急剧下降。由于TCP源端无法知道网络资源当前的利用状况，因此新建立的TCP连接不能一开始就发送大量数据，而只能逐步增加每次发送的数据量，以避免上述现象的发生。具体地说，当建立新的TCP连接时，拥塞窗口（congestion window，cwnd）初始化为一个数据包大小。源端按cwnd大小发送数据，每收到一个ACK确认，cwnd就增加一个数据包发送量，这样cwnd就将随着回路响应时间（Round Trip Time，RTT）呈指数增长，源端向网络发送的数据量将急剧增加。事实上，慢启动一点也不慢，要达到每RTT发送W个数据包所需时间仅为RTT×logW。由于在发生拥塞时，拥塞窗口会减半或降到1，因此慢启动确保了源端的发送速率最多是链路带宽的两倍。
2. 拥塞避免阶段：如果TCP源端发现超时或收到3个相同ACK副本时，即认为网络发生了拥塞（主要因为由传输引起的数据包损坏和丢失的概率很小（<<1%））。此时就进入拥塞避免阶段。慢启动阈值（ssthresh）被设置为当前拥塞窗口大小的一半；如果超时，拥塞窗口被置1。如果cwnd>ssthresh，TCP就执行拥塞避免算法，此时，cwnd在每次收到一个ACK时只增加1/cwnd个数据包，这样，在一个RTT内，cwnd将增加1，所以在拥塞避免阶段，cwnd不是呈指数增长，而是线性增长。
3. 快速重传和快速恢复阶段：快速重传是当TCP源端收到到三个相同的ACK副本时，即认为有数据包丢失，则源端重传丢失的数据包，而不必等待RTO超时。同时将ssthresh设置为当前cwnd值的一半，并且将cwnd减为原先的一半。快速恢复是基于“管道”模型（pipe model）的“数据包守恒”的原则（conservation of packets principle），即同一时刻在网络中传输的数据包数量是恒定的，只有当“旧”数据包离开网络后，才能发送“新”数据包进入网络。如果发送方收到一个重复的ACK，则认为已经有一个数据包离开了网络，于是将拥塞窗口加1。如果“数据包守恒”原则能够得到严格遵守，那么网络中将很少会发生拥塞；本质上，拥塞控制的目的就是找到违反该原则的地方并进行修正。
   
   

 
图4（a）：慢启动和拥塞避免 图4（b）：快速重传和快速恢复

经过十多年的发展，目前TCP协议主要包含有四个版本：TCP Tahoe、TCP Reno、TCP NewReno和TCP SACK。TCP Tahoe是早期的TCP版本，它包括了3个最基本的拥塞控制算法－“慢启动”、“拥塞避免”和“快速重传”。TCP Reno在TCP Tahoe基础上增加了“快速恢复”算法。TCP NewReno对TCP Reno中的“快速恢复”算法进行了修正，它考虑了一个发送窗口内多个数据包丢失的情况。在Reno版中，发送端收到一个新的ACK后旧退出“快速恢复”阶段，而在NewReno版中，只有当所有的数据包都被确认后才退出“快速恢复”阶段。TCP SACK关注的也是一个窗口内多个数据包丢失的情况，它避免了之前版本的TCP重传一个窗口内所有数据包的情况，包括那些已经被接收端正确接收的数据包，而只是重传那些被丢弃的数据包。

另外，在1994年，L.S.Brakmo等提出了一种新的拥塞控制策略－TCP Vegas。由于RTT值与网络运行情况有密切关系，因此，TCP Vegas通过观察TCP连接中RTT值改变感知网络是否发生拥塞，从而控制拥塞窗口大小。如果发现RTT值变大，Vegas就认为网络正在发生拥塞，于是开始减小拥塞窗口；另一方面，如果RTT变小，Vegas就认为网络拥塞正在解除，于是再次增加拥塞窗口。这样，拥塞窗口在理想情况下就会稳定在一个合适的值上。TCP Vegas的最大优点在于拥塞机制的触发只与RTT的改变有关，而与包的具体传输时延无关。由于TCP Vegas不是利用丢包来判断网络可用带宽，而是以RTT的变化来判断，因此能更精确地预测网络的可利用带宽，其公平性、效率都较好。但TCP Vegas之所以未能在互联网上大规模使用，主要是因为使用TCP Vegas的流在带宽竞争能力方面不及未使用TCP Vegas的流，从而导致网络资源享用不公平，而不是算法本身的问题。

3.2 拥塞控制的主要问题

拥塞控制的问题主要集中在效率和公平性（fairness）上。网络资源的使用效率是指源端要求的总资源与网络所能提供的资源之间的关系。如果二者刚好相等或者很接近，那么这种算法的效率就是高的，否则都是效率不高的表现。

公平性是指在网络发生拥塞时各连接能公平地共享网络资源。产生公平性的根本原因在于拥塞发生必然导致数据包丢失，而数据包丢失会导致各数据流之间为争抢有限的网络资源发生竞争，竞争能力强的数据流将到更多网络资源，从而损害了其他流的利益。所以说没有拥塞，也就没有公平性问题。公平性问题表现在两方面：一是拥塞响应的TCP流和非拥塞响应的UDP流之间资源享用不公平；二是TCP流之间资源享用的不公平。前者主要是在发生拥塞时对拥塞指示作出的不同反应造成的。由于TCP流具有拥塞控制机制，在收到拥塞指示后，源端会主动降低发送速率；而UDP流由于没有端到端的拥塞控制机制，因此在收到拥塞指示后，UDP不会降低数据发送速率。结果在网络拥塞时，拥塞适应的TCP流得到的资源越来越少，非拥塞适应的UDP得到的资源越来越多，从而导致了网络资源分配的不公平。网络资源分配的不公平反过来会加重拥塞情况，甚至可能导致拥塞崩溃。对于第二个不公平性问题，研究表明，不同的窗口大小、RTT值及数据包的尺寸都会影响TCP流对带宽的占用。窗口较大，或者RTT较小，或者数据包较大的流往往能占用更多的带宽。

3.3 有线网络中TCP拥塞控制机制的改进

3.3.1 针对对不必要的超时重传和快速重传

我们知道，当前的TCP应用主要有两种重传机制－快速重传和超时重传。当TCP源端收到3个ACK副本时，就会触发快速重传机制，此时源端重传丢失的数据包并且将拥塞窗口大小减半。这种情况下，TCP流往往能够很快从丢包中恢复过来，重新回到原先的发送速率。但如果TCP源端没有收到3个ACK副本，例如拥塞窗口大小小于4，那么TCP源端则需要等待相当长时间，以便超时重发。这样，小窗口的TCP流就很容易陷入不必要的超时重发，使其吞吐量大大下降。

为了避免这种不必要的超时重传，一种改进办法就是只要TCP源端收到一个或者两个ACK副本，并且如果通告窗口允许，便继续发送新的数据包。这是因为只要收到ACK副本，就表明有数据包已经离开网络被接受端接收了，而此时源端还无法判断数据包是否被丢弃，根据“数据包守恒”原则，只要遵守拥塞窗口的规范，也即同时在网络中传送的数据包数量不能超过拥塞窗口的大小（以数据包为单位），源端就可以继续发送新的数据包。这种机制称为限制传输机制（Limited Transmit mechanism），这种机制对排序的数据包尤其有效。

限制传输机制可以使小窗口的TCP流很快从丢包中恢复过来。例如，对于拥塞窗口大小为4地TCP流，如果其第二个数据包丢失，那么按传统地做法需要等待超时重传。而在限制传输机制下，当源端收到对第三个数据包确认的ACK副本时（ACK中要求源端发送第二个数据包），继续发送新的数据包，最终源端可以收到三个ACK副本从而触发快速重传，从而减少了不必要的超时重传。

3.3.2 针对乱序包和延迟包引起的重传

在不少情况下，TCP源端推断认为数据包被丢弃了，从而导致重传及拥塞窗口的减小，而实际上数据包并没有被丢弃。如果超时时钟过早地到时了（事实上数据包或者ACK并没有丢失，只要能够再等待一会儿并可收到ACK），源端便毫无必要地重发了数据包，更严重的是拥塞窗口的减小，而实际上并没有数据包被丢弃。类似地，如果由于数据包的乱序导致源端接收到3个ACK副本，便会导致快速重传，TCP源端也毫无必要地重发了数据包，并且减小了拥塞窗口。对于前者，虽然可以通过更为精确地调节超时时钟来减少不必要地超时重传，但要完全避免却是不可能的。同样，对于后者，虽然可以通过提高快速重传算法的性能来减少不必要的快速重传，但也不可能完全避免。

对于拥塞窗口较大的流，比如大小为W，不必要地减小拥塞窗口会导致其至少花费W/2 RTT时间恢复到原来拥塞窗口的大小，从而使其性能大大下降，特别是在数据包持续出现乱序或者对RTT的估算不很精确的情况下。持续乱序的数据包往往是由于路由的改变或者链路层重传受损的数据包引起的。

为了使得在出现不必要的超时重传和快速重传情况下，TCP性能能够更加健壮（robust），一种方法就是在出现这些情况时向TCP源端发送有关的信息。这个工作已经由D-SACK扩展（duplicate-SACK extension）完成了。D-SACK扩展允许TCP接受端在利用SACK选项来通报收到重复的数据包，从而TCP源端能够正确地推断出接受端是否收到了重复地数据包。因此，D-SACK扩展使得TCP源端在重发后一个RTT时间内正确地推断出重发是否必要。如果源端认为重发是不必要的，那么拥塞窗口减半也就没必要了，源端就会将拥塞窗口大小和慢启动阈值分别恢复到原来的值，这样拥塞窗口恢复到原来的大小只需1RTT时间而不是W/2 RTT时间了。

3.3.3一种新的拥塞控制机制XCP

针对目前基于窗口的TCP拥塞控制机制的不足，最近MIT的D.Katabi、C.Rohrs和UC Berkeley的M.Handley共同提出了一种新的互联网拥塞控制机制XCP（eXplicit Control Protocol）。XCP源端维持有拥塞窗口cwnd和回路响应时间RTT并且通过数据包中的拥塞头（congestion header）将这两个值与路由器进行通信。当XCP连接刚刚建立时，与TCP一样，初始cwnd较小，XCP将其理想的发送速率填入到拥塞头中，如果链路带宽允许，则在一个RTT后就以次速率发送数据；如果链路带宽不足，则网络会给出一个发送速率，在一个RTT后源端就以此速率发送数据。

在随后的数据包传输过程中，根据数据流入速率和链路带宽之间的关系，路由器通知每个流是要增加还是减少拥塞窗口并将有关信息填入到拥塞头中。如果在后面的传输过程中，有路由器拥塞更加严重，则该路由器将拥塞头中的有关信息改写。最终该数据包将获得传输过程中的瓶颈链路信息，并将传送给接收端。接收端再将次信息写入到确认包中传送给源端，源端依此信息对拥塞窗口进行调整。通过将拥塞状态信息放入数据包中，XCP无需路由器维持每流状态信息，扩展性较好。

实验表明，与传统的TCP拥塞控制机制相比，XCP具有链路利用效率高、公平性好、可扩展性强、排队时延小的优点，并且路由器的开销也非常小。但XCP最终能否被标准化作为下一代互联网的传输协议我们将拭目以待。