TCPIPChap1920交互和成块数据流

 

TCP交互和成块数据流

一、        成块数据和交互数据

一些有关T C P通信量的研究发现，

如果按照分组数量计算，约有一半的T C P报文段包含成块数据（如F T P、电子邮件和U s e n e t新闻），另一半则包含交互数据（如Te l n e t和R l o g i n）。

如果按字节计算，则成块数据与交互数据的比例约为9 0 %和1 0 %。这是因为成块数据的报文段基本上都是满长度（ f u l l - s i z e d）的（通常为5 1 2字节的用户数据），而交互数据则小得多（上述研究表明Te l n e t和R l o g i n分组中通常约9 0 %左右的用户数据小于1 0个字节）。

 

二、        交互式输入

首先来观察在一个R l o g i n连接上键入一个交互命令时所产生的数据流。

每次从客户传到服务器的是一个字节的按键（而不是每次一行）。而且，R l o g i n需要远程系统（服务器）回显我们（客户）键入的字符。这样就会产生4个报文段：

（1）来自客户的交互按键；

（2）来自服务器的按键确认；

（3）来自服务器的按键回显；

（4）来自客户的按键回显确认。

经受时延的ACK：通常T C P在接收到数据时并不立即发送A C K；相反，它推迟发送，以便将A C K与需要沿该方向发送的数据一起发送（有时称这种现象为数据捎带A C K）。绝大多数实现采用的时延为200 ms，也就是说，T C P将以最大200 ms 的时延等待是否有数据一起发送。

 

三、局域网（交互数据流/小分组）、广域网（Nagle算法）

在一个R l o g i n连接上客户一般每次发送一个字节到服务器，这就产生了一些4 1字节长的分组：2 0字节的I P首部、2 0字节的T C P首部和1个字节的数据。在局域网上，这些小分组（被称为微小分组（ t i n y g r a m））通常不会引起麻烦，因为局域网一般不会出现拥塞。但在广域网上，这些小分组则会增加拥塞出现的可能。

 

一种简单和好的方法就是采用RFC 896 [Nagle 1984]中所建议的N a g l e算法。

该算法要求一个T C P连接上最多只能有一个未被确认的未完成的小分组，在该分组的确

认到达之前不能发送其他的小分组。相反， T C P收集这些少量的分组，并在确认到来时以一个分组的方式发出去。该算法的优越之处在于它是自适应的：确认到达得越快，数据也就发送得越快。而在希望减少微小分组数目的低速广域网上，则会发送更少的分组。

 

有时我们也需要关闭N a g l e算法。一个典型的例子是X窗口系统服务器（见3 0 . 5节）：小消息（鼠标移动）必须无时延地发送，以便为进行某种操作的交互用户提供实时的反馈。

 

三、滑动窗口协议

3.1 停止等待协议 VS 滑动窗口协议

T F T P使用了停止等待协议。数据发送方在发送下一个数据块之前需要等待接收对已发送数据的确认。

我们将介绍T C P所使用的被称为滑动窗口协议的另一种形式的流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。

3.2 经受时延的ACK VS 时延定时器溢出ACK

报文段7的A C K的序号之所以是2 0 4 8而不是3 0 7 3是由以下原因造成的：当一个分组到达时，它首先被设备中断例程进行处理，然后放置到I P的输入队列中。三个报文段4、5和6依次到达并按接收顺序放到I P的输入队列。I P将按同样顺序将它们交给T C P。当T C P处理报文段4时，该连接被标记为产生一个经受时延的确认。T C P处理下一报文段（5），由于T C P现在有两个未完成的报文段需要确认，因此产生一个序号为2 0 4 8的A C K（报文段7），并清除该连接产生经受时延的确认标志。T C P处理下一个报文段（ 6），而连接又被标志为产生一个经受时延的确认。在报文段9到来之前，由于时延定时器溢出，因此产生一个序号为3 0 7 3的A C K（报文段8）。报文段8中的窗口大小为3 0 7 2，表明在T C P的接收缓存中还有1 0 2 4个字节的数据等待被应用程序读取。

3.3具体定义

窗口左边沿，受收到ACK序号确定。

窗口大小（offered window提出窗口）由得到的窗口大小决定。

窗口大小标示接受方能够接受的总数据的大小，包括已经发送和可用窗口之和。

三个运动：

1) 称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。

2) 当窗口右边沿向右移动时将允许发送更多的数据，我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了T C P的接收缓存时。

3) 当右边沿向左移动时，我们称之为窗口收缩。Host Requirements RFC强烈建议不要使用这种方式。但T C P必须能够在某一端产生这种情况时进行处理。

例子：

1）发送方不必发送一个全窗口大小的数据。

2) 来自接收方的一个报文段确认数据并把窗口向右边滑动。

3) 正如从报文段7到报文段8中变化的那样，窗口的大小可以减小，但是窗口的右边沿却

不能够向左移动。

4) 接收方在发送一个A C K前不必等待窗口被填满。在前面我们看到许多实现每收到两个

报文段就会发送一个A C K。

 

四、PUSH标示和慢启动

4.1PUSH标示

发送方使用该标志通知接收方将所收到的数据全部提交给接收进程。这里的数据包括与P U S H一起传送的数据以及接收方T C P已经为接收进程收到的其他数据。

