텔넷이 프로토콜로 간주되는 이유는 무엇입니까? 이것은 단순한 TCP 전송/에코 프로그램이 아닌가요?

텔넷이 프로토콜로 간주되는 이유는 무엇입니까? 이것은 단순한 TCP 전송/에코 프로그램이 아닌가요?

이것은 개념적인 질문에 가깝습니다. 설명이 좀 필요해요.


오늘 저는 소켓 프로그래밍을 배우고 간단한 채팅 서버와 채팅 클라이언트를 작성했습니다.Beej의 네트워크 프로그래밍 가이드. (채팅 서버는 클라이언트 메시지를 수신하고 다른 모든 클라이언트에게 메시지를 보냅니다)

복사했어요 채팅 서버내가 직접 썼어채팅 클라이언트.

채팅 클라이언트는 stdin서버에 입력을 보내고 서버에서 소켓 데이터를 인쇄하는 프로그램일 뿐입니다.

telnet그러다가 서버에 연결하는 데만 사용할 수 있다는 가이드를 발견했습니다 . 나는 그것을 시도했고 효과가 있었다.


저는 텔넷을 처음 접했고 그것이 실제로 무엇인지 오랫동안 몰랐습니다.

이제 내 경험으로 인해 혼란스러워졌습니다.

텔넷은 단순한 TCP 전송/에코 프로그램이 아닌가요? 무엇이 그것을 그렇게 특별하게 만드는가?규약물건? 내 멍청한 채팅 클라이언트 프로그램은 [application] 프로토콜을 생성하지 않습니다.

위키피디아에서규약:

통신에서 통신 프로토콜은 시스템입니다.규칙 두 개 이상의 개체가 모든 유형의 물리량 변화를 통해 정보를 전송할 수 있도록 하는 통신 시스템입니다.

Telnet은 어떤 규칙을 생성합니까? telnet host port, 원시 입력/출력을 위해 TCP 스트림 소켓을 열까요? 이것은 규칙이 아닙니다.

답변1

텔넷은 다음에 정의되어 있습니다.RFC 854. 프로토콜을 비롯한 모든 것을 프로토콜로 만드는 것은 일련의 규칙/제약 사항입니다. 규칙 중 하나는 Telnet이 TCP를 통해 수행되고 포트 23이 할당된다는 것입니다. 이는 사소해 보일 수 있지만 어딘가에 지정해야 합니다.

원하는 것을 보낼 수는 없으며 일부에는 제한 사항과 특별한 의미가 있습니다. 예를 들어 "네트워크 가상 터미널"을 정의합니다. 이는 텔넷이 설정되면 프린터, 흑백 모니터, ANSI 코드를 지원하는 컬러 모니터 등 다양한 터미널이 있을 수 있기 때문입니다.

또한 다음과 같은 것도 있습니다.

요약하자면, 모든 당사자는 옵션 XXX, DO XXX 및 DON'T 실행을 시작하기를 원함(제안)을 나타내기 위해 WILL XXX를 보내 옵션 XXX, WILL XXX 및 WON'T XXX의 요청(요청) 실행을 시작합니다. 긍정적이고 부정적인 확인. NVT는 옵션이 활성화되지 않은 경우 남아 있는 것이므로 DON'T 및 WON'T 응답은 양쪽 끝이 처리할 수 있는 상태로 연결을 유지하도록 보장됩니다. 따라서 모든 호스트는 지원되지 않는 옵션을 전혀 인식하지 못하고 이해되지 않는 옵션 요청에 대해 거부(즉, 거부)를 반환하도록 TELNET 프로시저를 구현할 수 있습니다.

현대에는 이러한 것의 대부분이 더 이상 중요하지 않습니다(다시 말하지만, 프로토콜로서의 텔넷은 보안이 부족하기 때문에 더 이상 널리 사용되지 않습니다). 따라서 실제로는 보내기/에코로 귀결됩니다. 실제로 터미널과 상호작용해야 하는 경우가 아니라면 말이죠.

답변2

두 터미널을 연결할 때 "그냥 작동한다"는 사실 telnet자체가 프로토콜 결정입니다. 설계자는 telnetTCP 연결의 양쪽 끝에 "네트워크 가상 터미널"이 있는 모델을 사용하기로 결정하고 이러한 가상 터미널 기능을 기반으로 모델링하기로 결정했습니다. 터미널(실제로는 텔레타이프)입니다.

