TCP的交互数据流

1.前言
2.TCP的交互数据流
2.1.捎带ACK
2.2.Nagle算法

1.前言

　　TCP报文段所携带的应用程序数据按照长度分为两种：交互数据和成块数据。交换数据仅包含很少的字节。使用交互数据的应用程序(或协议)对实时性要求高，比如Telnet，ssh等。成块数据的长度则通常为TCP报文段允许的最大数据长度。使用成块数据的应用程序(或协议)对传输效率要求高，比如FTP。

2.TCP的交互数据流

　　交互数据流总是以小于最大报文段长度的分组发送，即进行小分组数据传输。主要应用在实时性要求比较高的场合。比如RLogin远程登陆中，需要回显客户端输入的字符，每发送一个字节到服务端，并回显到客户端的过程如下：
　　

1. 客户端产生一个41bit长的报文(20字节的IP首部，20字节的TCP首部，1字节的数据)，发送到服务器端；
2. 服务器端发送确认报文，不包含应用数据(长度为0）；
3. 服务端发送回显的字符；

4. 客户端发送确认报文，不包含应用数据(长度为0)。

   　　上面的过程中，虽然达到了实时性要求，但是交互数据太频繁，并且在服务器发送的确认报文中并没有返回有用的应用程序数据，回显数据是服务器单独发送，并不跟确认报文一起发送，这样频繁的交互数据导致网络阻塞。为了防止网络阻塞，在进行交互数据流时可采用两种方法：捎带ACK和Nagle算法；

2.1.捎带ACK

　　当服务器收到远程主机的TCP数据报之后，通常不立即发送ACK确认数据报，而是推迟发送，即等待一个短暂的时间，这个时间一般是200ms。如果这段时间里面服务器有需要发送给远程主机的TCP数据报，那么就把这个ACK确认数据报”捎带“着发送出去，把本来两个TCP数据报整合成一个发送。由于TCP具有超时重传机制，若等待时间超过了200ms，若此时服务器仍然没有数据要一起发送，就直接发送ACK确认报文段。这种机制可以提高TCP数据报的利用率。
　　使用捎带ACK机制的交互数据流时，客户端针对服务器返回的数据所发送的确认报文段都不携带任何应用程序数据(长度为０)，而服务器每次发送的确认报文段都包含它需要发送的应用程序数据。服务器的这种处理方式成为延迟确认，即它不马上确认上次收到的数据，而是在一段延迟时间后查看本端是否有数据需要发送，如果有，则和确认信息一起发出。因为服务器对客户请求处理得很快，所以它发送确认报文段的时候总是有数据一起发送。延迟确认可以减少发送TCP报文段的数量。而由于用户输入速度明显慢于客户端程序的处理速度，所以客户端的确认报文段总是不携带任何应用重新数据。

2.2.Nagle算法

　　该算法要求一个TCP连接的通信双方在任意时刻最多只能发送一个未被确认的TCP报文段，在该报文段的确认到达之前不能发送其他TCP报文段。另一方面，发送方在等待确认的同时收集本端需要发送的微量数据，并在确认到来时以一个TCP报文段将它们全部发出。这样就极大地减少了网络上的微小TCP报文段的数量。该算法的另一个优点在于其自适应性：确认到达得越快，数据也就发送得越快。