なぜ多くのインターネットプロトコルがテキストベースですか？

私が発見したことから、インターネット上を移動する非常に大量のプロトコルは、バイナリではなく「テキストベース」です。問題のプロトコルには、HTTP、SMTP、FTP（これはすべてテキストベースですか？）、WHOIS、IRCが含まれますが、これらに限定されません。

実際、これらのプロトコルの一部は、バイナリデータを送信する場合に、いくつかのフープを介してジャンプします。

これには理由がありますか？テキストベースのプロトコルは、同じ量の情報を送信するためにより多くのデータを送信する必要があるため、明らかに多少のオーバーヘッドがあります（以下の例を参照）。これを上回るメリットは何ですか？

することで、テキストベースの、私はプロトコルで使用される文字のほとんどが間にある意味0x20（スペース）と0x7E（~）のために使用される臨時の「speical文字」と非常に特殊な目的な改行、ヌル、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ビットでエンコードされたテキストは、データを配布するための基本的な手段によって破壊されないことを合理的に確信できます（ごく最近まで、一部の8ビットエンコードで電子メールを送信すると、受信者が切断されたメッセージを受け取ることが保証されましたが、

たとえば、telnetまたはFTPプロトコルの説明（最初のインターネットプロトコル、ネットワークのアイデアはリモートで「スーパーコンピューター」に接続し、ファイルを前後にシャッフルすることでした）を調べてみると、接続には多くの詳細な交渉が含まれていることがわかります私たちは制服として、

はい、バイナリは（少し）より効率的です。しかし、マシンとメモリー（およびネットワーク）は非常に大きくなったため、昔のビットスクリッピングは過去のものです（ほとんど）。そして、彼らの正しい考えの誰もが、既存のプロトコルをすべて取り除いてそれらをバイナリーのものに置き換えることを提案しないでしょう。また、テキストプロトコルは非常に便利なデバッグ手法を提供します。今日、Telnetサーバーをインストールすることはありません（リモート接続に暗号化されたSSHプロトコルを使用する方がよい）が、誤ったサーバーと「通信」して手掛かりを見つけるのに便利なTelnetクライアントを使用する必要があります。今日、あなたはおそらくnetcatまたはncatを使ってふざけているでしょう...

見落とされるかもしれない1つの利点は、実験する能力です。チューブの下にビットを押し込んでいる場合、に変換EHLOする0x18などのユーティリティを作成する必要があります。それを行う代わりに、単にメールサーバーにtelnetで接続し、送信EHLOして途中で待機することができます。

何もでコードを書くことから、この日および年齢であなたを防ぐことはありませんアセンブリまたはBrainf * ckを、あなたは非常によくそうすることによって、いくつかのビットを保存することがあります。ただし、コードを理解してやり取りできるように他の人に自分が何をしたかを正確に説明することは、そうするのが簡単ではありません。

プロトコルを使用する場合、ARPAnetまたはインターネットの始まりを使用していた当時のほとんどの人々は端末の背後に居心地が良いと感じていたため、ユーザーがそれらの使用方法を簡単に習得できることが重要です。

ちなみに、今日の企業でも同様の議論が行われています。JSONまたはBSON（JSONのバイナリ表現）にシリアル化する必要がありますか？BSONにシリアル化すると、オーバーヘッドがいくらか減りますが、BSONをJSONに、またはその逆に変換するためのトランスレーターが必要になります。何かが避けられない場合に人間がそのデータを読み取る必要があるためです。

多くのインターネットプロトコルがテキストベースであることはありません。実際、テキストベースのプロトコルは少数派だと思います。インターネットで見るほとんどすべてのテキストベースのプロトコルには、同じまたは類似のデータを送信するために人々が発明した少なくとも2つのバイナリプロトコルがあります。

しかし、インターネットトラフィックの大部分がテキストベースのプロトコルを使用しているのは事実です。この事実は、テキストよりも多くのバイナリプロトコルがあるが、バイナリよりもはるかに多くのテキストトラフィックがあると仮定した場合に興味深いです。これは、インターネットで成功しているプロトコルのほとんどがテキストベースであることを意味します。少数のアプリケーション（ビットトレントがその一例です）を除き、バイナリプロトコルは死にがちです。

インターネットの初期には、企業はバイナリプロトコル（たとえば、今日のMSN Webサイトではなく、HTTPに代わるものとされていた独自のMicroSoftネットワークではなくMSN）を設計して使用する傾向がありましたが、軍隊、研究機関、学者はテキストベースのプロトコルを設計および使用します。その理由の一部は、バイナリプロトコルの構築とデバッグが困難であり、軍隊、研究者、学者が暇なときに無料でそれを行っている間に、企業がそれを行うために人々に支払う余裕があることでした（インターネットを開発した人々のほとんどはインターネットの開発に関係のない仕事）。

