第20章TCP的成块数据流.doc

下载 第20章 TCP的成块数据流 20.1 引言 在第15章我们看到 TFTP使用了停止等待协议。数据发送方在发送下一个数据块之前需要 等待接收对已发送数据的确认。本章我们将介绍 TCP所使用的被称为滑动窗口协议的另一种 形式的流量控制方法。该协议允许发送方在停止?}等待确认前可以连续发送多个分组。由于 发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。 我们还将介绍 TCP的PUSH标志，该标志在前面的许多例子中都出现过。此外，我们还要 介绍慢启动， TCP使用该技术在一个连接上建立数据流，最后介绍成块数据流的吞吐量。 20.2 正常数据流 我们以从主机 svr4单向传输 8192个字节到主机 bsdi开始。在 bsdi上运行 sock?{序作 为服务器： bsdi % sock -i -s 7777 其中，标志 -i和-s指示?{序作为一个“吸收（ sink）”服务器运行（从网络上读取?}丢弃 数据），服务器端口指明为 7777。相应的客户?{序运行为： svr4 % sock -i -n8 bsdi 7777 该命令指示客户向网络发送 8个1024字节的数据。图 20-1显示了这个过?{的时间系列。我 们在输出的前 3个报文段中显示了每一端 MSS的值。 发送方首先传送 3个数据报文段（ 4~6）。下一个报文段（ 7）仅确认了前两个数据报文段， 这可以从其确认序号为 2048而不是3073看出来。 报文段7的ACK的序号之所以是 2048而不是3073是由以下原因造成的：当一个分组到达时， 它首先被设备中断例?{进行处理，然后放置到 IP的输入队列中。三个报文段 4、5和6依次到达 ?}按接收顺序放到 IP的输入队列。 IP将按同样顺序将它们交给 TCP。当 TCP处理报文段 4时， 该连接被标记为产生一个经受时延的确认。 TCP处理下一报文段（ 5），由于TCP现在有两个未 完成的报文段需要确认，因此产生一个序号为 2048的ACK（报文段 7），?}清除该连接产生经 受时延的确认标志。 TCP处理下一个报文段（ 6），而连接又被标志为产生一个经受时延的确 认。在报文段9到来之前，由于时延定时器溢出，因此产生一个序号为 3073的ACK（报文段 8）。 报文段 8中的窗口大小为 3072，表明在 TCP的接收缓存中还有 1024个字节的数据等待被应用?{ 序读取。 报文段11~16说明了通常使用的“隔一个报文段确认”的策略。报文段 11、12和13到达?} 被放入 IP的接收队列。当报文段 11被处理时，连接被标记为产生一个经受时延的确认。当报 文段12被处理时，它们的 ACK（报文段 14）被产生且连接的经受时延的确认标志被清除。报 文段13使得连接再次被标记为产生经受时延。但在时延定时器溢出之前，报文段 15处理完毕， 因此该确认立刻被发送。 图20-1 从svr4 传输8192个字节到bsdi 注意到报文段 7、14和16中的ACK确认了两个收到的报文段是很重要的。使用 TCP的滑动 窗口协议时，接收方不必确认每一个收到的分组。在 TCP中，ACK是累积的—它们表示接 收方已经正确收到了一直到确认序号减 1的所有字节。在本例中，三个确认的数据为 2048字节 而两个确认的数据为 1024字节（忽略了连接建立和终止中的确认）。 用tcpdump看到的是 TCP的动态活动情况。我们在线路上看到的分组顺序依赖于许多无 法控制的因素：发送方 TCP的实现、接收方 TCP的实现、接收进?{读取数据（依赖于操作系统 的调度）和网络的动态性（如以太网的冲突和退避等）。对这两个TCP而言，没有一种单一的、 正确的方法来交换给定数量的数据。 为显示情况可能怎样变化，图 20-2显示了在同样两个主机之间交换同样数据时的另一个 时间系列，它们是在图 20-1所示的几分钟之后截获的。 一些情况发生了变化。这一次接收方没有发送一个序号为 3073的ACK，而是等待?}发送 序号为 4097的ACK。接收方仅发送了 4个ACK（报文段 7、10、12和15）：三个确认了 2048字 节，另一个确认了 1024字节。最后 1024字节数据的 ACK出现在报文段 17中，它与 FIN的ACK 一道发送（比较该图中的报文段 17与图20-1中的报文段 16和18）。 图20-2 从svr4 到bsdi 的另外8192字节数据的传输过?{ 快的发送方和慢的接收方 图20-3显示了另外一个时间系列。这次是从一个快的发送方（一个 Sparc工作站）到一个 慢的接收方（配有慢速以太网卡的 80386机器）。它的动态活动情况又有所不同。 发送方发送 4个背靠背（ back-to-back）的数据报文段去填充接收方的窗