19.TCP的交互数据流

介绍

TCP通讯中，按分组数量算，块数据占一半，交互数据占一半；按字节数算，块数据占9成，交互数据占1成。TCP同时处理这两类数据，可是使用了不一样的算法

交互式输入

Rlogin提供交互式输入，大部分都是小数据

数据交互过程：

一般能够将报文段2（确认）和报文段3（回显）合并减小网络负载

经受时延的ACK

一般TCP接收到数据并非立刻回应ACK，它最多等待一个时延（绝大多数设置200ms），直到有数据时将数据和ACK一块发送

经受时延的ACK就是等待了最大时延后才响应的ACK

• 从bsdi到srv4的7个ACK（报文三、六、九、十二、1五、1七、19）被标记为经受时延的ACK
• 经受时延的ACK等待的时延并非200ms，并且1~200ms中的任意值
• 经受时延的ACK之间间隔都是200ms的整数倍
• 从srv4到bsdi的7个ACK（报文二、五、八、十一、1四、1六、18）不是经受时延的ACK，由于都有数据随着ACK一块发送

上面几个现象说明，TCP实现经受时延的ACK，并非要等待200ms，发现没数据才ACK。而是采用一个200ms定时器，每隔200ms检查有没有数据须要确认，若是有就响应ACK，不然就不发

Nagle算法

如图，在广域网中，产生不少小分组一般会致使网络拥塞，一般会使用Nagle算法，保证一个链接上最多只有一个未被确认的小分组

对时延要求较高的应用，一般会关闭Nagle算法，若是在局域网，一些小的分组并不会影响网络情况

窗口大小通告

大多数状况下，客户端窗口是4096字节，服务端窗口是8192字节。可是后面客户端发送交互数据到服务端时，它并无机会读取服务端响应就要发送新的数据，致使窗口一直不能恢复，老是小于4096

小结

发送交互数据的时候，不少都是小分组，须要经过引入经受时延的ACK和Nagle算法来减小报文段的数量