020tcp的成块数据流.pdfVIP

下载 第20章 TCP 的成块数据流 20.1 引言 在第 1 5章我们看到T F T P使用了停止等待协议。数据发送方在发送下一个数据块之前需要 等待接收对已发送数据的确认。本章我们将介绍 T C P所使用的被称为滑动窗口协议的另一种 形式的流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于 发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。 我们还将介绍T C P 的P U S H标志，该标志在前面的许多例子中都出现过。此外，我们还要 介绍慢启动，T C P使用该技术在一个连接上建立数据流，最后介绍成块数据流的吞吐量。 20.2 正常数据流 我们以从主机 s v r 4单向传输 8 1 9 2个字节到主机 b s d i开始。在b s d i上运行 s o c k程序作 为服务器： bsdi % sock -i -s 7777 其中，标志 - i和- s指示程序作为一个“吸收（ s i n k ）”服务器运行（从网络上读取并丢弃 数据），服务器端口指明为7 7 7 7 。相应的客户程序运行为： svr4 % sock -i -n8 bsdi 7777 该命令指示客户向网络发送 8个1 0 2 4字节的数据。图 2 0 - 1显示了这个过程的时间系列。我 们在输出的前3个报文段中显示了每一端 M S S 的值。 发送方首先传送3个数据报文段（4 ~ 6 ）。下一个报文段（7 ）仅确认了前两个数据报文段， 这可以从其确认序号为2 0 4 8而不是3 0 7 3看出来。 报文段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个字节的数据等待被应用程 序读取。 报文段 11 ~ 1 6说明了通常使用的“隔一个报文段确认”的策略。报文段 11、1 2和1 3到达并 被放入 I P 的接收队列。当报文段 11被处理时，连接被标记为产生一个经受时延的确认。当报 文段 1 2被处理时，它们的 A C K （报文段1 4 ）被产生且连接的经受时延的确认标志被清除。报 文段 1 3使得连接再次被标记为产生经受时延。但在时延定时器溢出之前，报文段 1 5处理完毕， 因此该确认立刻被发送。 210使用TCP/IP详解，卷1：协议 下载 图20-1 从s v r 4传输8192个字节到b s d i 注意到报文段7 、1 4和1 6中的A C K确认了两个收到的报文段是很重要的。使用 T C P 的滑动 窗口协议时，接收方不必确认每一个收到的分组。在 T C P 中，A C K 是累积的—它们表示接 收方已经正确收到了一直到确认序号减 1的所有字节。在本例中，三个确认的数据为 2 0 4 8字节 而两个确认的数据为 1 0 2 4字节（忽略了连接建立和终止中的确认）。 用t c p d u m p看到的是T C P 的动态活动情况。我们在线路上看到的分组顺序依赖于许多无 法控制的因素：发送方 T C P 的实现、接收方T C P 的实现、接收进程读取数据（依赖于操作系统 的调度）和网络的动态性（如以太网的冲突和退避等）。对这两个T C P而言，没有一种单一的、 正确的方法来交换给定数量的数据。 为显示情况可能怎样变化，图 2 0 - 2 显示了在同样两个主机之间交换同样数据时的另一个