왜 많은 인터넷 프로토콜이 텍스트 기반입니까?

내가 찾은 것에서 인터넷을 통해 이동 하는 매우 많은 양의 프로토콜은 이진이 아니라 "텍스트 기반"입니다. 해당 프로토콜에는 HTTP, SMTP, FTP (이것이 모두 텍스트 기반이라고 생각하십니까?), WHOIS, IRC가 포함됩니다.

실제로이 프로토콜 중 일부는 이진 데이터를 전송하려고 할 때마다 일부 후프를 뛰어 넘습니다 .

이것 뒤에 이유가 있습니까? 텍스트 기반 프로토콜은 동일한 양의 정보를 전송하기 위해 더 많은 데이터를 전송해야하기 때문에 약간의 오버 헤드가 있습니다 (아래 예 참조). 이보다 더 큰 이점은 무엇입니까?

하여 텍스트 기반 , 내가 프로토콜에 사용되는 문자의 대부분이 사이 평균 0x20(공간)과 0x7E( ~)에 사용되는 가끔 "테이지 스페셜 캐릭터"와 아주 특별한 목적을 같은 줄 바꿈, 널 (null), ETX 및 EOT 등. 이것은 연결을 통해 원시 이진 데이터를 전송하는 것과 반대입니다.

예를 들어, 정수 123456를 텍스트로 전송하면 문자열 전송 123456(16 진수로 표시 31 32 33 34 35 36)이 포함되지만 32 비트 이진 값은 16 진수로 표시되고 0x0001E240(보시다시피 특수 널 문자를 "포함"합니다. .

세계가 어렸을 때 컴퓨터가 모두 영광스러운 PC가 아니었을 때, 단어 크기는 다양했으며 (여기서 DEC 2020은 36 비트 단어를 가짐), 이진 데이터의 형식은 논쟁적인 문제였습니다 (빅 엔디안 대 리틀 엔디안, 심지어 더 이상 함) 비트 순서는 합리적으로 일반적이었습니다). 문자 크기 / 인코딩에 대한 합의는 거의 없었습니다 (ASCII, EBCDIC가 주요 경쟁자였으며 DEC는 5/6/7/8 비트 / 문자 인코딩을 가졌습니다). ARPAnet (인터넷 선임자)은 모든 설명의 컴퓨터를 연결하도록 설계되었습니다. 공통 분모는 텍스트였습니다. 7 비트로 인코딩 된 텍스트가 데이터를 전달하기위한 기본 수단에 의해 엉망이되지 않을 것이라 확신 할 수 있습니다.

예를 들어 텔넷 또는 FTP 프로토콜 설명 (첫 번째 인터넷 프로토콜, 네트워크 아이디어는 원격으로 "슈퍼 컴퓨터"에 연결하고 파일을 셔플하는 것)에서 뒤죽박죽이는 경우 연결에 많은 세부 사항 협상이 포함되어 있음을 알 수 있습니다 우리는 유니폼을 입고

예, 이진은 조금 더 효율적입니다. 그러나 기계와 메모리 (및 네트워크)도 엄청나게 커졌기 때문에 요어의 비트 스크림은 과거의 일입니다 (주로). 그리고 올바른 생각을 가진 사람은 기존의 모든 프로토콜을 제거하여 이진 프로토콜로 대체 할 것을 제안하지 않습니다. 또한 텍스트 프로토콜은 매우 유용한 디버깅 기술을 제공합니다. 현재 는 텔넷 서버를 설치 하지 않지만 (원격 연결에 암호화 된 SSH 프로토콜을 사용하는 것이 좋습니다), 잘못된 서버를 "통화하여"문제를 파악하기 위해 텔넷 클라이언트를 사용해야합니다. 오늘은 아마 캣팅을 위해 netcat 또는 ncat 을 사용할 것입니다 ...

간과 될 수있는 한 가지 장점은 실험 능력 입니다. 튜브 아래로 비트를 밀어 EHLO넣는 경우 0x18, 그와 유사한 것으로 번역 되는 유틸리티를 작성해야합니다 . 그렇게하는 대신 간단히 메일 서버에 텔넷으로 연결하여 보내고 나갈 수 있습니다 EHLO.

