TELNET协议规范(中文版)

TELNET协议规范

ARPA Internet上的主机被要求采用并实现此标准。

介绍

TELNET Protocol的目的是提供一个相对通用的，双向的，面向八位字节的通信方法。它主要的目标是允许接口终端设备的标准方法和面向终端的相互作用。可以预见到，此协议也可被用于终端到终端的通信和处理到处理的通信（分布式计算）。

　

　

一般考虑

一个TELNET连接是一个用于传输控制协议的传送数据的。TELNET 协议是建立在以下三个想法上的：首先是网络虚拟终端的概念；其次是对话选项的方法；最后是终端和处理的协调。

　

1. 当一个TELNET连接被初次建立时，每一端都被假设使用了网络虚拟终端，也就是NVT。NVT是一个想象中的标准设备通用设备的代表。这就消除了“服务器”和“用户”机要了解对方机器终端的特点，而终端可以直接处理对话。所有的主机，用户端的和服务器端的，它们自己本地的设备特点因此在网络上可以作为一种NVT处理，任何一个都可以认为对方使用的是相同特点的设备。NVT倾向于不过多地限制（提供了一个相应比较丰富的映射到本地设备的字符集），也不是包括一切的（它要求用户使用适当的终端）。注意：用户机通常是与处理终端连接的主机，服务器机通常是提供某种服务的机器。从另一点看，在终端到终端或进程到进程的通信上，用户机是发起通信的机器。
2. 规定选项的原理将以下事实考虑在内，许多机器希望在现在的NVT上提供另外的服务，多数用户有比较复杂的终端，它们也就希望一种比较完整的而不是最小的服务。独立的，但是存在于 TELNET 协议的不同选项支持这些需求，它们使用"DO, DON'T, WILL, WON'T" 结构允许用户机和服务器建立建立一种更加精巧的TELNET会话连接。这种选项包括改变字符集，响应模式等等。设置选项的基本策略是任一方（或者两者）初始化要求一个选项生效的请求。另一方可以接受也可以拒绝这一请求。如果接受请求，此选项立刻生效；如果被拒绝，连接仍然保持基本的NVT的连接属性。很明显，一方可以拒绝另一方关于启用某一选项的请求，但是不能拒绝另一方关于使一选项失效的请求，因为双方必须准备支持NVT。对话选项语法的建立使在双方都发出请求某一选项生效的请求时，另一方可以直接认为收到对方的确认信息。
3. 这种对称式的对话语法潜在地引起了一个不可终止的确认环--任何一方都将收到的确认信息看作是请求，而不是一个确认信息。为了防止这种循环的出现，有下面的规则：

1. 任何一方仅可以要求对选项状态的变化：例如，一方不可以发出请求，仅仅说明它在什么样的选项状态下。
2. 如果一方接收到好象是请求的信息，请求进入一个已经进入的状态，此信息将被看作是一个确认消息。这种非响应从本质上防止了不可终止的对话的循环。如果要求发送一个要求改变状态的请求，即使状态并未改变。
3. 无论何时，一方发送选项命令到另一方，无论作为一个请求或者是一个确认消息，选项的使用将对发送的数据处理有影响，这样命令应该被插入到希望发生作用的数据流中的数据点之前。（应该注意，传送请求和收到确认消息之间有一定的时间间隔，这是被动方式的。因此，一个主机希望在要求一个选项后缓存数据，直到它知道它的请求是否被接受，这样就可以使这段不不确定时间对用户不可见。）选项的请求可以在建立TELNET连接时十分频繁地来往交换，因为每一方都希望从对方得到更好的服务。

除此以外，选项也可以在连接持续过程中动态改变来适应本地机器条件的变化。例如，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被作为一种请求发送给另一方来启动选项XXX，WILL XXX 和WON'T将被作为确定和不确定的响应。因为NVT是没有任何选项时的结果， DON'T和WON'T响应将保证使连接最终保持于这种没有任何选项的状态。因此，所有主机可以不支持不理解的选项，它仅仅需要返回这种选项的请求即可。

尽可能的，TELNET协议被用作服务器-用户的对称，这样，它就可以更容易而自然地处理用户-用户和服务器-服务器的情况。用选项来扩展这一功能是被希望实现的，但不是必要的。在任何情况下，对称是一个运行的准则而不是固定的准则多次被明确提出。一个比较文档，“TELNET选项说明”，可以被用于对建立新选项过程信息的参考。

