web-dev-qa-db-ja.com

バイナリプロトコルv。テキストプロトコル

誰がバイナリプロトコルとは何かについて良い定義を持っていますか？そして実際にテキストプロトコルとは何ですか？ワイヤで送信されるビットの点で、これらはどのように比較されますか？

ウィキペディアのバイナリプロトコルについての説明は次のとおりです。

バイナリプロトコルは、人間ではなくマシンによって読み取られることを意図または期待されるプロトコルです（ http://en.wikipedia.org/wiki/Binary_protocol ）

おいおい！

もっと明確にするために、jpgファイルがある場合、それはバイナリプロトコルを介してどのように送信され、テキストプロトコルを介してどのように送信されますか？もちろん、ワイヤで送信されるビット/バイトの観点から。

1日の終わりに文字列を見ると、それ自体がバイトの配列であるため、2つのプロトコルの区別は、実際のデータがワイヤで送信されているものに依存するはずです。つまり、初期データ（jpgファイル）が送信前にどのようにエンコードされるかについて。

textbinaryprotocols
77
der_grosse

バイナリプロトコルとテキストプロトコルは、実際にはバイナリBLOBのエンコード方法に関するものではありません。違いは、プロトコルがデータ構造またはテキスト文字列のどちらに向けられているかです。例を挙げましょう：HTTP。 HTTPはテキストプロトコルです。jpegイメージを送信する場合でも、テキストエンコードではなく、生のバイトのみを送信します。

しかし、HTTPをテキストプロトコルにしているのは、getへの交換がjpgのように見えることです：

要求：

GET /files/image.jpg HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.01 [en] (Win95; I)
Host: hal.etc.com.au
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8

応答：

HTTP/1.1 200 OK
Date: Mon, 19 Jan 1998 03:52:51 GMT
Server: Apache/1.2.4
Last-Modified: Wed, 08 Oct 1997 04:15:24 GMT
ETag: "61a85-17c3-343b08dc"
Content-Length: 60830
Accept-Ranges: bytes
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/jpeg

<binary data goes here>

これは、非常に簡単に（Cで）次のように見える構造に非常に緊密にパックできることに注意してください。

要求：

struct request {
  int requestType;
  int protocolVersion;
  char path[1024];
  char user_agent[1024];
  char Host[1024];
  long int accept_bitmask;
  long int language_bitmask;
  long int charset_bitmask;
};

応答：

struct response {
  int responseType;
  int protocolVersion;
  time_t date;
  char Host[1024];
  time_t modification_date;
  char etag[1024];
  size_t content_length;
  int keepalive_timeout;
  int keepalive_max;
  int connection_type;
  char content_type[1024];
  char data[];
};

フィールド名をまったく送信する必要がなく、たとえば、応答構造のresponseTypeが、3文字の「2」「0」「0」ではなく値200のintである場合。それがテキストベースのプロトコルです。多くの異なるタイプの構造化データとしてではなく、（通常は人間が読める）テキスト行のフラットストリームとして通信するように設計されたプロトコルです。

141
Tyler McHenry

以下に、一種の警戒定義を示します。

あなたはそれを見たときにそれを知るでしょう。

これは、すべてのコーナーケースをカバーする簡潔な定義を見つけるのが非常に難しいケースの1つです。しかし、これらは、実際の生活では発生しないため、コーナーケースが完全に無関係なケースの1つでもあります。

実生活で遭遇するほとんどすべてのプロトコルは、次のようになります。

> fg,m4wr76389b zhjsfg gsidf7t5e89wriuotu nbsdfgizs89567sfghlkf
>  b9er t8ß03q+459tw4t3490ß´5´3w459t srt üßodfasdfäasefsadfaüdfzjhzuk78987342
< mvclkdsfu93q45324äö53q4lötüpq34tasä#etr0 awe+s byf eart

[印刷できない他の大量のがらくたを想像してください。テキストとバイナリの違いを伝える際の課題の1つは、テキストで伝える必要があることです:-)]

またはこのように：

< HELLO server.example.com
> HELLO client.example.com
< GO
> GETFILE /foo.jpg
< Length: 3726
< Type: image/jpeg
< READY?
> GO
< ... server sends 3726 bytes of binary data ...
> ACK
> BYE

