☰

`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.

この要件が今日でもまだ適用されているかどうか疑問に思います。

telnetLinux Netkitコマンド（Ubuntuに付属のコマンド）を試しました。 Telnetサーバーとの通信を開くと、クライアントはデータフラッシュに対して非常に編集的です。telnetキーストロークをすぐにパケットに変換して取得します。

FTPがTelnetの上にあることを考えると、telnetFTPサーバーにアクセスすると同じ編集可能な動作が予想されます。代わりに、telnet新しい行が出るまでキーストロークをバッファリングします。完全なFTPコマンドパケットのみを取得します。 FTPサーバーと通信する場合にのみ該当します。

telnet上記の要件を考えると、なぜFTPに文字バッファリングが必要なのですか？ MTU制限を超える文字（およびTCP層のセグメント）もバッファリングします。

man telnetこのトピックについて沈黙を守ったため、Netkitのソースコードが見つかりませんでした。 （リンクの1つが壊れ、他のリンクが空のストレージを指します。とにかくman telnet「ソースコードを理解できません」とされていて、その根拠を説明するコメントをどこかで見つけるのが悲観的です。

実装が半分だけ完了したFTPコマンドを自由に取得するのを防ぐいくつかのアップデート仕様や実際の制約がありますか?私は何を見逃していますか？

telnetバッファFTPが接続回線を制御する理由は何ですか？

答え1

Telnetには、ラインモードとキャラクタモードという2つの基本的な動作モードがあります。デフォルトモードは常に回線モードです。その後、Telnetアプリケーションは、サポート可能なものとサポートできないものをリモートサーバーとネゴシエートする必要があります。これは、TELOPTというシステムとIAC（コマンドとして解釈される）という特殊文字255を介して行われます。

リンクは、両端が同時に文字を処理できることに同意する場合、または一端が受信した文字をエコーする場合にのみ、従来の対話型（非ラインバッファ）モードにあります。

FTPはTelnetを使用した手動対話のためではないため、高度なTelnet TELOPT機能をサポートしていません。したがって、キャラクターモードは決して交渉できません。

すべてそこにいるRFC854

関連情報