TCP/IP 详解卷一 - TCP的交换数据流和成块数据流

        TCP 报文段所携带的应用程序数据按照长度分为两种：交互数据和成块数据。

         交互数据仅包含很少的字节。使用交互数据的应用程序（或协议）对实时性要求高，比如 Telnet、ssh 等。

         成块数据的长度则通常为 TCP 报文段允许的最大数据长度。使用成块数据的应用程序（或协议）对传输效率要求高，比如 FTP。 

TCP的交互数据流

 

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



1.        客户端产生一个41bit长的报文（20字节的IP首部，20字节的TCP首部，1字节的数据），发送到服务端；

2.        服务端发送确认报文，不包含应用数据（长度为0）；

3.        服务端发送回显的字符；

4.        客户端发送确认报文，不包含应用数据（长度为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的成块数据流

 

        TCP 的成块数据流是在要求传输效率较高的情况下使用，例如 FTP。对于这些要求传输 TCP 最长报文段的应用，TCP 协议采用了滑动窗口协议，使发送端在等待确认前可以连续发送多个分组。

        一般来说，发送端发送一个TCP 数据报，则接收端就应该发送一个 ACK 数据报。但在实际应用中却并非如此，而是发送端将连续发送数据报保存在接受端的缓冲区中，并且尽量使其填满，接受端对这些连续发送的数据报只发送一个 ACK报文应答，这就是 ACK 的累积特性，这个特性大大减少了发送端和接收端的负担。

 

滑动窗口

 

       滑动窗口的滑动是以字节为单位的，窗口是在建立 TCP 连接时，通信双方协商好的接收端的窗口。窗口大小本质上是发送端在等待确认之前所发送数据的最大值。如果发送端收到接受端的窗口大小为 0 的 TCP 数据报，则表示发送端将停止发送数据，等到接受端发送窗口大小不为 0 的数据报的到来。



       在这个图中，我们将字节从1 至11 进行标号。接收方通告的窗口称为提出的窗口，它覆盖了从第4字节到第9字节的区域，表明接收方已经确认了包括第3字节在内的数据，且通告窗口大小为6。回顾第17章，我们知道窗口大小是与确认序号相对应的。发送方计算它的可用窗口，该窗口表明多少数据可以立即被发送。当接收方确认数据后，这个滑动窗口不时地向右移动。窗口两个边沿的相对运动增加或减少了窗口的大小。我们使用三个术语来描述窗口左右边沿的运动：

以下是窗口协议中窗口变化的三种情况：

1.        窗口合拢，即窗口左边沿 向 右边沿 靠近。这种现象发生在数据被发送和确认时；

2.        窗口张开，即窗口右边沿 向右移动，此时将允许发送更多的数据。这种现象一般发生在另一端的接收进程读取已经确认的数据并释放 TCP的接收缓存时；

3.        窗口收缩，即窗口右边沿 向左移动。一般不建议出现这种现象；

注意：窗口的左边沿受另一端发送的确认序号的控制，因此不能向左边移动。如果接收到一个指示窗口左边沿向左移动的 ACK，则它被认为是一个重复的 ACK，并被丢弃。

       在滑动窗口中，发送端只能发送窗口内的数据，并且数据的发送顺序是从左到右。当窗口的左边沿 达到 右边沿 时，则称其为一个零窗口，表示发送端不能发送任何数据。

 

慢启动

 

       在本章所有的例子中，发送方一开始便向网络发送多个报文段，直至达到接收方通告的窗口大小为止。当发送方和接收方处于同一个局域网时，这种方式是可以的。但是如果在发送方和接收方之间存在多个路由器和速率较慢的链路时，就有可能出现一些问题。一些中间路由器必须缓存分组，并有可能耗尽存储器的空间。

        为了防止网络拥塞，TCP 采用了一种慢启动算法，对发送数据量进行控制。为了调节发送端的数据发送量，引入了拥塞窗口，在慢启动时，将这个拥塞窗口设为 1 个报文段发送数据，之后每收到一次确认应答，拥塞窗口的值就加 1个报文段。在发送数据包时，将拥塞窗口的大小与接收端主机通知的窗口大小进行比较，然后选择较小的值来控制数据量的发送。拥塞窗口是发送端使用的流量控制，而通告窗口则是接收端使用的流量控制。

 

紧急方式

 

        TCP 的 紧急方式，它使一端可以告诉另一端有些具有某种方式的 紧急数据 已经放置在普通的数据流中。另一端被通知这个紧急数据 已被放置在普通的数据流中，由接收方决定如何处理。然而 紧急数据 并不是 带外数据 。TCP 的紧急方式只是一个从发送方到接收方的通知，该通知告诉接收方 紧急数据 已被发送，并提供该数据最后一个字节的序号，由接收方决定如何处理。应用程序使用的有关紧急数据 部分的编程接口都不是最佳的，从而导致更多的混乱。

 

小结

 

       没有一种单一的方法可以使用 TCP进行成块数据的交换。这是一个依赖于许多因素的动态处理过程，有些因素我们可以控制（如发送和接收缓存的大小），而另一些我们则没有办法控制（如网络拥塞、与实现有关的特性等）。进行成块数据有效传输的最重要的方法是 TCP的滑动窗口协议。

       本章最后一个主题是 TCP的紧急数据，人们常常错误地称其为“带外数据”。

       TCP的紧急方式只是一个从发送方到接收方的通知，该通知告诉接收方紧急数据已被发送，并提供该数据最后一个字节的序号。应用程序使用的有关紧急数据部分的编程接口常常都不是最佳的，从而导致更多的混乱。