[私はちょうどその場でこれを作り上げた。]

あいまいさはそれほど多くありません。

私が時々聞いた別の定義は

テキストプロトコルは、telnetを使用してデバッグできるものです。

たぶん私はここで私のオタクを示していますが、私はhave実際にSMTPとPOP3経由で電子メールを読み書きし、NNTP経由でusenet記事を読み、telnetを使用してHTTP経由でWebページを閲覧しました実際に機能するかどうかを確認する以外に理由はありません。

実際、これを書いている間、私はちょっと熱をキャッチしました：

bash-4.0$ telnet smtp.googlemail.com 25
Trying 74.125.77.16...
Connected to googlemail-smtp.l.google.com.
Escape character is '^]'.
< 220 googlemail-smtp.l.google.com ESMTP Thu, 15 Apr 2010 19:19:39 +0200
> HELO
< 501 Syntactically invalid HELO argument(s)
> HELO client.example.com
< 250 googlemail-smtp.l.google.com Hello client.example.com [666.666.666.666]
> RCPT TO:Me <[email protected]>
< 503 sender not yet given
> SENDER:Me <[email protected]>
< 500 unrecognized command
> RCPT FROM:Me <[email protected]>
< 500 unrecognized command
> FROM:Me <[email protected]>
< 500-unrecognized command
> HELP
< 214-Commands supported:
< 214 AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP ETRN
> MAIL FROM:Me <[email protected]>
< 250 OK
> RCPT TO:You <[email protected]>
< 250 Accepted
> DATA
< 354 Enter message, ending with "." on a line by itself
> From: Me <[email protected]>
> To: You <[email protected]>
> Subject: Testmail
>
> This is a test.
> .
< 250 OK id=1O2Sjq-0000c4-Qv
> QUIT
< 221 googlemail-smtp.l.google.com closing connection
Connection closed by foreign Host.

くそー、私がこれをやってからかなりの時間が経ちました。かなりの数のエラーがあります:-)

24
Jörg W Mittag

バイナリプロトコルの例： [〜＃〜] rtp [〜＃〜] 、 [〜＃〜] tcp [〜＃〜] 、 [〜＃ 〜] ip [〜＃〜] 。

テキストプロトコルの例： [〜＃〜] smtp [〜＃〜] 、 [〜＃〜] http [〜＃〜] 、 [〜＃ 〜] sip [〜＃〜] 。

これにより、バイナリプロトコルとテキストプロトコルの合理的な定義に一般化できます。

ヒント：サンプルセクションまたは図にスキップしてください。 タイラーの揺れる答え を説明するのに役立ちます。

6
Frank Shearar

ほとんどの人が示唆したように、プロトコルをバイナリにするかテキストにするかは、単にワイヤ上のコンテンツを見ても区別できません。

AFIK

バイナリプロトコル-ビットは境界です順序は非常に重要です

たとえば、RTP

最初の2ビットはバージョンです次のビットはMarkUpビットです

テキストプロトコル-プロトコル固有の区切り文字フィールドの順序は重要ではありません

たとえば、SIP

もう1つは、バイナリプロトコルでは、バイトを分割できます。つまり、1つのビットが特定の個別の意味を持つ場合があります。テキストプロトコルでは、意味のある最小単位はバイトです。バイトを分割することはできません。

5
toyvenu

私は誤ってこの古い質問を見つけて、少なくともそれを確認するために私の意見を追加することにしました。

ほとんどの回答は、テキストおよびバイナリプロトコルがマシンの観点とどのように異なるかを説明しています。人間の観点から見ると、テキストプロトコルは人間が読み取り/編集できるものです（人間はデコーダ/エンコーダなしでパケットを読み書きできます）。これには、少なくとも2つの利点があります。テキストプロトコル実装のデバッグ/メンテナンスの簡素化と、telnetなどのシンプルで汎用的なツールによるテストの可能性です。

もう1つの小さな利点：テキストプロトコルはより信頼できるものとして扱われます。なぜなら、プロトコル実装に穴を開けて悪意のあるコードを実行することは不可能または困難だからです。バッファオーバーフローを利用します。バイナリプロトコルはbase64エンコーディングで同じことを実現できるため、わずかなメリットがあります。

