rfc854.txt

中文RFC文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者： 
译文发布时间：2001-10-20
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。



Network Working Group                                          J. Postel
Request for Comments: 854                                    J. Reynolds
                                                                     ISI
Obsoletes: NIC 18639                                            May 1983


TELNET协议规范
(RFC874——TELNET PROTOCOL SPECIFICATION)

本RFC指定了一个ARPA互联网社区的标准。在ARPA互联网上的主机应该采纳与实
现该标准。
目录
简介	1
一般性的考虑	1
网络虚终端	4
数据的传输	4
控制功能的标准表示	5
TELNET中的“同步（SYNCH）"信号	7
NVT打印机和键盘	8
TELNET命令结构	11

简介
TELNET协议的目的是提供一个相对通用的，双向的，面向八位字节的通信机制。它的主要
目标是允许界面终端设备和面向终端的过程能通过一个标准过程进行互相交互。另外，可以
预想，该协议可以应用到终端到终端通信(“连接”)和过程到过程通信(分布计算)中。
一般性的考虑
一个TELNET连接就是一个用来传输带有TELNET控制信息数据的传输控制协议(TCP)的
连接。

TELNET协议的建立基于这样三个主要想法:一，网络虚终端的概念;二，可谈判的选项
的原理;三，对终端和过程进行均衡看待的观点。

1．一旦一个TELNET连接建立后，通信的两端被假设为在一个”网络虚拟终端”，或
者NVT上开始和终止操作。一个NVT可以被想象为一个能提供标准的，网络范围的规范终
端的中间代表者。这消除了”服务者”和”用户”之间需要保存对方终端和终端处理协定的
信息的必要。所有的主机，包括用户和服务器，把他们本地的设备属性和协定映射为就象一
个在网络上的NVT，而且每一方都可以假设对方也有一个类似的映射。NVT有意地使过度
受限(没有提供给主机足够的词汇来映射到他们的本地字符集)和过度包含(使用适当的终止
来处罚用户)达到了平衡。

    注意:”用户”机通常指那些进行连接的物理终端，”服务器”提出指的是那些能够提供
一些服务的机器。从终端到终端或过程到过程的可应用的平等性来看，”用户”指的是初始
化通信连接的机器。

2．可谈判的选项的观点基于这样一个事实:许多主机都希望能够在NVT之上提供更多
的服务，而许多用户将会拥有一个更复杂的终端，并且希望能够得到一流的，而不是极少的
一点服务。尽管相互独立，但建立在TELNET协议中的是许许多多的”选项”，这些选项将
被用来认可及同”DO,DON’T,WILL,WON’T”结构(下面将会讨论)一起使用去允许用户
和服务器同意在他们的TELNET连接上使用更精致的(或者可能是完全不同的)协议集合。这
些选项包括改变字符集，回显，等等。
  
建立选项使用的基本策略，是让每一方(或双方)初始化一个使一些选项有效的请求，另
一方可以接受或拒绝该请求。如果该请求被接受了，选项立即生效;如果该请求被拒绝，连
接的另一端仍然保留NVT的特性。很显然，一方经常可以通过拒绝来使能，而从来不能通
过拒绝来取消一些选项，因为这些选项是双方为了支持NVT而准备的。

我们已经建立了一套谈判选项的规则，使得双方在同时请求一个相同选项的时候，每一
方都可以把对方的请求当作对自己的请求的肯定回应。

3．谈判句法的对称性可能会导致无穷尽的应答循环--每一方都把对方发送过来的命令
当作必须回答的请求而不是对方的应答。为防止这种循环，可以应用下面这些规则:

a．一方只能请求改变选项的状态。也就是一方不能只发送宣布它所使用的模式的请求。

b．如果一方所接收到的请求是要求它进入当前它所在的状态，那么该请求将不会被应
答。这种不应答对防止无穷尽的循环是非常重要的。对于那些改变模式的请求，都需要一个
应答--尽管该模式不一定改变。

