3. 远程登录 -- Telnet 协议 (Remote Login - TELNET Protocol)
3.1 简介 (INTRODUCTION)
Telnet 是用于远程登录的标准互联网应用协议.它提供编码规则, 将客户端 ("用户") 系统上的用户键盘/显示器与远程服务器系统上的命令解释器链接起来.Telnet 协议的一个子集也被纳入其他应用协议中, 例如 FTP 和 SMTP.
Telnet 使用单个 TCP 连接, 其正常数据流 ("网络虚拟终端 (Network Virtual Terminal, NVT)"模式) 是带有嵌入控制功能转义序列的 7 位 ASCII.Telnet 还允许协商许多可选模式和功能.
主要的 Telnet 规范在 RFC-854 [TELNET:1] 中, 而选项在许多其他 RFC 中定义; 参考文献参见第 7 节.
3.2 协议逐步分析 (PROTOCOL WALK-THROUGH)
3.2.1 选项协商 (Option Negotiation): RFC-854, 第 2-3 页
每个 Telnet 实现必须 (MUST) 包含选项协商和子协商机制 [TELNET:2].
主机必须 (MUST) 仔细遵循 RFC-854 的规则以避免选项协商循环.主机必须 (MUST) 拒绝 (即对 DO/WILL 回复 WONT/DONT) 不支持的选项.选项协商应该 (SHOULD) 在 Telnet 连接的整个生命周期内继续运行 (即使所有请求都被拒绝).
如果所有选项协商都失败, Telnet 实现必须 (MUST) 默认为并支持 NVT.
讨论 (DISCUSSION):
尽管更复杂的"终端"以及对选项协商的支持正在成为常态, 所有实现都必须做好准备, 为任何用户-服务器通信支持 NVT.
3.2.2 Telnet Go-Ahead 功能 (Telnet Go-Ahead Function): RFC-854, 第 5 页, 以及 RFC-858
在从不发送 Telnet 命令 Go Ahead (GA) 的主机上, Telnet 服务器必须 (MUST) 尝试协商 Suppress Go Ahead 选项 (即发送"WILL Suppress Go Ahead").用户或服务器 Telnet 必须 (MUST) 始终接受 Suppress Go Ahead 选项的协商.
当驱动对 GA 没有意义的全双工终端时, 用户 Telnet 实现可以 (MAY) 忽略 GA 命令.
讨论 (DISCUSSION):
Go-Ahead 机制所针对设计的半双工 ("锁定键盘") 逐行终端已基本从舞台上消失.事实证明, 在许多操作系统中实现发送 Go-Ahead 信号是困难的, 甚至在一些支持原生半双工终端的系统上也是如此.困难通常在于 Telnet 服务器代码无法访问关于用户进程是否正阻塞等待来自 Telnet 连接的输入的信息, 也就是说, 它无法可靠地确定何时发送 GA 命令.因此, 大多数 Telnet 服务器主机不发送 GA 命令.
本节规则的效果是允许 Telnet 连接的任何一端否决 GA 命令的使用.
有一类半双工终端在商业上仍然重要: 以全屏方式交互的"数据录入终端".然而, 使用 Telnet 协议支持数据录入终端并不需要 Go Ahead 信号; 参见第 3.3.2 节.
3.2.3 控制功能 (Control Functions): RFC-854, 第 7-8 页
Telnet 命令列表已扩展为包含 EOR (记录结束), 代码为 239 [TELNET:9].
用户和服务器 Telnet 可以 (MAY) 支持控制功能 EOR、EC、EL 和 Break, 并且必须 (MUST) 支持 AO、AYT、DM、IP、NOP、SB 和 SE.
主机必须 (MUST) 能够接收并忽略任何它不支持的 Telnet 控制功能.
讨论 (DISCUSSION):
注意, 服务器 Telnet 必须支持 Telnet IP (Interrupt Process, 中断进程) 功能, 即使服务器主机具有等效的流内功能 (例如许多系统中的 Control-C).由于 TCP 紧急数据的带外效应, Telnet IP 功能可能比流内中断命令更强大.
EOR 控制功能可用于分隔数据流.一个重要的应用是数据录入终端支持 (参见第 3.3.2 节).曾经有人担心, 由于 EOR 未在 RFC-854 中定义, 未准备好正确忽略未知 Telnet 命令的主机在收到 EOR 时可能会崩溃.为保护此类主机, 引入了 End-of-Record 选项 [TELNET:9]; 然而, 正确实现的 Telnet 程序并不需要这种保护.
3.2.4 Telnet "Synch" 信号 (Telnet "Synch" Signal): RFC-854, 第 8-10 页
当收到"紧急"TCP 数据时, 用户或服务器 Telnet 必须 (MUST) 丢弃所有数据 (Telnet 命令除外), 直到到达 DM (和紧急结束).
当发送 Telnet IP (中断进程) 时, 用户 Telnet 应该 (SHOULD) 在其后跟随 Telnet "Synch"序列, 即作为 TCP 紧急数据发送序列"IAC IP IAC DM".TCP 紧急指针指向 DM 八位字节.
当收到 Telnet IP 命令时, 服务器 Telnet 可以 (MAY) 向用户发回 Telnet "Synch"序列, 以刷新输出流.该选择应当与本地用户中断进程时服务器操作系统的行为方式保持一致.
当收到 Telnet AO 命令时, 服务器 Telnet 必须 (MUST) 向用户发送 Telnet "Synch"序列, 以刷新输出流.
用户 Telnet 应该 (SHOULD) 具备在发送 Telnet IP 时刷新输出的能力; 另参见第 3.4.5 节.
讨论 (DISCUSSION):
用户 Telnet 刷新服务器输出数据流有三种可能的方式:
(1) 在 IP 之后发送 AO.
这将使服务器主机向其操作系统发送"刷新缓冲输出"信号.然而, AO 可能不会在本地立即生效, 即在服务器 Telnet 收到并处理 AO 并发回"Synch"之前, 用户 Telnet 端的终端输出不会停止.
(2) 在 IP 之后发送 DO TIMING-MARK [TELNET:7], 并在本地丢弃所有输出, 直到从服务器 Telnet 收到 WILL/WONT TIMING-MARK.
由于 DO TIMING-MARK 将在服务器上于 IP 之后被处理, 对它的回复应当位于输出数据流中的正确位置.然而, TIMING-MARK 不会向服务器操作系统发送"刷新缓冲输出"信号.是否需要这样做取决于服务器系统.
(3) 两者都做.
最佳方法并不完全明确, 因为它必须适应大量以各种方式不遵循 Telnet 标准的现有服务器主机.最安全的方法可能是提供一个用户可控的选项来选择 (1)、(2) 或 (3).
3.2.5 NVT 打印机和键盘 (NVT Printer and Keyboard): RFC-854, 第 11 页
在 NVT 模式下, Telnet 不应 (SHOULD NOT) 发送高位为 1 的字符, 并且不得 (MUST NOT) 将其作为奇偶校验位发送.将高位传递给应用程序的实现应该 (SHOULD) 协商二进制模式 (参见第 3.2.6 节).
讨论 (DISCUSSION):
实现者应当注意, 严格解读 RFC-854 允许期望 NVT ASCII 的客户端或服务器忽略设置了高位的字符.一般来说, 二进制模式预期用于通过 Telnet 传输扩展的 (超出 7 位的) 字符集.
然而, 确实存在真正需要 8 位 NVT 模式的应用, 而该模式目前尚未定义, 这些现有应用确实会在 Telnet 连接的部分或全部生命周期内设置高位.注意, 二进制模式与 8 位 NVT 模式并不相同, 因为二进制模式会关闭行末处理.因此, 对高位的要求表述为应该 (SHOULD) 而非必须 (MUST).
RFC-854 定义了"网络虚拟终端"或 NVT 的最小属性集; 这并不意味着排除真实终端中的附加特性.Telnet 连接对所有 7 位 ASCII 字符 (包括任意 ASCII 控制字符) 是完全透明的.
例如, 某个终端可能支持编码为 ASCII 转义序列的全屏命令; Telnet 实现会将这些序列作为未经解释的数据传递.因此, 不应将 NVT 理解为某种高度受限设备的终端类型.
3.2.6 Telnet 命令结构 (Telnet Command Structure): RFC-854, 第 13 页
由于选项可能出现在数据流中的任何位置, 要作为数据发送的 Telnet 转义字符 (称为 IAC, 值为 255) 必须 (MUST) 加倍.
3.2.7 Telnet 二进制选项 (Telnet Binary Option): RFC-856
当二进制选项成功协商后, 允许任意 8 位字符.但是, 数据流必须 (MUST) 仍然扫描 IAC 字符, 任何嵌入的 Telnet 命令必须 (MUST) 被遵守, 等于 IAC 的数据字节必须 (MUST) 加倍.其他字符处理 (例如将 CR 替换为 CR NUL 或 CR LF) 不得 (MUST NOT) 进行.特别地, 二进制模式下不存在行末约定 (参见第 3.3.1 节).
讨论 (DISCUSSION):
二进制选项通常在两个方向上协商, 以将 Telnet 连接从 NVT 模式改为"二进制模式".
序列 IAC EOR 可用于在二进制模式的 Telnet 流中分隔数据块.
3.2.8 Telnet 终端类型选项 (Telnet Terminal-Type Option): RFC-1091
终端类型选项必须 (MUST) 使用已分配号码 RFC [INTRO:5] 中官方定义的终端类型名称 (当它们对特定终端可用时).但是, 终端类型选项的接收方必须 (MUST) 接受任何名称.
讨论 (DISCUSSION):
RFC-1091 [TELNET:10] 更新了 RFC-930 中定义的终端类型选项的早期版本.早期版本允许能够支持多种终端类型的服务器主机了解特定客户端终端的类型, 其假设是每个物理终端都有一个固有类型.然而, 如今"终端"往往实际上是运行在 PC 中的终端仿真程序, 可能能够仿真一系列终端类型.因此, RFC-1091 扩展了该规范, 以允许用户 Telnet 与服务器 Telnet 之间进行更通用的终端类型协商.
3.3 具体问题 (SPECIFIC ISSUES)
3.3.1 Telnet 行末约定 (Telnet End-of-Line Convention)
Telnet 协议将序列 CR LF 定义为"行末".对于终端输入, 这对应于用户终端上按下命令完成或"行末"键; 在 ASCII 终端上, 这是 CR 键, 但也可能标记为"Return"或"Enter".
当服务器 Telnet 从远程终端接收到 Telnet 行末序列 CR LF 作为输入时, 效果必须 (MUST) 与用户在本地终端上按下"行末"键相同.特别地, 在使用 ASCII 的服务器主机上, 收到 Telnet 序列 CR LF 必须产生与本地用户在本地终端上按下 CR 键相同的效果.因此, 当通过 Telnet 连接作为输入接收时, CR LF 和 CR NUL 在 ASCII 服务器主机上必须 (MUST) 具有相同的效果.
用户 Telnet 必须 (MUST) 能够发送以下任何形式: CR LF、CR NUL 和 LF.ASCII 主机上的用户 Telnet 应该 (SHOULD) 有一个用户可控模式, 在用户按下"行末"键时发送 CR LF 或 CR NUL, 并且 CR LF 应该 (SHOULD) 是默认值.
Telnet 行末序列 CR LF 必须 (MUST) 用于发送非终端到计算机的 Telnet 数据 (例如, 服务器 Telnet 发送输出, 或 Telnet 协议纳入另一个应用协议).
讨论 (DISCUSSION):
为了允许任意 Telnet 客户端与服务器之间的互操作, Telnet 协议为行终止符定义了标准表示.由于 ASCII 字符集不包含显式的行末字符, 各系统选择了不同的表示, 例如 CR、LF 以及序列 CR LF.Telnet 协议选择 CR LF 序列作为网络传输的标准.
不幸的是, RFC-854 [TELNET:1] 中的 Telnet 协议规范在客户端应向服务器发送何种字符以表示"行末"键这一点上, 事实证明有些含糊.其结果是一个巨大且持续的互操作性难题, 而用户与服务器 Telnet 的各种错误实现更是雪上加霜.
尽管 Telnet 协议基于一个完全对称的模型, 但在远程登录会话中, 终端处用户的角色不同于服务器主机的角色.例如, RFC-854 定义了 CR、LF 和 CR LF 作为服务器输出时的含义, 但未规定当用户按下终端上的"行末"键时用户 Telnet 应发送什么; 这正是争议所在.
当用户按下"行末"键时, 一些用户 Telnet 实现发送 CR LF, 而另一些发送 CR NUL (基于对 RFC-854 中同一句话的不同解释).如上文所述, 对于正确实现的 ASCII 服务器主机, 这两者是等效的.对于其他服务器, 则需要在用户 Telnet 中提供一个模式.
只在按下 CR 时发送 CR NUL 的用户 Telnet 的存在, 为非 ASCII 主机制造了两难: 它们要么将输入中的 CR NUL 视为等同于 CR LF, 从而排除输入"裸" CR 的可能性, 要么就完全失去互通性.
假设主机 A 上的用户使用 Telnet 登录到服务器主机 B, 然后执行 B 的用户 Telnet 程序登录到服务器主机 C.理想情况下, B 上的服务器/用户 Telnet 组合应尽可能透明, 即表现得如同 A 直接连接到 C.特别地, 正确的实现将使 B 对 Telnet 行末序列透明, 只是 CR LF 可能被转换为 CR NUL, 反之亦然.
实现 (IMPLEMENTATION):
要理解 Telnet 行末问题, 必须至少对 Telnet 与本地操作系统之间的关系有一个大致的模型.服务器 Telnet 进程通常作为伪终端耦合到操作系统的终端驱动软件中.服务器 Telnet 收到的 Telnet 行末序列必须与在真实的本地连接终端上按下行末键具有相同的效果.
支持交互式逐字符应用 (例如编辑器) 的操作系统通常为其终端 I/O 提供两种内部模式: 格式化模式, 其中行末及其他格式化规则的本地约定已应用于数据流; 以及"原始 (raw)"模式, 其中应用程序可以直接访问输入的每个字符.服务器 Telnet 的实现方式必须使这些模式对远程终端与本地终端产生相同的效果.例如, 假设 ASCII 主机上的服务器 Telnet 收到 CR LF 或 CR NUL.在原始模式下, CR 字符被传递给应用程序; 在格式化模式下, 则使用本地系统的行末约定.
3.3.2 数据录入终端 (Data Entry Terminals)
讨论 (DISCUSSION):
除了 Telnet 所针对设计的面向行和面向字符的 ASCII 终端之外, 还有若干类视频显示终端, 有时被称为"数据录入终端 (data entry terminals)"或 DET.IBM 3270 系列是一个众所周知的例子.
已有两个互联网协议被设计用于支持通用 DET: SUPDUP [TELNET:16, TELNET:17] 和 DET 选项 [TELNET:18, TELNET:19].DET 选项使用 (子) 协商在 Telnet 连接上驱动数据录入终端.SUPDUP 则是一个完全独立的终端协议, 可以通过协商从 Telnet 进入.尽管 SUPDUP 和 DET 选项都曾在特定环境中成功使用, 但两者都未获得普遍接受或广泛实现.
针对通过 Telnet 支持 IBM 3270 系列, 已发展出一种不同的 DET 交互方法, 尽管同样的方法也适用于任何 DET.其思路是进入"原生 DET"模式, 在该模式下, 原生 DET 输入/输出流作为二进制数据发送.Telnet EOR 命令用于在此二进制流中分隔逻辑记录 (例如"屏幕").
实现 (IMPLEMENTATION):
进入和退出原生 DET 模式的规则如下:
o 服务器使用终端类型选项 [TELNET:10] 得知客户端是 DET.
o 按照惯例 (但非必需), 两端协商 EOR 选项 [TELNET:9].
o 两端协商二进制选项 [TELNET:3] 以进入原生 DET 模式.
o 当任一端协商退出二进制模式时, 另一端也随之退出, 模式随即恢复为正常 NVT.
3.3.3 选项要求 (Option Requirements)
每个 Telnet 实现必须 (MUST) 支持二进制选项 [TELNET:3] 和 Suppress Go Ahead 选项 [TELNET:5], 并且应该 (SHOULD) 支持 Echo [TELNET:4]、Status [TELNET:6]、End-of-Record [TELNET:9] 和 Extended Options List [TELNET:8] 选项.
如果本地操作系统提供相应功能, 用户或服务器 Telnet 应该 (SHOULD) 支持窗口大小选项 [TELNET:12].
讨论 (DISCUSSION):
注意, End-of-Record 选项仅表示 Telnet 能够接收 Telnet EOR 而不崩溃; 因此, 每个 Telnet 都应当愿意接受 End-of-Record 选项的协商.另参见第 3.2.3 节中的讨论.
3.3.4 选项发起 (Option Initiation)
当 Telnet 协议在客户端/服务器情况下使用时, 服务器应该 (SHOULD) 发起其期望的终端交互模式的协商.
讨论 (DISCUSSION):
Telnet 协议被定义为完全对称, 但其应用通常是不对称的.已知有远程登录因双方都未发起所需非默认终端模式的协商而失败的情况.通常是由服务器决定首选模式, 因此服务器需要发起协商; 由于协商是对称的, 用户也可以发起它.
客户端 (用户 Telnet) 应该 (SHOULD) 为用户提供启用和禁用选项协商发起的方法.
讨论 (DISCUSSION):
用户有时需要连接到某个应用服务 (例如 FTP 或 SMTP), 该服务将 Telnet 用于其控制流但不支持 Telnet 选项.如果禁用了选项协商的发起, 用户 Telnet 便可用于此目的.
3.3.5 Telnet Linemode 选项 (Telnet Linemode Option)
讨论 (DISCUSSION):
一个重要的新 Telnet 选项 LINEMODE [TELNET:12] 已被提出.LINEMODE 选项为用户 Telnet 与服务器 Telnet 提供了一种标准方式, 用以约定由客户端而非服务器执行终端字符处理.当客户端准备好一整行文本后, 它将 (通常) 在一个 TCP 分组中把该行发送给服务器.该选项将大大降低 Telnet 会话的分组开销, 并且在拥塞或长延迟网络上提供好得多的用户响应.
LINEMODE 选项允许在本地与远程字符处理之间动态切换.例如, 在全屏编辑器运行期间, Telnet 连接会自动协商进入单字符模式, 并在编辑器结束后返回 linemode.
我们期望在本 RFC 发布时, 主机应当实现该选项的客户端一侧, 并且可以实现该选项的服务器一侧.为了正确实现服务器一侧, 服务器需要能够告知本地系统不要进行任何输入字符处理, 而是记住其当前终端状态, 并在状态变化时通知服务器 Telnet 进程.举例来说, 这将使密码回显和全屏编辑器能够得到正确处理.
3.4 Telnet/用户接口 (TELNET/USER INTERFACE)
3.4.1 字符集透明性 (Character Set Transparency)
用户 Telnet 实现应该 (SHOULD) 能够发送或接收任何 7 位 ASCII 字符.在可能的情况下, 用户主机操作系统对这些字符的任何特殊字符解释应该 (SHOULD) 被绕过, 以便这些字符可以方便地在连接上发送和接收.
某个字符值必须 (MUST) 保留为"转义到命令模式"; 按照惯例, 加倍此字符允许将其作为数据输入.使用的特定字符应该 (SHOULD) 是用户可选择的.
在二进制模式连接上, 如果主机操作系统不允许从键盘直接输入任意 8 位值, 用户 Telnet 程序可以 (MAY) 提供输入这些值的转义机制.
实现 (IMPLEMENTATION):
透明性问题在服务器上不那么紧迫, 但实现者应当注意处理如下问题: 在数据到达仅期望 NVT ASCII 的程序之前屏蔽掉奇偶校验位 (由较旧的、不符合规范的客户端发送), 以及正确处理请求 8 位数据流的程序.
3.4.2 Telnet 命令 (Telnet Commands)
用户 Telnet 程序必须 (MUST) 为用户提供输入任何 Telnet 控制功能 IP、AO 或 AYT 的能力, 并且应该 (SHOULD) 提供输入 EC、EL 和 Break 的能力.
3.4.3 TCP 连接错误 (TCP Connection Errors)
用户 Telnet 程序应该 (SHOULD) 向用户报告传输层报告的任何 TCP 错误 (参见 [INTRO:1] 中的"TCP/应用层接口"一节).
3.4.4 非默认 Telnet 联系端口 (Non-Default Telnet Contact Port)
用户 Telnet 程序应该 (SHOULD) 允许用户可选地指定服务器 Telnet 主机上的非标准联系端口号.
3.4.5 刷新输出 (Flushing Output)
用户 Telnet 程序应该 (SHOULD) 为用户提供指定发送 IP 时是否应刷新输出的能力; 参见第 3.2.4 节.
对于任何使用户 Telnet 在本地刷新输出直到从服务器收到 Telnet 信号的输出刷新方案, 应该 (SHOULD) 为用户提供一种手动恢复正常输出的方式, 以防服务器未能发送预期的信号.
3.5 Telnet 要求摘要 (TELNET REQUIREMENTS SUMMARY)
| 功能 | 章节 | MUST | SHOULD | MAY | SHOULD NOT | MUST NOT |
|---|---|---|---|---|---|---|
| 选项协商 (Option Negotiation) | ||||||
| 实现选项协商 | 3.2.1 | x | ||||
| 避免协商循环 | 3.2.1 | x | ||||
| 拒绝不支持的选项 | 3.2.1 | x | ||||
| 连接上任何时候都可协商 | 3.2.1 | x | ||||
| 默认为 NVT | 3.2.1 | x | ||||
| 在 Term-Type 选项中发送官方名称 | 3.2.8 | x | ||||
| 在 Term-Type 选项中接受任何名称 | 3.2.8 | x | ||||
| 实现 Binary、Suppress-GA 选项 | 3.3.3 | x | ||||
| Echo、Status、EOL、Ext-Opt-List 选项 | 3.3.3 | x | ||||
| 适当时实现 Window-Size 选项 | 3.3.3 | x | ||||
| 服务器发起模式协商 | 3.3.4 | x | ||||
| 用户可启用/禁用发起协商 | 3.3.4 | x | ||||
| Go-Ahead | ||||||
| 非 GA 服务器协商 SUPPRESS-GA 选项 | 3.2.2 | x | ||||
| 用户或服务器接受 SUPPRESS-GA 选项 | 3.2.2 | x | ||||
| 用户 Telnet 忽略 GA | 3.2.2 | x | ||||
| 控制功能 (Control Functions) | ||||||
| 支持 SE NOP DM IP AO AYT SB | 3.2.3 | x | ||||
| 支持 EOR EC EL Break | 3.2.3 | x | ||||
| 忽略不支持的控制功能 | 3.2.3 | x | ||||
| 用户、服务器丢弃紧急数据直到 DM | 3.2.4 | x | ||||
| 用户 Telnet 在 IP、AO、AYT 后发送"Synch" | 3.2.4 | x | ||||
| 服务器 Telnet 对 IP 回复 Synch | 3.2.4 | x | ||||
| 服务器 Telnet 对 AO 回复 Synch | 3.2.4 | x | ||||
| 用户 Telnet 发送 IP 时能刷新输出 | 3.2.4 | x | ||||
| 编码 (Encoding) | ||||||
| 在 NVT 模式下发送高位 | 3.2.5 | x | ||||
| 将高位作为奇偶校验位发送 | 3.2.5 | x | ||||
| 若向应用传递高位则协商 BINARY | 3.2.5 | x | ||||
| 始终加倍 IAC 数据字节 | 3.2.6 | x | ||||
| 在二进制模式下加倍 IAC 数据字节 | 3.2.7 | x | ||||
| 在二进制模式下遵守 Telnet 命令 | 3.2.7 | x | ||||
| 在二进制模式下使用行末、CR NUL | 3.2.7 | x | ||||
| 行末 (End-of-Line) | ||||||
| 服务器上的 EOL 与本地行末相同 | 3.3.1 | x | ||||
| ASCII 服务器接受 CR LF 或 CR NUL 作为 EOL | 3.3.1 | x | ||||
| 用户 Telnet 能发送 CR LF、CR NUL 或 LF | 3.3.1 | x | ||||
| ASCII 用户能选择 CR LF/CR NUL | 3.3.1 | x | ||||
| 用户 Telnet 默认模式为 CR LF | 3.3.1 | x | ||||
| 非交互式使用 CR LF 作为 EOL | 3.3.1 | x | ||||
| 用户 Telnet 接口 (User Telnet interface) | ||||||
| 输入与输出所有 7 位字符 | 3.4.1 | x | ||||
| 绕过本地操作系统的解释 | 3.4.1 | x | ||||
| 转义字符 | 3.4.1 | x | ||||
| 用户可设置转义字符 | 3.4.1 | x | ||||
| 用转义方式输入 8 位值 | 3.4.1 | x | ||||
| 可输入 IP、AO、AYT | 3.4.2 | x | ||||
| 可输入 EC、EL、Break | 3.4.2 | x | ||||
| 向用户报告 TCP 连接错误 | 3.4.3 | x | ||||
| 可选的非默认联系端口 | 3.4.4 | x | ||||
| 可指定: 发送 IP 时刷新输出 | 3.4.5 | x | ||||
| 可手动恢复输出模式 | 3.4.5 | x |