그 외에도 telnet이는 단순한 TCP 기반 에코 서비스 그 이상입니다. 다양한 목적으로 대역 내로 전송되는 제어 코드를 지원합니다. 프로그래밍되어 있어요RFC 854.

답변3

서브시스템라고"원격 로그인"이것이라고 제안네트워크 시스템 프리미티브를 둘러싼 쉘 프로그램, 원격 호스트의 텔레타이프 또는 유사한 터미널이 서비스 호스트에서 텔레타이프 역할을 할 수 있도록 허용합니다.

이는 Wikipedia "telnet"에 언급된 RFC 15에서 가져온 것입니다. 이 기사에서는 먼저 텔넷을 "애플리케이션규약".

RFC 15는 1969년 9월에 출시되었습니다. 불과 며칠 전에 저는 정확히 50년 전 최초의 "인터넷" 커넥터 중 하나와의 흥미로운 인터뷰를 들었습니다. 그의 이야기는 이렇습니다.

"N. Armstrong과 다르게 우리는 특별한 메시지를 기대하지 않았습니다. 그러나 "lo"("login")를 입력한 후 시스템이 충돌했습니다. 그래서 돌이켜보면 "lo"("lo and behold"에서와 같이)가 처음 두 개였습니다. , 우리는 더 나은 것을 생각할 수 없습니다."

(다음은 인터뷰 내용의 일부입니다.Wiki.apa.net 클라인록)


텔넷은 TCP/IP보다 우선합니다. RFC 15는 "네트워크 프리미티브"에 대해 설명합니다. TCP/IP 이후 텔넷은 "나머지"인 응용 프로그램 계층(RFC854의 "협상 옵션")만 처리합니다.

예, 텔넷은 TCP가 없어도 매우 간단합니다. RFC 15는 다음으로 끝납니다.

TELNET 하위 시스템은 "레벨 0" 네트워크 프로그램을 구성하며 곧 능가할 것입니다. 그러나 매우 간단하고 빠르게 작동합니다.


"프로토콜"은 본질적으로 두 개의 (다른) 시스템이 하나의 "언어"를 사용하여 통신해야 하기 때문에 텔넷과 함께 사용됩니다.

RFC 854에서도 이 개념을 설명합니다.

TELNET 프로토콜은 세 가지 주요 아이디어를 바탕으로 구축되었습니다.네트워크 가상 터미널"...


답변4

기존 답변에서는 telnetTCP를 통해 입력 데이터를 변경하지 않고 스트리밍하는 것 이상의 작업을 수행할 수 있다고 이미 설명했습니다. "내 멍청한 채팅 클라이언트 프로그램이 [응용 프로그램] 프로토콜을 생성하지 않습니다"에 초점을 맞추고 싶습니다. - 문제의 일부. (BTW, 실제 "TCP를 통한 원시 데이터"의 경우 netcat대신 사용할 수 있습니다 telnet)

