タイトルはそれをすべて言います。基本的に、クライアントサーバーのセットアップにTCPを使用していますが、tcpを介してデータを送信する前に、文字列をバイナリに変換する利点があるかどうか疑問に思っていますか?
3 に答える
文字列はバイナリデータであるか、少なくとも簡単にそのようなbyte[]に変換できます。
static byte[] GetStringBytes(string str)
{
byte[] bytes = new byte[str.Length * sizeof(char)];
System.Buffer.BlockCopy(str.ToCharArray(), 0, bytes, 0, bytes.Length);
return bytes;
}
送信するデータを圧縮/エンコードする場合、それが文字列またはバイナリデータとして最初から始まるかどうかに関係なく、同じ合計バイト数を送信する可能性があります。
ほとんどの場合、実際の利点はありません。また、バイナリデータはプラットフォームに依存する傾向があるため、クライアント/サーバーをマルチプラットフォーム環境に拡張する場合は、文字列を使用する方がよいでしょう。
DERのように、バイナリでエンコードされたデータがいくつかあります。
アプリケーションがこれらの種類のデータを送信する必要がある場合は、バイナリを直接送信できます。たとえば、CAの証明書。base64のように文字列として送信する場合は、それを表すためにより多くのサイズが必要です。
TCPなどの一部の下位レベルでは、サイズ、パフォーマンス、およびフォールトトレランスのために、2つのエンティティ間で情報を共有(ハンドシェイク)するためにバイナリが使用されます。
しかし、機敏に進化する必要のあるアプリケーション開発者として、互換性やメンテナンスなど、サイズ以外にも考慮する必要のあることがたくさんあります。いくつかのメタデータをバイナリデータで応答する必要があるとしましょう。JSONを使用して以下を表す必要がある場合があります。
{
"version": 1,
"data": "base64 encoded data"
}
JSONの解析に役立つツールがたくさんあり、ツールなしでデータを表示できる(人間が読める形式)とデバッグが容易になるため、クライアントにとっては作業が簡単になります。一方、バイナリエンコード(DERなど)では、プロトコルドキュメントをアップグレードして、クライアントがコードを新しい形式に簡単にアップグレードできるようにする必要があります。また、下位/上位互換性も考慮する必要があります。
Apache Thrift、Protocol Buffer、Apache Avroなど、バイナリエンコードの互換性と保守性を高めるためのツールがいくつかあります。
パフォーマンスの側面をより深く見ていきます。エンコード/デコードプロセスがある場合とない場合を比較する場合を除きます(どちらが優れているかを比較するのは簡単です)。それを確認するには、負荷テストを実行する必要があります。
たとえば、非常に高速なJSONパーサーがいくつかありますが、他のパーサーよりもパフォーマンスが優れていると主張するバイナリパーサーを簡単に打ち負かすことができます。