為什麼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 命令？我錯過了什麼？

為什麼telnet緩衝 FTP 控制連接線？

Telnet 有兩種基本的操作模式：線路模式和字元模式。預設模式始終為線路模式。然後，telnet 應用程序必須與遠端伺服器協商它可以支持和不支持的內容。這是通過一個稱為 TELOPT 的系統和稱為 IAC - Interpret As Command 的特殊字元 255 完成的。

只有當兩端都同意他們可以一次做字元，甚至遠端端將回顯接收到的字元時，連結才會處於傳統的互動（非行緩衝）模式。

由於 FTP 並不意味著使用 telnet 手動互動，因此它不支持任何高級 telnet TELOPT 功能。因此，永遠無法協商字元模式。

所有這些都在rfc854中

引用自：https://unix.stackexchange.com/questions/248868