网络虚拟终端网络虚拟终端（NVT）是一个双向字符设备。NVT有一个显示设备和一个键盘。显示设备响应到达的数据，键盘负责通过TELNET连接发送数据，如果需要回显，也应该在NVT的显示设备上显示。对于网络上的回显并不要求（虽然确实存在这个“远程”回显选项，但是主机必不是必须实现此选项）。字符集是由七位ASCII码组成的，而保存在八位的域中。任何字符的转换和计时方面的考虑都是本地的问题，这不影响NVT的工作。

数据传送方面，虽然TELNET连接是全双工的，NVT却是在线缓冲状态下的半双工设备。传送数据 虽然TELNET连接是全双工的，在线缓冲模式下，NVT却被当作半双工的设备。此信号可以由进程或者用户产生。对于一些主机处理网络输入中断，或与默认的不进行远程回显的NVT说明的主机来说，此规则的代价是高昂的。因此，在源点缓存一些数据是有理由的。一些系统在每个输入行未采用一些操作（即使是行打印机或打卡机也经常采用这种方法），这样可以在每行未开始发送。在另一方面，用户或者进程可以有时发觉提供在行未不中断的数据是有用的而且是必须的；因此，也应该在实现在本地能够识别这种信号并把这些数据立刻发送的方法和机制。当一个进程已经完成将数据发送到对方的显示设备而且也没有缓存的输入数据时时，进程必须发送TELNET Go Ahead (GA)命令。

这个规则并不是要求 TELNET GA命令必须由双方终端发送，因为服务器主机通常不要求特定的信号来继续进程。但是，此命令的设计可以帮助用户的本地主机操作一个物理上半双工的终端，它如果IBM2741一样拥有可锁定的键盘。对此种类型终端的描述有助于解释GA命令的正确使用。终端和计算机的连接总是在计算机或用户的控制之下。任何一方都不能够隐式地从另一方获得控制权；控制权必须显式地从一方转移到另一方。

在终端一方，设置硬件在每一行结束时放弃控制权（例如，当用户按下回车键时）。当这种情况发生时，本地计算机处理输入数据，决定是否输出，如果不需要，将控制权回送给终端。如果需要产生输出，计算机将保有控制权直到输出数据发送完毕。在网络上使用这种终端的困难是显而易见的。“本地”计算机不知道在读到行未符号时是否应该继续保持控制权；这个问题的决定权在远地处理此数据的计算机。因此，TELNET GA命令提供了一种机制让远程计算机能够通知本地计算机，让它将控制权转交给用户终端。在用户需要控制权时，此信号应该也只能在此时发送。注意：过早地发送GA命令会使输出数据阻塞，因为用户可以假定传送系统暂停，因此不能将一行结束。当然，前述内容不能够用于用户到服务器方面的通信方面。在这个方面，GA命令可以在任何时候发送，可以根本不用发送。同样，如果TELNET连接被用于进程到进程的通信，也不需要发送GA命令。

最后，对于终端到终端的通信，可以在两端都需要GA命令，也可以在一端，也可以两端都需要。如果主机希望支持终端到终端的通信主机应该提供一种让用户自由发送GA命令的方法；然而，对于一个TELNET进程而言，这并不是必须的。注意：TELNET模式的对称性要求在概念上，两端中的一端至少是一个NVT。控制函数的标准表示 如要本文的介绍中所说的，TELNET协议的目的是提供一种网络上面向终端进程和终端设备的标准接口。

这种类型互连的先前的经验告诉我们，在许多主机上已经实现了类似的功能，但它们的实现方法却差别很大。对于接触这些系统的用户而言，这些差别将是令人头痛的。因此，TELNET定义了以下功能的五种标准表示。这种标准表示有一定的标准的意义，但这也不是必须的（例外是中断处理函功能要其它使用TELNET的协议执行）；这也就是说，系统不提供给本地用户的功能也不可以不提供给远程用户，它可以将标准表示作为非操作的功能。

在另一方面，给本地用户提供此功能的系统必须也向传送此功能标准表示的远程用户提供此功能。

中断处理（IP）一些系统提供可以暂停，中断，放弃或终止用户进程操作的功能。当用户确定它的进程处于不可结束的循环中，或不经意地激活了一个进程时经常使用此功能。IP是使用此功能的标准表示。实现者应该注意的是：使用TELNET的其它协议可能也需要IP，因此，如果需要支持其它协议就应该实现IP。放弃输出 (AO) 许多系统提供此功能，它允许产生输出的进程到达类似操作结束的点，而不将输出发送到用户的终端。更深一层的，此功能通常清除已产生的所有输出，而不显示到用户的终端上。AO是使用此功能的标准表示。

