TCP事务协议详解：优化TCP通信

需积分: 10 41 浏览量更新于2024-07-20 收藏 9.64MB PDF 举报

"TCP-IP详解卷三：TCP事务协议，主要探讨了TCP/IP通信中的一种优化方式T/TCP，以及客户-服务器事务的概念。书中通过对比UDP、TCP和T/TCP在实现客户-服务器应用程序时的差异，展示了T/TCP如何减少分组数量并提高效率。同时，内容涵盖了互联网上常见事务协议的历史和发展，以及如何在现有TCP应用程序中引入T/TCP的支持。" 在TCP/IP协议栈中，TCP（传输控制协议）以其可靠性和面向连接的特性而闻名，但它的开销相对较高，尤其在处理短生命周期的事务时。T/TCP（TCP for Transactions）就是为了优化这一情况而提出的。它旨在快速完成客户-服务器间的事务处理，例如DNS查询，通过减少连接建立和释放的延迟，提高系统效率。本章首先从基础的客户-服务器模型开始，使用UDP（用户数据报协议）作为起点，因为UDP是无连接且轻量级的，适合快速传输小数据包。然而，UDP的不可靠性可能导致数据丢失，因此通常需要更高层的应用程序来处理重传和错误恢复。接着，章节转到使用TCP的客户-服务器模型，TCP提供了顺序数据传输和确认机制，确保数据的完整传输，但这也增加了额外的开销，特别是在频繁的短事务中。T/TCP的引入，就是在保持TCP可靠性的基础上，通过复用已有的连接来减少建立和释放连接的开销，从而提升性能。书中通过实际的源代码示例，演示了如何在UDP、TCP和T/TCP下编写客户-服务器程序，并对比它们在执行时间和资源消耗上的差异。此外，还探讨了如何在现有的TCP应用中平滑地引入T/TCP支持，以及T/TCP在Internet协议族中的地位和实现情况。在TCP/IP详解卷三中，作者不仅深入解析了T/TCP的工作原理，还介绍了4.4BSD-Lite发布版中的相关源代码，帮助读者理解T/TCP的实际操作和编程接口。这部分内容对于开发者和网络工程师来说，是非常宝贵的参考资料，能够加深他们对TCP/IP协议栈的理解，特别是如何在实际应用中优化事务处理效率。

刚返回后分别读取当前系统时间。这两个时间的差值即为客户端测得的事务时间。

• 在图1 - 5 所示的T C P上客户程序中，我们在即将调用 c o n n e c t函数前和r e a d _ s t r e a m

函数刚刚返回后分别读取当前系统时间。

• 在图1 - 1 0 所示的T / T C P 上客户程序中，我们取当前的系统时间为即将调用 s e n d t o函数

前和r e a d _ s t r e a m 函数刚刚返回后。

图1 - 1 4给出了以1 4 种不同长度的请求和应答分别测得的结果。客户和服务器分别为图 1 - 1 3

中的b s d i 和l a p t o p。附录A中给出了这些测量的细节，并分析了影响结果的因素。

T / T C P 上的事务时间总是比同样条件下的 U D P 上的事务时间要长几个毫秒 (由于这个时间

差是软件造成的，因此这个时间差会随着计算机速度的提高而缩短 )。T / T C P 协议栈比U D P协

议栈所做的操作要多 (图A - 8 ) ，而且T / T C P上的客户和服务器要分别调用两次 r e a d 函数，而

U D P 上的客户和服务器则只需分别调用一次 r e c v f r o m 函数。

T C P上的事务时间总是比相同条件下 T / T C P 上的事务要长大约 20 ms。其中部分原因是由

于T C P 建立连接时的三次握手。两个 S Y N报文段的长度是 4 4 字节( 2 0字节的I P 首部、2 0 字节的

标准T C P 首部和4字节的TCP MSS选项)。这相当于用户数据为 1 6字节的P i n g ；从图A - 3 可知，

