TCP-IP详解卷1-20：TCP的成块数据流

TCP-IP详解卷1-20：TCP的成块数据流

一：正常数据流，“隔一个报文段确认”

1： TCP通常不会对每个到达的数据分段进行确认操作，一个ACK报文可以确认多个成块数据报文，一般情况下两个成块数据报文段需要一个ACK报文确认。

即ACK并不立即发送，而是使用一个200ms的定时器，在有数据需要发送、或定时器到时才发送ACK。理由如下：

A： 当收到一个报文后，此TCP连接被表示成一个未完成的延时确认，当再次收到一个报文后，此时连接有两个未确认的报文段，TCP马上发送一个ACK。

B： 当第三个数据报文到达后，第四个报文到达前，这时此TCP连接已经过了200MS延时。因此一个ACK被发送。

C： 这样周而复始，出现一个ACK确认两个数据报文的情况。

D： 而且ACK得产生很大程度上和其接受数据报文段的时间紧密相关，即和Client端发送数据报的频率相关，和网络拥塞程度相关，和Client及Server两端的处理能力相关。

二：滑动窗口：TCP使用滑动窗口来进行流量控制。

1： 滑动窗口(Sliding window )是一种流量控制技术。

早期的网络通信中,通信双方不会考虑网络的拥挤情况直接发送数据。

由于大家不知道网络拥塞状况，一起发送数据,导致中间结点阻塞掉包,谁也发不了数据。所以就有了滑动窗口机制来解决此问题。

需要注意的是滑动窗口是针对每一个TCP连接的，而且是有方向的，所以一个TCP连接应该有两个滑动窗口，每个数据传输方向上有一个，而不是针对连接的每一端。

2： 窗口两个边沿的相对运动增加或减少了窗口的大小。我们使用三个术语来描述窗口左右边沿的运动：

A： 窗口合拢，即窗口左边延右边滑动，表示发送方发送了数据或者接收到了确认。

B： 窗口张开，即窗口右边延右边滑动，表示数据已经被用户空间进程接受并且释放了缓存。

C： 窗口收缩，即窗口右边延左边滑动，

2： TCP中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。

发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。

当滑动窗口为0时，发送方一般不能再发送数据报，但有两种情况除外，

一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。

另一种情况是发送方可以发送一个1字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

3： 滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；

接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。

发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。

不同的滑动窗口协议窗口大小一般不同。

发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。

接收方数据链路层的窗口对应于它可以接受的帧。任何落在外面的帧都被丢弃，无需任何提示。

4： 下面举一个例子（假设发送窗口尺寸为2，接收窗口尺寸为1）：

A： 初始态，发送方没有帧发出，发送窗口前后沿相重合。接收方0号窗口打开，等待接收0号帧；

B： 发送方打开0号窗口，表示已发出0帧但尚确认返回信息。此时接收窗口状态不变；

C： 发送方打开0、1号窗口，表示0、1号帧均在等待确认之列。至此，发送方打开的窗口数已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧。接收窗口此时状态仍未变；

D： 接收方已收到0号帧，0号窗口关闭，1号窗口打开，表示准备接收1号帧。此时发送窗口状态不变；

E： 发送方收到接收方发来的0号帧确认返回信息，关闭0号窗口，表示从重发表中删除0号帧。此时接收窗口状态仍不变；

F： 发送方继续发送2号帧，2号窗口打开，表示2号帧也纳入待确认之列。至此，发送方打开的窗口又已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧，此时接收窗口状态仍不变；

G： 接收方已收到1号帧，1号窗口关闭，2号窗口打开，表示准备接收2号帧。此时发送窗口状态不变；

H： 发送方收到接收方发来的1号帧收毕的确认信息，关闭1号窗口，表示从重发表中删除1号帧。此时接收窗口状态仍不变。

5： 1比特滑动窗口协议：发送窗口=1，接收窗口=1；

当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop－and－wait）。

该协议规定发送方每发送一帧后就要停下来，等待接收方已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。

由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。

由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。

6： 后退n协议： 发送窗口>1，接收窗口=1

由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议。

后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。

且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧，就要重发相应的数据帧。

如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。 　　

从这里不难看出，后退n协议一方面因连续发送数据帧而提高了效率，

但另一方面，在重传时又必须把原来已正确传送过的数据帧进行重传（仅因这些数据帧之前有一个数据帧出了错），这种做法又使传送效率降低。

由此可见，若传输信道的传输质量很差因而误码率较大时，连续测协议不一定优于停止等待协议。

