速读原著-TCP/IP(Telnet举例)

第26章 Telnet和Rlogin：远程登录

26.5 Telnet举例

在这里我们将介绍在三种不同的操作方式下 Te l n e t选项协商的情况。这些方式包括：单字符方式、实行方式和准行方式。同样我们还将讨论当用户在服务器端按了中断键退出了一个正在运行的进程后，系统的运行情况。

26.5.1 单字符方式

首先介绍基本的单字符方式，该方式类似于 R l o g i n。用户在终端输入的每个字符都将由终端发送到服务器进程，服务器进程的响应也将以字符方式回显到终端上。在这里运行的是一个新的客户进程B S D / 3 8 6，它试图激活很多新的选项，服务器进程还是运行老的 S V R 4，我们将看到很多选项被服务器拒绝。

为了看到服务器和客户机之间选项协商的内容，我们将激活客户进程的一个选项来显示所有的选项协商。同样我们运行 t c p d u m p来获得数据报交换的时间次序。图 2 6 - 1 2显示了这个交互会话。

在图中，我们已经对由 S E N T或R C V D开头的选项协商的每一步都进行了标注。关于每一步的解释如下：

1. 客户发起SUPPRESS GO AHEAD选项协商。由于GO AHEAD命令通常是由服务器发送给客户的，而且客户希望服务器激活该选项，因此该选项的请求方式是 D O（由于激活这一选项将会禁止G A命令的发送，上述过程很容易让人混淆）。在第1 0行可以看到服务器进程同意该选项。
2. 客户进程要按照在RFC 1091[VanBokkelen 1989]中的定义发送终端类型。这对U n i x类型的客户进程来讲是很普通的。因为客户进程要激活本地的选项，所以该选项的请求方式是W I L L。
   
