TCP的交互数据流知识点记录
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 报文段的数量。而由于用户的输入速度明显慢于客户端程序的处理速度，所以客户端的确认报文段总是不携带任何应用程序数据。