これらはすべて、バイナリのシリアル化、RPC フレームワーク、および IDL を提供します。それらと特性 (パフォーマンス、使いやすさ、プログラミング言語のサポート) の主な違いに興味があります。
他の同様の技術を知っている場合は、回答に記載してください。
質問する
38608 次
6 に答える
101
ASN.1は ISO/ISE 標準です。非常に読みやすいソース言語と、バイナリ形式と人間が読める形式の両方のさまざまなバックエンドを備えています。国際標準であるため (しかも古い言語です!)、ソース言語は少し使いにくいですが (大西洋が少し湿っているのとほぼ同じように)、非常に詳細に指定されており、適切な量のサポートがあります。 . （十分に掘り下げれば、名前を付けた任意の言語のASN.1ライブラリをおそらく見つけることができます。そうでない場合でも、FFIで使用できる優れたC言語ライブラリが利用可能です。）それは、標準化された言語であり、執拗に文書化されており、いくつかの優れたチュートリアルも利用できます。
倹約は標準ではありません。もともとは Facebook からのもので、後にオープンソース化され、現在はトップレベルの Apache プロジェクトです。それは十分に文書化されていません-特にチュートリアルレベル-そして私の（確かに簡単な）一見したところ、他の以前の取り組みがまだ行っていないことを追加しているようには見えません（場合によってはより優れています）。公平を期すために、いくつかの有名な非主流言語を含む、すぐに使用できるかなり印象的な数の言語があります。IDL も漠然と C に似ています。
Protocol Buffersは標準ではありません。これは、より広いコミュニティに向けてリリースされている Google 製品です。すぐにサポートされる言語に関しては少し制限があります (C++、Python、および Java のみをサポートします) が、他の言語 (非常に可変性の高い品質) に対する多くのサードパーティ サポートがあります。Google はほとんどすべての作業を Protocol Buffers を使用して行っているため、これは戦闘でテスト済みの、戦闘で強化されたプロトコルです (ただし、ASN.1 ほど戦闘で強化されているわけではありません。Thrift よりもはるかに優れたドキュメントがありますが、 Google の製品は不安定である可能性が高い (信頼できないという意味ではなく、常に変化しているという意味で) IDL も C に似ています。
上記のシステムはすべて、ある種の IDL で定義されたスキーマを使用して、エンコードおよびデコードに使用されるターゲット言語のコードを生成します。アブロはしません。Avro の型付けは動的であり、そのスキーマ データは実行時にエンコードとデコードの両方に直接使用されます (これには処理に明らかなコストがかかりますが、動的言語や型のタグ付けが不要になるなどの明白な利点もあります)。 . そのスキーマは JSON を使用しているため、JSON ライブラリが既に存在する場合、新しい言語での Avro のサポートが少し簡単になります。繰り返しますが、ほとんどの車輪を再発明するプロトコル記述システムと同様に、Avro も標準化されていません。
個人的には、好き嫌いはありますが、ほとんどの RPC とメッセージ送信の目的にはおそらく ASN.1 を使用するでしょう。十分に単純です）。
于 2011-01-08T12:24:48.110 に答える
15
パフォーマンスの観点に加えて、Uber は最近、エンジニアリング ブログでこれらのライブラリのいくつかを評価しました。
https://eng.uber.com/trip-data-squeeze/
彼らの勝者は？MessagePack + 圧縮用の zlib
私たちの目標は、エンコード プロトコルと圧縮アルゴリズムの組み合わせを見つけて、最高速度で最もコンパクトな結果を得ることでした。Uber New York City からの 2,219 の疑似ランダム匿名化された乗車 (JSON としてテキスト ファイルに入力) で、エンコード プロトコルと圧縮アルゴリズムの組み合わせをテストしました。
ここでの教訓は、要件によってどのライブラリが適切かが決まるということです。Uber の場合、メッセージ パッシングのスキーマレスな性質のため、IDL ベースのプロトコルを使用できませんでした。これにより、一連のオプションが削除されました。また、生のエンコード/デコード時間だけでなく、保存されているデータのサイズも影響します。
サイズ結果
速度結果
于 2016-04-09T13:40:20.140 に答える
13
ASN.1 の 1 つの重要な点は、ist が実装ではなく仕様のために設計されていることです。 したがって、「実際の」プログラミング言語で実装の詳細を隠したり無視したりするのに非常に優れています。
エンコーディング ルールを asn1 ファイルに適用し、両方から実行可能コードを生成するのは、ASN.1 コンパイラの仕事です。エンコーディング ルールは、エンコーディング記法 (ECN) で指定される場合もあれば、BER/DER、PER、XER/EXER などの標準化されたルールのいずれかである場合もあります。つまり、ASN.1 はタイプと構造体であり、エンコーディング ルールはネットワーク上でのエンコーディングを定義し、最後に重要なこととして、コンパイラはそれをプログラミング言語に転送します。
無料のコンパイラは、私の知る限り、C、C++、C#、Java、および Erlang をサポートしています。(非常に高価で、特許/ライセンスが必要な) 商用コンパイラは非常に用途が広く、通常は完全に最新であり、時にはさらに多くの言語をサポートしますが、それらのサイト (OSS Nokalva、Marben など) を参照してください。
asn.1 ファイル、BER などのエンコード規則、UML 相互作用図などの手法を使用して、まったく異なるプログラミング文化の関係者 (「組み込み」の人々と「サーバー ファーマー」など) の間のインターフェイスを指定するのは驚くほど簡単です。 . 実装方法は気にせず、みんなで「自分のもの」を使おう！私にとって、それは非常にうまく機能しました。ところで: OSS Nokalva のサイトでは、ASN.1 に関する無料でダウンロードできる書籍が少なくとも 2 冊あります (1 冊は Larmouth 著、もう 1 冊は Dubuisson 著)。
私見では、他の製品のほとんどは、シリアライゼーションの問題に多くの空気を送り込んで、さらに別の RPC スタブ ジェネレーターになることだけを試みています。まあ、それが必要なら、いいかもしれません。しかし、私には、それらは (80 世紀後半からの) Sun-RPC の再発明のように見えますが、まあ、それもうまくいきました。
于 2012-11-04T18:28:05.120 に答える
5
パフォーマンスについては、1 つのデータ ポイントはjvm-serializersベンチマークです。これは非常に具体的で小さなメッセージですが、Java プラットフォームを使用している場合に役立つ可能性があります。一般的なパフォーマンスは、多くの場合、最も重要な違いではないと思います。また: 著者の言葉を決して福音と見なさないでください。宣伝されている主張の多くは偽物です (たとえば、msgpack サイトには疑わしい主張がいくつかあります。高速かもしれませんが、情報は非常に大ざっぱで、ユースケースはあまり現実的ではありません)。
大きな違いの 1 つは、スキーマを使用する必要があるかどうかです (少なくとも PB、Thrift。Avro はオプションかもしれません。ASN.1 もそう思います。MsgPack は必ずしもそうではありません)。
また、私の意見では、階層化されたモジュール設計を使用できるのは良いことです。つまり、RPC レイヤーはデータ形式やシリアライゼーションを決定するべきではありません。残念ながら、ほとんどの候補者はこれらをしっかりとバンドルしています。
最後に、データ形式を選択する場合、最近のパフォーマンスはテキスト形式の使用を妨げるものではありません。非常に高速な JSON パーサー (および非常に高速なストリーミング xml パーサー) があります。また、スクリプト言語からの相互運用性と使いやすさを考慮すると、バイナリ形式とプロトコルは最良の選択ではない可能性があります。
于 2011-01-12T20:08:48.850 に答える