3. NAW S的意思是“协商窗口大小”，它在RFC 1073 [Wa i t z m a n ]中有定义。如果服务器进程同意该选项（实际上不同意，见 11行），客户进程就要发送终端窗口的行、列大小的子选项。而且只要窗口大小发生变化，客户进程随时都将向服务器进程发送这一子选项（这和图2 6 - 4中R l o g i n的0 x 8 0命令类似）。
4. TSPEED 选项允许发送方（通常是客户进程）发送它的终端速率，这在 RFC 1079[Hedrick 1988b]中有定义。如果服务器进程同意（实际上不同意，见 1 2行），客户进程将发送其发送速率和接收速率的子选项。
5. LFLOW代表“本地流量控制”，这在RFC1371 [Hedrick 和Borman 1992]中定义。客户进程给服务器进程发送该选项，表示客户进程希望用命令方式激活或禁止流量控制。如果服务器进程同意（实际上不同意，见 1 3行），只要C o n t r o l _ S和C o n t r o l _ Q进程需要在客户进程和服务器进程进行切换，客户进程都要向服务器进程发送子选项（这类似于图 2 6 - 4中R l o g i n的0 x 1 0和0 x 2 0命令）。正如在关于R l o g i n的讨论中我们所提到的那样，由客户进程进行流量控制的效果比由服务器进程来完成要好。
6. LINEMODE代表在2 6 . 4中所说的实行方式。所有终端字符的处理由 Te l n e t客户进程完成（例如回格，删除行等），然后整行发送给服务器进程。在本节后面，我们将介绍一个例子。该选项同样被服务器进程拒绝，如 1 4行所示。
7. ENVIRON选项允许客户进程把环境变量发送给服务器进程，这在 RFC 1408 [Borman1 9 9 3 a ]中有定义。这样就可以把客户进程的用户环境变量自动传播到服务器进程。在 1 5行，服务器进程拒绝该选项（ U n i x中的环境变量通常是大写字母，紧跟一个等号，然后是一个字符串值，当然这只是一个惯例而已）。默认情况下，BSD/386 Te l n e t客户进程发送两个环境变量：D I S P L AY和P R I N T E R，前提是这两个变量已经定义并且有效。 Te l n e t用户可以定义其他一些要发送的环境变量。
8. STAT U S选项（RFC 859 [Postel 和Reynolds 1983e]中定义）允许连接的一方询问对方对Te l n e t选项目前状态的理解。在这个例子中，客户进程要求对方激活选项（ D O）。如果服务器进程同意（实际上不同意，见 1 6行），客户进程就可以要求服务器进程以子选项的形式发送它的状态值。
9. 这是服务器进程的第一个响应。服务器进程同意激活终端类型选项（几乎所有的 U n i x类型的服务器进程都支持该选项）。但现在客户进程还不能立即发送它的终端类型。它必须要等到服务器进程用子选项的形式询问终端类型的时候才能够发送（ 1 7行）。
10. 服务器进程同意抑制发送GO AHEAD命令。
11. 服务器进程不同意客户进程发送它的窗口大小。
12. 服务器进程不同意客户进程发送它的终端速率。
13. 服务器进程不同意客户进程实施流量控制。
14. 服务器进程不同意客户进程激活行方式选项。
15. 服务器进程不同意客户进程发送环境变量。
16. 服务器进程不发送状态信息。
17. 这是服务器进程要求客户进程发送终端类型的子选项。
18. 客户进程把终端类型“I B M P C 3”以6字节的字符串形式发送给服务器进程。
19. 服务器进程要求客户进程发起请求，要求服务器进程激活回显选项。这是本例中服务器进程第一次主动发起选项协商。
20. 客户进程同意由服务器进程实现回显功能。
21. 服务器进程要求客户进程实现回显功能。这个命令是多余的，它只是将前两行进行了交换。这是目前大多数 U n i x的Te l n e t服务器进程判断客户进程是否运行 4 . 2 B S D或更新的B S D版本时的一个方法。如果客户进程回送 WILL ECHO ，就表明客户进程运行的是老版本的4 . 2 B S D，不支持T C P的紧急方式（在这种情况下就不能采用 T C P紧急方式）。
22. 客户进程回送WONT ECHO，表示它不是一台4 . 2 B S D主机。
23. 对于客户进程回送的WONT ECHO，服务器进程以DONT ECHO作为响应。图2 6 - 1 3显示的是本例中服务器进程和客户进程交互的时间系列（去掉了连接建立部分）。报文段1包含了图2 6 - 1 2中的1 ~ 8行。该报文段中包含2 4个字节数据，每个选项占 3个字节。这是客户进程发起的选项协商。该报文段显示多个 Te l n e t选项可以打在一个T C P段中发送。报文段3是图2 6 - 1 2中的第9行，即DO TERMINAL TYPE命令。报文段5包含下面的8个选项协商中服务器进程的响应，即图 2 6 - 1 2中的1 0 ~ 1 7行。该报文段的长度是 2 7个字节，因为1 0 ~ 1 6行是常规选项，每个占 3个字节，而1 7行的子选项部分占 6个字节。报文段6包含1 2个字节，和1 8行对应，这是客户发送它的终端类型的子选项。

报文段8（5 3个字节）包含两个 Te l n e t命令和4 7字节的输出数据。前面的两个服务器进程发送Te l n e t命令占6字节，：WILL ECHO和DO ECHO（1 9和2 1行）。后4 7个字节的数据是：\r\n\r\nUNIX(r) System V Release 4.0 (svr4) \r\n\r\0\r\n\r\0前面4个字节数据在字符串输出之前产生两个空行。两字节的字符序列“ \ r \ n”在Te l n e t中被认为是换行命令，而两字节的字符序列“ \ r \ 0”则被认为是回车命令。这表明数据和命令可以在一个数据段中传输。 Te l n e t服务器进程和客户进程必须扫描接收到的每个字符，寻找 I A C字节并执行它后续的命令。

报文段9包含客户进程发送的最后两个选项： 2 0和2 2行。2 3行是报文段1 0的响应，也是服务器进程发送的最后一个选项数据。

