《TCP/IP 卷1》笔记：TCP的成块数据流

TCP的成块数据流

引言

本章介绍TCP使用的被称为滑动窗口协议的另一张形式的流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必等待每个分组的确认，因此该协议可以加速数据的传输。
还介绍PUSH标志，此前出现过。介绍慢启动，TCP使用该技术在一个连接上建立数据流。最后介绍成块数据流的吞吐量。

正常数据流

• 前三个报文段是三次握手
• 发送方首先传送3个数据报文段（4-6）。下一个报文段（7）仅确认了前两个数据报文段。从ACK2049，可知是产生了一个经受时延的确认。ack3073也是产生了一个经受时延的确认
• 9，10是正常的发送和产生经受时延的确认
• 14，16分别产生了经受时延的确认
• 17~20 tcp四次挥手

这是另一次传输8192个字节数据，是在图20-1的几分钟之后。

这是一个快的发送方到一个慢的接收方

• 发送方发送了4个数据报文，然后停下来等待一个ACK。
• 接收方发送ACK，但通告其窗口大小为0，说明接收方已收到所有数据，但这些数据都在接收方的TCP缓冲区，在17.4ms后发送了可以接受另外4096字节的数据。虽然这看起来像一个ACK，但由于它并不确认任何新数据，只是用来增加窗口的右边沿，因此称为窗口更新

滑动窗口

接收方通告的窗口称为提出的窗口，它覆盖了从第4字节到第9自己的区域，表明接收方已经确认了包括第三个字节在内的数据，且通告窗口大小为6
当接收方确认数据后，这个滑动窗口不时地向右移动。窗口两个边沿的相对运动增加或减少了窗口的大小。我们使用三个术语来描述窗口左右边沿的运动：

1. 称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时
2. 当窗口右边沿向右移动时将允许发送更多的数据，我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了TCP的接收缓存时
3. 当右边沿向左移动时，我们称之为窗口收缩。RFC强烈建议不要使用这种方式。但TCP必须能够在某一端产生这种情况时进行处理。

窗口的左边沿受另一端发送的确认序号的控制，因此不可能向左边移动。如果接收到一个指示窗口左边沿向左移动的ACK，则它被认为是重复ACK，并被丢弃
如果左边沿到达右边沿，则称其为一个零窗口，此时发送方不能够发送任何数据

图例可以总结如下几点：

1. 发送方不必发送一个全窗口大小的数据
2. 来自接收方的一个报文段确认数据并把窗口向右边移动。这是因为窗口的大小是相对于确认序号的
3. 正如报文段7到报文段8中变化的那样，窗口的大小可以减小，但是窗口的右边沿不能够向左移动
4. 接收方在收到一个ACK前不必等待窗口被填满。在前面我们看到收到两个报文段就发送一个ACK

窗口大小

由接收方提供的窗口的大小通常可以由接收进程控制，这将影响TCP的性能
插口API运行进程设置发送和接收缓存的大小。
设置发送方的发送缓存大小为6144字节，接收方的接收缓存大小为8192字节

• 连续发送了6个报文段后停止
• 13~16位窗口张开通告

PUSH标志

PUSH表示是：发送方使用该标志通知接收方将所收到的数据全部提交给接收进程。这里的数据包括与PUSH一起传送的数据以及接收方TCP已经为接收进程收到的其他数据。
目前大多数的API没有向应用程序提供通知其TCP设置PUSH标志的方法。认为一个好的TCP实现能够自行决定何时设置这个标志。
如果待发送数据将清空发送缓存，则大多数的实现能够自动设置PUSH标志。这意味着我们能够观察到每个应用程序写的数据均被设置了PUSH标志，因为数据在写的时候就立即被发送。
图20-1中8个数据报文段的PUSH标志均被置1，是因为每次写操作均清空了发送缓存。
20-7，我们预计报文段12的PUSH标志被置为1，因为它是最后一个报文段。报文段7被置为PUSH标志是发送方的缓存是4096字节。