テキストプロトコルにはいくつかの欠点もあります。

  • 通常、テキストプロトコルの実装は、パーサーのため、バイナリよりも実装が困難です。
  • バイナリプロトコルは帯域幅の消費が少ない

これからいくつかの最終的な勧告をコンパイルしようとしています：

次の場合に、プロトコルをテキストとして設計します。

  • これは、一連のコマンドまたは要求/応答として処理できる制御プロトコルです（（インタラクティブ）。実装の観点から、有限状態マシンとして実装できます。例として、マルチメディアストリーミングを検討してください。RTSP-制御プロトコル、ステートマシンを使用し、要求/応答で構成されます-RTPがバイナリプロトコルの場合、テキストプロトコルです。マルチメディアストリームのような自然なバイナリデータを主に運ぶためです。
  • 大量使用を目的としています。多くの人々、実装、またはアプリケーションによるものです。そのため、デバッグ/保守の簡素化が非常に重要です。

。

3
Andriy Tylychko

両方とも異なる文字セットを使用し、テキスト文字セットは縮小文字セットを使用し、バイナリには「文字」と「数字」だけでなく、可能なすべてが含まれます（だからこそウィキペディアは「人間」と言っています）

oより明確に、jpgファイルがある場合、バイナリプロトコルを介してどのように送信され、テキストプロトコルを介してどのように送信されますか？もちろん、ワイヤで送信されるビット/バイトの観点で。

これを読む必要があります Base64

どんなコメントも感謝します、私はここで物事の本質に到達しようとしています。

文字セットを狭めるための本質は、複雑さを狭め、移植性、互換性に達することだと思います。ワイド文字セット（またはワイドは何でも）を尊重するように多くの人を手配して同意することは困難です。ラテン/ローマ字のアルファベットとアラビア数字は世界的に知られています。 （もちろん、コードを減らすために他の考慮事項がありますが、それが主なものです）

バイナリプロトコルでは、パーツ間の「契約」はビットについてであり、最初のビットはこれ、2番目のことなどを意味します。たとえば、プライベートなクローズドシステムでは、バイト（移植性を考えずに文字セットを使用する自由）または（ハードウェアスタンダーの近く）ただし、オープンシステムを設計する場合は、さまざまな状況でコードがどのように表現されるか、たとえば世界の反対側のマシンでどのように表現されるかを考慮する必要がありますか？ここに、契約が可能な限り標準になるテキストプロトコルがあります。私は両方を設計しました。それが理由で、非常にカスタムソリューションのバイナリと、オープンまたはポータブルシステムのテキストです。

3
Hernán Eche

SOAPで画像ファイルを送信する方法：ここをクリック

これは、バイナリデータが[ATTACHMENT]として添付され、その参照がSOAPメッセージに保存されることを示しています。

したがって、プロトコルはテキストベースであり、data [Image]はエンコードが関係のないバイナリ添付ファイルです

したがって、SOAPは、SOAPヘッダーを指定する方法によるテキストプロトコルであり、実際にエンコードされたデータではありません。

1
Karan Kaw

間違っていると思います。データが「ワイヤ」上でどのように見えるかを決定するのはプロトコルではなく、送信に使用するプロトコルを決定するのはデータ型です。たとえば、tcpソケットを使用すると、jpegファイルはバイナリプロトコルで送受信されます（バイナリデータ（人間が読み取れない、32〜126のASCII範囲に含まれるバイト）であるため）。ただし、テキストファイルは両方のプロトコルとあなたは違いに気付かないでしょう。

0
Simone Margaritelli

テキストプロトコルは、一目瞭然で広範囲にわたる場合があります。メッセージには、メッセージ自体にフィールド名が含まれているため、一目瞭然です。プロトコル仕様を参照しないと、バイナリプロトコルのメッセージでどの値が意味するのか理解できません。

これは広範であり、テキストプロトコルとしてのHTTPは単純なルールを作成するだけですが、新しいヘッダーを自由に追加するか、コンテンツタイプを変更して異なるペイロードを転送することにより、データ構造を拡張できます。そして、ヘッダーはメタデータであり、ネゴシエーションと自動適応の機能を備えています。

0
Chao