EEPW论坛

随着查询/响应类应用联网设备的不断增加，以及带宽竞争的加剧，高效实现互动数据交换就显得十分迫切。在臃肿的网络上，响应时间、存储器的使用、可靠性和互动性是选择传输协议时需要考虑的多个重要因素，本文就从这几个方面说明三种不同的传输层协议对上述指标的影响，并说明具备T/TCP功能的联网设备可能是未来的发展趋势。 目前，连接上网的嵌入式设备的数量和种类都在迅速增加。许多数据通讯应用方面的要求涉及频繁的查询－响应，或者在客户端设备与服务器设备之间小型数据(小到可以放在单一而不拆分的IP包中)的互动数据交换(transaction)类型互换。本文中“客户端”指启动这种信息交换的设备，而“服务器”是指响应该请求的设备。客户同服务器的关系可以是多对一，一对多或者是多对多的关系。 联网设备通常都采用IP(互联网络协议)作为网络层协议。传输应用中一个至关重要的选择就是传输层协议的应用。本文着重讨论这种选择所面临的若干问题以及注意事项，特别是(但不仅仅是)在嵌入式设备中，要注意存储器、网络带宽、响应时间、可靠性以及互动性等问题。根据这些情况，传输层协议将分别考虑三种可能的选择：UDP、TCP以及T/TCP. 用于互动数据交换的TCP扩充 一般来说，传输控制协议(TCP)和用户数据包协议(UDP)是读者比较熟悉的，而用于互动数据交换的TCP扩充协议(T/TCP)还不太为人所知，本段简要介绍有关该协议的概况。 T/TCP并不是一种新的协议。该协议在1994年就以RFC1644标准的形式给出了定义。在标准版TCP的基础上，通过增加某些新功能来实现互动数据交换应用的优化，从而构成了T/TCP。在T/TCP中使用了所有的标准版TCP的机制及基本结构。T/TCP后向兼容TCP。T/TCP不论是在客户端还是在服务器端，当与一个不支持T/TCP协议的对等设备通讯时，就会自动适配为标准版TCP。 T/TCP连接中的每一个IP包(TCP术语中称为一个区段)都会用一个32位的连接计数(connection count)来标识，该连接计数对每个连接来说都是唯一的。绝大多数情况下，它能防止旧的区段破坏后续连接。一个称为“CC”的TCP数据头选项可以携带T/TCP连接计数。 对持续时间较短---小于一个数据段最长寿命(MSL)---的连接来说，CC选项的一个好处就是它可以缩短或者避免出现TCP的TIME_WAIT状态。TIME_WAIT状态提供保护TCP数据流不被破坏的一种机制，这种机制通过复制同一个连接以往数据段的早期副本来实现。TCP连接的一端驻留在TIME_WAIT状态来维持两个MSL---一个MSL通常持续两分钟---的时间间隔，这样可以防止当所有的副本信息段在网络上仍然处于有效期时创建同一连接的新副本。T/TCP的CC选项确保TIME_WAIT状态可以被截短到最多高达一个连接往返时间(RTT)的八倍。更重要的是，同一连接的新副本可以立即创建，也就是说，TIME_WAIT状态可以完全消除。 T/TCP会维护每一个相互作用的远程主机的协议信息的缓存。这个缓存包括往返时间、最大信息段长度以及堵塞窗口等相关信息。因此，这些信息无需在每一次连接中重新创建，T/TCP连接可以根据这些参数立即运行。 标准TCP连接总是以一个不携带任何数据信息的三段同步(SYN)序列开始，而以同样不携带任何数据信息的一个三段结束(FIN)序列来中止。SYN与FIN之间的数据段携带需要交换的信息。如果需要发送数据的总量可以整合在单一的数据段中，那么T/TCP就可以将SYN、FIN以及数据功能组合为单个信息段(single segment)，所以完整的一个T/TCP连接仅需要三个数据段就可以打开和关闭。 用于T/TCP的插座API是标准TCP插座API的最小扩充。通过将两个现有的API功能“send to”和“send”进行了扩展，可以确保应用端整合各种要求，从而打开连接、传输数据和关闭连接传输方向以便被单API调用。 在客户端一方，三区段连接的最小持续时间与一个简单的往返时间为同一数量级。这里，通常假定与往返时间相比，服务器处理请求并且发送响应需要花费的时间很小。 存储器的使用 由于生产成本较高，所以嵌入式设备的存储器通常都比较有限，因此进行软件设计时必须牢记这一约束条件。 标准TCP之所以可靠，一个原因是一旦连接中止，那么启动连接中止的一端(通常是客户端)就会进入TIME_WAIT状态，并且维持这一状态的时间较长，通常为二倍MSL。在这段时间内，不会创建同一连接的新例程。这种机制保护TCP连接免受同一端点之间早期连接中相同端点之间旧的复制信息段的破坏。这样看来，当TIME_WAIT状态时间到期为止，所有这些旧的信息段都将在网络上到期。 当一个连接维持在TIME_WAIT状态时，TCP就必须为该连接维护一个包括状态信息的控制模块。通常情况下，一个连接的TCP控制模块会占用几百个字节的存储器空间。 与此同时，如果客户端应用希望管理与同一个服务器之间后续互动数据交换的话，就必须为每一个客户端应用分配一个新的本地TCP端口，并且为该连接的TCP控制模块分配存储器。如果客户端应用运行的硬件平台中存储器空间比较紧张，该TCP层的设计就要考虑让传输容量能够满足一定数量的同时连接需要。一旦连接容量(connection capacity)为TIME_WAIT状态下的连接全部占用，那么只有其中的一个TIME_WAIT状态到期才能创建新的连接。这可能严格制约传输的速率，例如，如果TIME_WAIT状态的持续时间是两分钟，并且客户设备的容量是20个同时连接，那么所能达到的最大传输速率就是每分钟10次互动数据交换。 由于UDP没有连接状态，因而无需维护连接状态，所以对UDP来说，存储器的大小和使用不成为问题。 T/TCP的TIME_WAIT具有截短特征(truncation feature)，因此应用可以立刻复用上一个连接的本地TCP端口，而无需进行额外的TCP控制模块分配。 即使应用并不复用同一本地TCP端口，由于T/TCP的TIME_WAIT状态持续时间与标准TCP相比通常都很短，那么，相对来说有限的同时连接容量而导致的互动数据交换速率(transaction rate)的下降就很小。 网络带宽 如果位于客户端和服务器之间路径上的网络数据传输量相对它们的容量来说负载很重的话，那么就可能出现因堵塞而导致的信息包丢失，使用具有较小开销的传输层协议就能够使这种风险降到最小。 使用标准TCP实现的一个最小互动数据交换通常需要9个TCP区段，尽管这些区段中只有两个区段携带有应用数据。7个额外的区段用于三方握手，以开放/关闭连接以及做出应答，因而开销很大。 此外，由于网络堵塞而产生的区段丢失将导致数据重传，这都会增加数据包数量。当然，传输协议中潜在的开销越大，那么数据路径上的网络数据传输也就更容易出现堵塞。 使用UDP的一个最小互动数据交换只需要两个UDP数据包，每一个方向各一个数据包，因而UDP可以使网络上的负载最小。 一对主机之间初始的T/TCP互动数据交换需要6个区段，同一对主机之间后续的传输只需要3个区段。 响应时间 如果客户端和服务器之间网络路径上的一个或者多个数据链使用低速(例如串行的PPP链接)传输介质或者呈现出较大的传输延时(例如用同步轨道卫星中的卫星链路)，那么互动数据交换的发起者就需要相对较长的响应时间。对于操作人员来说，这或许算只是等得不耐烦的问题。而对于具有严格实时约束的客户端程序来说，问题就严重了。 在采用标准TCP的互动数据交换中，客户端需要的响应时间至少是连接路径往返时间的两倍，加上服务器应用端处理请求／询问以及产生响应所需要的时间。后者的服务器处理时间称为SPT，因此，总的响应时间至少是2*RTT+SPT。 在采用UDP的一个最小互动数据交换中，客户端的响应时间是RTT+SPT。 一对主机之间初始的T/TCP互动数据交换具有与TCP同样的响应时间(2*RTT + SPT)。同一对主机之间所有后续互动数据交换的响应时间与UDP相似(RTT + SPT)。 可靠性 IP网络的可靠性不够高，例如单个信息包可能由于网络节点的堵塞而丢失。如果某种应用要求端到端数据传输的可靠性，那么就必须在传输层或者通过应用端自身来确保这种可靠性。 由于标准TCP是一种可靠的数据传输协议，它能够很好地从堵塞导致丢失的区段中恢复并且完成互动数据交换。对于应用软件来说，只是增加了响应时间，这种情况非常明显。如果由于一个网络节点出现故障以及/或者客户端和服务器之间的数据路径被切断，并且没有任何其它可能的路由而导致互动数据交换不能完成，那么应用端就会被告知出现了故障，从而造成数据交换无法进行。 UDP不是一种可靠的传输协议。如果一个UDP数据包由于网络堵塞而丢失，那么互动数据交换就不能完成。如果要求数据的传递必须可靠，那么这种可靠性就必须在应用层中构建。T/TCP具有和标准TCP一致的可靠性。 互动性 与使用专属协议栈或者尚未普遍使用的新的协议栈相比，采用公认和业已实现的标准协议栈更容易实现互动性。 标准TCP不会对互动性造成任何障碍。 如果要求可靠性，就必须在UDP之上使用一种专有机制，这样可能会导致互动性方面的问题。 由于T/TCP具有后向兼容标准TCP，因而它的应用对于互动性的影响较小甚至不会产生任何障碍。一个特例是如果一个客户端T/TCP试图与一个有故障的标准TCP(该TCP不能无视CC选项)进行通讯，那么可能存在障碍。当T/TCP的性能优势不能在这种“互动性”模式中实现时，至少互动数据交换本身仍然可以发生。 应用复杂性 如果一个请求需要可靠的数据传输，就必须使用一个可靠的传输层协议，或者由应用自身来提供这种可靠性。在请求中包含数据传输的可靠性机制能极大地增加复杂性并且提高应用的开发成本。 如果使用的传输层协议实现方案为其它的应用广泛采用，那么与传输层协议接口的代码很可能也是从其它应用“克隆”得到，而不是从头开始开发的。这种优势不可能通过使用一种专有的协议栈或者一种尚未被许多应用所使用的新协议栈来实现。 由于TCP是一种可靠的数据传输协议，因而无需在使用TCP的应用中引入可靠性机制。绝大多数TCP实现都提供事实标准BSD插座API。 绝大多数UDP的实现也提供事实标准BSD插座API，另一方面，UDP并不提供任何的可靠性保证，所以应用端自身必须提供可靠性机制。 T/TCP提供与TCP一样的可靠性保障，所以使用T/TCP的应用无需提供可靠性机制。由于TCP的API进行了适当的扩展以实现对T/TCP的支持，与T/TCP接口的应用代码不可能完全从使用标准TCP的应用中“克隆”得到。但是差别并不明显，而且那些代码仍然可以作为开发起点，从而利用T/TCP的优点，并避免对代码进行大的改动。 性能比较 下列测试中的客户机是一个运行FreeBSD 4.4版本0并且具有T/TCP补丁的PC机。路由器是一个运行Linux 2.2.14-5.0的PC机。服务器是一个运行Windows 98并且具有Fusion 6.5 TCP/IP协议栈的PC机。 在某些测试中，路由器上要用一个工具加入250ms的延时后才把数据包从出口路由出去(如图1所示)，这样做的目的是模拟一个“长”链接的延时特性，比如地球同步人造卫星链接，因此，实际上有四种测试配置，分别代表以下四种网络路径： 1. HB－DL：高带宽，低延时； 2. HB-HD：高带宽，高延时； 3. LB-LD：低带宽，低延时； 4. LB-HD：低带宽，高延时。 每一次互动数据交换中，客户端应用都向服务器端应用发送一个1,000字节的请求，服务器端应用通过重复回送这一请求给客户端来完成对客户端应用的响应。由于API差异较小，因此在T/TCP和标准TCP测试中要用不同的客户/服务器应用程序。 每一次试验都连续快速地执行100次互动数据交换。客户端应用在前一个互动数据交换结束之后，立即启动一个新的互动数据交换。网络监控器捕获这些数据流用来进行脱机分析。三个试验分别在上述四种结构中执行，对每一种结构考察第一次互动数据交换的第一个包，和第100次互动数据交换的最后一个包之间所花费的全部时间并且记录下来。同时记录的还有每次试验中通过该网络的TCP区段数量。将每一种结构中三个试验的结果取平均值(事实上这些结果的变化基本上可以忽略)，结果显示在表1中。在绝大多数结构中，测试结果表明差别主要区段计数上。T/TCP互动数据交换的区段计数是三个，标准TCP是9个。唯一的例外就是在低带宽结构中运行标准的TCP，在这种结构下，包的数量甚至高于期望值。这是由于某些不必要的由客户端查询的1,000字节的重发，造成这种情况的原因在于启动重新互动数据交换定时器的值小于客户端接收确认的时间值。由于T/TCP缓存测量的往返时间(取决于基于哪一个重新传输定时器)并且应用在后续的连接中，所以这种情况就不会出现在T/TCP(在第一次传输时可能出现)中。标准TCP不能记忆跨连接之间的RTT。 所有的测试结构都表明，T/TCP互动数据交换的完成要快于标准TCP互动数据交换。这种差别在HB-HD结构中效果最明显，在这种结构中标准TCP互动数据交换大约要花T/TCP互动数据交换时间的两倍。这种结构中决定往返时间的重要因素是延时；标准TCP需要两个往返时间，而T/TCP只需要一个。在LB-LD结构中差距最小，这是因为在这种结构中1,000字节的查询和响应的传输时间构成最主要的时间成分。 本文小结 随着查询/响应类应用联网设备的不断增加，以及带宽竞争的加剧，高效实现互动数据交换就显得十分重要。由于许多这样的应用是交互式的，并且可能运行在臃肿的网络上，因此响应时间也构成设计过程需要考虑的一个重要的因素。 传输层协议的选择会影响带宽效率，而且也是决定响应时间的重要因素。UDP具有最佳的带宽效率因而被广泛采用，很清楚，传输层协议并不适合于那些数据传输可靠性要求非常严格的应用。如果具有严格的可靠性方面的要求，那么标准TCP就可能是更好的选择。但是如同本文所介绍的，T/TCP在带宽效率和响应时间两方面都要优于TCP，与此同时仍然保持较高的可靠性。基于上述原因，网络上在不久的将来可能会出现大量具备T/TCP功能的设备。 参考资料 1. Braden, R. "T/TCP - TCP Extensions for Transactions Functional Specification," RFC 1644, 1994. 2．Stevens, W.R. TCP为传输，HTTP，NNTP以及UNIX域协议。Boston: Addison Wesley, 1996. 作者简介：Michael Mansberg是NetSilicon Softworks小组的主任软件工程师。他持有马里兰大学的计算机科学学位，并且具有在实现数据通讯协议领域广泛的经验。可以通过电子地址：mmansberg@netsilicon.com与他联系。 作者：Michael Mansberg