组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：ouyang@china-pub.com 译者： 译文发布时间：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连接进行数据传输。
定义这个规则的动机是，对于一些主机，处理网络输入中断的代价是很高的，另外，缺省的 NVT规范指定“回显”操作的数据不经过网络的传输。因此，有理由在产生数据的源上缓 冲一些数据。许多系统都会在输入一行结束后进行一些动作（行式打印机或者卡片打孔机经 常都是这样子的），因此数据传输可以在一行数据结束时触发。另外，有时候一个用户或者 进程会发现有必要或者应该提供一些不在一行的结尾结束的数据；因此实现者要注意，提供 的局部信号机制要确保所有的缓冲数据都能够被立即发送出去。
这个规则并不要求在一个连接的两端上的终端都发送TELNET GA命令，因为服务器 开始进行处理时，一般情况下都不需要一个特别的信号（以及断开连接信号和其他在本地定 义的特性）。况且，TELNET GA被设计来帮助一个具有“可锁定”键盘的本地计算机（如 IBM2741）建立一个物理上的半双工终端。这种终端的一个说明可能对解释GA命令的正确 用法有帮助。
终端到计算机的连接总是在用户或者计算机的控制之下。任何一方都不能单方面地夺取 另一方的控制；而且取得控制的一方必须明确地放弃它地控制。在终端这一方，硬件上就支 持在每次一个“连接”终止的时候（也就是在用户按下“新连接”的键时），它就放弃控制。 当这种情况发生时，连接的（本地）计算机处理输入的数据，决定是否要产生输出，如果不 需要的话，就把控制返回给终端。如果要产生输出，计算机维持控制，直到所有的输出都被 传输完毕。
通过网络使用这种类型的终端，困难是显而易见的。“本地”计算机在看到一个结束连 线信号后，无法决定是否要保持控制，这个决定只能由处理这些数据的“远程”计算机作出。 因此，TELNET中的GA命令提供了一个机制，使“远程”计算机（服务器）如何给“本地” 计算机（用户）发送信号，告诉对方现在是给用户终端传递控制的时间。当用户需要获得对 终端的控制时，它应该并且只能在这段时间传递。 注意，过早地传递GA命令将导致输出 阻塞，由此用户可能会认为传输系统已经被暂停，因此将导致用户手工转向连接时失败。
当然，前面所说的这种情况不会在通讯过程中用户到服务器这个方向上出现。在这个方 向上，尽管没有必要，但在任何时候都可能发送出GA。同样，如果TELNET连接被应用在 过程到过程的通讯中，在两个方向上都不需要发送GA。最后，对于终端到终端的通讯，在 两个方向上可能都需要GA。如果一个主机打算支持终端到终端的通讯，建议主机在需要通 过TELNET连接发送GA的时候，提供一个手工发信号给用户的方法。然而，在实现TELNET 过程中，这一点并不是必需的。
注意：由于TELNET模型的对称性，从理论上来说，在一个TELNET连接的每一端，都必 须有一个NVT。 控制功能的标准表示 就象我们在本文档的简介中所说，TELENT协议的主要目标是在通过网络连接的终端 设备和面向终端的过程之间提供一个标准的接口。早期具有这种互联性质的实验表明，大部 分的服务器都实现了某些功能，但调用这些功能的方式却差别很大。对于一个要与多个服务 器系统交互的用户来说，这些差别是一个非常大的障碍。因此，TELNET协议定义了这些 功能中的下面5种的标准表示。这些标准表示包括标准，含义 --- 尽管不是必需的（除了 中断进程（IP）功能，使用TELENT协议的其他协议可能需要该功能）。因此，一个没有给 本地用户提供某种功能的系统也没有必要给网络上的其他用户提供该功能，并且可以把该功 能的标准表示当作No操作。在另一方面，如果一个系统已经给本地用户提供了该功能，那 么它必须给网络上那些传该功能的标准表示的用户提供同样的功能。
中断进程 – Interrupted Process(IP)
许多系统提供挂起，中断，中止，终止用户进程的操作的功能。当用户确信他的进程已 经进入了无穷尽的循环，或者不小心激活了一个并不希望激活的进程时，就要经常使用该功 能。IP就是调用该功能的标准表示。该功能的实现者需要注意，其他使用TELNET协议的 协议可能要使用IP，因此实现时要支持这些协议。
中断输出 -- Abort Output (AO)
许多系统提供了允许一个产生输出的进程在不向用户的终端发送输出的情况下完成运行
（或者达到在完成运行的过程中将会达到的某一个停止点）的功能。
另外，该功能一般还清除那些已经生成但还没有实际打印（或者显示）到用户的终端上的
输出。AO是调用该功能的标准表示。 比如，许多子系统通常会接受一个用户的命令，然
后以一个发送到用户终端的长的字符串作为回应，最后，给用户的终端发送一个“提示”字
符（前面跟着
同时还需要注意到，对那些提供这种功能的服务器，可能还需要清除那些存在于系统外 的缓冲机制（在网络中或者在用户的本地机器上）中的内容。完成这个过程的一个合适的方 法是给用户的系统发送“同步”信号（将在下面描述）。
你在那里吗？ -- Are You There (AYT)
许多系统提供了给用户提供系统仍然在运行的一些可见的（如可打印的）迹象。这个功 能可以在系统在一个想象不到的很长一段时间里都没有动静时（可能是由于用户没有想象到 的计算时间，或者不正常的巨大系统负荷等导致。）由用户调用。 AYT是调用该功能的标 准表示.
消除一个字符 - - Erase Character (EC)
许多系统提供了删除在未删除字符前面或者用户提供的数据流中的“打印位置” 最后 面的一个字符的功能。该功能通常在键盘输入时输入了错误的字符时使用。EC是调用该功 能的标准表示。
*注意 ：一个“打印位置”可能包含相互覆盖的几个字符，或者象下面的字符系列：
消除一行 -- Erase Line (EL)
许多系统提供了删除输出设备上的当前一行的全部数据的功能。该功能经常在用键盘进 行输入编辑时使用。EL是调用该功能的标准表示。 TELNET中的“同步（SYNCH）"信号 许多系统提供了一种机制，可以允许一个终端的用户对一个“失控“的进程重新获得控 制权。上面描述的IP和AO功能就是这种机制的例子。当在本地使用时，这样的系统可以 访问由用户提供的所有信号，而不管这些信号是一些普通字符或者是由电传打字机中的 "BREAK"键或IBM 2741中的"ATTN"键发送的”带外“信号。然而当通过网络把系统联结 起来时，这可能是不正确的。网络的流程控制机制可能导致把这些信号缓冲到其他地方，比 如用户的机器中。
为了解决这个问题，提出了TELNET中的"同步" 机制。 一个同步信号包含一个同TELNET命令DATA MARK结合在一起的TCP紧急通知。该 紧急通知与TELNET连接中的流程控制没有关系，接收它的进程用它来调用数据流的特殊 处理过程。在这种模式中，立即对数据流进行扫描，查找下面定义的一些“有趣“的信号， 而把那些干涉的数据丢弃。
TELNET命令DATA MARK (DM)是数据流中的同步标记，表示所有特殊的信号都已经 产生，接受者可以继续对数据流进行一般的处理。
同步信号通过TCP中的发送操作发送，在发送过程中需要把紧急标志设为“真“，并 且把DM作为最后（或者唯一的）一个字节。
当许多同步信号快速地连续不断地发送时，可以合并紧急通知。不可能去计算紧急通知 的次数，因为接收到的紧急通知的次数可能等于或者少于发送次数。在普通模式中，一个 DM是没有任何操作的，但在紧急模式中，它表示紧急处理过程的结束。
如果在发现DM之前，TCP已经指示紧急数据的结束，TELNET应该继续对数据流进 行特殊的处理，直到发现DM。
如果在发现DM之后，TCP指示有更多的紧急数据，它只能是另外同步信号。TELNET 应该继续对数据流进行特殊的处理，直到发现另外一个DM。
定义的“有趣的“信号为：TELNET中的IP， AO， 和 AYT (没有EC 或EL)的标准 表示;与这些标准表示类似的本地表示（如果有的话）；所有的其他TELNET命令；其他在 不延迟数据流的扫描并且能够起作用的自定义信号。
由于SYNCH机制的一个影响是丢弃本来在发送者和接收者之间要传输的所有字符（除 了TELNET命令），如果需要，这个机制可以作为清除数据路径的一种标准方式。例如，在 一个终端上的用户需要传输一个AO，接收到该AO的服务器应该给该用户返回一个同步信 号（如果它提供该功能的话）。
最后，就象在TELNET层，需要把一个TCP紧急通知当作一个带外信号，因此其他使 用TELNET的协议可能需要从不同层次来看可以当作带外信号的TELNET命令。
通过约定系列[IP, Synch] 可以把它作为这样的信号。例如，假设有一个使用 TELNET协议的其他协议定义了一个类似于TELNET命令AO的字符串STOP。想象 用户使用该协议的目的是希望服务器处理STOP字符串，但由于服务器在处理其他的命令， 导致连接被阻塞。用户应该引导他的系统：
a) 发送出TELNET IP字符；
b) 发送出TELNET SYNC系列，也就是：在一个紧急模式的TCP发送操作中把Data Mark (DM)作为唯一的字符发送出去。
c) 发送出字符串STOP；接着
d) 如果有的话，把其他协议中类似于TELNET DM的命令发送出去。
用户（或者代表该用户的进程）必须传输上面步骤2中的TELNET SYNCH 系列，以确保 TELNET IP已经到达服务器的TELNET 解释器。
紧急通知将激活TELNET进程，而IP将激活随后级别较高的进程。 NVT打印机和键盘 NVT打印机有一个没有指定宽度的走纸器，并且每一页的长度也没有指定。NVT打印 机可以产生所有95个USASCII编码的图形表示（从32到126的编码）。在33个USASCII 编码（0到31及127）和未包含的其他128个编码（128到255）中，下面几个编码对NVT 打印机有确定意义：
名称 编码 意义
NULL (NUL) 0 没有操作
Line Feed (LF) 10 打印头移到下一个打印行，但不改变打印头的水平位置。 Carriage Return (CR) 13 把打印头移到当前行的左边 。
另外，在NVT打印机上，尽管不是必需的，同时应该定义下面这些编码。TELNET连 接的双方，都不会假设另一方在接收到或传输下面这些编码时将会，或者已经实施某种特殊 动作：
BELL (BEL) 7 产生一个可以看到或可以听到的信号（而不移动打印头。） Back Space (BS) 8 向左移动打印头一个字符位置。 Horizontal Tab (HT) 9 把打印头移到下一个水平制表符停止的位置。 它仍然没有指定每一方如何检测或者设定如 何定位这样的制表符的停止位置。 Vertical Tab (VT) 11 把打印头移到下一个垂直制表符停止的位置。它 仍然没有指定每一方如何检测或者设定如何 定位这样的制表符的停止位置。
Form Feed (FF) 12 把打印头移到下一页的顶部，保持打印头在相同的水平位置上。
剩下的其他编码都不会导致NVT打印实施任何动作。
在定义中，系列"CR LF"将导致NVT打印头移动到下一行的左边（与系列 "LF CR"的 效果是一样的）。然而，许多系统和终端并不独立处理CR和LF，为了模拟它们的效果，需 要进行一些处理。 （比如，许多终端没有独立于LF的CR，但是在这样的终端上可以用退 格键来模拟一个CR。）因此，必须把系列CR LF"当作一个单独的“新行”字符看待，并且 在需要把它们结合在一起的时候使用它们。必须在只需要一个单独的回车键时使用系列"CR NUL"；在其他的场境中必须避免使用CR字符。这个规则可以确保系统在发现一个TELNET 流中有一个字符的后面跟有CR的情况下，可以作出合理的选择：是进行“换行”功能还是 进行多次的退格操作。
注意，在两个方向上（在缺省的ASCII模式下）都需要"CR LF"或者"CR NUL"，以确保NVT模式的对称性。
尽管在某种情况下（如当远程回显和禁止超前选项同时起作用时），可以认为字符并不 被发送到一个实际的打印机上，然而，为了保证一致，在一个数据流中，如果一个CR的后 面没有跟着一个LF，该协议要求把一个NUL插到CR的后面。 相反，在接收方，如果从数据流中接收到一个跟在CR的后面的NUL（在没有用谈判 选项显式指定其他选择的情况下），在把NVT转换成本地字符集之前，应该把NUL去掉。
NVT键盘有键或者键的组合，或者键系列来产生所有128格USAACII编码。要注意尽管一些在NVT打印机上没有什么用处，NVT键盘还是可以生成。
除了这些编码，NVT键盘还可以生成下面这些附加的编码，除注明外，还定义了这些编码的意义（尽管不是必需的）。
对这些“字符”的实际代码分配在TELNET命令这一节，因为从某种意义上来讲，我 们可以认为这些编码是固有的，甚至在把数据流中的数据都解释为属于另外的一个字符集的 时候，都可以使用这些编码。
Synch
这个键允许一个用户清空到另一方的数据通道。激活该键将导致发送一个带有TCP紧 急通知的DM（参看命令这一节）。一对DM-紧急通知具有在前面定义的一些意义。
Break (BRK)
之所以提供这个编码，是因为在当前的许多系统中，它是USASCII集合之外的一个 信号，并且具有本地意义。 可以用它来表示Break键或Attention键已被按下。然而，需 要注意的是，它的目的是给需要它的系统提供第129个编码，而不等同于IP的标准表示。
Interrupt Process (IP)
挂起，中断，中止，终止一个NVT连接的进程。另外，它也是那些使用TELNET的其他协 议的带外信号的一部分。
Abort Output (AO)
允许当前的进程继续运行直到结束，但不给用户发送它的输出信息。并且把一个同步信 号发送给用户。
Are You There (AYT)
给NVT发送回一些可见的（也就是可打印的）信息以表明已经收到AYT。
Erase Character (EC)
接收者将删除数据流中最后一个未被删除的前导字符或者“打印位置”。
Erase Line (EL)
接收方将删除由TELNET连接发送的数据流中最后一个“CR LF”系列（但不包括该系列） 后面的全部内容。
这些“额外”的键，也就是打印机的格式控制字符的本质是，它们是对从“NVT”到“本地”这个必须进行的映射过程的一个自然的扩展。
就象NVT中的字节68（八进制104），可以映射为本地中代表“大写D”的任何一个编码， 字符EC也可以映射为本地中代表“删除一个字符”功能。
另外，就象在一个没有“垂直线”字符的环境下，对编码124（八进制174）的映射是 任意的，如果在本地没有“删除一个字符”这种机制，对EL的映射也是任意的（甚至不映 射）。
类似地，对格式控制字符，如果终端确实有一个“垂直制表键”，那么对VT地映射就 是显而易见的，只有在终端没有一个垂直制表键的情况下，VT的作用才是无法预测的。 TELNET命令结构 所有的TELNET命令至少包含一个两个字节的序列:跟在命令的代码的后面，"当作命令 来解释(Interpret as Command)"(IAC)的转义字符。处理选项谈判的命令有三个字节系列， 第三个字节就成了被选项引用的编码。之所以选择这种格式，是这种格式能够更大范围地使 用"数据空间"---当然，是通过基本NVT的谈判来进行。数据字节与保留的命令值的冲突被 大大减少了，而所有这些冲突都需要复杂，低效的方法来把数据字节转换为流。使用现在的 方法，只有在需要把IAC当作数据发送时才需要把相同的数据发送两次，其他255个代码 都可以透明地传输。
下面是所有已定义的TELNET命令。需要注意的是，这些代码和代码序列只有在前面 跟有一个IAC时才有意义。
名称 代码 意义SE 240 子谈判参数的结束 NOP 241 空操作 Data Mark 242 一个同步信号的数据流部分。该 命令的后面经常跟着一个TCP紧急 通知 Break 243 NVT的BRK字符 Interrupt Process 244 IP功能. Abort output 245 AO功能. Are You There 246 AYT功能. Erase character 247 EC功能. Erase Line 248 EL功能. Go ahead 249 GA信号. SB 250 表示后面所跟的是对需要的选项的子谈 判 WILL (option code) 251 表示希望开始使用或者确认所使用的是 指定的选项。 WON'T (option code) 252 表示拒绝使用或者继续使用指定的选项。 DO (option code) 253 表示一方要求另一方使用，或者确认 你希望另一方使用指定的选项。 DON'T (option code) 254 表示一方要求另一方停止使用，或者确 认你不再希望另一方使用指定的选项。 IAC 255 Data Byte 255.
连接的建立
TELNET TCP连接是在用户端口U和服务器端口L之间建立的。服务器在用于这种类型的 连接的一个众所周知的端口L上监听客户请求。由于一个TPC连接是全双工的，并且通过 双方的端口来标识，服务器可以对不同的用户端口U和端口L的之间的许多并发连接进行 应答。
端口分配
当用来给远程用户提供访问服务主机的服务(也就是远程终端访问)，这个协议分配了服务端 口23(把进制27)。也就是L=23。
本RFC指定了一个ARPA互联网社区的标准。在ARPA互联网上的主机应该采纳与实现该标准。
给TELNET协议提供一些选项的目的是，使相互通信的主机在解决不同设备之间的通信问题时获得比由网络虚拟终端（NVT）提供的可能框架有更好的方案。它可以让主机自由 地创建，测试或者丢弃某些选项。当然，可以想象，那些普遍有用的选项最终大部分的主机 都应该支持。因此，应该仔细地设计这些选项的文档，并且尽可能地公布它们。另外，确保 不在不同地选项中使用相同的选项代码也是必要的。
本文档指定了一个选项代码的分配和选项的文档标准方面的方法。在进行试验时，可能只需 要选项代码分配而不需要完整的文档，不过一般来说，在分配选项代码之前都需要一个文档。 我们通过把一个选项的文档作为一个RFC文档来发布，从而发布该选项。当然，选项的创 建者也可以用其他的方式发布选项。
选项代码由下面人员分配：
Jonathan B。 Postel
University of Southern California
Information Sciences Institute (USC-ISI)
4676 Admiralty Way
Marina Del Rey, California 90291
(213) 822-1511
Mailbox = POSTEL@USC-ISIF选项的文档至少要包含下面几个小节：
第1节 - - 命令的名称和选项的代码
第2节 - - 命令的意义
应该描述同该选项相关的每一个TELNET命令的意义。需要注意的是，对于复杂的选项，“子谈判”是必需的，因此可能有许多相关的命令。“子谈判”的原理在下面有更详细的 描述。
第3节 - 缺省的规范
对那些没有实现，或者没有使用该选项的主机，必须描述这些选项在这些主机中的缺省假定值。
第4节 - 动机
对创建一个特殊的选项，或者对某种选项选择一种特殊的格式的动机进行详细的描述，对那些还没有碰到（或者虽然已经碰到，但没有认识到）该选项设计来解决的问题的人，是 非常有用的。
第5节 - 描述（或者实现规则）
为了确保一个命令的两个不同实现相互之间能够通讯，仅仅定义命令的意义和对该命令的意 图进行说明有时候是远远不够的。因此，在许多情况下，我们需要给一个命令提供一个完整 的描述。这个描述可以用文本来表示，也可以是一个示例性的实现，或者是实现的线索等等。
对“子谈判”的解释
在主机之间传递选项时，除了一个选项编码外可能还需要更多其他信息。例如，要求一个参 数的那些选项就属于这种情况。在主机之间传递除了选项代码外的其他信息的策略包含两个 步骤：双方都同意去”商讨“该参数，第二，对参数进行”商讨“。
在第一步中，同意去讨论参数以一种普通的方式来进行。一方通过发送一个带有选项代码的 DO(或WILL)命令来建议使用选项，另一方发送一个带有选项代码的DO(或WILL)命令来表 示接受这个建议。一旦双方都同意使用这选项，通过在SB命令的后面跟上相应的选项代码， 参数和命令SE来开始子谈判。每一方都被假设为能够解析该参数。因为在最初通过交换 WILL和DO命令，双方都表明可以支持该选项。另外，即使接收方不能解析该参数，接收 方也可以通过搜索SE命令（如字符串IAC SE）来定位参数字符串的结束位置。当然，在 任何时候，任何一方都可以给另一方发送WON'T或DON'T来拒绝继续进行进一步的子谈 判。
Rfc845---TELNET PROTOCOL SPECIFICATION TELNET协议规范
10 RFC文档中文翻译计划
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8