이 시대와 그 어느 때에도 Assembly 또는 Brainf * ck 코드를 작성하는 데 방해가되지 않으며 그렇게함으로써 약간의 비트를 절약 할 수 있습니다. 그러나 코드를 이해하고 상호 작용할 수 있도록 다른 사람에게 정확히 한 일을 설명하는 것은 쉬운 일이 아닙니다.

ARPAnet 을 사용 하던 시절 이나 인터넷이 시작된 대부분의 사람들이 터미널 뒤에서 편안하다고 느끼는 사람들이 있었기 때문에 프로토콜을 사용하면 사용자가 프로토콜 사용법을 쉽게 배울 수 있어야합니다 .

그건 그렇고 오늘날에도 비슷한 주장이 회사에서 개최됩니다. JSON 또는 BSON (JSON의 이진 표현)으로 직렬화해야합니까 ? BSON으로 직렬화하면 약간의 오버 헤드가 발생하지만 불가피하게 잘못 될 때 인간이 특정 시점에서 데이터를 읽어야하기 때문에 이제 BSON을 JSON으로 변환하거나 그 반대로 변환하는 변환기가 필요합니다.

많은 인터넷 프로토콜이 텍스트를 기반으로하는 것은 아닙니다. 사실, 내가 추측한다면 텍스트 기반 프로토콜이 소수라고 말할 것입니다. 인터넷에서 볼 수있는 거의 모든 텍스트 기반 프로토콜에는 사람들이 동일하거나 유사한 데이터를 전송하기 위해 발명 한 이진 프로토콜이 두 개 이상 있습니다.

그러나 대부분의 인터넷 트래픽 은 텍스트 기반 프로토콜을 사용합니다. 텍스트보다 이진 프로토콜이 많지만 이진보다 더 많은 텍스트 트래픽이 있다고 가정하면이 사실은 흥미 롭습니다. 인터넷 에서 성공한 프로토콜의 대부분 은 텍스트 기반 이라는 것을 의미합니다 . 소수의 응용 프로그램 (비트 토렌트가 하나의 예)을 제외하고 이진 프로토콜은 죽는 경향이 있습니다.

인터넷 초창기, 기업들은 바이너리 프로토콜 (예 : 오늘날 MSN 웹 사이트가 아닌 MSN, HTTP를 대체해야했던 독점적 MicroSoft 네트워크가 아닌 MSN)을 설계하고 사용하는 경향이 있었지만 군대, 연구소 및 학자들은 텍스트 기반 프로토콜을 디자인하고 사용합니다. 그 이유 중 하나는 바이너리 프로토콜을 구축하고 디버깅하는 것이 어려웠으며 기업은 사람들이 지불 할 비용을 지불 할 수있는 반면 군대, 연구원 및 학자는 여가 시간에 무료로 지불했습니다 (인터넷을 개발 한 사람들은 대부분 인터넷 개발과 관련이없는 직업).

주말에 취미로 코드를 작성하고 자신이하는 일에 대한 대가를 치르지 않을 때는 더 간단한 솔루션 인 텍스트를 선택하는 경향이 있습니다. 따라서 텍스트 기반 프로토콜은 이진 프로토콜보다 많은 사람들이 사용했습니다.

그러나 그것은 전체 이야기가 아닙니다. 네트워크 구축이 어렵습니다. 정말 열심히. 우리는 오늘날 인터넷에 너무 익숙하여 엔지니어링의 기적이 무엇인지 완전히 알지 못합니다. 인터넷의 거의 모든 측면이 버그 수정에서 발전했습니다. 예를 들어, 라우팅 테이블에 테라 바이트의 RAM 대신 킬로바이트 (또는 요즘 메가 바이트)로 라우터를 구축 할 수 있으므로 MAC 주소 대신 IP 주소를 사용합니다. 점점 더 많은 문제를 해결하려고할수록 텍스트 기반 프로토콜을 선호하는 경향이 있습니다. 저수준 네트워크 프로토콜 개발에 충분한 경험이 있으면, 응용 프로그램 프로토콜을 개발할 시간이되었을 때 숙련 된 프로그래머와 엔지니어 대부분은 텍스트 프로토콜을 선호하는 경향이있었습니다.