从现在开始，双方就可以交互数据了。当然在交互数据的过程中还可以进行选项协商，我们在该例子中就不多介绍了。报文段 1 2是服务器进程发送的提示符“ l o g i n :”。报文段1 4是用户输入的登录用户名的第一个字符，它的回显在报文段 1 5中。这和我们在 1 9 . 2节中介绍的R l o g i n交互类似：客户进程每次发送一个字符，服务器进程完成回显工作。

图2 6 - 1 2中的选项协商由客户进程初始化的，但是在本书中我们已经介绍了用Te l n e t客户进程连接某些标准服务器进程如：日间（d a y t i m e）服务器、回显( e c h o )服务器等情况。当然我们介绍这些的目的是为了描述 T C P的各种特性。但考察这些例子中的分组交换，如图1 8 - 1，我们并没有看到客户进程发起的选项协商。为什么？这是因为在U n i x系统中，除非使用标准的Te l n e t端口号2 3，否则客户进程不进行选项协商。这个特性使得Te l n e t客户进程可以使用标准的N V T同其他一些非Te l n e t服务器进程交换数据。我们已经在日间服务器、回显服务器和丢弃( d i s c a r d )服务器中使用了这个特性，在后面章节介绍FTP和SMTP服务器的时候我们还将使用该特性。

26.5.2 行方式

为了描述 Te l n e t的行方式选项协商过程，我们在主机 b s d i运行客户进程，服务器是位于v a n g o g h . v s . b e r k e l e y . e d u节点运行4 . 4 B S D操作系统的一台主机。 B S D / 3 8 6和4 . 4 B S D都支持这个选项。

我们不详细讨论所有的报文、选项和子选项协商过程，因为这个过程和前面的例子类似，而且对于行方式选项我们已经论述得比较清楚。下面我们仅仅讨论在选项协商中的一些区别。

1. 对于B S D / 3 8 6希望协商的选项例如：窗口大小、本地流量控制、状态、环境变量和终端速率等，4 . 4 B S D服务器进程都支持。
2. 4 . 4 B S D服务器进程将协商一个 B S D / 3 8 6客户进程不支持的新选项：鉴别（为避免以明文形式在网络上传输用户口令）。
3. 和上个例子一样，客户进程发送 WILL LINEMODE选项，由于服务器进程支持该选项，所以服务器进程发送DO LINEMODE。此时客户进程以子选项形式给服务器进程发送1 6个特定字符。这些字符是能影响客户进程的特定终端字符值：如中断字符，文件结束符等。服务器进程给客户进程发送一个子选项，让客户进程处理所有的输入，执行所有的编辑功能（删除字符，删除行等）。客户进程把除控制字符以外的字符以行的形式发送给服务器进程。服务器进程还要求客户进程把所有中断键和信号键转换为相应的 Te l n e t字符。例如中断键是C o n t r o l _ C，我们可以按C o n t r o l _ C来中断服务器端的某个进程。客户进程必须把C o n t r o l _ C转换为Te l n e t的I P命令（<IAC, IP>）传输给服务器进程。
4. 当用户输入口令时情况也有所不同。在 R l o g i n和一次一字符方式的 Te l n e t中，都是由服务器进程负责回显，所以当服务器进程读到口令时，它并不回显这些字符。但在行方式中由客户进程负责回显。下面这些交互过程将处理这种情况：
   (a) 服务器进程发送WILL ECHO，以告诉客户进程：服务器进程将处理回显。
   (b) 客户进程回送DO ECHO。
   © 服务器进程向客户进程发送字符串 P a s s w o r d:，客户进程把它发送到终端上。
   (d) 然后用户输入口令，当用户按下 R E T U R N键的时候，客户进程把口令发送给服务器进程。此时口令不回显，因为客户进程认为服务器进程将回显它。
   (e) 由于口令的结束符 R E T U R N没有回显，服务器进程发送两字节字符序列 C R和L F以移动光标。
   (f) 服务器进程发送WONT ECHO。
   (g) 客户进程回送DONT ECHO。然后继续由客户进程负责回显。