프로토콜이 단순하거나 나쁘거나 심지어 명시적으로 지정되지 않았다고 해서 그것이 프로토콜이 아니라는 의미는 아닙니다. 두 시스템은 프로토콜이 "TCP를 통한 원시 데이터"일지라도 합의된 프로토콜 없이는 통신할 수 없습니다. 한쪽 끝에서는 FTP를 사용하고 다른 쪽 끝에서는 HTTP를 사용하려고 하면 어느 쪽이든 문제가 발생할 수 있습니다. 운이 좋으면 작동하지 않고, 운이 좋으면 작동하지 않습니다. 이렇게 하지 않으면 잘못된 행동을 하게 됩니다. (적어도 HTTP 서버와 동일한 호스트의 비표준 포트에서 FTP 데몬을 실행하는 경우 일부 브라우저에서는 이를 사용하여 XSS를 수행하고 피해자의 브라우저가 CSRF를 우회하도록 지정할 수 있었습니다. 오류 메시지에 POST 내용을 표시하는 FTP 서버에 POST를 수행하여 보호합니다. 이 내용은 브라우저가 HTTP/0.9 응답으로 해석하고 모든 자바스크립트를 실행합니다.

my dumb chat client program"당신이 말하는 것은 어떤 프로토콜을 사용합니까? 내 프로그램을 통해 그것에 대해 이야기하고 싶습니다"는 완벽하게 유효한 질문입니다. 가능한 대답 중 하나는 "TCP를 통한 원시 데이터"입니다. 그러나 이것이 완전한 답변은 아닙니다.

  • 기본 포트가 있는 경우 이것이 대답의 일부일 것입니다.
  • 매우 명확하게 하고 싶다면 "TCP 비상/대역 외 데이터가 아닌 일반 TCP 데이터"를 의미한다고 명시할 수 있습니다. (이는 말이 안 되기 때문에 약간 과장된 것입니다. 내가 본 바로는 세 번째 그룹 fd가 select()잘못된 인원수라고 생각합니다. 대부분의 사람들은 대역 외 데이터가 존재한다는 사실조차 모르는 것 같습니다. 하지만 그것도 나쁜 예입니다. 제가 이해해 주시길 바랍니다. 평균)
  • 당신이 생각하지 못한 것조차도 암묵적으로 프로토콜의 일부일 수 있습니다. 연결을 어떻게 닫나요? 그냥 호출하시겠습니까, 아니면 대기 중인 모든 데이터가 먼저 전달되도록 close()사용하시겠습니까 ?shutdown()

"원시 입력/출력을 위해 TCP 스트림 소켓을 여나요? 그건 규칙이 아닙니다."라고 말하지만 실제로 그런가요? "TCP를 사용해야 합니다", "데이터를 있는 그대로 보내야 합니다", "XXX 포트를 사용해야 합니다"는 제게는 규칙처럼 들립니다.

(PS, 이 글을 쓰는 동안 저는 약간 집착했습니다. 이 답변의 나머지 부분은 주제에서 약간 벗어났으며 "좋아, 모든 것이 프로토콜입니다. 이것이 어떤 영향을 미치나요?"라는 자연스러운 후속 질문에 대답하려고 시도합니다. )

따라서 두 시스템이 서로 통신하도록 할 때마다 기존 프로토콜을 사용하거나 새 프로토콜을 생성한다는 점을 기억하십시오. 너무 늦기 전에 프로토콜을 문서화하십시오! (즉, 늦어도 프로토콜이 더 이상 단순하지 않게 되거나 개발자보다 사용자가 많아지기 시작할 때) 많은 초기 P2P 프로토콜에서는 "공식 클라이언트의 소스는 문서"라고 했는데, 이는 복잡한 프로젝트에서는 매우 짜증나는 일이며, 클라이언트는 미묘하게 다른 프로토콜을 사용하고 모든 곳에서 호환되지 않게 됩니다.

"생산하는 것에 엄격하고 받는 것에 느슨하게 하라"라는 오래된 격언이 있습니다. 핵심 요점은 좋지만 솔직히 적어도 그것이 적용되는 방식은 헛소리이며 유지 관리성과 호환성 문제를 더 많이 초래한다고 생각합니다. 나는 구체적으로 말하고(모든 경우를 고려하려고 노력하고) 생성하고 수용하는 것에 대해 극도로 엄격해야 합니다. 그러면 실제 버그를 방지/해결할 수 있을 것입니다.

엄격한 해결 버그의 예: 몇 년 전 특정 BitTorrent 추적기에 문제가 발생하기 시작했습니다. 토렌트 중 일부가 특정 클라이언트에서 실행되지 않았습니다. 클라이언트는 불평하지 않았고 단지 정보의 다른 해시를 얻었을 뿐이었습니다. 발견된 씨앗. 그들은 무슨 일이 일어나고 있는지 알 수 없었고 영향을 받은 클라이언트에 뭔가 문제가 있을 것이라고 선언했습니다. 사용을 중지하십시오. Bittorrent는 매우 엄격하고 모호하지 않은 Bencoding을 사용합니다. 동일한 입력은 항상 정확히 동일한 인코딩된 출력 문자열을 생성하므로 [info] 해시는 동일한 입력 데이터에 대해 항상 동일합니다. 이 토렌트 중 하나를 처음 접했을 때 나는 그것을 내 자신의 (매우 엄격한) 파서에 입력하려고 시도했고 즉시 다음과 같이 말했습니다 Error: Bencoded dictionary keys not sorted (last='sha1', key='private').

그래서 무슨 일이 일어났나요? 추적기는 업로드된 모든 토렌트에 "개인" 키를 자동으로 추가하기 시작하지만 벤코딩이 지정한 대로 사전 키를 정렬하는 대신 끝에 추가합니다. 생성되는 내용은 엄격하지 않습니다. 일부 클라이언트는 토렌트를 부분적으로만 디코딩하고 디코딩되지 않은 변경되지 않은 문자열의 해시를 계산합니다. 일부 클라이언트는 전체 토렌트를 디코딩하고 해시가 필요한 부분을 다시 인코딩하여 프로세스에서 키를 올바르게 정렬하고(유효한 벤코딩 생성) 다른 해시를 얻습니다. 내가 알고/기억하는 한, 유효하지 않은 데이터에 대해 불만을 제기한 고객은 없습니다. 고객은 어떤 데이터를 허용하는지에 대해 엄격하지 않습니다. 그렇다면 어떤 해시가 맞나요? 어느 것도 아니다! 해시를 계산하는 두 가지 방법 모두 정확하지만 토렌트 파일이 손상되었습니다! 고객 중 한 명이 불만을 제기하더라도 버그는 몇 달이 아니라 당일 수정될 가능성이 높습니다. (IIRC에서도 몇 년 후 전혀 관련이 없는 다른 추적기에서 동일한 버그를 보고했습니다. 첫 번째 추적기의 소프트웨어는 사내에서 개발되었으므로 동일한 코드베이스도 아니었습니다.)

이번에는 특수한 경우에 대한 또 다른 예입니다. eDonkey2000 P2P 프로토콜은 ed2k라는 사용자 정의 해시를 사용합니다. 사양에서는 입력 데이터 길이가 블록 크기로 나누어지는 특수한 경우의 동작을 지정하지 않으므로 두 개의 호환되지 않는 변형이 생성됩니다. 특정 파일에 대해 다른 해시를 생성하고 호환되지 않습니다. ("사양"이라고 말하지만 초기 P2P 프로토콜이기 때문에 사양이 없다고 확신합니다. 프로토콜을 리버스 엔지니어링할 때 특별한 경우가 누락될 수 있습니다)

자세한 사양의 필요성에 대해: 프로토콜용 클라이언트나 파일 형식용 파서를 작성하려고 할 때 원래 프로그래머조차 특정 데이터가 실제로 어떻게 인코딩되는지 모르는 상황에 직면한 적이 많습니다. 그 때문에 일부 라이브러리를 사용해 봤지만 실제로 어떤 용도로 사용되는지 자세히 확인하지 않았습니다. 두 가지 예:

API는 암호화된 [가변 길이] 패킷과 함께 사용자 정의 UDP 프로토콜을 사용합니다. 문서에서는 AES128을 지정하지만 사용된 패딩에 대해서는 언급하지 않습니다. 이에 대해 개발자들이 물었을 때, 그들의 대답은 다음과 같았습니다.

글쎄, 우리는 실제로 알지 못합니다. 우리는 이 Java 라이브러리에서 이 함수를 사용했으며 문서에는 어떤 패딩을 사용하는지 언급하지 않은 것 같습니다.

한 장치의 웹사이트에는 파일 저장 인터페이스에 대해 다음과 같은 내용이 나와 있습니다.

저장된 *.logicdata 파일은 생성하거나 수정할 수 없습니다. 이는 이러한 파일이 부스트 바이너리 직렬화를 통해 생성되고 매우 복잡한 개체 구조를 포함하기 때문입니다. 사실, 우리는 그것이 어떻게 작동하는지조차 이해하지 못합니다. Boost 직렬화는 매우 복잡합니다.

(참고: 그러나 실제로는 데이터를 내보낼 만큼 충분한 파일 형식을 리버스 엔지니어링하는 데 그리 오랜 시간이 걸리지 않습니다.)

일부 예는 인코딩, 파일 형식 또는 사용자 정의 알고리즘에 관한 것이지만(마지막 것을 제외하고 프로토콜에서 여전히 내부적으로 사용되지만) 모두 적용된다고 말하고 싶습니다. 프로토콜, 파일 형식, 인코딩 또는 사용자 정의 알고리즘에 관해 이야기하는 경우:

  • 좋은 스펙을 작성하고 잘 문서화하세요
    • 모든 극단적인 경우를 고려해보세요
    • 모든 필수 세부정보를 포함시키세요.
  • 규정을 엄격히 따르다/엄격히

관련 정보