例如，一些子系统可能通常接受用户命令，发送长文本串到用户终端，最后发送一个提示用户允许接收下一命令的提示符到用户终端。如果在传送文本串的过程中接收到AO命令，将会不再发送剩余的字符串，而直接显示提示符告知用户可以输入下一命令。（这与接收到IP之后的操作可能有所不同；IP会放弃发送剩余的字符串而且退出子系统。）应该注意到，使用提供此功能的服务器系统时外部缓冲区（在网络和用户本地主机上）也被清除；完成的正确方法是向用户系统发送“Synch”信号。

你在此吗 （AYT） 许多系统提供用户这样的功能，让用户知道是否正在运行。此功能在系统由于不可预知长度运算，或系统负载重的情况下长时间不响应时由用户发起。AYT是使用此功能的标准表示。

删除字符（EC） 许多系统提供此功能用于删除最近相邻的不可删除字符或用户提供数据流的最近相邻的“显示位置”。此功能通常用于编辑键盘错误的输入。EC是使用此功能的标准表示。注意：“显示位置”可能包括多于一个的字符，它们是过多键入的结果或者如下格式的字符串：<char1> BS <char2>...

删除行（EL） 许多系统提供此功能用于删除当前输入行中的所有数据。此功能通常被用于是编辑键盘输入。EL是使用此功能的标准表示。

TELNET的"Synch"信号 大部分时分系统提供一种允许终端用户重新获得失控进程的机制；上述的IP和AO功能就是此机制的一个例子。这些系统，当被用于本地时，访问由用户提供的所有信号，无论此信号是一般字符还是不可显示的字符如电传中的“BREAK”或IBM 2741中的“ATTN”键。当系统通过网络连接时这种情况不一定就是准确的；网络流量控制机制可能导致一个信号被缓存于网络中某处，例如在用户的主机中。为了克服这个问题，引入了TELNET的“Synch”机制。一个Synch信号包括一个TCP 紧急信号和TELNET命令 DATA MARK。

紧急信号，它不受限于限制TELNET的流量控制，它可以在接收到进程引发特定的数据处理。

在这种模式中，此数据流立即被看作是“有重大意义的”，而抛弃其它数据。

TELNET命令DATA MARK (DM)是数据流中的同步标志，它指示任何特定的信号已经发生过了，接收可以返回到正常处理其它数据的状态中了。Synch通过TCP发送操作完成，它和紧急标志及在最后的DM标志一起发送。当一些Synch信号被连续快速发送时紧急信号可能被淹没。不可能对紧急信号记数，因为这一数字有可能小于也可能等于已经发送的数目。当处于通常模式下，DM不是一个操作；当处于紧急模型下，它指示紧急处理的结束。如果TCP指示紧急数据结束前发现DM，TELNET应该继续操作数据流直到遇到DM为止。如果TCP在DM之后指示又有一些紧急数据，那只能是因为是一串Synch。TELNET应该继续操作数据流直到遇到DM。

“有意义的”信号被定义为：IP，AO和AYT（但不是EC或EL）的TELNET标准定义；如果有的话，本地对这些标准定义的模拟；所有其它TELNET命令；其它站点定义的不需要拖后数据流的信号。因为SYNCH命令的另一个作用是抛弃所有在接收者和发送者之间随了TELNET命令之外的字符，如果需要时，此机制被指定为标准方法来清理数据路径。例如，如果一个在终端的用户传送一个AO命令，收到此命令的服务器（如果此服务器提供此功能）应该返回一个SYNCH给用户。

最后，正如需要TCP紧急信号作为供他们使用的命令一样，其它使用TELNET协议的协议也需要类似的命令。这通过使用[IP，SYNCH]就可以达到。例如，假设其它一些使用TELNET的协议定义了类型于AO命令的停止字符串。试想此协议的用户希望服务器来处理停止字符串，但连接因为服务器正在处理别的命令而被阻塞。用户应该使它的系统做以上工作：

1. 发送TELNET IP字符；
2. 发送TELNET SYNC串，这就是说：发送DM作为在TCP紧急模式发送操作下的唯一字符串。
3. 发送字符串STOP，并且
4. 发送其它协议的类型于TELNET DM的命令。

用户（或者进程）必须象步2一样重新发送TELNET SYNCH序列来确保TELNET IP到达服务器的TELNET解释器。“紧急”将唤醒TELNET进程；IP应该唤醒更高级的进程。NVT显示和键盘 NVT显示有一个未指定的行宽和页面大小，并且可以产生代表ASCII码的字符。