在最初的T C P规范中，一般假定编程接口允许发送进程告诉它的T C P何时设置P U S H标志。例如，在一个交互程序中，当客户发送一个命令给服务器时，它设置P U S H标志并停下来等待服务器的响应。通过允许客户应用程序通知其T C P设置P U S H标志，客户进程通知T C P在向服务器发送一个报文段时不要因等待额外数据而使已提交数据在缓存中滞留。类似地，当服务器的T C P接收到一个设置了P U S H标志的报文段时，它需要立即将这些数据递交给服务器进程而不能等待判断是否还会有额外的数据到达。

然而，目前大多数的A P I没有向应用程序提供通知其T C P设置P U S H标志的方法。的确，许多实现程序认为P U S H标志已经过时，一个好的T C P实现能够自行决定何时设置这个标志。

 

4.2慢启动

发送方一开始便向网络发送多个报文段，直至达到接收方通告的窗口大小为止。当发送方和接收方处于同一个局域网时，这种方式是可以的。但是如果在发送方和接收方之间存在多个路由器和速率较慢的链路时，就有可能出现一些问题。

一些中间路由器必须缓存分组，并有可能耗尽存储器的空间。证明了这种连接方式是如何严重降低了T C P连接的吞吐量的。

现在，T C P需要支持一种被称为“慢启动(slow start)”的算法。该算法通过观察到新分组

进入网络的速率应该与另一端返回确认的速率相同而进行工作。

慢启动为发送方的T C P增加了另一个窗口：拥塞窗口(congestion window)，记为c w n d。当与另一个网络的主机建立T C P连接时，拥塞窗口被初始化为1个报文段（即另一端通告的报文段大小）。每收到一个A C K，拥塞窗口就增加一个报文段（ c w n d以字节为单位，但是慢启动以报文段大小为单位进行增加）。发送方取拥塞窗口与通告窗口中的最小值作为发送上限。拥塞窗口是发送方使用的流量控制，而通告窗口则是接收方使用的流量控制。

发送方开始时发送一个报文段，然后等待A C K。当收到该A C K时，拥塞窗口从1增加为2，即可以发送两个报文段。当收到这两个报文段的A C K时，拥塞窗口就增加为4。这是一种指数增加的关系。

 

 

五、TCP传输吞吐量

5.1理想状态

发送方和接收方之间的管道( p i p e )被填满。此时不论拥塞窗口和通告窗口是多少，它都不能再容纳更多的数据。每当接收方在某一个时间单位从网络上移去一个报文段，发送方就再发送一个报文段到网络上。但是不管有多少报文段填充了这个管道，返回路径上总是具有相同数目的A C K。这就是连接的理想稳定状态。

5.2带宽时延乘积

可以计算通道的容量为：

c a p a c i t y (bit) = b a n d w i d t h (b/s) × ro u n d-trip time ( s )

一般称之为带宽时延乘积。这个值依赖于网络速度和两端的RT T，可以有很大的变动。例如，一条穿越美国（RT T约为60 ms）的T 1的电话线路（1 544 000 b/s）的带宽时延乘积为11 580字节。

5.3拥塞

当数据到达一个大的管道（如一个快速局域网）并向一个较小的管道（如一个较慢的广域网）发送时便会发生拥塞。当多个输入流到达一个路由器，而路由器的输出流小于这些输

入流的总和时也会发生拥塞。

 

 

六、紧急方式

6.1定义

T C P提供了“紧急方式( u rgent mode) ”，它使一端可以告诉另一端有些具有某种方式的

“紧急数据”已经放置在普通的数据流中。另一端被通知这个紧急数据已被放置在普通数据流中，由接收方决定如何处理。

可以通过设置T C P首部（图1 7 - 2）中的两个字段来发出这种从一端到另一端的紧急数据

已经被放置在数据流中的通知。U R G比特被置1，并且一个1 6 b i t的紧急指针被置为一个正的偏移量，该偏移量必须与T C P首部中的序号字段相加，以便得出紧急数据的最后一个字节的序号。

 

6.2紧急方式不是带外数据

许多实现不正确地称T C P的紧急方式为带外数据(out-of-band data)。如果一个应用程序确实需要一个独立的带外信道，第二个T C P连接是达到这个目的的最简单的方法

（许多运输层确实提供许多人认为的那种真正的带外数据：使用同一个连接的独立的逻辑数据通道作为正常的数据通道。这是T C P所没有提供的）。

 

6.3应用

两个最常见的例子是Te l n e t和R l o g i n。当交互用户键入中断键时，我们在第2 6章将看到使用紧急方式来完成这个功能的例子。另一个例子是F T P，当交互用户放弃一个文件的传输时，我们将在第2 7章看到这样的一个例子。

Te l n e t和R l o g i n从服务器到客户使用紧急方式是因为在这个方向上的数据流很可能要被客户的T C P停止（也即，它通告了一个大小为0的窗口）。但是如果服务器进程进入了紧急方式，尽管它不能够发送任何数据，服务器T C P也会立即发送紧急指针和U R G标志。当客户T C P接收到这个通知时就会通知客户进程，于是客户可以从服务器读取其输入、打开窗口并使数据流动。