개인적인 경험으로, 라우터를 만드는 회사에서 일했고, 텔레 메 트리 장비를 만드는 회사에서 일하기도했기 때문에 TCP / IP, ARP, IEC60870-5- 101 및 DNP3. 또한 HTTP, POP3 및 NMEA와 같은 텍스트 프로토콜로 작업했습니다. 또한 ASN.1과 같은 이진 데이터 형식과 JSON 및 XML과 같은 텍스트 데이터 형식으로 작업했습니다. 내가 선택한다면 거의 매번 텍스트를 선택할 것입니다. 바이너리를 선택하는 유일한 시간은 프로토콜이 실제로 저수준 (텍스트 기반 프로토콜을 맨 위에 놓을 수 있도록 구현하거나 오디오 파일과 같이 자연스럽게 바이너리 인 경우)입니다. .

구조적 바이너리도 확장에 한계가 있습니다. FidoNet과 함께 일하고 UUCP / USNET 사이에 게이트웨이를 구축하던 시절, Fidonet의 메시지 헤더는 구조화 된 바이너리였습니다. 바이트를 추가하려고해도 확장하면 작업하려고하는 모든 것을 깨뜨릴 수 있습니다. 텍스트 헤더 또는 프로토콜이 있다는 것은 침입하지 않고 무언가를 확장 할 수 있음을 의미합니다.

질문은 세 가지 방식으로 해석 될 수 있습니다.

1. 숫자 데이터가 예를 들어 printf()?
2. ftp 제어 채널, smtp, http와 같은 기존 응용 프로그램 계층 프로토콜이 전통적으로 7 비트 ASCII 문자 집합을 사용하는 이유는 무엇입니까? 대부분의 바이트는 인쇄 가능한 글리프 또는 줄 바꿈 및 피드와 같은 텍스트 제어 코드에 해당하므로 7 비트 ASCII는 "텍스트"로 간주 될 수 있습니다.
3. 이진 데이터 Blob이 인터넷을 통해 전송 될 때 (예 : 메일 첨부 파일) 종종 7 비트 ASCII로 변환되는 이유는 무엇입니까?

첫 번째 답변은 상호 운용성입니다. 정수와 부동 소수점 값은 다른 기계 또는 컴파일러에서 또는 다른 컴파일러 옵션으로 다른 이진 표현을 갖습니다. 이를 통해 효과적으로 전송 printf/scanf하면 상호 운용성이 쉬워집니다. 이 선택은 위에 언급 된 몇 가지 상위 레벨 프로토콜에 대해서만 수행되었습니다. 네트워크 계층에서 데이터는 이진으로 전송된다. 이를 위해 TCP / IP는 이진 정수 표현을 정의하고 TCP / IP를 구현하는 라이브러리는 호스트와 네트워크 표현을 htonl친구들 과 변환하는 수단을 제공합니다 .

두 번째 질문에 대한 답은 아마도 RFC 206 (낮은 숫자 — 1971!)은 많은 텔레 그램 프로토콜을 기반으로하는 텔넷 프로토콜을 직접 텔레타이프 대체로 설명한다는 것입니다.

이 기능은 온라인 시스템 터미널 이 마치 마치 해당 시스템에 직접 연결된 것처럼 네트워크의 모든 텔레타이프 호환 시간 공유 시스템에 표시 되도록하는 것입니다 .

(원본 텍스트의 느낌표) 최소한 일부 텔레타이프 및 특히 텔레타이프 네트워크 는 7 비트 ASCII 를 문자 세트로 사용하여 자연스럽게 선택 했어야합니다.

세 번째 방법은 단순히 응용 계층 프로토콜이 텔넷 기반이고 텔넷이 7 비트 ASCII이기 때문에 8 비트 데이터를 처리 할 소프트웨어 및 하드웨어 가 많지 않다는 것 입니다. 이진 첨부 파일을 보내는 것은 전자 메일 오용으로 간주 될 수 있습니다. 따라서 후프. 오늘날은 일반적으로 더 이상 사실이 아니며 프로토콜은 이진 데이터를 직접 처리하기 위해 지속적으로 확장되거나 사용됩니다.