对于33个控制字符和另外128个没有使用的字符，将指定给显示：

NULL (NUL) 0 无操作；

Line Feed (LF) 10 将显示移动到下一行的同一垂直位置。

Carriage Return (CR) 13 将显示移至当前行的左边界处。

另外，还应该定义如下字符（但这不是必须的），它们对显示也有作用。TELNET的任何一方都不会假定另一方会在接收或传送时采取以下行动：

BELL (BEL) 7 响铃或者给出一个可视的信号（这并不移动显示位置）。

Back Space (BS) 8将显示向左移一个位置。

Horizontal Tab (HT) 9 将显示移至下一个制表位。现在还未指定任何一方如何决定制表位的位置究竟在什么地方。

Horizontal Tab (HT) 9 将显示移至下一个垂直制表位。现在还未指定任何一方如何决定制表位的位置究竟在什么地方。

Form Feed (FF) 12 将显示移动到下页起始位置，并保持相同的水平位置。所有现在的代码都不使NVT显示作任何操作。

CR LF序列将使显示定位于下一显示行的左边界处。然而，许多系统和终端并不将这两个字符分开处理而不得不作一些工作模拟它们的作用。（例如，一些终端没有独立于LF的CR，但在这些终端上可以通过后退键模拟CR的功能。）因此，CR LF序列必将作为新行标记使用它们的复合功能；CR NUL必须在希望仅输入一个回车时使用；在其它情况下应该避免单独使用CR。这个法则使必须决定是否进行一个“新行”操作功能或多个回退的系统能够保证包括由一个字符在CR后面的TELNET流的操作，并作出正确的决定。注意：CR LF或者CR NUL对双方都是要求的，这就保证了NVT的对称性。即使在一些情况下可以知道字符未被送到实际的终端，然而，出于一致性的考虑，协议要求在CR后面如果没有LF就必须插入一个NUL。反过来说，在CR后面接收到一个NUL后，应该把它从数据流中抛弃，而不应该将它用于NVT的字符映射。

在NVT上有键盘，组合键或键序列来产生这全部128个字符。注意：虽然其中的一些对NVT显示没有作用，NVT也有能力产生它们。除了这些以外，NVT键盘还应该能够产生如下有意义，但不要求的的字符。对这些字符的实际代码指派在TELNET命令一节中，因为它们被作为普通的应该被提供的，即使在数据流被解释为一些其它字符集的情况下。

Synch 此键允许用户清除到另一方的数据通道。此键的激活导致DM的发送，而且还导致同时发送TCP的紧急信号。DM-紧急信号对有如前面定义的意义。

Break (BRK) 它的提供是因为它不是ASCII字符集内的一员。它指示Break键和Attention键被按下。然而，请注意：它是作为第129个代码，而不是IP标准定义。

Interrupt Process (IP) 暂停，中断，放弃或终止NVT连接的进程的执行。同样的，它也是使用TELNET协议的协议要使用的信号。

Abort Output (AO) 允许当前进程运行至终止，但不将结果送给用户。同样，发送SYNCH给用户。

Are You There (AYT) 回送给NVT一些可见的字符。

Erase Character (EC) 接收方应该删除紧后一个未删除的字符或从数据流中删除一个“显示位置”。

Erase Line (EL) 接收方应该将数据流中的字符从当前位置开始一直删除到最近的“CR LF”为止。

这些“额外”键的功能和一些显示格式功能键是它们应该代表一个对从NVT到本地机映射的扩充。如同NVT数据字节68应该被映射为大写D一样，一个EC字符应该被映射为一个“删除行”的功能键。另外，如果映射124在一些情况下是武断的一样，EL字符的映射有时候也是武断的。对于格式字符也是一样的：如果终端实际上拥有“垂直制表位”，那么映射到NVT是显然的，如果终端不提供此功能，那么结果将是不可预料的。TELNET命令结构 所有TELNET命令结构至少包括一个两个字节的序列：由一个IAC后跟一个命令。关于选项会话的命令是由三个字节的序列构成的，第三个字节是关于选项参考的。选择这种结构，这样随着完全使用数据空格数据与命令值之间的冲突就会减少，所有这些冲突导致了不一致和没有效率和数据的丢失。根据目前的设置，只有与IAC冲突的数据需要被发送两次，其它255个代码都可以直接发送。下面是定义了的TELNET命令。注意：只有当代码和代码序列前面是IAC时它才是命令。

SE 240 结束子会话参数。

NOP 241 无操作。

Data