第5章 运输层 问题与回答

问题1: 在TCP传送数据时，有没有规定一个最大重传次数？

答：数据链路层的以太网规定重传16次就认为传输失败，然后报告上层。但TCP没有规定最大重传次数，而是通过设置一些计时器来解决有关传输失败的问题。（见问题5）

问题2：假定在一个互联网中，所有的链路的传输都不出现差错，所有的结点也都不会发生故障。试问在这种情况下，TCP的“可靠交付”的功能是否就是多余的？

答：不是多余的。TCP的“可靠交付”功能在互联网中起着至关重要的作用。

至少在以下所列举的情况下，TCP的“可靠交付”功能是必不可少的。

(1) 每个IP数据报独立地选择路由，因此在到达目的主机时有可能出现失序。

(2) 由于路由选择的计算出现错误，导致IP数据报在互联网中兜圈子。最后数据报首部中的生存时间TTL的数值下降到零。这个数据报在中途就被丢弃了。

(3) 在某个路由器突然出现很大的通信量，以致路由器来不及处理到达的数据报。因此有的数据报被丢弃。

以上列举的问题表明了：必须依靠TCP的“可靠交付”功能才能保证在目的主机的目的进程接收到正确的报文。

问题3：从通信的起点和终点来比较，TCP和IP的不同点是什么？

答：用下面的图就可说明。

进程A和进程B的通信是使用面向连接的TCP提供的可靠的传输。

主机X和主机Y的通信是使用无连接的IP提供的不可靠的传输。

对TCP来说，通信的起点和终点是运输层上面的两个套接字(socket)，而应用层的应用进程正是通过应用层和运输层之间的套接字来使用TCP提供的服务。TCP协议根据报文段首部中的端口号找到目的端口，将报文段交付给目的进程。

对IP来说，通信的起点和终点是连接在网络上的两个主机。IP协议根据数据报首部中的目的IP地址找到目的主机，将数据报交付给目的主机。

可靠传输的范围和不可靠传输的范围是不同的。

还应当注意的是：虽然在两个套接字之间的通信是面向连接的，但IP数据报在下面的网络中传输时是独立地选择路由，而不是沿着某一条固定的路径传输。然而在上面的端口看来，TCP报文段好像都是从一个虚拟的、可靠的通信管道中传输到对方的端口。

问题4：端口(port)和套接字(socket)的区别是什么？

答：套接字 = (IP地址，端口号)，套接字是TCP连接的端点，套接字又称为“插口”。

套接字(socket)有多种意思。当使用API时，套接字往往被看成是操作系统的一种抽象，这时，套接字和一个文件描述符是很相似的，并且是应用编程接口API的一部分。套接字由应用程序产生，并指明它将由客户还是服务器来使用。当应用进程创建一个套接字时，要指明该套接字使用的端口号。

端口则是应用层服务的一种代号，它用来标志应用层的进程。端口是一个16 bit的整数。各种服务器使用的端口号都是保留端口号，以便使客户能够找到服务器。例如万维网服务器使用的端口号是80。

在发送数据时，应用层的数据通过端口向下交付到运输层。在接收数据时，运输层的数据通过适当的端口向上交付到应用层的某个应用程序。

问题5：TCP协议中有哪些计时器技术？

答：TCP共使用以下四种计时器，即重传计时器、持续计时器、保活计时器和时间等待计时器。这几个计时器的主要特点如下：

重传计时器

当TCP发送报文段时，就创建该特定报文段的重传计时器。可能发生两种情况：

1. 若在计时器截止时间到之前收到了对此特定报文段的确认，则撤销此计时器。

2. 若在收到了对此特定报文段的确认之前计时器截止期到，则重传此报文段，并将计时器复位。

持续计时器

为了解决零窗口通知问题，TCP需要一个持续计时器。假定接收端TCP告知了接收窗口大小为零，发送端TCP就停止传送报文段。何时恢复发送呢？