週末に趣味としてコードを書いていて、自分がしたことに対してお金を払っていないときは、よりシンプルなソリューションであるテキストを選択する傾向があります。そのため、テキストベースのプロトコルは、バイナリプロトコルよりも多くの人々に使用されました。

しかし、それは完全な話ではありません。ネットワークの構築は困難です。とても大変。今日、私たちはインターネットに非常に慣れているため、エンジニアリングの奇跡が何であるかを完全には理解していません。インターネットのほぼすべての側面は、バグ修正から発展しました。たとえば、ルーティングテーブル用にテラバイトのRAMではなく、キロバイト（または最近はメガバイト）でルーターを構築できるため、MACアドレスの代わりにIPアドレスを使用します。解決しようとする問題が多ければ多いほど、それらをデバッグするためにテキストベースのプロトコルを好む傾向があります。低レベルのネットワークプロトコルの開発に十分な経験を積んだ後、アプリケーションプロトコルを開発するときが来たとき、経験豊富なプログラマやエンジニアのほとんどはテキストプロトコルを好む傾向がありました。

個人的な経験から、私はルーターを構築する会社で働いていました。また、テレメトリー機器を構築する会社で働いていたので、TCP / IP、ARP、IEC60870-5-などのバイナリプロトコルを使った多くの経験があります。 101およびDNP3。また、HTTP、POP3、NMEAなどのテキストプロトコルも使用しました。また、ASN.1などのバイナリデータ形式や、JSONやXMLなどのテキストデータ形式も使用しました。私が選択した場合、ほぼ毎回テキストを選択します。バイナリを選択するのは、プロトコルが本当に低レベル（テキストベースのプロトコルを上またはその上に突っ込むことができるように十分に実装する）またはデータが自然にバイナリ（オーディオファイルなど）である場合のみです。

構造化バイナリには、拡張の制限もあります。私がFidoNetで作業し、FidonetとUUCP / USNETの間にゲートウェイを構築していた頃、Fidonetのメッセージヘッダーは構造化されたバイナリでした。バイトをどこかに追加しようとするだけで拡張するということは、それを使用しようとしているすべてのものをそこに分割することを意味します。テキストヘッダーまたはプロトコルがあることは、何かを壊すことなく何かを拡張できることを意味します。

あなたの質問は3つの方法で解釈できます：

1. それは例えばで印刷されたかのように、なぜ数値データは、テキスト表現で送信されますかprintf()？
2. 従来のアプリケーション層プロトコル（ftp制御チャネル、smtp、httpなど）が伝統的にすべて7ビットASCII文字セットを使用するのはなぜですか？（7ビットASCIIは、ほとんどのバイトが印刷可能なグリフまたは改行やフィードからのテキスト制御コードに対応するため、「テキスト」と見なすことができます。）
3. バイナリデータの塊が、たとえばメールの添付ファイルとしてインターネット経由で送信されると、しばしば7ビットASCIIに変換されるのはなぜですか？

最初の答えは相互運用性です。整数と浮動小数点値は、異なるマシン、コンパイラー、さらには異なるコンパイラーオプションで異なるバイナリー表現を持ちます。これらを効果的に送信することによりprintf/scanf、相互運用性が容易になります。この選択は、上記で言及したいくつかの上位レベルのプロトコルに対してのみ行われたことに注意してください。ネットワーク層では、データはバイナリで送信されます。このために、TCP / IPはバイナリ整数表現を定義し、TCP / IPを実装するライブラリは、ホスト表現とネットワーク表現をhtonl友人と変換する手段を提供します。

2番目の質問に対する答えは、RFC 206（低い番号に注意してください-1971！）が直接テレタイプの置換として、多くのアプリケーション層プロトコルが基づいているtelnetプロトコルを説明していることです。

その機能は、オンラインシステムの端末を、ネットワーク内のテレタイプ互換のタイムシェアリングシステムに、そのシステムに直接接続されているかのように見せることです。

（元のテキストのエンファシス。）少なくとも一部のテレタイプ、特にテレタイプネットワークでは、文字セットとして7ビットASCIIを使用していたため、当然の選択になったはずです。

3番目の答えは、アプリケーション層プロトコルがtelnetベースであり、telnetが7ビットASCIIであるため、8ビットデータを処理するための多くのソフトおよびハードウェアが用意されていないということです。バイナリ添付ファイルの送信は、電子メールの誤用と見なされる可能性があります。したがって、フープ。今日では、これは通常もはや真実ではなく、プロトコルはバイナリデータを直接処理するために継続的に拡張（または単に使用）されています。