其网络往返时间 RT T 大约为 10 ms。另外10 ms的差值可能是因为 T C P 协议需要处理额外 6个

T C P报文段造成的。

因此我们可以得出结论： T / T C P上的事务时间接近、但比 U D P 上的事务时间略大，比 T C P

上的事务时间短至少相当于一个 4 4 字节报文段的网络往返时间。

就客户段测量的事务时间而言，用 T / T C P 取代T C P 带来的好处依赖于 RT T 和S P T之间的关

16计计第一部分 TCP事务协议

下载

Cisco路由器

以太网

拨号

支持T/TCP的

BSD/0S 2.0

支持T/TCP的

BSD/OS 2.0

以太网140.252.13.0

图1 - 1 3用于验证本书所有例子的测试网络，所有 I P 地址都以1 4 0 . 2 5 2打头

系。比如，在一个局域网上的 RT T为3 ms(如图A - 2 )，服务器的平均处理时间为 500 ms，那么

T C P 上的事务时间大约为 506 ms(2×RT T + S P T ) ，而T / T C P 的事务时间则大约为 503 ms。但如

果是一个网络往返时间 RT T 为2 0 0 m s 的广域网(见第1 4 . 4节)，服务器处理时间 S P T 的平均值为

100 ms，那么T C P 上和T / T C P上的事务时间就分别为大约 500 ms和300 ms。我们已经看到，使

用T / T C P所需传送的网络分组数少 (从图1 - 8 和图1 - 1 2 的比较中看分别是 3个和9个)，因此，不

管客户端所测得的事务时间减少了多少，使用 T / T C P 总是能减少网络分组数。减少了网络分

组数就可以减少分组丢失的概率，而在 I n t e r n e t中，分组丢失对整个网络的稳定性有很大影响。

图1-14 UDP、T / T C P和T C P上客户-服务器事务的时间系列

在A . 3节里，我们介绍了传播时迟和带宽的差异。这两者对 RT T都有影响；但是当网络变

快以后，传播时迟的影响也就变大了。此外，传播时延是我们几乎无法控制的，因为它的大

小取决于客户和服务器之间的信号传播距离和光在介质中的传播速度。于是，在网络速率越

来越快的条件下，省下一个 RT T 的时间就显得尤为可贵，使用 T / T C P的相对好处也就越发明

显。

现在可以公开获得并支持T / T C P 的用于测量网络性能的工具：

h t t p : / / w w w . c u p . h p . c o m / n e t p e r f / n e t p e r f p a g e . h t m l

1.7 应用

T / T C P 给所有T C P上的应用程序带来的第一个好处就是可以缩短 T I M E _ WA I T状态的持续

时间。这样，一般情况下协议必须处理的控制块也跟着少了。 4 . 4节详细介绍了T / T C P 协议的

这个特性。现在我们可以这样说：对于连接时间很短 (典型值为小于2分钟)的所有T C P应用程

第1章 T / T C P概述计计17

下载

测得的事务

时间(ms)

用户数据：请求和回答的长度(字节)

序，如果通信双方的主机都支持 T / T C P 的话，它们都将因使用该协议而获益。

使用T / T C P的最大好处或许在于避免了三次握手过程，对于那些交换的数据量比较小的应

用程序，T / T C P减少的时延将给它们带来好处。我们将给出几个例子来说明这一点 (附录B谈

到了利用T / T C P来避免三次握手过程要对应用程序做怎样的修改 )。

1. WWW：超文本传输协议

W W W及其所依赖的 H T T P 协议(将在第1 3章介绍该协议)将可能大大地受益于 T / T C P协议。

参考书[Mogul 1995b]中指出：“然而，构成We b 应用传输时延的主要因素是网络通信……即便

我们无法提高光的传播速度，但我们至少应该想办法减少一次交互过程中的往返传输次数。

当前We b网中使用的超文本传输协议 ( H T T P )实际上造成了大量不必要的往返传输”。