一旦登录完成，客户进程将把数据以整行的方式发送给服务器进程。这就是行方式选项的目的。行方式大大地减少了客户进程和服务器进程之间的数据交互数量，而且对于用户的击键（也就是回显和编辑）提供更快的响应。图 2 6 - 1 4显示的是当我们输入命令时，在行方式连接下分组交换的情况。Vangogh % d a t e（去掉了业务种类信息和窗口通告信息）。

把它和在R l o g i n中输入同样命令（图 1 9 - 2）时的情况进行一下比较。我们看到在 Te l n e t行方式下只需要 2个报文段（一个包含数据，另一个用于 A C K，连同 I P和T C P首部共8 6字节），而在R l o g i n中要发送1 5个报文段（5个有键入的数据， 5个有回显的数据， 5个是A C K，共6 11字节）。可见节省的数据量是非常可观的。

如果在服务器端运行一个需要进入单个字符方式的应用程序（例如 v i编辑器）会怎么样呢？实际上将发生如下的一些交互：

1. 当服务器的应用程序启动了，并改变其伪终端方式时， Te l n e t服务器进程被通告需要进入单个字符方式。然后服务器发送 WILL ECHO命令和行方式子选项，以告知客户不要再以行方式工作，转而进入单个字符方式。
2. 客户响应以DO ECHO，并确认行方式子选项。
3. 应用程序在服务器上运行。我们键入的每个字符将发送到服务器（当然要强制使用N a g l e算法），此时服务器将处理必要的回显工作。
4. 当应用程序终止时，就恢复其伪终端方式，并通告 Te l n e t服务器。服务器将向客户发送WONT ECHO命令，同时发送行方式子选项，告诉客户恢复进入行方式。
5. 客户响应DONT ECHO，确认进入行方式。

上述情况同我们键入口令之间的区别表明：回显功能和单个字符方式与一次一行方式没有依赖关系。当我们键入口令时，回显功能必须失效，但一次一行方式有效。对于一个全屏应用来讲，例如编辑器，回显必须失效而单个字符方式必须有效。

图2 6 - 1 5概括了R l o g i n和Te l n e t不同方式之间的差异。

26.5.3 一次一行方式（准行方式）

从图2 6 - 11可以看出，如果客户不支持行方式，那么较新的服务器支持行方式选项，它也将转入准行方式(Kludge line mode)。我们同时指出所有的客户进程和服务器进程都支持准行方式，但它不是默认方式，必须由客户进程或用户特地激活它。让我们来看看如何用 Te l n e t选项激活准行方式。
首先介绍当客户进程不支持行方式时， B S D / 3 8 6服务器进程如何协商进入该方式。

1. 当客户进程不同意服务器进程激活行方式的请求时，服务器进程发送 DO TIMINGM A R K选项。RFC 860 [Postel Reynolds1983f]定义了这个Te l n e t选项。它的作用是让收发双方同步，关于这个问题将在本节的后面讲到用户键入中断键时讨论。该选项只是用来判断客户进程是否支持准行方式。
2. 客户响应WILL TIMING MARK，表明支持准行方式。
3. 服务器发送WONT SUPPRESS GO AHEAD和WONT ECHO选项，告诉客户它希望禁止这两个选项。我们在前面已经强调：单个字符方式下是假定 SUPPRESS GO AHEAD和E C H O选项同时有效的，所以禁止两个选项就进入了准行方式。
4. 客户响应DONT SUPPRESS GO AHEAD和DONT ECHO命令。
5. 服务器发送l o g i n :提示符，然后用户键入用户名。用户名是以整行的方式发送给服务器，回显由客户进程在本地处理。
6. 服务器发送P a s s w o r d :提示符和WILL ECHO命令。这将使客户进程的回显失效，因为此时客户进程认为服务器进程将处理回显工作，所以用户键入的口令就不回显到屏幕上。客户响应DO ECHO命令。
7. 我们键入口令。客户以整行方式发送到服务器。
8. 服务器发送WONT ECHO命令，使得客户重新激活回显功能，客户响应 DONT ECHO。从此以后的普通命令处理过程就和行方式相似了。客户进程负责所有的编辑和回显，并以整行的方式发送给服务器进程。

