速读原著-TCP/IP(Rlogin的例子)

第26章 Telnet和Rlogin：远程登录

26.3 Rlogin的例子

在这里举两个例子：第一个是当 R l o g i n会话建立的时候，客户和服务器的协议交互；从第二个例子可以看到，当用户键入中断键以取消正在服务器运行的程序时，服务器将产生很多输出。在图1 9 - 2中，我们给出了通常情况下， R l o g i n会话上的数据流交互情况。

26.3.1 初始的客户-服务器协议

图2 6 - 5显示的是从主机b s d i到服务器s v r 4的R l o g i n建立一个连接时的时间系列 (在图中，去掉了通常的T C P连接的建立过程，窗口通告以及服务类型信息）。

上节介绍的协议对应图中的报文段 1 ~ 9。客户发送一个字节的 0（报文段1）之后发送3个字符串（报文段 3）。在本例中，这 3个字符串分别是： r s t e v e n s（客户的登录名）、r s t e v e n s（服务器的登录名）和 i b m p c 3 / 9 6 0 0（终端类型和速率）。当服务器确认了这些信息后回送一个字节的0（报文段5）。

然后服务器发送窗口请求命令（报文段 7）。这是采用T C P紧急方式发送的，我们又一次看到一个实现( S V R 4 )采用较老的但更普通的解释，即紧急指针指明的序号是紧急数据的最后一个字节加1。客户回送1 2字节的数据：2字节的0 x ff，2字节的‘s’，4个16 bit长度的窗口数据。

下面的4个报文段（ 10, 12, 14和1 6）是由服务器发送的，是从服务器操作系统的问候( g r e e t i n g )。之后报文段1 8是一个7字节长度的外壳进程提示符“ s v r 4％”。客户输入的信息如图 1 9 - 2所示，每次发送一个字节。客户和服务器都可以主动中断该连 接。如果我们输入一个命令，让服务器的外壳程序终止运行，那么服务器将中断该连接。如果我们给R l o g i n客户键入一个转移符（通常是一个“ ~”），紧跟着一个句点或者是一个文件结束符号，那么客户将主动关闭该连接。

图2 6 - 5中，客户进程的端口号是 1 0 2 3，这是由I A N A分配的（在 1 . 9节中介绍）。R l o g i n协议要求客户进程用小于1 0 2 4的端口号，术语叫做保留端口。在U n i x系统中，客户进程一般不能使用保留端口号，除非客户进程具有超级用户权限。这是客户进程和服务器进程相互鉴别的一部分，这种鉴别可以使得用户不需要口令而可以登录。[ S t e v e n s 1 9 9 0 ]详细讨论了客户进程和服务器进程相互鉴别的过程和有关保留端口号的问题。

在这里插入图片描述

26.3.2 客户中断键

让我们看一下另外一个例子，这个例子涉及到 T C P的紧急方式。当数据流已经终止时，我们键入中断键。这个例子要用到前面讲到的很多 T C P算法如：紧急方式、糊涂窗口避免技术、窗口流量控制和坚持计时器。在主机 s u n上运行客户进程。我们登录到主机 b s d i，向终端输出一个大文本文件，然后键入 C o n t r o l _ S中断输出。当输出停止时，我们键入中断键（D E L E T E）以异常方式中止该进程。

在这里插入图片描述

下面这些要点是关于客户、服务器和连接的状态的概述：

1. 键入C o n t r o l _ S以停止终端的输出。
2. 用户终端的输出缓存很快被填满，所以 R l o g i n的客户向终端的写操作被阻塞。
3. 此时客户也不能从网络连接上读取数据，所以客户的 T C P接收缓存也将被填满。
4. 当接收缓存已满时，客户进程的 T C P会向服务器进程的T C P通告现在的接收窗口是0。
5. 当服务器收到客户的窗口为 0时，将停止向客户发送数据，这样，服务器的发送缓存也将被填满。
6. 由于发送缓存已满，所以R l o g i n服务器进程将停止。这样， R l o g i n服务器将不能从服务器运行的应用程序（c a t）处读取数据。
7. 当c a t程序的输出缓存也被填满时， c a t也将停止。
8. 然后我们用中断键来终止服务器上的 c a t程序。这个命令从客户的 T C P传输到服务器的T C P，这是因为该方向的数据传输没有被流量控制所终止。
9. c a t应用程序收到中断命令并且终止。这使得它的输出缓存（也就是 R l o g i n服务器进程读取数据的地方）被清空，这将唤醒R l o g i n服务器进程。然后R l o g i n服务器进程进入紧急方式，向客户进程发送“清仓输出”命令（ 0 x 0 2）。

图2 6 - 6概括了从服务器到客户的数据流（图中的序号就是下面将介绍的图中的时间系列）。

在这里插入图片描述

发送缓存的阴影部分是4 0 9 6字节的缓存中没有被使用的部分。图2 6 - 7是该例子的时间系列。

在报文段1 ~ 3，服务器进程向客户进程发送满长度（即 1 0 2 4字节）的T C P报文段。由于此时客户进程不能向终端写信息，客户进程也不能从网络上读数据，所以在报文段 4中，客户进程向服务器进程发送A C K确认时，告诉服务器进程此时接收窗口是1 0 2 4个字节。在报文段5中，服务器进程发送的数据长度就不再是满长度的了。

同样，报文段 6中客户进程的确认信号所带的接收窗口大小是此时接收缓存的空余字节长度。那么在报文段 5中，客户进程A C K信号中为什么接收窗口大小是 3 4 9而不是0呢？这是因为如果发送的是 0（糊涂窗口避免技术），那么窗口指针将右边界移动到了左边界，而这是绝对不能发生的（见 2 0 . 3节）。当服务器进程收到报文段6的A C K信号后，它就不能再发送全长的数据报了，这时候它就采用糊涂窗口症避免技术，不发送任何东西，同时置一个 5秒的坚持计时器。当计时器超时，服务器进程就发送一个 3 4 9字节大小的数据（如报文段 7）。由于此时客户进程依然不能输出接收缓存的信息，所以接收缓存将被填满，客户进程将发送 A C K信号，此时接收窗口大小为 0（如报文段8）。

这时候我们键入中断键并且以报文段 9显示的那样传输。此时的接收窗口大小依然为 0。当服务器进程接收到该中断键后，服务器进程把它发送给应用程序（ c a t），应用程序就终止。由于应用程序被终端中断键所终止，应用程序就清空它的输出缓存。服务器进程发现该变化后就通过T C P紧急方式向客户进程发送“清仓输出”命令，这如报文段 1 0所示。注意命令字节0 x 0 2放在第3 0 1 4 6字节中（紧急指针减1）。报文段1 0告诉客户进程在命令字节前还有 3 4 1 9个字节（从2 6 7 2 7到3 0 1 4 5）在服务器进程的发送缓存中等待发送。

报文段1 0采用紧急通知方式发送，包含了服务器进程向客户进程发送的下一个字节（序号是2 6 7 2 7）。它不包含“清仓输出”命令字节。记得在 2 2 . 2节中曾经介绍过，发送进程可以发送一个字节的数据来试探对方的接收窗口是否关闭。报文段 1 0就是采用了这个原理。然后客户进程T C P就立即发送如报文段 11所示的数据。虽然此时接收窗口还是 0，但是在客户进程内部，由于客户进程的 T C P收到了对方的紧急通知，它把该通知告诉客户进程，客户进程就知道服务器进程已经进入了紧急方式了。

在这里插入图片描述

当R l o g i n客户进程从它的T C P收到了紧急通知，并且客户进程开始读取已经在输入缓存中等待被读取的数据时，接收窗口就会重新打开（报文段 1 3）。然后服务器进程就开始正常发送数据（报文段14, 15, 17和1 8）。注意报文段1 8的数据报中包含紧急数据的最后一个字节的数据（序号3 0 1 4 6），该字节包含服务器进程发送给客户进程的命令字节。当客户进程收到该命令后，它就丢弃报文段 1 4、1 5、1 7和1 8所收到的数据，并且清空终端的输出缓存。在报文段 1 9中的下两个字节是中断键的回显“ ^ ?”。最后一个报文段（2 1）包含了客户进程的外壳提示符。

这个例子描述了当用户键入中断键后，连接的双方数据如何被存储的情况。如果这些动作仅仅丢弃在服务器的 3 4 1 9个字节数据，而不丢弃已经在客户的 4 0 9 6个字节的数据，那么这些已经在客户的终端输出缓存中的 4 0 9 6字节数据将输出到终端上。