前言
TCP 报文段所携带的应用程序数据按照长度分为两种：交互数据和成块数据。交互数据仅包含很少的字节。使用交互数据的应用程序（或协议）对实时性要求高，比如
Telnet、ssh 等。成块数据的长度则通常为 TCP 报文段允许的最大数据长度。使用成块数据的应用程序（或协议）对传输效率要求高，比如 FTP。
TCP 的交互数据流
交互数据流总是以小于最大报文段长度的分组发送，即进行小分组数据传输。主要应用在实时性要求比较高的场合。比如 Rlogin 远程登录中，需要回显客户端输入的字符，每发送一个字节到服务端，并回显到客户端的过程如下：
- 客户端产生一个41bit长的报文（20字节的IP首部，20字节的TCP首部，1字节的数据），发送到服务端；
- 服务端发送确认报文，不包含应用数据（长度为0）；
- 服务端发送回显的字符；
- 客户端发送确认报文，不包含应用数据（长度为0）。
上面的过程中，虽然达到了实时性要求，但是交互数据太频繁，并且在服务器发送的确认报文中并没有返回有用应用程序数据，回显数据是服务器单独发送，并不跟确认报文一起发送，这样频繁的交互数据会导致网络拥塞。为了防止网络拥塞，在进行交互数据流时可采用两种方法：捎带 ACK和Nagle 算法；
捎带 ACK
当服务器收到远程主机的 TCP 数据报之后，通常不立即发送 ACK 确认数据报，而是推迟发送，即等待一个短暂的时间，这个时间一般是 200 ms。如果这段时间里面服务器有需要发送给远程主机的 TCP 数据报，那么就把这个 ACK 确认数据报“捎带”着发送出去，把本来两个 TCP 数据报整合成一个发送。由于 TCP 具有超时重传机制，若等待时间超过了200 ms，若此时服务器依然没有数据要一起发送，就直接发送 ACK 确认报文段。这种机制可以提高 TCP 数据报的利用率。
使用捎带 ACK 机制的交互数据流时，客户端针对服务器返回的数据所发送的确认报文段都不携带任何应用程序数据（长度为0），而服务器每次发送的确认报文段都包含它需要发送的应用程序数据。服务器的这种处理方式称为延迟确认，即它不马上确认上次收到的数据，而是在一段延迟时间后查看本端是否有数据需要发送，如果有，则和确认信息一起发出。因为服务器对客户请求处理得很快，所以它发送确认报文段的时候总是有数据一起发送。延迟确认可以减少发送 TCP 报文段的数量。而由于用户的输入速度明显慢于客户端程序的处理速度，所以客户端的确认报文段总是不携带任何应用程序数据。
Nagle 算法
该算法要求一个 TCP 连接的通信双方在任意时刻最多只能发送一个未被确认的 TCP 报文段，在该 TCP 报文段的确认到达之前不能发送其他TCP报文段。另一方面，发送方在等待确认的同时收集本端需要发送的微量数据，并在确认到来时以一个 TCP 报文段将它们全部发出。这样就极大地减少了网络上的微小 TCP 报文段的数量。该算法的另一个优点在于其自适应性：确认到达得越快，数据也就发送得越快。
参考资料：
《TCP/IP 详解》