采用接收端主动告知？如接收端TCP发送确认并宣布一个非零的窗口大小，但这个确认可能会丢失，我们知道在TCP中，对确认是不需要发送确认的。若确认丢失了，接收TCP端并不知道，而是会认为它已经完成告知对方的任务了，并等待着发送端TCP接着会发送更多的报文段。但发送端TCP由于没有收到确认，就一直等待对方发送确认来通知窗口的大小。双方的TCP都在永远地等待着对方。

要打开这种死锁，TCP为每一个连接使用一个持续计时器。当发送端TCP收到一个窗口大小为零的确认时，就启动持续计时器。当持续计时器期限到时，发送端TCP就发送一个特殊的报文段，叫做探测报文段。这个报文段只有一个字节的数据。它有一个序号，但它的序号永远不需要确认；甚至在计算对其他部分的数据的确认时该序号也被忽略。探测报文段提醒接收端TCP：确认已丢失，必须重传。

持续计时器的值一般设置为重传时间的数值。但是，若没有收到从接收端来的响应，则需发送另一个探测报文段，并将持续计时器的值加倍和复位。发送端继续发送探测报文段，将持续计时器设定的值加倍和复位，直到这个值增大到门限值（通常是60秒）为止。在这以后，发送端每隔60秒就发送一个探测报文段，直到窗口重新打开。

保活计时器

保活计时器用在某些实现中，防止在两个TCP之间的连接出现长时期的空闲。假定客户打开了到服务器的连接，传送了一些数据，然后就保持静默了。也许这个客户出故障了。在这种情况下，这个连接将永远地处理打开状态。

要解决这种问题，在大多数的实现中都是服务器设置保活计时器。每当服务器收到客户的信息，就将计时器复位。超时通常设置为2小时。若服务器过了2小时还没有收到客户的信息，它就发送探测报文段。若发送了10个探测报文段（每一个相隔75秒）还没有响应，就假定客户出了故障，因而就终止该连接。

时间等待计时器

时间等待计时器是在连接释放期间使用的。当TCP关闭一个连接时，它并不认为这个连接马上就真正地关闭了。在时间等待期间中，连接还处于一种中间过渡状态。这就可以使重复的FIN报文段（如果有的话）可以到达目的站因而可将其丢弃。这个计时器的值通常设置为一个报文段的寿命期待值的两倍。

问题6：假定TCP开始进行连接建立。当TCP发送第一个SYN报文段时，不能利用教材中所介绍的方法计算往返时间RTT。那么这时TCP又怎样设置重传计时器呢？

