章节回顾：
《TCP/IP详解卷1：协议》第1章 概述-读书笔记
《TCP/IP详解卷1：协议》第2章 链路层-读书笔记
《TCP/IP详解卷1：协议》第3章 IP：网际协议（1）-读书笔记
《TCP/IP详解卷1：协议》第3章 IP：网际协议（2）-读书笔记
《TCP/IP详解卷1：协议》第4章 ARP：地址解析协议-读书笔记
《TCP/IP详解卷1：协议》第5章 RARP：逆地址解析协议-读书笔记
《TCP/IP详解卷1：协议》第6章 ICMP：Internet控制报文协议-读书笔记
《TCP/IP详解卷1：协议》第11章 UDP：用户数据报协议-读书笔记
《TCP/IP详解卷1：协议》第17、18章 TCP：传输控制协议（1）-读书笔记
《TCP/IP详解卷1：协议》第17、18章 TCP：传输控制协议（2）-读书笔记
《TCP/IP详解卷1：协议》第19章 TCP的交互数据流-读书笔记
1、引言
有关TCP通信量的研究发现：按分组数量计算，约有一半的TCP报文段包含成块数据（如FTP、电子邮件和Usenet新闻），另一半则包含交互数据（如Telnet和Rlogin）。按字节计算，成块数据与交互数据的比例约为90%和10%。
成块数据的报文段基本上都是满长度的（通常为512字节的用户数据），交互数据则小得多（Telnet和Rlogin分组中约90%左右的用户数据小于10个字节）
TCP需要同时处理这两类数据，但使用的处理算法不同。
2、交互式输入
说明：本书是以远程登录Rlogin协议模拟交互输入的，我没有进行相关实验，下面我会给出作者所做的实验截图。
如图19-1所示，Rlogin协议需要远程系统回显客户输入的字符，每按一个字符就会产生一个分组，而不是每次一行作为一个分组。
一般可以将报文段2和3合并（图中两个红框）
当我们键入5个字符date\n时的数据流，如图19-2所示：
说明：
（1）第1行：客户发送字符d到服务器；第2行：该字符的确认及回显；第3行：回显字符的确认。
（2）与字符a有关的是第4~6行，与字符t有关的是第7~9行，与字符e有关的是第10~12行。
（3）13~15行与上面稍有不同。客户发送到服务器的是一个字符（换行符），而回显的是两个字符（图中14行红线处），这两个字符为：回车和换行字符，作用是将光标移动到左边并换到下一行。
（4）第16行：来自服务器date命令的输出。这30个字节（图中红线处）由28个字符与最后的回车+换行组成。第17、18行：服务器发往客户7个字符（第18行），它们是在服务器主机上的客户提示符：svr4%。第19行：确认了这7个字符。
3、经受时延的确认
图19-3表示了图19-2中数据交换的时间。
通常TCP在接收到数据时并不立即发送ACK；它会推迟发送，以便将ACK与需要沿该方向发送的数据一起发送，有时称这种现象为数据捎带ACK。
说明：绝大多数实现采用的时延为200ms，即TCP将以最大200ms的时延等待是否有数据一起发送。
下面我假设你会看这张图中标记的时间差，会计算实际时间（累加）。说明如下：
观察bsdi接收到数据和发送ACK之间的时间差：123.5、65.6、109.0、132.2、42.0、140.3和195.8 ms，似乎是随机的。观察bsdi发送ACK的实际时间（从0开始计算）为：139.9、539.3、940.1、1339.9、1739.9、1940.1和2140.1 ms，这些时间差是200ms的整数倍。
注意：因为TCP使用了一个200ms的定时器，以相对于内核引导的200ms固定时间溢出。由于将要确认的数据是随机到达的，TCP在内核的200ms定时器的下一次溢出时得到通知。
4、Nagle算法
Rlogin连接时，一般每次发送一个字节到服务器，这就产生了一些41字节长的分组：20字节的IP首部、20字节的TCP首部和1个字节的数据。
在局域网上，这些小分组（被称为微小分组tinygram）通常不会引起麻烦，因为局域网一般不会出现拥塞。在广域网上，这些小分组则会增加拥塞出现的可能。一种简单有效的方法就是采用RFC 896建议的Nagle算法。
算法说明：
算法要求一个TCP连接上最多只能有一个未被确认的未完成的小分组，在该分组的确认到达之前不能发送其他的小分组。相反，TCP收集这些少量的分组，并在确认到来时以一个分组的方式发出去。
算法优点：
算法的优越之处在于它是自适应的：确认到达得越快，数据也就发送得越快。在希望减少微小分组数目的低速广域网上，则会发送更少的分组。
从图19-3中看到，在以太网上一个字节被发送、确认和回显的平均往返时间约为16ms。为了产生比这个速度更快的数据，我们每秒键入的字符必须多于60个。说明在局域网环境下两个主机之间发送数据时很少使用这个算法。
当往返时间（RTT）增加时，如通过一个广域网，情况发生了变化。如图19-4：
从左到右待发数据的长度是不同的，分别为：1、1、2、1、2、2、3、1和3个字节。这是因为客户只有收到前一个数据的确认后才发送已经收集的数据。通过使用Nagle算法，为发送16个字节的数据客户只需要使用9个报文段，而不再是16个。
关闭Nagle算法
有时我们也需要关闭Nagle算法。例如，X窗口系统服务器，小消息（鼠标移动）必须无时延地发送，以便为进行某种操作的交互用户提供实时的反馈。
5、窗口大小通告
观察图19-4，可以看到slip通告窗口大小为4096字节，vangogh通告其窗口大小为8192字节。但报文段5通告的窗口大小为4095个字节，意味着TCP缓冲区中仍然有一个字节等待应用程序（Rlogin客户）读取。
说明：
（1）通常服务器通告窗口大小为8192个字节，这是因为服务器在读取并回显接收到的数据之前，其TCP没有数据发送。当服务器已经读取了来自客户的输入后，来自服务器的数据将被发送。
（2）在ACK到来时，客户的TCP总是有数据需要发送。这是因为它在等待ACK的过程中缓存接收到的字符。当客户TCP发送缓存的数据时，Rlogin客户没有机会读取来自服务器的数据，因此，客户通告的窗口大小总是小于4096。
小结：
交互数据总是以小于最大报文段长度的分组发送。对于这些小的报文段，接收方使用经受时延的确认方法来判断确认是否可被推迟发送，以便与回送数据一起发送。这样通常会减少报文段的数目。在较慢的广域网环境中，通常使用Nagle算法来减少这些小报文段的数目。这个算法限制发送者任何时候只能有一个发送的小报文段未被确认。