当收到为0窗口的通告报文段时，当窗口张开时，需要发送另一个窗口非0的ACK来使发送方重新启动。
图20-7的15~16的窗口更新报文段不是必需的。因为已经收到对方的FIN。
许多TCP实现在窗口大小增加了两个最大报文段长度或者最大可能窗口的50%时发送这个窗口更新。在22.3节详细考察糊涂窗口综合征的时候，我们还会看到这种现象。
作为PUSH标志的另一个例子，看20-3图，看到前4个报文段（4~7）的标志被设置，是因为他们每一个均被TCP产生了一个报文段并提交给IP层。但随后，TCP停下来等待一个确认来移动4096字节的窗口。在此期间，TCP又得到了应用程序的最后的4096个字节的数据。当窗口张开时（报文段9），发送方TCP知道它有4个可立即发送的报文段，因此只设置了最后一个报文段（13）的PUSH标志，这个例子上又可以看出TCP是自主决定什么时候设置PUSH标志。

慢启动

来本章的所有例子中发送方一开始便向网络发送多个报文段，直至达到接收方通告的窗口大小为止。当双方处于同一局域网中是可行的。但是如果双方中间有多个慢速率的网络，就会出现一些问题。一些中间路由器必须缓存分组，并有可能耗尽存储器的空间。有研究证明了这种连接方式如何严重降低了TCP连接的吞吐量的。
TCP需要支持一种被称为“慢启动（slow start）”的算法。该算法通过观察到新分组进入网络的速率应该与另一端返回确认的速率相同而进行工作。
慢启动为发送方的TCP增加了另一个窗口：拥塞窗口（congestion window），记为cwnd。当与另一个网络的主机建立TCP连接时，拥塞窗口被初始化为1个报文段（即另一端通告的报文段大小）。每收到一个ACK，拥塞窗口就增加一个报文段（cwnd以字节为单位，但是慢启动以报文段大小为单位进行增加）。发送方取拥塞窗口与通告窗口中的最小值作为发送上限。拥塞窗口是发送方使用的流量控制，而通告窗口则是接收方使用的流量控制
例子
发送方开始时发送一个报文段，然后等待ACK。当收到该ACK时，拥塞窗口从1增加为2，即可以发送两个报文段。当收到这两个报文段的ACK时，拥塞窗口就增加为4。这是一种指数增加的关系
在某些点上可能达到了互联网的容量，中间路由器开始丢弃分组。这就通知发送方它的拥塞窗口开得过大。下一章将讨论TCP的超时和重传机制，将会看到它们是怎么对拥塞窗口起作用的。

慢启动的例子

当拥塞窗口增加了2个报文段。当收到报文段5的ACK后，拥塞窗口增加为3.此时尽管可以发送多达3个报文段，可是在下一个ACK收到之前，只发送了2个报文段。
在21.6节中再次讨论慢启动，并介绍怎么采用另一种被称为“拥塞避免”的技术来作为通常的实现

成块数据的吞吐量

让我们看一看窗口大小、窗口流量控制以及慢启动对传输成块数据的TCP连接的吞吐量的相互作用。
图20-9显示了发送方和接收方的在一个TCP连接上的时间系列，共显示了16个时间单元。
可以看到time0，发送了一个报文段，time7收到一个ack，拥塞窗口为2，time8、9发送了2，3的报文段。time12和time
13分别发回了两个ACK。这两个返回到发送方的ACK之间的间隔与报文段之间的间隔一致，被称为TCP的自计时行为。

通常发送一个分组的时间取决于两个因素：传播时延（由光的有限速率、传输设备的等待时间等引起）和一个取决于媒体速率（即媒体每秒可传输的比特数）的发送时延。对于一个给定的两个接点之间的通路，传播时延一般是固定的，而发送时延则取决于分组的大小。在速率较慢的情况下发送时延起主要作用（例如，在习题7.2中我们甚至没有考虑传播时延），而在千兆比特速率下传播时延则占主要地位（见图24-6）。

从16~31可以看到，在31的时候管道已经填充满了报文段，为理想状态，发送方收到一个ACK发送一个报文。

带宽时延乘积
窗口大小应该设置为多大的问题。
可以计算通道的容量为

capacity（bit）=bandwidth（b/s）X round-trip time（s）