答：针对第一个报文段,这时TCP显然无法利用已有的公式算出往返时间RTT。这个时段的TCP可能是选择(一个猜测值）一个比较长的时间作为初始的往返时间RTT。等到收到至少一个确认报文段时才能利用公式计算出比较合理的往返时间RTT。

问题7：为什么TCP在建立连接时不能每次都选择相同的、固定的初始序号？

答：如果TCP在建立连接时每次都选择相同的、固定的初始序号，那么设想以下的情况：

(1) 假定主机A和B频繁地建立连接，传送一些TCP报文段后，再释放连接，然后又不断地建立新的连接、传送报文段和释放连接。

(2) 假定每一次建立连接时，主机A都选择相同的、固定的初始序号，例如，选择1。

(3) 假定主机A发送出的某些TCP报文段在网络中会滞留较长的时间，以致造成主机A超时重传这些TCP报文段。

(4) 假定有一些在网络中滞留时间较长的TCP报文段最后终于到达了主机B，但这时传送该报文段的那个连接早已释放了，而在到达主机B时的TCP连接是一条新的TCP连接。

这样，工作在新的TCP连接下的主机B就有可能会接受在旧的连接传送的、已经没有意义的、过时的TCP报文段（因为这个TCP报文段的序号有可能正好处在现在新的连接所使用的序号范围之中）。结果产生错误。

因此，必须使得迟到的TCP报文段的序号不处在新的连接中所使用的序号范围之中。

这样，TCP在建立新的连接时所选择的初始序号一定要和前面的一些连接所使用过的序号不一样。因此，不同的TCP连接不能使用相同的初始序号,一般随机产生一个数字号。

问题8：主机A向主机B连续发送了两个TCP报文段，其序号分别为70和100。试问：
（1）第一个报文段携带了多少个字节的数据？
（2）主机B收到第一个报文段后发回的确认中的确认号应当是多少？
（3）如果主机B收到第二个报文段后发回的确认中的确认号是180，试问A发送的第二个报文段中的数据有多少字节？
（4）如果A发送的第一个报文段丢失了，但第二个报文段到达了B。B在第二个报文段到达后向A发送确认。试问这个确认号应为多少？

解：（1）第一个报文段的数据序号是70到99，共30字节的数据。

（2）确认号应为100.

（3）80字节。

（4）70

问题9（选读）：讨论糊涂窗口综合症及其解决方法？

答：发送端产生的症状

如果发送端为产生数据很慢的应用程序服务，例如，一次产生一个字节。这个应用程序一次将一个字节的数据写入发送端的TCP的缓存。如果发送端的TCP没有特定的指令，它就产生只包括一个字节数据的报文段。结果有很多41字节的IP数据报就在互连网中传来传去。

解决的方法是防止发送端的TCP逐个字节地发送数据。必须强迫发送端的TCP收集数据，然后用一个更大的数据块来发送。发送端的TCP要等待多长时间呢？如果它等待过长，它就会使整个的过程产生较长的时延。如果它的等待时间不够长，它就可能发送较小的报文段。Nagle找到了一个很好的解决方法。

Nagle算法

Nagle算法非常简单，但它能解决问题。这个算法是为发送端的TCP用的：

1. 发送端的TCP将它从发送应用程序收到的第一块数据发送出去，哪怕只有一个字节。

2. 在发送第一个报文段（即报文段1）以后，发送端的TCP就在输出缓存中积累数据，并等待：或者接收端的TCP发送出一个确认，或者数据已积累到可以装成一个最大的报文段。在这个时候，发送端的TCP就可以发送这个报文段。

3. 对剩下的传输，重复步骤2。这就是：如果收到了对报文段x的确认，或者数据已积累到可以装成一个最大的报文段，那么就发送下一个报文段(x + 1)。

Nagle算法的优点就是简单，并且它考虑到应用程序产生数据的速率，以及网络运输数据的速率。若应用程序比网络更快，则报文段就更大（最大报文段）。若应用程序比网络慢，则报文段就较小（小于最大报文段）。

接收端产生的症状

接收端的TCP可能产生糊涂窗口综合症，如果它为消耗数据很慢的应用程序服务，例如，一次消耗一个字节。假定发送应用程序产生了1000字节的数据块，但接收应用程序每次只吸收1字节的数据。再假定接收端的TCP的输入缓存为4000字节。发送端先发送第一个4000字节的数据。接收端将它存储在其缓存中。现在缓存满了。它通知窗口大小为零，这表示发送端必须停止发送数据。接收应用程序从接收端的TCP的输入缓存中读取第一个字节的数据。在入缓存中现在有了1字节的空间。接收端的TCP宣布其窗口大小为1字节，这表示正渴望等待发送数据的发送端的TCP会把这个宣布当作一个好消息，并发送只包括一个字节数据的报文段。这样的过程一直继续下去。一个字节的数据被消耗掉，然后发送只包含一个字节数据的报文段。这又是一个效率问题和糊涂窗口综合症（见下图）。

对于这种糊涂窗口综合症，即应用程序消耗数据比到达的慢，有两种建议的解决方法。

Clark解决方法 Clark解决方法是只要有数据到达就发送确认，但宣布的窗口大小为零，直到或者缓存空间已能放入具有最大长度的报文段，或者缓存空间的一半已经空了。

延迟的确认 第二个解决方法是延迟一段时间后再发送确认。这表示当一个报文段到达时并不立即发送确认。接收端在确认收到的报文段之前一直等待，直到入缓存有足够的空间为止。延迟的确认防止了发送端的TCP滑动其窗口。当发送端的TCP发送完其数据后，它就停下来了。这样就防止了这种症状。

迟延的确认还有另一个优点：它减少了通信量。接收端不需要确认每一个报文段。但它也有一个缺点，就是迟延的确认有可能迫使发送端重传其未被确认的报文段。

可以用协议来平衡这个优点和缺点，例如现在定义了确认的延迟不能超过500毫秒。