比如，[Mogul 1995b]中对随机抽取的200 000个H T T P请求的统计发现，应答长度的中值

为1 7 7 0 字节(通常使用中值而不使用均值，这是因为很少出现的大文件会使均值变大 )。M o g u l

还引用了另一个例子。该例随机抽样了大约 1 5 0万个请求，其应答的长度中值为 9 5 8 字节。客

户的请求一般很短：在1 0 0 ~ 3 0 0字节之间。

典型的H T T P客户-服务器事务和图 1 - 8 所示的很相似。客户端主动打开，向服务器发出很

短的请求，服务器收到请求后发出应答，然后服务器关闭连接。这种情况非常适于使用

T / T C P 协议，把客户端的 S Y N和客户的请求合并在一起传送省去三次握手中的往返时间。这

也还减少了网络上的分组数，而这对于已经非常巨大的 We b通信量来说也是很有意义的。

2. FTP数据连接

F T P 数据连接也会从使用 T / T C P 协议中获益。从一项对 I n t e r n e t 通信量的统计调查中，

[Paxson 1994b]发现平均每个F T P数据连接所传输的数据量约为 3 000字节。卷1的第3 2 3页给出

了F T P数据连接的一个例子。虽然例子中的数据流是单向的，但其传输过程还是与图 1 - 1 2所示

的十分相似。采用T / T C P 后，图中的8个报文段减少到了3个。

3. 域名服务系统( D N S )

D N S 客户的查询请求是用 U D P传送到D N S 服务器的。服务器仍然用 U D P发送给客户的应

答。但如果应答超过 5 1 2 字节，那么只有前 5 1 2字节会在应答中返回给客户，同时在应答中有

“t r u n c a t e d ( 截断)”标志，表示还有信息要传给客户。于是客户用 T C P 向服务器重新发送查询

请求，而后服务器用T C P 向客户传送完整的应答。

采用这项技术的原因是不能保证特定的主机能够重组长度超过 5 7 6字节的I P 数据报(实际

上，许多U D P 应用程序都把用户数据的长度限定在 5 1 2 字节以内，以保证不超过 5 7 6 字节的限

制)。由于T C P是一个字节流协议，应答数据量再大也不会有问题。发送方 T C P会根据连接建

立时对等端声明的报文段最大长度 ( M S S ) 限制，把应用程序的应答数据分割成适当长度的报文

段发给对方。接收方 T C P 会把这些报文段拼接起来，并以应用程序读取时指定的数据长度交

给接收的应用程序。

D N S 的客户和服务器可以利用 T / T C P ，既达到 U D P 的请求-应答速度，又具有 T C P 的所有

好处。

4. 远程过程调用( R P C )

在所有论述将传输协议用于事务的论文中，无不将 R P C作为一个候选的应用协议。 R P C

中客户要向载有待执行程序的服务器发送请求，请求中带有客户给定的参数；服务器的应答

中包括过程执行后所返回的结果。参考书 [Stevens 1994]的第2 9 . 2 节中讨论了S u n R P C。

18计计第一部分 TCP事务协议

下载

R P C 的数据包往往会非常大，必须给 R P C协议增加可靠性，使其能在像 U D P 这样不保证

可靠性的协议上运行，同时还要避免 T C P 的三次握手。使用T / T C P协议就能实现这一目标，既

有T C P的可靠性，又没有三次握手的开销。

所有建立在R P C基础上的应用程序，比如网络文件系统 ( N F S ) 等都可以采用T / T C P 协议。

1.8 历史

RFC 938 [Miller 1985]是较早讲述事务的 R F C 文档之一。该文档中规定了 I RT P ，即：

Internet 可靠的事务协议，能保证数据分组的可靠、按顺序提交。该文档中把事务定义为一个

短小的、自包含的报文；而 I RT F 定义了任意两台主机 (即I P 地址)之间持续存在的优选连接，

当其中任何一台主机重新启动后，该连接都重新同步。 I RT F协议位于I P协议之上，并定义了

