Telnet和Rlogin：远程登录（26.4__3）

来源：互联网发布：碧蓝航线知乎编辑：程序博客网时间：2024/05/22 08:20

26.4.5 半双工、一次一字符、一次一行或行方式

对于大多数Te l n e t的服务器进程和客户进程，共有4种操作方式。

1. 半双工

----------------------- Page 13-----------------------

这是Te l n e t的默认方式，但现在却很少使用。N V T默认是一个半双工设备，在接收用户输

入之前，它必须从服务器进程获得GO AHEAD （G A）命令。用户的输入在本地回显，方向是

从N V T键盘到N V T打印机，所以客户进程到服务器进程只能发送整行的数据。

虽然该方式适用于所有类型的终端设备，但是它不能充分发挥目前大量使用的支持全双

工通信的终端功能。RFC 857 [Postel 和Reynolds 1983c] 定义了E C H O选项，RFC 858 [Postel

和Reynolds 1983d]定义了SUPPRESS GO AHEAD （抑制继续进行）选项。如果联合使用这两

个选项，就可以支持下面将讨论的方式：带远程回显的一次一个字符的方式。

2. 一次一个字符方式

这和前面的R l o g i n工作方式类似。我们所键入的每个字符都单独发送到服务器进程。服务

器进程回显大多数的字符，除非服务器进程端的应用程序去掉了回显功能。

该方式的缺点也是显而易见的。当网络速度很慢，而且网络流量比较大的时候，那么回

显的速度也会很慢。虽然如此，但目前大多数Te l n e t实现都把这种方式作为默认方式。

我们将看到，如果要进入这种方式，只要激活服务器进程的 SUPPRESS GO AHEAD选项

即可。这可以通过由客户进程发送DO SUPPRESS GO AHEAD （请求激活服务器进程的选项）

请求完成，也可以通过服务器进程给客户进程发送 WILL SUPPRESS GO AHEAD （服务器进

程激活选项）请求来完成。服务器进程通常还会跟着发送 WILL ECHO ，以使回显功能有效。

3. 一次一行方式

该方式通常叫做准行方式（kludge line mode ），该方式的实现是遵照RFC 858 的。该R F C

规定：如果要实现带远程回显的一次一个字符方式， E C H O选项和SUPPRESS GO AHEAD选

项必须同时有效。准行方式采用这种方式来表示当两个选项的其中之一无效时， Te l n e t就是工

作在一次一行方式。在下节中我们将介绍一个例子，可以看到如何协商进入该方式，并且当

程序需要接收每个击键时如何使该方式失效。

4. 行方式

我们用这个术语代表实行方式选项，这是在RFC 1184[Borman 1990] 中定义的。这个选项

也是通过客户进程和服务器进程进行协商而确定的，它纠正了准行方式的所有缺陷。目前比

较新的Te l n e t实现支持这种方式。

图2 6 - 11是不同的Te l n e t客户进程和服务器进程之间默认的操作方式。“c h a r ”表示一次一

个字符方式，“k l u d g e ”表示准行方式，“l i n e m o d e ”表示如RFC 11 8 4定义的实行方式。

图26-11 不同的Telnet客户进程和服务器进程之间默认的操作方式

从图中可以看出，只有当客户进程和服务器进程都是 B S D / 3 8 6或4 . 4 B S D 的时候才支持实

行方式。当服务器进程的操作系统是这两者之一时，如果客户进程不支持实行方式，才会协

商进入准行方式。从图中还可以看出，其实任何类型的客户进程和服务器进程都支持准行方

式，但是一般都不把它作为默认方式，除非服务器进程指定。

----------------------- Page 14-----------------------

26.4.6 同步信号

Te l n e t 以Data Mark命令（即图2 6 - 8 中的D M ）作为同步信号，该同步信号是以T C P紧急数

据形式发送的。D M命令是随数据流传输的同步标志，它告诉收端回到正常的处理过程上来。

Te l n e t的双方都可以发送该命令。

当一端收到对方已经进入了紧急方式的通知后，它将开始读数据流，一边读一边丢弃所读

的数据，直到读到Te l n e t命令为止。紧急数据的最后一个字节就是D M字节。采用T C P紧急方式

的原因就是：即使T C P数据流已经被T C P流量控制所终止，Te l n e t命令也可以在连接上传输。

在下节中我们将看到Te l n e t同步信号的使用情况。

26.4.7 客户的转义符

和R l o g i n 的客户进程一样，Te l n e t客户进程也可以使用户直接和客户进程进行交互，而不

是被发送到服务器进程。通常客户的转义字符是 C o n t r o l _ ] （c o n t r o l键和右中括号键，通常以

“^ ] ”表示）。这使得客户进程显示它的提示符，通常是“t e l n e t >”。这时候有很多命令可供

用户选择，以改变连接的特性或打印某些信息。大多数的 U n i x客户进程提供“h e l p ”命令，

该命令将显示所有可用的命令。

在下节中我们将看到客户进程转义的例子，以及此时可以输入的命令。

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。

----------------------- Page 15-----------------------

图26-12 Telnet双方选项协商的初始化过程

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 [Borman

----------------------- Page 16-----------------------

1 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个字节的数据是：

----------------------- Page 17-----------------------

\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

字节并执行它后续的命令。

图26-13 Telnet服务器进程和客户进程选项协商初始化过程

报文段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的各种特性。但考察这些例子中

----------------------- Page 18-----------------------

的分组交换，如图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 。

(d) 然后用户输入口令，当用户按下R E T U R N键的时候，客户进程把口令发送给服务器

进程。此时口令不回显，因为客户进程认为服务器进程将回显它。

(e) 由于口令的结束符R E T U R N没有回显，服务器进程发送两字节字符序列 C R和L F 以

移动光标。

(f) 服务器进程发送WONT ECHO 。

(g) 客户进程回送DONT ECHO 。然后继续由客户进程负责回显。

一旦登录完成，客户进程将把数据以整行的方式发送给服务器进程。这就是行方式选项

的目的。行方式大大地减少了客户进程和服务器进程之间的数据交互数量，而且对于用户的

----------------------- Page 19-----------------------

击键（也就是回显和编辑）提供更快的响应。图 2 6 - 1 4显示的是当我们输入命令时，在行方式

连接下分组交换的情况。

Vangogh %d a t e

（去掉了业务种类信息和窗口通告信息）。

图26-14 Telnet行方式下客户进程向服务器进程发送命令的情况

把它和在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-15 Rlogin和不同方式的Telnet之间的比较

0 0