C．无论何时，只要一方向第二方发送一个选项命令，不管该命令是请求还是应答，而
且使用该选项将会对从第一方发送到第二方的数据进行处理时生产影响，那么必须把该命令
插到数据流中它希望开始起作用的点上。(要注意到在传送请求和接收到可能是否定的应答
的过程需要一些时间。因此，一台主机可能在发出请求一个选项的请求后希望缓冲要发送的
数据，直到它知道该请求是被接受还是被拒绝，来隐藏这段对用户来说是"不确定"的时间。)

选项请求在TELENT连接刚刚建立起的时候要在在连接的两端来来回回传送许多次，
每一方都试图从对方获取尽可能好的服务。然而，在另一方面，选项可以用来动态地改变连
接的特性，使它与对本地状态的改变相一致。例如，NVT(后面将要解释)使用的传输方式比
较适合一个用BASIC语言编的应用，这类应用在传输数据时是每次一行，而对那些每次传
输一个字符的应用(比如NLS)就不是很适合。当对本地的处理来说是合适的，一个服务器可
能会忍受这种“临时的特征”所需的巨大的处理器开销，并且会谈判一个合适的选项。然而，
当不再需要详尽的控制时，处理开销可以（通过谈判）切换回NVT下的状态。

如果一个过程在收到一个拒绝回应后，仅仅是重新请求该选项，那么由一个过程发起的
请求将会导致不停的请求循环。 为了防止出现这样的循环，不能重复被拒绝的请求，除非
已经改变了某些选项。在运行中，这可能意味着该过程运行一个不同的程序，或者用户已经
发出了另外的命令，或者出现了其他所有可以影响一个过程及其选项的上下文的东西。根据
经验，重新请求只能是一个连接的另外一端在后来又提交了某些信息，或者本地用户的交互
的需要。

选项的设计者不应该拘泥于选项谈判中有限的一些语法。使用简单的语法的本意是希望
使得选项易于使用 – 因为要忽略它们是很容易的。如果有一些特殊的选项需要一个比
“DO,DON’T,WILL,WON’T”更完整的谈判结构，一个比较好的方法是用"DO, DON'T, 
WILL, WON'T"使双方都能理解该选项，一旦这个过程已经完成，就可以自由地使用一个更
为特别的语法。比如，一方可以发送一个请求来通知（建立）一行的长度。如果这个请求被
另一方所接受，那么可以用另外一个不同的语法来进行实际的对一行的长度的谈判 – 如一
个”子谈判“可能包括可以允许的最小值，可以允许的最大值，以及最合适的行的长度等字
段。一个较为重要的原理是，这样的扩展谈判只有在前面的一些（标准）谈判已经建立，并
且双方都可以解释这些扩展语法的情况下才能开始。

总之，WILL XXX由双方发送出去，表示该方希望（提出）开始对选项XXX进行处理。
DO XXX和DON'T XXX表示它的肯定和否定回应；类似地，DO XXX发送出去指示（请求）
对方（也即DO的接收者）开始对选项XXX进行处理，WILL XXX和WON'T XXX表示肯
定和否定回应。

由于在没有使用任何的选项的情况下，NVT通过使用DON'T和WON'T回应来保证连
接在连接的双方都可以处理的状态中。因此，所有主机都应该这样实现它们的TELNET进
程：在完全不知道一个不支持的选项的情况下，只需要简单地拒绝任何无法了解的该选项请
求。

TELNET协议尽可能地使服务器和用户之间是对称的，以便比较容易和自然地包含用
户到用户（连接）和服务器到服务器（协作处理）这两种情况。尽管不是完全需要，但我们
也希望选项能够加强这个目的。在任何情况下，我们更倾向于明确承认对称性是一个操作上
的原则，而不是一个不变的标准。
请参考相关文档“TELNET选项规范”来得到关于如何建立新的选项的信息。
网络虚终端
网络虚终端（NVT）是一个双向的字符设备。NVT有一个打印机和一个键盘。打印机
负责进来的数据，而键盘负责产生通过TELNET连接发送出去的数据，并且在需要"回显“时，
同时在NVT的打印机上回显这些数据。”回显“并不要求数据一定要经过网络（尽管有一个
选项可以控制该操作的”远程“模式，但并不要求主机实现该选项）。

