☰

为什么 `telnet` 缓冲 FTP 控制连接线路？

tag-icon • tag-icon ftp telnet
为什么 `telnet` 缓冲 FTP 控制连接线路？

RFC 1123 说

Implementors MUST NOT assume any correspondence between READ
boundaries on the control connection and the Telnet EOL
sequences (CR LF).

DISCUSSION:
    Thus, a server-FTP (or User-FTP) must continue reading
    characters from the control connection until a complete
    Telnet EOL sequence is encountered, before processing
    the command (or response, respectively).  Conversely, a
    single READ from the control connection may include
    more than one FTP command.

我想知道这个要求今天是否仍然适用。

我尝试了一下 Linux Netkit 的telnet命令（Ubuntu 附带的命令）。当我打开与 telnet 服务器的通信时，客户端对刷新数据非常偏执。telnet立即将按键转化为数据包并获取它们。

鉴于 FTP 位于 Telnet 之上，如果我telnet访问 FTP 服务器，我会期望出现同样的偏执行为。相反，telnet缓冲我的按键直到换行。它仅获取整个 FTP 命令数据包。仅当与 FTP 服务器通信时。

telnet既然存在上述要求，为什么还要费心为 FTP 缓冲字符呢？它甚至会缓冲超过 MTU 限制的字符（以及 TCP 层中的段）。

man telnet对这个话题保持沉默，我找不到 Netkit 的源代码。 （其中一个链接已损坏，另一个链接指向空存储库.）无论如何，man telnet都会说“源代码无法理解”，所以我对于在某个地方找到可以解释其基本原理的评论持悲观态度。

是否存在某种更新规范或实际约束使实现无法自由获取半完成的 FTP 命令？我缺少什么？

为什么telnetBuffer FTP要控制连接线路？

答案1

Telnet 有两种基本操作模式：线路模式和字符模式。默认模式始终为线路模式。然后，telnet 应用程序必须与远程服务器协商它可以支持什么和不能支持什么。这是通过称为 TELOPT 的系统和称为 IAC（解释为命令）的特殊字符 255 来完成的。

只有当两端都同意可以同时处理字符，甚至远端会回显接收到的字符时，链路才会处于传统的交互（非行缓冲）模式。

由于 FTP 并不意味着使用 telnet 进行手动交互，因此它不支持任何高级 telnet TELOPT 功能。因此字符模式永远无法协商。

这一切都在RFC854

相关内容