TCP的交互数据流

在TCP进行数据传输时，可以分为成块数据流和交互数据流两种，如果按字节计算，成块数据与交互数据的比例约为90%和10%，TCP需要同时处理这两类数据，且处理的算法不同。

书籍本章中以Rlogin应用为例观察交互数据的传输过程。提示经受时延的确认是如何工作以及Nagle算法怎样减少了通过广域网络传输的小分组的数目。

交互式输入

经受时延的确认
上图第二，三个报文段可以合并---按键确认和按键回显一起发送。这种技术叫做经受时延的确认。
通常TCP在接收到数据时并不立即发送ACK，相反，它推迟发送，以便将ACK与需要沿该方向发送的数据一起发送（有时这种现象为数据捎带的ACK）。绝大数实现采用的时延为200ms，也就是说，TCP将以最大200ms的时延等待是否有数据一起发送。

ACK延时等待时间不大于TCP定时器的原因:
假如TCP使用200ms的定时器，该定时器将相对于内核引导的200ms固定时间溢出，由于将要确定的数据随机到达，TCP将在下一次内核的200ms定时器溢出时得到通知，所以ACK实际等待的时间为1~200ms中任一刻。

Nagle算法
Nagle算法要求TCP连接上最多只有一个未被确认的未完成小分组，在该分组确认到达之前不能发送其他的小分组。相反，TCP收集这些少量的分组，并在确认到达时以一个大的分组发出去。

流程:
(1)发送端TCP将从应用进程接收到的第一数据块立即发送，不管其大小，哪怕只有一个字节。
(2)发送端输出第一块数据后开始收集数据，并等待确认。
(3)确认未达到时，若收集数据达到窗口的一半或一个MSS段，立即发送。
(4)确认到达后，把缓冲区中的数据组成一个TCP段，然后发送。

TCP的成块数据流

1.滑动窗口协议

            TCP滑动窗口的可视化表示

 我们将字节从1到11进行标号，接收方通告的窗口称为提供的窗口，它覆盖了第4字节到第9字节的数据，且通告窗口大小为6。发送方计算接收者的可用窗口，以便确定有多少数据可以被立即发送。当接收方确认数据后，这个滑动窗口向右移动。窗口两个边沿的相向运动有以下3种情况：

    （1）在数据被发送和确认时，窗口左边沿向右边沿靠近，称为窗口合拢。

    （2）在另一端接收进程读取已经确认的数据并释放了TCP接收缓存时，窗口右边沿向右移动，称为窗口张开，此时允许发送更多的数据。

    （3）当右边沿向左移动时，称为窗口收缩。这种方式不被建议。

2.窗口大小

 

    接收方的窗口大小通常可以由接收进程控制，这将影响TCP的性能。对于以太网来说，默认的4096字节并不是最理想的大小，提高窗口的大小 有时 可以提高网络的吞吐量。

 

理解窗口

IP层协议属于不可靠的协议，IP层并不关心数据是否发送到了对端，TCP通过确认机制来保证数据传输的可靠性，在比较早的时候使用的是send–wait–send的模式，其实这种模式叫做stop-wait模式，发送数据方在发送数据之后会启动定时器，如果数据或者ACK丢失，那么定时器到期之后，收不到ACK就认为发送出现状况，要进行重传，这样就会降低了通信的效率。 
为了优化上述问题，比如我让发送的每一个包都有一个ID，接收端必须对每一个包进行确认，这样设备A一次多发送几个片段，而不必等候ACK，同时接收端也要告知它能够收多少，这样发送端发起来也有个限制，当然还需要保证顺序性，不要乱序，对于乱序的状况，我们可以允许等待一定情况下的乱序，比如说先缓存提前到的数据，然后去等待需要的数据，如果一定时间没来就丢弃掉，来保证顺序性。在TCP/IP协议栈中，滑动窗口的引入可以解决此问题。 
发送方发送窗口和接收端接收窗口一一对应，告诉接收端接收区缓存是多少。 

 

理解前提 
1、“窗口”对应的是一段可以被发送者发送的字节序列，其连续的范围称之为“窗口”。 
2、 “滑动”则是指这段“允许发送的范围”是可以随着发送的过程而变化的，方式就是按顺序“滑动”。在引入一个例子来说这个协议之前，我觉得很有必要先了解以下前提：

• TCP协议的两端分别为发送者A和接收者B，由于是全双工协议，因此A和B应该分别维护着一个独立的发送缓冲区和接收缓冲区，由于对等性（A发B收和B发A收），我们以A发送B接收的情况作为例子；
• 发送窗口是发送缓存中的一部分，是可以被TCP协议发送的那部分，其实应用层需要发送的所有数据都被放进了发送者的发送缓冲区；
• 发送窗口中相关的有四个概念：已发送并收到确认的数据（不再发送窗口和发送缓冲区之内）、已发送但未收到确认的数据（位于发送窗口之中）、允许发送但尚未发送的数据以及发送窗口外发送缓冲区内暂时不允许发送的数据；
• 每次成功发送数据（发送且收到了ACK）之后，发送窗口就会在发送缓冲区中按顺序移动，将新的数据包含到窗口中准备发送；

3.PUSH标志

 

    发送方使用该标志通知接收方将所收到的数据全部提交给接收进程，这里的数据包括与PUSH一起传送的数据 以及 接收方TCP已经为接收进程收到的其他数据。

特点：

（1）通过设置PUSH标志，客户进程通知TCP在向服务器发送一个报文段时不要因等待额外数据而使已提交数据在缓存中滞留。

（2）当服务器接收到设置了PUSH标志的报文段时，它需要立即将这些数据提交给服务器进程而不能等待判断是否还会有额外数据到达。

（3）如果待发送数据将清空发送缓存，则自动设置PUSH标志（大多数源自伯克利的实现）。

慢启动：

前边的TCP连接，可以看到，当连接建立后，发送端总是一下发送好几个分组过去，直至达到接收方的通告窗口大小为止。
当然这种策略在局域网中，几乎没有什么问题。但是如果发送方和接收方之间是一个存在着多个路由器和速率较慢的链路时，这就可能出现拥塞的问题...
TCP需要支持一种慢启动的算法。顾名思义，是一点点加速，而不是一次传太多过去。
实现原理:发送方需要支持一个窗口，拥塞窗口（congestion window,cwnd）。当TCP连接建立好以后，拥塞窗口被初始化为1个报文段，发送端每收到ACK，就在cwnd中增加报文段（比如说这个ACK是确认的一个报文段，那么我就增加一个报文段；下次我就发俩报文段，收到这俩的ACK后，我就增加到4个报文段长度。有点类似于成倍增加，这就是慢启动）。那么现在有两个窗口了，发送端传数据的时候是用拥塞窗口大小还是接收端的通告窗口大小呢？这里是取两者中较小的一个大小。