此协议中的发送窗口的大小为k，接收窗口仍是1。

7： 选择重传协议：发送窗口>1,接收窗口>1

在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是正确到达的帧，这显然是一种浪费。

另一种效率更高的策略是当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。

一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。

三：窗口大小

TCP窗口大小一般由接收方确认，即在TCP建链的第二个SYN+ACK报文的WIN字段确认。

接收方提供的窗口大小通常可以由接受进行控制。默认窗口大小事4096个字节。

四：PUSH标志

1： PUSH是TCP包头中的一个标志位，发送方在发送数据的时候可以设置这个标志位。

该标志通知接收方将接收到的数据全部提交给接受进程。这里所说的接收数据包括与此PUSH包一起传输的数据以及之前就为该进程传输过的数据。

2： 当Server端收到这些数据后，它需要立刻将这些数据提交给应用层进程，而不再等待是否还有额外的数据到达。

3： PUSH标志位的设置现在都有TCP协议自行处理，而不是交给应用层处理。

如，当发送的数据会清空发送缓存时，栈就会自动将此包设置PUSH标志。

五：慢启动

1： TCP在局域网环境中效率是很高的，但是到了广域网情况就不同了。

在发送方和接收方之间可能存在多个路由器及一些速率比较慢的链路，而且一些中继路由器必须缓存分组，还可能分片，这是TCP效率可能会出现问题。

2： TCP需要支持一种被称为“慢启动”的算法。改算法通过观察新分组进入网络的速率应该与另一端返回确认的速率相同时而进行工作。

3： 慢启动为发送方的TCP增加了另一个窗口：拥塞窗口(congestion window)，记为cwnd。

当与另一个网络的主机建立TCP连接时，拥塞窗口被初始化为1个报文段（即另一端通告的报文段大小）。

每收到一个ACK，拥塞窗口就增加一个报文段（cwnd以字节为单位，但是慢启动以报文段大小为单位进行增加）。

发送方取拥塞窗口与通告窗口中的最小值作为发送上限。拥塞窗口是发送方使用的流量控制，而通告窗口则是接收方使用的流量控制。

六：成块数据的吞吐量

1： RTT：往返时间，指一个报文段冬发出去到收到此报文段的ACK所经历的实际那。通常一个报文段的RTTI与传播时延和发送时延两因素相关。

对于一个给定的两个接点之间的通路，传播时延一般是固定的，而发送时延则取决于分组的大小。

在速率较慢的情况下发送时延起主要作用，而在千兆比特速率下传播时延则占主要地位

2： 在发送过程中可能会发生这种情况，即TCP两端的传输“管道”被填满，即整个管道上都有数据在跑，此时不管拥塞窗口和通告窗口是多少，官道上都不能再容纳更多的数据了。

每当接收方在某一个时间单位从网络上移去一个报文段，发送方就再发送一个报文段到网络上。但是不管有多少报文段填充了这个管道，返回路径上总是具有相同数目的A C K。这就是连接的理想稳定状态。

3： 宽带时延乘积：容量=带宽*RTT。

因此增加RTT可以增加一条线路的容量（RTT的加大意味着传输时间减小）

4： 拥塞

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

这种情况常发生于局域网和广域网的接口处。

如果发送发处于局域网，而且不适用慢启动，使用局域网的宽带尽快的发送报文，那么返回的ACK之间的间隔与最慢的广域链路一致。

而且，由于路由器转发包的速度慢，所以路由器就有可能主动丢失分组包。

5： 紧急方式

A： TCP提供了“紧急方式( u rgent mode) ”，它使一端可以告诉另一端有些具有某种方式的“紧急数据”已经放置在普通的数据流中。另一端被通知这个紧急数据已被放置在普通数据流中，由接收方决定如何处理。

可以通过设置TCP首部中的两个字段来发出这种从一端到另一端的紧急数据已经被放置在数据流中的通知。

URG比特被置1，并且一个16bit的紧急指针被置为一个正的偏移量，该偏移量必须与TCP首部中的序号字段相加，以便得出紧急数据的最后一个字节的序号。

B： TCP本身对紧急数据知之甚少。没有办法指明紧急数据从数据流的何处开始。

TCP通过连接传送的唯一信息就是紧急方式已经开始（ TCP首部中的URG比特）和指向紧急数据最后一个字节的指针。

C： 用于：

最常见的例子是Telnet和Rlogin。当交互用户键入中断键时，使用紧急方式来完成这个功能的例子。

FTP，当交互用户放弃一个文件的传输时，