在图2 6 - 11中，我们已经强调：所有标注为“ c h a r”的记录都支持准行方式，只不过默认是单个字符方式罢了。如果要客户进入行方式，我们就能很容易看到选项协商的过程：


这将使Te l n e t会话进入准行方式，此时SUPPRESS GO AHEAD和E C H O选项都是失效的。如果在服务器端运行如v i编辑器这样的应用程序，同样会有行方式下遇到的问题。当要运行这样的应用程序时，服务器进程必须告诉客户进程从准行方式切换到单字符方式。当应用程序结束时，必须告诉客户进程返回到准行方式。下面是这个过程需要用到的技术要点。

1. 当应用程序改变其伪终端方式并通知服务器进程时，服务器进程将进入单字符方式。服务器进程向客户进程发送 WILL SUPPRESS GO AHEAD和WILL ECHO，这将使客户进程进入单字符方式。
2. 客户进程回送DO SUPPRESS GO AHEAD和WILL ECHO。
3. 应用程序开始在服务器端运行。
4. 当应用程序结束并改变其伪终端方式时，服务器进程发送 WONT SUPPRESS GOA H E A D和WONT ECHO命令，使得客户进程返回准行方式。
5. 客户进程回送DONT SUPPRESS GO AHEAD和DONT ECHO命令，告诉服务器进程它已经回到了准行方式。

图2 6 - 1 6概括了单个字符方式及准行方式中不同的SUPPRESS GO AHEAD和E C H O选项设置。

26.5.4 行方式：客户中断键

看一下当用户键入中断键时 Te l n e t将发生什么情况。假定在客户主机 b s d i和服务器c a n g o g h . c s . b e r k e l e y . e d u之间建立了一个Te l n e t会话。图2 6 - 1 7显示了当用户键入中断键后的时间系列（去掉了窗口通告和服务类型）。

报文段1中显示的是中断键（通常是C o n t r o l _ C或D E L E T E）已经转换为Te l n e t的I P（中断进程）命令：<IAC, IP>。下面的3个字节：<IAC, DO, TM>，组成了Te l n e t的DO TIMING MARK选项。这个标志由客户进程发送，必须使用W I L L或W O N T响应。所有在响应前收到的数据都要丢弃（除非是Te l n e t命令）。这是服务器进程和客户机端的同步过程。报文段1没有采用T C P紧急方式。

Host Requirements RFC叙述了I P命令不能使用Te l n e t的同步信号来发送。如果可以的话，那么<IAC, IP>的后面将跟随<IAC, DM>，同时紧急指针指向D M字节。大多数的Unix Telnet 客户有一个选项来使用同步信号发送I P命令，但是这个选项默认是不用的（正如我们这里看到的）。

报文段 2是服务器进程对 DO TIMING MARK选项的响应。紧随其后的是报文段 3和4中 Te l n e t的同步信号：<IAC, DM>。报文段3中的紧急指针指向将在报文段 4中发送的D M字节。

如果服务器进程到客户进程的窗口已满，那么客户进程发送了如报文段 1中的I P命令后就丢弃收到的所有数据。即使服务器进程被 T C P流量控制所终止而不能发送如报文段 2、3和4中的数据，紧急指针仍然可以发送。这和图 2 6 - 7中的R l o g i n类似。

为什么同步信号要分为两个数据段发送（ 3和4）？原因就是我们在 2 0 . 8节中详细讨论T C P紧急指针时提到的情况。有关主机需求的 R F C中提到紧急指针应指向紧急数据的最后一个字节，而很多衍生于伯克利的系统中，紧急指针指向紧急数据的倒数第 2个字节（回忆一下在图2 6 - 6中，紧急指针指向命令字节的前一个字节）。Te l n e t服务器进程故意把同步信号的第 1个字节作为紧急数据，它知道紧急指针将指向下 1个字节（即D M字节），而I A C字节和紧急指针必须立即发送，在下一步才发送 D M字节。

最后一个报文段6发送的是数据，它是服务器进程发生的提示符。