除了在这里说明的外，所有的编码集合都是有八位的，但只使用其中的七位的USASCII
码。所有的代码转换和时区方面的问题都是本地的事情，而不影响NVT。
数据的传输
尽管一个通过网络连接的TELNET连接本质上是全双工的，但通常把NVT看作在线性
缓冲模式下的半双工设备。也就是说，除非已经和对方谈判好，以下情形 对应于通过
TELNET连接进行数据传输。

1) 在本地缓冲空间允许的可用范围内，可以在产生数据的机器上汇集数据，直到完整的一
行数据已经准备好传输，或者某些在局部定义的信号明确地要求传输数据。这些信号既可以
有进程产生，也可以有用户发出。

定义这个规则的动机是，对于一些主机，处理网络输入中断的代价是很高的，另外，缺省的
NVT规范指定“回显”操作的数据不经过网络的传输。因此，有理由在产生数据的源上缓
冲一些数据。许多系统都会在输入一行结束后进行一些动作（行式打印机或者卡片打孔机经
常都是这样子的），因此数据传输可以在一行数据结束时触发。另外，有时候一个用户或者
进程会发现有必要或者应该提供一些不在一行的结尾结束的数据；因此实现者要注意，提供
的局部信号机制要确保所有的缓冲数据都能够被立即发送出去。

 2) 当一个过程已完成向一个NVT打印机发送数据，并且输入队列中也没有来自NVT键盘，
需要进一步进行处理的数据（就是说，当一个在TELNET连接的一端的过程无法在另一端
没有数据输入的情况下进行处理），该过程必须传输TELNET 的继续（Go Ahead,GA）命
令。

这个规则并不要求在一个连接的两端上的终端都发送TELNET GA命令，因为服务器
开始进行处理时，一般情况下都不需要一个特别的信号（以及断开连接信号和其他在本地定
义的特性）。况且，TELNET GA被设计来帮助一个具有“可锁定”键盘的本地计算机（如
IBM2741）建立一个物理上的半双工终端。这种终端的一个说明可能对解释GA命令的正确
用法有帮助。

终端到计算机的连接总是在用户或者计算机的控制之下。任何一方都不能单方面地夺取
另一方的控制；而且取得控制的一方必须明确地放弃它地控制。在终端这一方，硬件上就支
持在每次一个“连接”终止的时候（也就是在用户按下“新连接”的键时），它就放弃控制。 
当这种情况发生时，连接的（本地）计算机处理输入的数据，决定是否要产生输出，如果不
需要的话，就把控制返回给终端。如果要产生输出，计算机维持控制，直到所有的输出都被
传输完毕。 

通过网络使用这种类型的终端，困难是显而易见的。“本地”计算机在看到一个结束连
线信号后，无法决定是否要保持控制，这个决定只能由处理这些数据的“远程”计算机作出。
因此，TELNET中的GA命令提供了一个机制，使“远程”计算机（服务器）如何给“本地”
计算机（用户）发送信号，告诉对方现在是给用户终端传递控制的时间。当用户需要获得对
终端的控制时，它应该并且只能在这段时间传递。  注意，过早地传递GA命令将导致输出
阻塞，由此用户可能会认为传输系统已经被暂停，因此将导致用户手工转向连接时失败。

当然，前面所说的这种情况不会在通讯过程中用户到服务器这个方向上出现。在这个方
向上，尽管没有必要，但在任何时候都可能发送出GA。同样，如果TELNET连接被应用在
过程到过程的通讯中，在两个方向上都不需要发送GA。最后，对于终端到终端的通讯，在