专门的8字节首部。

RFC 955 [Braden 1985]本质上并未规定任何协议，而只是给出了事务协议的一些设计准

则。它认为U D P 和T C P 这两个主流的运输层协议所提供的业务相差太大，而事务协议正好填

补T C P 和U D P 之间的空档。该 R F C 文档把事务定义为一次简单的报文交换：一个请求发给服

务器，然后一个应答发回到客户。它还认为各种事务都有如下特征：不对称的模式 (一端是服

务器，另一端是客户 )、单工数据传递 (任一时刻都只有一个方向有数据传输 )、持续时间短(可

能延续几十秒，但绝不可能几小时 )、时延小、数据分组少以及面向报文 (不是字节流)。

该R F C 中列举了域名服务系统 D N S 的例子。它认为，在考虑是用 U D P 还是用T C P 作为域

名服务系统的运输层协议时，设计者往往陷入两难的境地。一个理想的解决方案应该既能提

供可靠的数据传输，又不需要专门地建立和释放连接，不需要报文的分段和重组 (从而应用程

序不再需要知道像5 7 6 这类的神秘数字)，同时还能使两端的空闲状态所处时间最短。 T C P 什么

都好，只可惜它需要建立和释放连接。

另一个相关的协议是R D P，即可靠数据协议。该协议在 RFC 908 [Ve l t e n，i n d e n，and Sax

1 9 8 4 ]中定义，后来又更新为RFC 1151 [Patridge and Hinden 1990]。与R D P实现有关的经验在

参考文献[Patridge 1987] 中可以找到。参考文献 [Patridge 1990a]中对R D P有如下评价：“当人

们寻求一个可靠的数据报协议时，他们通常是想要一个事务协议，一个能够让他们与多个远

端系统可靠地交换数据单元的协议，一个类似于可靠 U D P 的协议。R D P 应该看作是一个面向

记录的T C P协议，它利用连接可靠地传输有格式数据块流。 R D P 并不是一个事务协议。”( R D P

不是一个事务协议的理由是因为它和 T C P一样采用了三次握手技术 )。

R D P 使用通常的插口应用编程接口 ( A P I ) 。与T C P 类似， R D P 提供流插口接口 (S O C K _

S T R E A M )。另外，R D P 还提供S O C K _ R D M插口类型(可靠的报文提交)和S O C K _ S E Q P A C K E T 插

口类型(有序的分组)。

V M T P ，即通用报文事务协议，是在 RFC 1045 [Cheriton 1998]中规定的，是一个专门用

于事务的协议，就像远程过程调用一样。像 I RT P 和R D P 那样，V M T P 也是I P 之上的运输层协

议，但V M T P 还支持多播通信，这个特性是 T / T C P 以及本节提到过的其他协议所不具备的 (参

考文献[Floyd et al. 1995]中有不同意见，他们认为提供可靠的多播通信是应用层的任务，而不

是运输层的任务)。

V M T P 还为应用程序提供不一样的应用编程接口 A P I，其插口类型为 S O C K _ T R A N S A C T 。

第1章 T / T C P 概述计计19

下载

具体定义详见RFC 1045。

虽然T / T C P的许多概念早在RFC 955中就已经出现，但直到RFC 1379 [Braden 1992b]发布

才正式有了 T / T C P 的第一个规范。该 R F C 文档定义了 T / T C P 的概念，接下来的 RFC 1644

[Braden 1994]给出了更多的细节，并讨论了一些实现问题。

图1 - 1 5比较了实现各种运输层协议分别都需要多少行 C源代码。

协议源代码行数

U D P (卷2 ) 8 0 0

R D P 2 700

T C P ( 卷2 ) 4 500

T / T C P模式的T C P 5 700

V M T P 21 000

图1-15 实现各种运输层协议所需要的源代码行数

为支持T / T C P所需增加的源代码行数 (大约1 2 0 0 行)是U D P 协议源代码行数的 1 . 5 倍。为使

