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.
이 요구 사항이 오늘날에도 여전히 적용되는지 궁금합니다.
telnet
Linux Netkit 명령(Ubuntu와 함께 제공되는 명령)을 사용해 보았습니다 . 텔넷 서버와의 통신을 열 때 클라이언트는 데이터 플러시에 대해 매우 편집증적입니다. telnet
키 입력을 즉시 패킷으로 변환하여 가져옵니다.
FTP가 Telnet 위에 있다는 점을 감안할 때 telnet
FTP 서버에 액세스하면 동일한 편집증적인 동작이 예상됩니다. 대신 telnet
새 줄이 나올 때까지 키 입력을 버퍼링합니다. 전체 FTP 명령 패킷만 가져옵니다. FTP 서버와 통신하는 경우에만 해당됩니다.
telnet
위의 요구 사항을 고려할 때 왜 FTP에 문자 버퍼링을 해야 할까요? MTU 제한을 초과하는 문자(및 TCP 계층의 세그먼트)도 버퍼링합니다.
man telnet
이 주제에 대해 침묵을 지켰기 때문에 Netkit의 소스 코드를 찾을 수 없습니다. (링크 중 하나가 끊어지고 다른 링크는 빈 저장소를 가리킵니다..) 어쨌든 man telnet
"소스 코드를 이해할 수 없습니다"라고 되어 있어서, 그 근거를 설명하는 코멘트를 어딘가에서 찾는 것이 비관적입니다.
구현이 절반만 완료된 FTP 명령을 자유롭게 가져오는 것을 방지하는 일부 업데이트 사양이나 실제 제약 조건이 있습니까? 내가 무엇을 놓치고 있나요?
telnet
버퍼 FTP가 연결 회선을 제어하는 이유는 무엇 입니까?
답변1
텔넷에는 라인 모드와 문자 모드라는 두 가지 기본 작동 모드가 있습니다. 기본 모드는 항상 회선 모드입니다. 그런 다음 텔넷 응용 프로그램은 지원 가능한 것과 지원 불가능한 것을 원격 서버와 협상해야 합니다. 이는 TELOPT라는 시스템과 IAC(명령으로 해석됨)라는 특수 문자 255를 통해 수행됩니다.
링크는 양쪽 끝이 동시에 문자를 처리할 수 있다고 동의하거나 심지어 맨 끝이 수신된 문자를 에코하는 경우에만 전통적인 대화형(비라인 버퍼) 모드에 있습니다.
FTP는 텔넷을 사용한 수동 상호 작용을 위한 것이 아니기 때문에 고급 텔넷 TELOPT 기능을 지원하지 않습니다. 따라서 캐릭터 모드는 절대로 협상될 수 없습니다.
다 거기 있어RFC854