64 KiB
概览
Telnet（"teletype network"的缩写）是一种客户端/服务器应用协议，它提供对局域网或互联网上远程系统的虚拟终端的访问。它是一种双向8位通信的协议。其主要目标是连接终端设备和面向终端的进程。
Telnet 由两个组成部分构成：（1）协议本身，它规定了两个方如何通信；（2）提供服务的软件应用程序。用户数据与 Telnet 控制信息一起，以 8 位字节为基础的数据连接通过传输控制协议（TCP）进行交错传输。Telnet 于 1969 年开发，起始于 RFC 15，后在 RFC 855 中得到扩展，并被标准化为互联网工程任务组（IETF）互联网标准 STD 8，这是最早的互联网标准之一。Telnet 传输的所有信息，包括用户名和密码，都是以明文形式，因此不推荐用于对安全性要求较高的应用，如远程管理路由器。使用 Telnet 进行此类操作的情况已大幅减少，转而更多采用 SSH。已经提出了一些为 Telnet 提供加密的扩展。
组成
Telnet 由两部分组成：（1）协议本身和（2）服务组件。Telnet 协议是基于可靠的面向连接的传输的客户端-服务器协议。该协议用于建立连接到传输控制协议（TCP）端口号23或2323，这是 Telnet 服务器应用程序正在监听的位置。Telnet 协议将任何终端抽象为一个网络虚拟终端（NVT）。客户端在与服务器通信时必须使用 NVT 代码来模拟一个网络虚拟终端。
Telnet 在 UDP/IP 之前已经存在，最初是在网络控制协议（NCP）之上运行。Telnet 服务最好在以下情境中理解：一个用户使用简单的终端，通过本地的 Telnet 程序（即客户端程序）在远程计算机上运行登录会话，用户的通信需求由 Telnet 服务器程序处理。
协议
历史
虽然Telnet最初是一个临时的协议，直到1973年3月5日才有正式的定义，但其名称实际上指的是“网络上的电传打字机协议”（Teletype Over Network Protocol）。RFC 206（NIC 7176）中对Telnet的描述明确了这一点：
TELNET协议基于虚拟电传打字机的概念，使用7位ASCII字符集。因此，用户TELNET的主要功能是提供一种手段，使其用户可以“敲击”那个虚拟电传打字机上的所有键。
本质上，它使用8位通道来交换7位ASCII数据。任何高位被设置的字节都是特殊的Telnet字符。1973年3月5日，在加州大学洛杉矶分校（UCLA）定义了Telnet协议标准，同时发布了两个NIC文件：《Telnet协议规范》（NIC 15372）和《Telnet选项规范》（NIC 15373）。这些文件为Telnet的发展提供了官方标准和详细的操作规范。
选项
Telnet的协议架构允许进行可协商的选项，因此许多扩展被引入。其中一些扩展已被采纳为互联网标准，即IETF文件中的STD 27至STD 32。这些标准包括不同的Telnet选项，如二进制传输、回显、抑制去向和终端类型协商等。
这些扩展有些已被广泛实施，而其他一些则是IETF标准轨道上的建议标准。例如，有些扩展提供了改进的安全性或兼容性特性，使Telnet能够在更多的环境中使用，尽管在安全性要求高的应用中，人们通常会选择使用更安全的协议，如SSH。
以下是一些IETF标准轨道上的Telnet扩展示例：
- Telnet二进制传输（Telnet Binary Transmission）：允许数据以二进制形式传输，而不仅限于7位ASCII。
- Telnet回显选项（Telnet Echo Option）：允许服务器控制回显功能，这对于实现远程命令行界面非常有用。
- Telnet抑制去向协商（Suppress Go Ahead）：在双向操作模式中，删除了不必要的网络流量，优化了通信效率。
- Telnet终端类型（Terminal Type）：允许客户端和服务器协商终端类型，使服务器可以根据连接的终端类型提供适当的输出。
这些扩展和其他相关的改进使Telnet能够在其生命周期内适应网络环境的变化，尽管如今它已经大部分被更现代的技术所取代。
服务
Telnet服务是通过Telnet协议提供服务的应用程序。大多数操作系统提供了一项服务，可以安装或启用以向客户端提供Telnet服务。
安全漏洞
Telnet容易受到网络攻击的威胁，如嗅探数据包以窃取敏感信息，包括密码和指纹信息。Telnet服务还容易受到利用，通过嗅探横幅泄露服务器信息（如主机名、IP地址和品牌），进而搜索确定Telnet服务是否接受未经身份验证的连接。Telnet也经常被恶意软件利用，因为它配置不当。事实上，与其他常见协议相比，Telnet更常被攻击者针对，尤其是与UPnP、CoAP、MQTT、AMQP和XMPP相比。常被攻击的设备包括物联网设备、路由器和调制解调器。
SANS Institute建议，在正常情况下应停止使用Telnet进行远程登录，原因如下：
- 默认情况下，Telnet不加密连接上发送的任何数据（包括密码），因此往往可以窃听通信，并稍后将密码用于恶意目的。
- 大多数Telnet实现缺乏身份验证。安全研究人员发现的约22,887个Telnet启用设备不仅缺乏身份验证，而且还提供对系统的无限制访问。
- 大多数Telnet身份验证机制容易受到中间人攻击的拦截。
Telnet的扩展提供了传输层安全性（TLS）和简单认证与安全层（SASL）身份验证，以解决上述问题。然而，大多数Telnet实现不支持这些扩展；而且它们也无法解决其他漏洞，如解析横幅信息。
通过自定义Telnet客户端（TN5250/TN3270）和IBM i系统，支持IBM 5250或3270工作站仿真。设计用于通过Telnet传递IBM 5250数据流的客户端和服务器通常支持SSL加密，因为SSH不包括5250仿真。在IBM i（也称为OS/400）下，端口992是安全Telnet的默认端口。
历史使用方式
Telnet 提供了对远程主机上命令行界面的访问。然而，由于通过开放网络（如互联网）使用 Telnet 存在严重的安全问题，其用途已大大减少，转而支持 SSH（Secure Shell）。SSH 提供了 Telnet 的许多功能，增加了强加密功能，以防止密码等敏感数据被截获，以及公钥身份验证，以确保远程计算机确实是其所声称的那个。
随着时间的推移，特别是在公共互联网上，使用 Telnet 进行远程管理的频率已经迅速下降，转而使用更安全的 SSH 协议。这种变化主要是由于：
- 安全性：SSH 通过加密所有传输的数据，提供了比 Telnet 更高的安全级别。这保护了传输中的数据不被窃听或篡改。
- 认证强度：SSH 支持更先进的认证机制，如公钥/私钥对，而不仅仅是密码。这减少了身份验证数据被盗用或破解的风险。
- 功能性：SSH 不仅支持远程命令行访问，还支持端口转发、文件传输等高级功能。
因此，尽管 Telnet 曾广泛用于教育和研究环境中进行远程管理和网络测试，现在它的使用主要限于内部网络或那些不需要高安全性的特定环境。在绝大多数现代网络环境中，SSH 由于其增强的安全性和功能性，已成为远程访问的首选协议。
现在的使用方式
Telnet客户端可用于调试诸如SMTP、IRC、HTTP、FTP或POP3等网络服务，以向服务器发出命令并检查响应。例如，Telnet客户端应用程序可以建立与Telnet服务器端口之外的端口的交互式TCP会话。然而，与这些端口的通信不涉及Telnet协议，因为这些服务仅使用透明的8位TCP连接，因为Telnet协议的大多数元素都是围绕着访问命令行界面的想法设计的，而这些选项或机制在大多数其他Internet服务连接中都没有使用。
例如，命令行Telnet客户端可以如下向TCP端口80上的Web服务器发出HTTP请求：
如今，这种较老的协议只在极少数情况下用于访问几十年前的遗留设备，因为这些设备不支持更现代的协议。例如，许多工业和科学设备只有Telnet作为通信选项。有些设备仅带有标准的RS-232端口，并使用串行服务器硬件设备来提供TCP/Telnet数据和RS-232串行数据之间的转换。在这种情况下，SSH并不是一个选择，除非可以为接口设备配置SSH（或者用支持SSH的设备替换）。
业余无线电操作员通常使用Telnet提供公共信息。
尽管不建议使用Telnet，但安全研究人员估计截至2021年，仍有7,096,465个Internet上的系统暴露使用Telnet。然而，关于这个数字的估计因超出默认TCP端口23的端口扫描数量而有很大不同。
协议内容
常用的ASCII码：
- NULL（空字符）：字节码为0。在文本中通常表示字符串的结束或空字符。
- Line feed（换行）：字节码为10。在Unix和Unix-like系统中表示换行。
- Carriage return（回车）：字节码为13。在老式的打字机中表示将打印头移回行首。
- Bell（响铃）：字节码为7。在打印机或终端上发出声音或闪烁光标，用于提醒用户。
- Backspace（退格）：字节码为8。在文本编辑中表示向左移动光标一个位置，通常用于删除最后输入的字符。
- Horizontal tab（水平制表符）：字节码为9。在文本编辑中表示向右移动光标到下一个制表位。
- Vertical tab（垂直制表符）：字节码为11。在文本中很少使用，可以用于在打印机上控制页面的垂直间距。
- Form feed（换页）：字节码为12。在打印机中表示换页，将打印位置移动到下一页。
这些控制码可以在文本编辑、打印和终端控制等场景中使用，用于控制文本的格式和行为。
telnet命令
Telnet命令至少由两个字节组成。第一个字节是IAC转义字符（通常为字节255），后跟给定命令的字节码：
| 功能 | 字节码 | 说明 |
|---|---|---|
| SE（子协商结束） | 240 | 结束协商（或数据块）的子服务的协议机制。 |
| NOP（无操作） | 241 | 不执行任何操作的数据包。 |
| Data Mark（数据标记） | 242 | |
| Break（中断） | 243 | |
| Interrupt Process（中断进程） | 244 | 请求另一方结束当前进程。 |
| Abort output（中止输出） | 245 | 请求另一方停止发送输出。 |
| Are you there?（你在吗？） | 246 | |
| Erase character（擦除字符） | 247 | |
| Erase Line（擦除行） | 248 | |
| Go ahead（继续） | 249 | |
| SB（子协商开始） | 250 | 启动协议机制的子服务的协商。 |
| WILL | 251 | 通知另一方，本方将使用某个协议机制。 |
| WON'T | 252 | 通知另一方，本方将不使用某个协议机制。 |
| DO | 253 | 指示另一方使用某个协议机制。 |
| DON'T | 254 | 指示另一方不要使用某个协议机制。 |
| IAC（序列初始化器/转义字符） | 255 |
希望这个表格能够帮助你更清晰地理解这些功能和它们的字节码。
这些命令用于Telnet协议的控制和协商，以便在Telnet会话期间执行各种操作和协议交互。
telnet转移字符
除了0xff之外的所有数据八位组都按原样传输到Telnet上。(0xff，或十进制255，是IAC字节（Interpret As Command），它表示下一个字节是Telnet命令。插入0xff到流中的命令是0xff，所以当通过Telnet协议发送数据时，必须将0xff转义为两倍。)
好的，下面是将上述内容转换为表格并翻译成中文的结果：
| 代码 | 名称 | 规范 | 备注 |
|---|---|---|---|
| 0 | 二进制传输 | RFC 856 | 8位模式（即二进制选项）旨在传输二进制数据，而不是ASCII字符。标准建议将代码0000–0176解释为ASCII，但并未提供高位设置数据八位组的任何含义。曾尝试引入类似于HTTP的可切换字符编码支持，但对其实际软件支持情况一无所知。 |
| 1 | 回显 | RFC 857 | |
| 2 | 重新连接 | 1973年NIC 15391 | |
| 3 | 抑制前导 | RFC 858 | 原始Telnet协议中的“Go Ahead”命令代码（249）用于通知另一端，另一端可以开始发送消息。这在“半双工”通信中使用，因为某些终端可以发送消息和接收消息，但不能同时进行。 |
| 4 | 大小约定 | 1973年NIC 15393 | |
| 5 | 状态 | RFC 859 | |
| 6 | 时间标记 | RFC 860 | |
| 7 | 远程控制传输和回显 | RFC 726 | |
| 8 | 输出行宽 | 1978年8月NIC 20196 | |
| 9 | 输出页大小 | 1978年8月NIC 20197 | |
| 10 | 输出回车符处理 | RFC 652 | |
| 11 | 输出水平制表符站位 | RFC 653 | |
| 12 | 输出水平制表符处理 | RFC 654 | |
| 13 | 输出换页符处理 | RFC 655 | |
| 14 | 输出垂直制表符站位 | RFC 656 | |
| 15 | 输出垂直制表符处理 | RFC 657 | |
| 16 | 输出换行符处理 | RFC 658 | |
| 17 | 扩展ASCII | RFC 698 | |
| 18 | 注销 | RFC 727 | |
| 19 | 字节宏 | RFC 735 | |
| 20 | 数据输入终端 | RFC 1043, RFC 732 | |
| 21 | SUPDUP | RFC 736, RFC 734 | |
| 22 | SUPDUP输出 | RFC 749 | |
| 23 | 发送位置 | RFC 779 | |
| 24 | 终端类型 | RFC 1091 | |
| 25 | 记录结束 | RFC 885 | |
| 26 | TACACS用户识别 | RFC 927 | |
| 27 | 输出标记 | RFC 933 | |
| 28 | 终端位置号 | RFC 946 | |
| 29 | Telnet 3270模式 | RFC 1041 | |
| 30 | X.3 PAD | RFC 1053 | |
| 31 | 关于窗口大小协商 | RFC 1073 | |
| 32 | 终端速度 | RFC 1079 | |
| 33 | 远程流量控制 | RFC 1372 | |
| 34 | Linemode | RFC 1184 | |
| 35 | X显示位置 | RFC 1096 | |
| 36 | 环境选项 | RFC 1408 | |
| 37 | 认证选项 | RFC 2941 | |
| 38 | 加密选项 | RFC 2946 | |
| 39 | 新环境选项 | RFC 1572 | |
| 40 | TN3270E | RFC 2355 | |
| 41 | XAUTH | ||
| 42 | 字符集 | RFC 2066 | |
| 43 | Telnet远程串行端口（RSP） | ||
| 44 | COM端口控制选项 | RFC 2217 | |
| 45 | Telnet抑制本地回显 | ||
| 46 | Telnet启动TLS | ||
| 47 | KERMIT | RFC 2840 | |
| 48 | 发送URL | ||
| 49 | FORWARD_X | ||
| 50-137 | 未分配 | ||
| 138 | TELOPT PRAGMA LOGON | ||
| 139 | TELOPT SSPI LOGON | ||
| 140 | TELOPT PRAGMA HEARTBEAT | ||
| 141-254 | 未分配 | ||
| 255 | 扩展选项列表 | RFC 861 |
RFC 854
1. 介绍
TELNET的目标是提供一个相对通用，双向，面向八位字节的通信机制。它的主要目的标是允许通过标准方法来连接终端设备和面向各个终端的进程。可以想象此协议同样可用于终端间通信（“链接”）以及进程间通信（“分布式计算”）。
2. 总则
TELNET连接是用于传输带有TELNET控制信息的数据的TCP连接。
TELNET协议的设计主要基于三点：一、网络虚拟终端（Network Virtual Terminal）的概念；二、选项可协商的原理；三、平等看待终端和进程。
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选项规范”来得到关于如何建立新的选项的信息。
3. 网络虚终端
网络虚终端（NVT）是一个双向的字符设备。NVT有一个打印机和一个键盘。打印机负责进来的数据，而键盘负责产生通过TELNET连接发送出去的数据，并且在需要“回显”时，同时在NVT的打印机上回显这些数据。“回显”并不要求数据一定要经过网络（尽管有一个选项可以控制该操作的”远程“模式，但并不要求主机实现该选项）。
除了在这里说明的外，所有的编码集合都是有八位的，但只使用其中的七位的USASCII码。所有的代码转换和时区方面的问题都是本地的事情，而不影响NVT。
4. 数据的传输
尽管一个通过网络连接的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。最后，对于终端到终端的通讯，在两个方向上可能都需要GA。如果一个主机打算支持终端到终端的通讯，建议主机在需要通过TELNET连接发送GA的时候，提供一个手工发信号给用户的方法。然而，在实现TELNET过程中，这一点并不是必需的。
注意：由于TELNET模型的对称性，从理论上来说，在一个TELNET连接的每一端，都必须有一个NVT。
5. 控制功能的标准表示
就象我们在本文档的简介中所说，TELENT协议的主要目标是在通过网络连接的终端设备和面向终端的过程之间提供一个标准的接口。早期具有这种互联性质的实验表明，大部分的服务器都实现了某些功能，但调用这些功能的方式却差别很大。对于一个要与多种服务器系统交互的用户来说，这些差别会使人沮丧。因此，TELNET协议定义了这些功能中的其中5种的标准表示。这些标准表示具有标准涵义 —— 但不是必要的（除了中断进程（IP）功能，使用TELENT协议的其他协议可能需要该功能）。也就是说，一个没有给本地用户提供某种功能的系统也没有必要给网络上的其他用户提供该功能，并且可以把该功能的标准表示当作No操作。另一方面，如果一个系统已经给本地用户提供了该功能，那么它必须给网络上那些传送该功能的标准表示的用户提供同样的功能。
中断进程 – Interrupted Process（IP）
许多系统提供挂起，中断，中止，终止用户进程的操作的功能。当用户确信他的进程已经进入了无穷尽的循环，或者不小心激活了一个并不希望激活的进程时，就要经常使用该功能。IP就是调用该功能的标准表示。该功能的实现者应注意的是，其他使用TELNET协议的协议可能要使用IP，因此若要支持这些协议则应实现此功能。
中断输出 -- Abort Output （AO）
许多系统提供了允许一个正在产生输出的进程在不向用户的终端发送输出的情况下完成运行（或者到达在完成运行后将会到达的某一个停止点）的功能。
另外，该功能的一个典型用途是清除那些已经生成但还没有实际打印（或者显示）到用户的终端上的输出。AO是调用该功能的标准表示。比如，许多子系统通常会接受一个用户的命令，然后以一个发送到用户终端的长的字符串作为回应，最后，给用户的终端发送一个“提示”字符（前面跟着 <CR><LF>）来表示准备接受下一个命令。如果是在传输字符串的过程中接收到AO，一个合理的实现应该停止继续传输字符串，而转向发送提示符和跟在前面的 <CR><LF>。（这可能同接收到IP所进行的动作有一些差别。在接收到IP时，将导致停止字符串的传输并且从子系统中退出。）
同时还需要注意到，对那些提供这种功能的服务器，可能还需要清除那些存在于系统外的缓冲机制（在网络中或者在用户的本地机器上）中的内容。完成这个过程的一个合适的方法是给用户的系统发送“同步”信号（将在下面描述）。
你在那里吗？ -- Are You There （AYT）
许多系统提供了给用户提供系统仍然在运行的一些可见的（如可打印的）迹象。这个功能可以在系统在一个想象不到的很长一段时间里都没有动静时（可能是由于用户没有想象到的计算时间，或者不正常的巨大系统负荷等导致。）由用户调用。 AYT是调用该功能的标准表示.
消除一个字符 - - Erase Character （EC）
许多系统提供了删除在未删除字符前面或者用户提供的数据流中的“打印位置” 最后面的一个字符的功能。该功能通常在键盘输入时输入了错误的字符时使用。EC是调用该功能的标准表示。
*注意 ：一个“打印位置”可能包含相互覆盖的几个字符，或者象下面的字符系列：<char1> BS <char2>...
消除一行 -- Erase Line （EL）
许多系统提供了删除输出设备上的当前一行的全部数据的功能。该功能经常在用键盘进行输入编辑时使用。EL是调用该功能的标准表示。
6. 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将激活随后级别较高的进程。
7. 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的作用才是无法预测的。
8. 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 | 251 | 表示希望开始使用或者确认所使用的是指定的选项 |
| WON'T | 252 | 表示拒绝使用或者继续使用指定的选项 |
| DO | 253 | 表示一方要求另一方使用，或者确认你希望另一方使用指定的选项 |
| DON'T | 254 | 表示一方要求另一方停止使用，或者确认你不再希望另一方使用指定的选项 |
| IAC | 255 | Data Byte 255 |
9. 连接的建立
TELNET TCP连接是在用户端口U和服务器端口L之间建立的。服务器在用于这种类型的连接的一个众所周知的端口L上监听客户请求。由于一个TPC连接是全双工的，并且通过双方的端口来标识，服务器可以对不同的用户端口U和端口L的之间的许多并发连接进行应答。
端口分配
当用来给远程用户提供访问服务主机的服务（也就是远程终端访问）时，此协议分配的服务端口是23（八进制27）。也就是L=23。
RFC 930 获取客户端类型
首先使用 IAC命令启用该功能：
IAC WILL 24
然后发送
IAC SB 24, 1, IAC, SE
等待一段时间后接收到以下字符串
IAC SB 24 0 n1,n2,n3.... IAC SE
其中 n1....nx 就是客户端类型（字符串格式）
RFC1184 行显示控制
从RFC1116变更的内容：
添加了两个新的模式位，SOFT_TAB和LIT_ECHO。这些位允许服务器向客户端提供一些关于如何回显制表符和非打印字符的建议。
当支持视觉编辑时，添加了几个新的特殊字符映射，用于光标移动。这些包括：将光标向左/向右移动一个字符（SLC_MCL/SLC_MCR），将光标向左/向右移动一个单词（SLC_MCWL/SLC_MCWR），将光标移动到行首/行尾（SLC_MCBOL/SLC_MCEOL），进入插入/覆盖模式（SLC_INSRT/SLC_OVER），向右删除一个字符/单词（SLC_ECR/SLC_EWR），以及删除到行首/行尾（SLC_EBOL/SLC_EEOL）。
概述
Linemode Telnet是一种在Telnet连接客户端进行终端字符处理的方式。当处于Linemode模式并且本地端启用编辑功能时，网络流量将减少到每行命令几个数据包，而不是每个输入字符几个数据包。这对于具有较长延迟的网络来说非常有用，因为用户在输入命令行时可以获得本地响应时间，只在命令输入完毕后才会遇到网络延迟。此外，它也有助于减少按数据包收费的网络的成本。
打开该功能：
IAC WILL 34
选项：
IAC SB 34 MODE mask IAC SE
MODE :
| 序号 | 命令名称 | 代码 |
|---|---|---|
| 1 | EDIT | 1 |
| 2 | TRAPSIG | 2 |
| 3 | MODE_ACK | 4 |
| 4 | SOFT_TAB | 8 |
| 5 | LIT_ECHO | 16 |
| 命令名称 | 描述 |
|---|---|
| EDIT | 当设置时，连接的客户端应处理所有输入行，执行任何编辑功能，并仅将完成的行发送到远程端。当未设置时，客户端不应处理来自用户的任何输入，服务器端应负责处理所有需要完成的字符处理。 |
| TRAPSIG | 当设置时，客户端应将适当的中断/信号转换为它们的Telnet等效项。（这些将是IP、BRK、AYT、ABORT、EOF和SUSP）当未设置时，客户端应将中断/信号作为它们的正常ASCII值传递。 |
| FLOW | 逻辑上，这属于“mask”。然而，这将与Telnet的TOGGLE-FLOW-CONTROL选项重叠，因此使用Telnet的TOGGLE-FLOW-CONTROL选项代替。当DO/WILL LINEMODE被协商时，也应协商DO/WILL TOGGLE-FLOW-CONTROL。有关正确使用，请参阅RFC 1080，“Telnet远程流量控制”。 |
| ECHO | 逻辑上，这属于“mask”。然而，这与Telnet的ECHO选项重叠，因此使用Telnet的ECHO选项代替。客户端不应协商“WILL ECHO”。当服务器协商了“WILL ECHO”时，客户端不应将用户输入的数据回显给用户。当服务器协商了“WONT ECHO”时，客户端负责将用户输入的数据回显给用户。有关Telnet ECHO选项使用的完整讨论，请参阅RFC 857，“Telnet ECHO OPTION”。 |
| SOFT_TAB | 当设置时，客户端应将水平制表符（HT）代码（USASCII 9）扩展为适当数量的空格，以便将打印机移动到下一个水平制表符停止位置。当未设置时，客户端应允许水平制表符代码未经修改地通过。 |
| LIT_ECHO | 当设置时，如果客户端正在将用户输入的非打印字符回显到用户屏幕上，则应将字符作为字面字符回显。如果未设置LIT_ECHO位，则客户端可以以任何它想要的方式回显字符。（许多系统将非打印字符回显为两个字符的序列，例如，它们会将ASCII值为1的字符回显为“^A”。） |
当连接的客户端接收到MODE命令时，它必须至少同意EDIT和TRAPSIG位的状态。如果接收到一个当前正在使用的模式掩码（忽略MODE_ACK位）的MODE命令，则该MODE命令将被忽略。如果接收到的MODE命令与当前模式掩码不同，则发送带有新模式掩码和MODE_ACK位设置的回复，或者发送新模式掩码的子集。唯一的例外是，如果服务器接收到EDIT或TRAPSIG位未设置的MODE，它可以在响应中设置EDIT和TRAPSIG位，而如果客户端接收到EDIT或TRAPSIG位设置的MODE，它不能在响应中清除这些位。
当接收到MODE_ACK位设置的MODE命令，且该模式与当前模式不同时，客户端将忽略新模式，而服务器将切换到新模式。这确保了连接的两端都将解析为相同的模式。在所有情况下，对于设置了MODE_ACK位的MODE命令，永远不会生成响应。
子选项
IAC SB LINEMODE DO FORWARDMASK mask0 mask1 ... mask31 IAC SE
这条命令的发送方请求对方在接收到由位掩码定义的任何ASCII字符时，发送任何缓冲的数据。只有发送DO LINEMODE命令的连接方（即服务器端）可以协商此选项。掩码的长度最多为32个八位字节。每个八位字节代表8个ASCII字符编码。mask0的最高位对应于ASCII码0，而mask0的最低位对应于ASCII码7。mask1的最高位对应于ASCII码8，而mask1的最低位对应于ASCII码15，以此类推。掩码列表可以在列表结束之前终止，在这种情况下，假设掩码八位字节的其余部分都被重置（等于零）。当服务器端处于DONT TRANSMIT-BINARY模式时，则仅使用掩码的前16个八位字节（ASCII码0到127）。如果掩码的任何单个八位字节等于IAC，则必须将其发送为双IAC。