terminated 和 enclosed 字段后没有终止定界符_TCP-IP详解第18章 TCP连接的建立与终止 习题与答案...

18.1 在1 8 . 2节我们说初始序号（ I S N）正常情况下由 1开始，并且每 0 . 5秒增加6 4 0 0 0，每次执行一个主动打开。这意味着 I S N的最低三位通常总是 0 0 1。但在图 1 8 - 3中，两个方向上I S N中的最低三位都是5 2 1。究竟是怎么回事?

答：I S N是一个 32 bit的计数器，它在系统引导大约 9 . 5小时后从 4 294 912 000环绕到 8 7 0 4。再过大约 9 . 5小时它将环绕到 17 408，然后再过 9 . 5小时是26 11 2，如此继续下去。因为系统引导时 I S N从1开始，并且因为最低次序的数字在 4、 8、 2、 6和0之间循环，所以I S N应该总是一个奇数。

18.2 在图1 8 - 1 5中，我们键入 1 2个字符，看到 T C P发送了 1 3个字节。在图 1 8 - 1 6中我们键入 8个字符，但 T C P发送了 1 0个字符。为什么在第 1种情况下增加 1个字节，而在第 2种情况下增加2个字节？

答：在第1种情况下，我们使用了s o c k程序。默认情况下它把 U n i x的新行字符不作改变地进行传输—单个A S C I I字符0 1 2（八进制） 。在第2种情况下，我们使用了 Te l n e t客户，它把U n i x的新行字符转变为两个 A S C I I字符—一个回车符（八进制 0 1 5）跟着一个换行符（八进制0 1 2）。

18.3 半打开连接和半关闭连接的区别是什么？

答：在一个半关闭的连接上，一个端点已经发送了一个 F I N，正等待另一端的数据或者一个F I N。一个半打开的连接是当一个端点崩溃了，而另一端还不知道的情况。

18.4 如果启动s o c k程序作为一个服务器程序，然后终止它（还没有客户进程与它相连接） ，我们能立即重新启动这个服务器程序。这意味着它没有经历 2 M S L等待状态。用状态变迁来解释这一切。

答：一个连接只有经过了已建立状态才能进入 2 M S L等待状态。

18.5 在1 8 . 6节我们知道一个客户进程不能重新使用同一个本地端口，如果该端口是仍处于2 M S L等待连接的一部分。但如果s o c k程序作为客户程序连续运行两次，并且连接到d a y t i m e服务器上，我们就能重新使用同一本地端口。另外，对一个仍处于 2 M S L等待的连接，也能为它创建一个替身。这将如何做？

答：首先，日期服务器在将时间和日期写给客户之后对 T C P连接做一个主动关闭。这可以通过s o c k程序打印的消息： “ connection closed by peer.”表现出来。连接的客户端经历了被动关闭的状态。这样就把一对插口置于服务器端的 T I M E _ WA I T状态，而不是在客户端。其次，正如在1 8 . 6节所示，大多数伯克利演变的实现都允许一个新的连接请求到达一个正处于T I M E _ WA I T状态的一对插口，这也就是这里所发生的情况。

18.6 在1 8 . 6节的最后，我们介绍了 F I N _ WA I T _ 2状态，提到如果应用程序仅过 11分钟后实行完全关闭（不是半关闭） ，许多具体的实现都将一个连接由这个状态转移到 C L O S E D状态。如果另一端（处于 C L O S E _ WA I T状态）在宣布关闭（即发送 F I N）之前等待了1 2分钟，这一端的T C P将如何响应这个F I N？

答：因为在一个已经关闭的连接上到达了一个 F I N，所以相应于这个F I N发送了一个复位。

18.7 对于一个电话交谈，哪一方是主动打开，哪一方是被动打开？是否允许同时打开？是否允许同时关闭？

答：拨号的一方做主动打开，电话振铃的一方做被动打开。不允许同时打开，但允许同时关

闭。

18.8 在图1 8 - 6中，我们没有见到一个 A R P请求或一个A R P应答。显然主机s v r 4的硬件地址一定在b s d i的A R P高速缓存中。如果这个A R P高速缓存不存在，这个图会有什么变化？

