计算机网络 第五章运输层习题答案.docx
《计算机网络 第五章运输层习题答案.docx》由会员分享，可在线阅读，更多相关《计算机网络 第五章运输层习题答案.docx（11页珍藏版）》请在冰豆网上搜索。
计算机网络第五章运输层习题答案
问题5-1：
TCP协议是面向连接的，但TCP使用的IP协议却是无连接的。
这两种协议都有哪些主要的区别？
答：
这个问题很重要，一定要弄清楚。
TCP是面向连接的，但TCP所使用的网络则可以是面向连接的（如X.25网络），但也可以是无连接的（如现在大量使用的IP网络）。
选择无连接网络就使得整个的系统非常灵活，当然也带来了一些问题。
下面是TCP和IP向上提供的功能和服务的比较。
TCP提供的
IP提供的
面向连接服务
无连接服务
字节流接口
IP数据报接口
有流量控制
无流量控制
有拥塞控制
无拥塞控制
保证可靠性：
不保证可靠性
无丢失
可能丢失
无重复
可能重复
按序交付
可能失序
显然，TCP提供的功能和服务要比IP所能提供的多得多。
这是因为TCP使用了诸如确认、窗口通知、计时器等机制，因而可以检测出有差错的报文、重复的报文和失序的报文。
问题5-2：
从通信的起点和终点来比较，TCP和IP的不同点是什么？
答：
用下面的图就可说明。
进程A和进程B的通信是使用面向连接的TCP提供的可靠的传输。
主机X和主机Y的通信是使用无连接的IP提供的不可靠的传输。
请注意：
对TCP来说，通信的起点和终点是运输层上面的两个套接字（socket），而应用层的应用进程正是通过应用层和运输层之间的套接字来使用TCP提供的服务。
TCP协议根据报文段首部中的端口号找到目的端口，将报文段交付给目的进程。
请注意：
套接字是由IP地址和端口号决定的，套接字也可称为“插口”。
对IP来说，通信的起点和终点是连接在网络上的两个主机。
IP协议根据数据报首部中的目的IP地址找到目的主机，将数据报交付给目的主机。
请注意可靠传输的范围和不可靠传输的范围是不同的。
我们还应当注意的是：
虽然在两个套接字之间的通信是面向连接的，但IP数据报在下面的网络中传输时是独立地选择路由，而不是沿着某一条固定的路径传输。
然而在上面的端口看来，TCP报文段好像都是从一个虚拟的、可靠的通信管道中传输到对方的端口。
问题5-3：
端口（port）和套接字（socket）的区别是什么？
答：
从本书经常使用的套接字定义来看，套接字包含了端口，因为套接字=（IP地址，端口号）。
套接字是TCP连接的端点。
套接字又称为“插口”。
但我们已经讲过，套接字（socket）有多种意思。
当使用API时，套接字往往被看成是操作系统的一种抽象，这时，套接字和一个文件描述符是很相似的，并且是应用编程接口API的一部分。
套接字由应用程序产生，并指明它将由客户还是服务器来使用。
当应用进程创建一个套接字时，要指明该套接字使用的端口号。
端口则是应用层服务的的一种代号，它用来标志应用层的进程。
端口是一个16bit的整数。
各种服务器使用的端口号都是保留端口号，以便使客户能够找到服务器。
例如万维网服务器使用的端口号是80。
在发送数据时，应用层的数据通过端口向下交付到运输层。
在接收数据时，运输层的数据通过适当的端口向上交付到应用层的某个应用程序。
问题5-4：
一个套接字能否同时与远地的两个套接字相连？
答：
不行。
一个套接字只能和另一个远地套接字相连。
如果许多个客户同时访问同一个服务器，那么对于这种情况，请参考教材的第6章的图6-30及相应的文字解释。
问题5-5：
数据链路层的HDLC协议和运输层的TCP协议都使用滑动窗口技术。
从这方面来进行比较，数据链路层协议和运输层协议的主要区别是什么？
答：
运输层的TCP协议是端到端（进程到进程）的协议，而数据链路层的HDLC协议则是仅在一段链路上的结点到结点的协议。
此外，TCP的窗口机制和HDLC的也有许多区别。
如TCP是按数据部分的字节数进行确认，而HDLC则是以帧为确认的单位。
需要注意的是，现在使用得最多的PPP链路层协议并不使用确认机制和窗口机制。
因此像PPP协议这样的链路层协议就和运输层协议有相当大的区别。
问题5-6：
TCP协议能够实现可靠的端到端传输。
在数据链路层和网络层的传输还有没有必要来保证可靠传输呢？
答：
在旧的OSI体系中，在数据链路层使用HDLC协议而在网络层使用X.25协议，这些协议都有确认机制和窗口机制，因而能够保证可靠传输。
但是技术的进步使得链路的传输已经相当可靠了，因此在数据链路层和网络层重复地保证可靠传输就显得多余了。
现在因特网在链路层使用的PPP协议和在网络层使用的IP协议都没有确认机制和窗口机制。
如果出现差错就由运输层的TCP来处理（若使用UDP协议则运输层也不处理出错的问题）。
问题5-7：
在TCP报文段的首部中只有端口号而没有IP地址。
当TCP将其报文段交给IP层时，IP协议怎样知道目的IP地址呢？
答：
显然，仅从TCP报文段的首部是无法得知目的IP地址。
因此，TCP必须告诉IP层此报文段要发送给哪一个目的主机（给出其IP地址）。
此目的IP地址填写在IP数据报的首部中。
问题5-8：
在TCP传送数据时，有没有规定一个最大重传次数？
答：
我们知道以太网规定重传16次就认为传输失败，然后报告上层。
但TCP没有规定最大重传次数，而是通过设置一些计时器来解决有关传输失败的问题。
问题5-9：
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报文段（如果有的话）可以到达目的站因而可将其丢弃。
这个计时器的值通常设置为一个报文段的寿命期待值的两倍。
问题5-10：
是否TCP和UDP都需要计算往返时间RTT？
答：
往返时间RTT只是对运输层的TCP协议才很重要，因为TCP要根据平均往返时间RTT的值来设置超时计时器的超时时间。
UDP没有确认和重传机制，因此RTT对UDP没有什么意义。
因此，不要笼统地说“往返时间RTT对运输层来说很重要”，因为只有TCP才需要计算RTT，而UDP不需要计算RTT。
问题5-11：
假定TCP开始进行连接建立。
当TCP发送第一个SYN报文段时，显然无法利用教材中5.6.3节所介绍的方法计算往返时间RTT。
那么这时TCP又怎样设置重传计时器呢？
答：
这时TCP显然无法利用已有的公式算出往返时间RTT。
实际上TCP是选择（也就是猜测）一个比较长的时间作为初始的往返时间RTT。
等到收到至少一个确认报文段时才能利用公式计算出比较合理的往返时间RTT。
问题5-12：
糊涂窗口综合症产生的条件是什么？
是否只有在接收方才产生这种症状？
答：
糊涂窗口综合症产生的条件是：
当发送应用程序产生数据很慢，或者接收应用程序吸收数据很慢，或者两者都有。
因此发送方和接收方都可能产生这种症状。
不管是上述情况中的哪一种，都使得发送数据的报文段很小，这就引起操作效率的降低。
例如，若TCP发送的报文段只包括一个字节的数据，则意味着我们发送41字节的数据报（20字节的TCP首部和20字节的IP首部）才传送1字节的数据。
数据的传送效率是1/41，它表示我们非常低效率地使用网络的容量。
问题5-13：
能否更详细些讨论一下糊涂窗口综合症及其解决方法？
答：
发送端产生的症状
如果发送端为产生数据很慢的应用程序服务，例如，一次产生一个字节。
这个应用程序一次将一个字节的数据写入发送端的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毫秒。
问题5-14：
为什么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连接不能使用相同的初始序号。
问题5-15：
能否利用TCP发送端和接收端交换报文段的图来说明慢开始的特点？
答：
慢开始的特点可以用下图来说明。
拥塞窗口cwnd的初始值是1（为方便起见，这里将拥塞窗口的单位设为报文段）。
以后每收到一个对新的报文段的确认，就将发送端的拥塞窗口cwnd加1。
可以看出，拥塞窗口cwnd按照指数规律增长。
所谓“新的报文段”就是指“未被确认过的报文段”。
由于报文段在因特网中传输时，有可能在某个路由器处滞留一段时间，但以后又被交付到接收端（重复交付）。
接收端对每一个收到的无差错的报文段都可能给出确认。
因此，对同一个报文段，发送端有可能收到几个重复的确认。
但除了第一个确认可以使发送端拥塞窗口cwnd加1以外，对其余重复的报文段的确认都不能再使发送端拥塞窗口加1。
问题5-16：
对于拥塞避免是否也能够用发送端和接收端交换的报文段来说明其工作原理？
答：
可以，但这只能是示意图。
因为在拥塞避免的开始，发送端的拥塞窗口swnd=ssthresh，这时可以发送好几个报文段。
按照RFC2581文档，每经过一个往返时间RTT，拥塞窗口就增加一个MSS的大小（以字节为单位）。
在我们讨论原理时，以报文段个数作为窗口单位较为方便，因此在图中每经过一个RTT，发送端拥塞窗口swnd就在ssthresh的基础上加1。
在图中将发送端发送报文段用一个粗箭头表示（因为这里面包含有许多个报文段，很难一个个画出），确认报文段也用一个粗箭头表示（这也可能有许多个确认报文段），因此RTT也是概念性的往返时间。
正因为RTT无法很严格地画出，因此在图中左边增加一个注释，即“收到对所有报文段的确认”。
这里假定收到对所有报文段的确认所需的时间就是RTT。
问题5-17：
TCP连接很像一条连接发送端和接收端的双向管道。
当TCP在连续发送报文段时，若要管道得到充分的利用，则发送窗口的大小应怎样选择？
答：
我们可以用下面的图来说明这一问题。
图中在发送端和接收端之间的两个白色长条表示TCP全双工通信的发送管道和接收管道。
管道是对信道的一种抽象，便于讨论问题（可以不涉及下层互连网络的细节）。
假定在t=0时发送端使用慢开始算法来发送报文段，因此在t=0时只能发送一个报文段（图中标有1的绿色长方条就代表报文段1）。
图中的时间都是按离散的时间单位表示。
为简化分析，我们还假定，发送窗口仅由发送端的拥塞窗口来确定，接收端不对发送窗口加以限制。
假定在t=1时，报文段1的第一个比特正好走完四分之一的管道，同时该报文段的最后一个比特正好发送完毕。
t=4，报文段1的前沿到达接收端。
t=5时，接收端将报文段1接收完毕。
假定接收端立即发送确认报文段。
我们所用的标记是：
对报文段n的确认报文段我们用具有标记n的红色小长方条表示。
t=9，对报文段1的确认的前沿到达发送端。
t=10，发送端将发送窗口加1变为2（可以发送报文段2和3），并开始发送报文段2（这一步图中省略了，没有画出）。
t=11，报文段2走完发送管道的四分之一，发送端开始发送报文段3。
t=12，报文段2和3填满发送管道的一半。
t=14，报文段2的前沿到达接收端。
t=15，接收端收完报文段2，并发送对报文段2的确认。
t=16，接收端收完报文段3，并发送对报文段3的确认。
t=19，对报文段2的确认前沿传播到发送端。
t=20，发送端收到对报文段2的确认，将发送窗口加1变为3（可以发送报文段4,5和6），并开始发送报文段4（这一步图中省略了，没有画出）。
对报文段3的确认的前沿也在这个时间传播到发送端。
再以后的过程我们用下面的另一张图来说明。
t=21，发送端收到对报文段3的确认，将发送窗口再加1变为4（可以发送报文段4,5,6和7），并开始发送报文段5。
此时，报文段4已完全进入发送管道，前沿到了管道的四分之一处。
以后的过程读者自己都可以看懂。
这里只再提几点。
发送端每收到一个对没有确认过的报文段的确认，就将发送窗口加1。
因此在陆续收到确认4~7后，将发送窗口加4，即增大到8，可以连续发送报文段8~15。
管道空间是有限的。
从图中表示的例子可以看出，这样的管道至多可容纳4个报文段。
当发送窗口很小时，管道在大部分时间内是比较空的（见前面的第一张图）。
这说明在TCP连接中传输数据的效率比较低。
当发送窗口增大时，管道逐渐被填满。
可以看出，在t=34~38时，发送管道一直是被填满的，这说明发送管道被利用得很充分。
因为报文段的传输需要时间，因此对报文段的确认总是会滞后一段时间。
上面的例子表明，在单方向发送报文段（另一个方向发送确认）的情况下，发送管道和接收管道往往不能同时被充分利用（除非发送窗口的数值较大）。
但如果双向都能发送数据报文段，那么发送管道和接收管道就都能够被利用得较充分。
我们还可看出，接收管道（即接收端发送确认报文段的管道）在任何情况下都没有填满。
这是因为确认报文段很短，只需很短的时间就可发送出去。
但接收一个数据报文段需要较多的时间，这就造成确认报文段不可能连续地从接收端发送出去。
问题5-18：
假定在一个互联网中，所有的链路的传输都不出现差错，所有的结点也都不会发生故障。
试问在这种情况下，TCP的“可靠交付”的功能是否就是多余的？
答：
不是多余的。
TCP的“可靠交付”功能在互联网中起着至关重要的作用。
至少在以下所列举的情况下，TCP的“可靠交付”功能是必不可少的。
（1）每个IP数据报独立地选择路由，因此在到达目的主机时有可能出现失序。
（2）由于路由选择的计算出现错误，导致IP数据报在互联网中兜圈子。
最后数据报首部中的生存时间TTL的数值下降到零。
这个数据报在中途就被丢弃了。
（3）在某个路由器突然出现很大的通信量，以致路由器来不及处理到达的数据报。
因此有的数据报被丢弃。
以上列举的问题表明了：
必须依靠TCP的“可靠交付”功能才能保证在目的主机的目的进程接收到正确的报文。
问题5-19：
TCP是通信协议还是软件？
答：
协议与实现协议的软件之间的区别，类似于编程语言的定义与编译器之间的区别。
与编程语言的情况类似，编程语言的定义与编程语言的实现之间的区别有时也会比较模糊。
大家与TCP软件打交道的机会远远比与TCP协议规范打交道的机会要多，因而会很自然地把某个协议的具体实现当作是协议的标准。
尽管如此，我们必须明确地区分两者。
总之，TCP是通信协议，而不是一个软件。
问题5-20：
在计算TCP的往返时间RTT的公式中，本教材过去的版本是取=7/8。
但现在的新版本是取=1/8。
为什么会有这样大的改变？
答：
过去的版本是参考有的国外教材，这个教材上把RTT的计算公式写为：
平均往返时延RTT（旧的RTT）
（1）（新的往返时延样本）
而取=7/8。
现在的新版本是考虑到最好和RFC文档的写法一致，这样可能会更加便于读者查阅RFC文档。
现在的RTT计算公式是：
新的RTTS
（1）（旧的RTTS）（新的RTT样本）
而取=1/8。
但这两种不同的写法在实质上并无不同，得出的计算结果是一样的。
另外有些改动的地方是：
（1）RTT以前译为“往返时延”，现在改为“往返时间”。
这样更加准确一些，因为RTT的后面一个T是Time，应当译为“时间”。
以前用的“往返时延”来自“Round-TripDelay”。
（2）以前没有用RTTS这个符号，是为了使符号不要太多。
现在看来，多用一个符号可能会更清楚一些（RFC文档也有这个符号，但他们使用的文本文件，不便于用下标，因此他们用的符号是SRTT，表示SmoothedRTT（平滑的RTT）。
升级会员 