dede做网站地图,wordpress数据库连接方法,安徽城乡建设厅官网站,1 童装网站建设目标20.1 引言
在第15章我们看到TFTP使用了停止等待协议。数据发送方在发送下一个数据块之前需要等待接收对已发送数据的确认。本章我们将介绍TCP所使用的被称为滑动窗口协议的另一种形式的流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必…20.1 引言
在第15章我们看到TFTP使用了停止等待协议。数据发送方在发送下一个数据块之前需要等待接收对已发送数据的确认。本章我们将介绍TCP所使用的被称为滑动窗口协议的另一种形式的流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认因此该协议可以加速数据的传输。
我们还将介绍TCP的PUSH标志该标志在前面的许多例子中都出现过。此外我们还要介绍慢启动TCP使用该技术在一个连接上建立数据流最后介绍成块数据流的吞吐量。
20.2 正常数据流
我们以从主机svr4单向传输8192个字节到主机bsdi开始。在bsdi上运行sock程序作为服务器
其中标志-i和-s指示程序作为一个“吸收sink”服务器运行从网络上读取并丢弃数据服务器端口指明为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处理完毕因此该确认立刻被发送。
注意到报文段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三个确认了2 0 4 8字节另一个确认了1024字节。最后1024字节数据的ACK出现在报文段17中它与FIN的ACK一道发送比较该图中的报文段17与图20-1中的报文段16和18。
快的发送方和慢的接收方
图20-3显示了另外一个时间系列。这次是从一个快的发送方一个Sparc工作站到一个慢的接收方配有慢速以太网卡的80386机器。它的动态活动情况又有所不同。
发送方发送4个背靠背back-to-back的数据报文段去填充接收方的窗口然后停下来等待一个ACK。接收方发送ACK报文段8但通告其窗口大小为0这说明接收方已收到所有数据但这些数据都在接收方的TCP缓冲区因为应用程序还没有机会读取这些数据。另一个ACK称为窗口更新在17.4ms后发送表明接收方现在可以接收另外的4096个字节的数据。虽然这看起来像一个ACK但由于它并不确认任何新数据只是用来增加窗口的右边沿因此被称为窗口更新。
发送方发送最后4个报文段10~13再次填充了接收方的窗口。注意到报文段13中包括两个比特标志PUSH和FIN。随后从接收方传来另外两个ACK它们确认了最后的4096字节的数据从4097到8192字节和FIN标号为8192。