4 . 4 B S D 支持多播通信，需要增加大约 2 0 0 0 行源代码(设备驱动程序的改变和支持多播路由所需

要的代码行数尚未计算在内 )。

V M T P 可以从f t p : / / g r e g o r i o . s t a n f o r d . e d u / v m t p - i p 得到。R D P通常

还得不到。

1.9 实现

第一个T / T C P实现是由Bob Braden和Liming We i 在南加州大学的信息科学学院 (USC ISI)完

成的。该项工作得到了国家科学基金 N S F的部分资助，批准号为 NCR-8 922 231。该实现是为

SunOS 4.1.3(从伯克利演变而来的内核 )做的，1 9 9 4 年9月就可以用匿名的F T P 得到了。S u n O S

4.1.3 的源代码补丁可以从 f t p : / / f t p . i s i . e d u / p u b / b r a d e n / T T C P . t a r . Z得到，但你

必须有S u n O S内核的源代码才能应用这些补丁。

Tw e n t e 大学(荷兰)的Andras Olah修改了USC ISI的实现，并于1 9 9 5 年3月将其在F r e e B S D

2 . 0 版中发布。FreeBSD 2.0中的网络代码是基于 4 . 4 B S D - L i t e 版的(卷2中有介绍)。图1 - 1 6 给出

了各种B S D版本的演变历程。与路由表 (我们将在第6章中讨论)有关的所有工作都是由麻省理

工学院(Massachusetts Institute of Te c h n o l o g y )的Garrett Wo l l m a n 完成的。F r e e B S D实现的有关

信息可以从h t t p : / / w w w . f r e e b s d . o r g 得到。

本书作者把 F r e e B S D实现移植到了BSD/OS 2.0内核(该内核也基于4 . 4 B S D - L i t e 中的网络代

码)中，也就是运行在主机 b s d i 和l a p t o p (图1 - 1 3 中)中的代码，本书从头至尾都用它们。为

了支持 T / T C P 而对 B S D / O S 所做的修改,可以从作者的个人主页里找到： h t t p : / / w w w .

n o a o . e d u / ~ r s t e v e n s。

图1 - 1 6 给出了各个B S D 版本的演变历程，其中还标出了重要的 T C P / I P特性。图中左边显

示的是可以公开得到源代码的版本，其中有所有网络代码：协议本身、网络接口的内核例程

以及许多应用程序和实用工具 (比如Te l n e t和F T P )。

本书中所描述的 T / T C P 实现的基础软件的正式名称是 4 . 4 B S D - L i t e ，但我们一般简称其为

N e t / 3。还要说明的是，可以公开得到的 N e t / 3 版本中不包括本书所述为支持 T / T C P而做的修改。

20计计第一部分 TCP事务协议

下载

剩余249页未读，继续阅读

小晏

粉丝: 174
资源: 34

TCP事务协议详解：优化TCP通信

TCP-IP详解卷三：TCP事务协议，HTTP，NNTP和UNIX域协议

TCP-IP详解卷三：TCP事务协议，HTTP，NNTP和UNIX域协议.

tcp/ip详解 卷1:协议(原书第2版)pdf csdn

tcp/ip详解 卷2:协议下载

tcp/ip详解 卷1:协议(原书第2版)电子版

openwrt中的ip6tables中的“-A FORWARD -o eth1 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone wan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu”

tcp/ip详解 卷二 下载

ip6tables中的“-A FORWARD -o eth1 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone wan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu”中的TCPMSS 如何修改TCP SYN包的最大字段大小

tcp ip详解 卷1 协议

条件取反_iptables系列------第四篇：iptables匹配条件总结之一

最新资源

tcp/ip详解卷1:协议(原书第2版)pdf csdn

tcp/ip详解卷2:协议下载

tcp/ip详解卷1:协议(原书第2版)电子版

tcp/ip详解卷二下载

tcp ip详解卷1 协议