一般称之为带宽时延乘积。这个值依赖于网络速度（线路的材质和技术）和两端的RTT（线路的长度）。有些线路的网路速度很大，超过了TCP通告窗口的大小（65535字节）。在24.4节我们将讨论能够避免当前TCP限制的新的TCP窗口大小选项。

拥塞

这是典型的拥塞，因为大多数主机都连接在局域网，并通过一个路由器与速率相对较低的广域网相连。
路由器R1是瓶颈，因为从左侧速率较高的局域网接收数据并向右侧速率较低的广域网发送。
在图20-13中已经假定发送方不使用慢启动，它按照局域网的带宽尽可能快地发送编号
为1~20的报文段（假定接收方的通告窗口至少为20个报文段）。正如我们看到的那样，ACK
之间的间隔与在最慢链路上的一致。假定瓶颈路由器具有足够的容纳这20个分组的缓存。
如果这个不能保证，就会引起路由器丢弃分组。在21.6节讨论避免拥塞时会看到怎样避免这
种情况。

紧急方式

TCP提供“紧急方式（urgent mode）”，它使一端可以告诉另一端有些具有某种方式的“紧急数据”已经放置在普通的数据流中。另一端被通知这个紧急数据已被放置在普通数据流中，由接收方决定如何处理。
可以在设置TCP首部中的两个字段来发出这种紧急数据的通知。URG比特被置为1，并且一个16bit的紧急指针被置为一个正的偏移量，该偏移量必须与TCP首部中的序号字段相加，得出是紧急数据的最后一个字节的序号

紧急指针是指向紧急数据的最后一个字节还是最后一个字节的下一个字节，存在争议。RFC解释是最后一个字节。但是需要实现的版本中是最后一个字节的下一个。

TCP必须通知接收进程，何时已接收到一个紧急数据指针以及何时某个紧急数据指针还不在此连接上，或者紧急指针是否在数据流中向前移动。接着接收进程可以读取数据流，并必须能够被告知何时碰到了紧急数据指针。只要从接收方当前读取位置到紧急数据指针之间有数据存在，就认为应用程序处于“紧急方式”。在紧急指针通过之后，应用程序便转回到正常方式。

TCP本身不处理数据，只知道紧急方法开始（URG标志）和指向紧急数据最后一个字节的指针，其他的交给应用程序。

紧急方式有什么用？两个最常见的例子是Telnet和Rlogin。当交互用户键入中断键时使用紧急方法来快速中断这个连接。

小结

进行成块数据传输的最重要的方法是TCP的滑动窗口协议.TCP使得发送方和接收方之间的管道充满来获得最可能快的传输速度而采用的方法。
介绍了TCP的PUSH标志，有TCP自己控制。
介绍了紧急方式，是一种发送方到接收方的通知。

习题

20.1在图20-6中，我们可以看到一个序号为0的字节和一个序号为8193的字节，试问这两个字节的含义是什么？
答： 0是第一个字节。8193是下一个传输报文的起始字节编号

20.2提前观察图22-1，并解释主机bsdi设置PUSH标志的含义。
答：

20.3在一个Usenet记录中，有人抱怨说美国和日本之间的一个128ms时延、速率为256000b/s的链
路吞吐量为120000b/s（利用率为47%），而当链路通过卫星时其吞吐量则为33000b/s（利用
率为13％）。试问在这两种情况下窗口大小各为多少（假定卫星链路的时延为500ms）？卫星
链路的窗口大小应该如何调整？
答： 128/1000 * 256000 / 8=4096字节。 卫星链路 500/1000 * 33000 / 8 =2062.5字节。调小一点，利用率较低。

20.4如果API提供一种方法，使得发送方可以告诉其TCP打开PUSH标志，而接收方可以查询
一个接收的报文段是否被设置了PUSH标志，试问该标志能否被用作一个记录标记？
答： 不能

20.5在图20-3中为什么没有合并报文段15和16？
答： 15是窗口更新报文，16是FIN标志的数据传输完成报文

20.6在图20-13中，我们假定对应数据报文段之间的间隔，返回的ACK之间的间隔被分隔得
很好。如果在链路某处进行缓存并使许多ACK同时到达发送方，试问会发生什么情况？
答： 那么发送方会发送多个报文段到网络中