在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.滑动窗口协议
2.窗口大小
为了优化上述问题，比如我让发送的每一个包都有一个ID，接收端必须对每一个包进行确认，这样设备A一次多发送几个片段，而不必等候ACK，同时接收端也要告知它能够收多少，这样发送端发起来也有个限制，当然还需要保证顺序性，不要乱序，对于乱序的状况，我们可以允许等待一定情况下的乱序，比如说先缓存提前到的数据，然后去等待需要的数据，如果一定时间没来就丢弃掉，来保证顺序性。在TCP/IP协议栈中，滑动窗口的引入可以解决此问题。
发送方发送窗口和接收端接收窗口一一对应，告诉接收端接收区缓存是多少。
理解前提
1、“窗口”对应的是一段可以被发送者发送的字节序列，其连续的范围称之为“窗口”。
2、 “滑动”则是指这段“允许发送的范围”是可以随着发送的过程而变化的，方式就是按顺序“滑动”。在引入一个例子来说这个协议之前，我觉得很有必要先了解以下前提：
- TCP协议的两端分别为发送者A和接收者B，由于是全双工协议，因此A和B应该分别维护着一个独立的发送缓冲区和接收缓冲区，由于对等性（A发B收和B发A收），我们以A发送B接收的情况作为例子；
- 发送窗口是发送缓存中的一部分，是可以被TCP协议发送的那部分，其实应用层需要发送的所有数据都被放进了发送者的发送缓冲区；
- 发送窗口中相关的有四个概念：已发送并收到确认的数据（不再发送窗口和发送缓冲区之内）、已发送但未收到确认的数据（位于发送窗口之中）、允许发送但尚未发送的数据以及发送窗口外发送缓冲区内暂时不允许发送的数据；
- 每次成功发送数据（发送且收到了ACK）之后，发送窗口就会在发送缓冲区中按顺序移动，将新的数据包含到窗口中准备发送；
3.PUSH标志
慢启动：
前边的TCP连接，可以看到，当连接建立后，发送端总是一下发送好几个分组过去，直至达到接收方的通告窗口大小为止。
当然这种策略在局域网中，几乎没有什么问题。但是如果发送方和接收方之间是一个存在着多个路由器和速率较慢的链路时，这就可能出现拥塞的问题...
TCP需要支持一种慢启动的算法。顾名思义，是一点点加速，而不是一次传太多过去。
实现原理:发送方需要支持一个窗口，拥塞窗口（congestion window,cwnd）。当TCP连接建立好以后，拥塞窗口被初始化为1个报文段，发送端每收到ACK，就在cwnd中增加报文段（比如说这个ACK是确认的一个报文段，那么我就增加一个报文段；下次我就发俩报文段，收到这俩的ACK后，我就增加到4个报文段长度。有点类似于成倍增加，这就是慢启动）。那么现在有两个窗口了，发送端传数据的时候是用拥塞窗口大小还是接收端的通告窗口大小呢？这里是取两者中较小的一个大小。