答：我们将只看到 A R P请求，而不是 TCP SYN报文段，但 A R P请求将和图中具有相同的计时。

18.9 解释如下的t c p d u m p输出，并和图1 8 - 1 3进行比较。

答：客户在主机 s o l a r i s上，服务器在主机b s d i上。客户对服务器 S Y N的确认（ A C K）和客户的第一个数据段结合在一起（第 3行） 。这种处理非常符合 T C P的规则，尽管大多数的实现都没有这么做。接着，客户在等待它的数据的确认之前发送了它的 F I N（第4行） 。这样使得服务器可以在第 5行同时确认客户数据和它的 F I N。这次交互（将一个报文段从客户发送到服务器）需要 7个报文段，而正常的连接建立和终止（图1 8 - 1 3），以及一个数据段和它的确认，需要 9个报文段。

18.10 为什么图1 8 - 4中的服务器不将对客户 F I N的A C K与自己的 F I N合并，从而将报文段数减少为3个？

答：首先，服务器对客户的 F I N的确认一般不会被延迟（我们在 1 9 . 3节讨论延迟的确认） ，而是在F I N到达后立即发送。应用进程需要一些时间来接收 E O F，告诉它的T C P关闭它这一端的连接。第二，服务器收到客户的 F I N后，并不一定要关闭它这一端的连接。就像我们在1 8 . 5节中看到的，仍然可以发送数据。

18.11 在图1 8 - 1 6中， R S T的序号为什么是2 6 3 6 8 0 0 2 ?

答：如果一个产生 R S T的到达报文段有一个 A C K字段，那么 R S T的序号就是到达的 A C K字段。第6行中值为1的A C K是相对于第2行中的2 6 3 6 8 0 0 1的I S N。

18.12 TCP向链路层查询M T U是否违反分层的规则？

答：参见 [Crowcroft et al. 1992]中对分层的评论。

18.13 假定在图1 4 . 1 6中，每个D N S使用T C P而不是U D P进行查询，试问需要交换多少个报文段？

答：发出了5个查询。假设有3个分组用于建立连接， 1个用于查询， 1个用于确认查询， 1个用于响应， 1个用于确认响应， 4个用于终止连接。这就是说每次查询需要 11个分组，总共需要5 5个分组。使用U D P则可以减少到1 0个分组。如果对查询的确认和响应结合在一起，每个查询需要的分组可以减少到 1 0个（ 1 9 . 3节）。

18.14 假定M S L为1 2 0秒，试问系统能够初始化一个新连接然后进行主动关闭的最大速率是多少？

答：限制是每秒2 6 8个连接：最大数目的T C P端口号（ 6 5 5 3 6-1024 = 64512，忽略知名端口）除以T I M E _ WA I T状态的2 M S L。

18.15 阅读RFC 793，分析处于 T I M E _ WA I T状态的主机收到使其进入此状态的重复的 F I N时所发生的情况。

答：重复的F I N会得到确认， 2 M S L定时器重新开始。

18.16 阅读RFC 793，分析处于T I M E _ WA I T状态的主机收到一个 R S T时所发生的情况。

答：在T I M E _ WA I T状态中收到一个 R S T引起状态过早地终止。这就叫作 T I M E _ WA I T断开( a s s a s s i n a t i o n )。 RFC1337 [Braden 1992a]仔细讨论了这个现象，并显示了潜在的问题。这个R F C提出的简单的修改就是在 T I M E _ WA I T状态时忽略R S T段。

18.17 阅读Host Requirements RFC并找出半双工T C P关闭的定义。

答：它是在具体实现不支持半关闭连接的时候。一旦应用进程引起发送一个 F I N，应用进程就不能再从这个连接读数据了。

18.18 在图1 - 8中，我们曾提到到来的 T C P报文段可根据其目的端口号进行区分，请问这种说法是否正确？

答：不。输入的数据段通过源 I P地址、源端口号、目的 I P地址和目的端口号进行区分。在1 8 . 11节中我们看到对于输入的连接请求，一个 T C P服务器一般可以通过目的 I P地址来拒绝接收。