Java 言語はどのようなプロトコルをサポートしていますか?

#以下は、Java 言語で一般的に使用されるいくつかの通信プロトコルとプロトコルのパフォーマンスの比較です。

1.RMI

RMI 呼び出し 予想どおり、RMI はもちろん最速であり、ほとんどすべてのケースで所要時間は最小のミリ秒です。特にデータ構造が複雑でデータ量が多い場合、他のプロトコルとの差が顕著になります。 RMIの性能を最大限に発揮するためにテストクラスを作成し、Springではなく独自のRMI形式（UnicastRemoteObjectオブジェクトを継承）でサービス提供とリモート呼び出しを行い、SpringのRMIと効率を比較しました。 POJOによってパッケージ化されています。結果から、この 2 つは基本的に同じであり、Spring によって提供されるサービスの方がわずかに高速であることがわかります。これは、Spring のプロキシおよびキャッシュ メカニズムが比較的強力であり、オブジェクトを再取得する時間が節約されるためであると当初考えられています。

2.Hessian

Hessian は、最速のサーバーとして知られ、Java 分野で一定の評価を得ている caucho 社の樹脂サーバーを呼び出します。樹脂のコンポーネントとしての Hessian の設計も非常に合理的かつ効率的であり、実際の操作によってこれが証明されています。平均すると、ヘシアンは RMI より約 20% 遅くなりますが、これはデータ量が特に多く、データ構造が複雑な場合にのみ反映され、データ量が中程度または少量の場合、ヘシアンは RMI よりも遅くなりません。ヘッセ行列の利点は、合理的かつ効率的であり、複数の言語で使用でき、プロトコル仕様が公開されているため、任意の言語向けにそのプロトコルの実装を開発できることです。現在実装されている言語には、java、c、.net、python、および Ruby が含まれます。 delphi の実装はまだありません。また、Hessian は WEB サーバーとの統合性が高く、WEB サーバーの機能を利用することで、多数のユーザーからの同時アクセスを処理する際に大きな利点を発揮し、リソースの割り当て、スレッドのキューイング、例外処理などをすべて実行できます。成熟した WEB サーバーによって保証されます。 RMI 自体はマルチスレッド サーバーを提供しません。さらに、RMI はファイアウォール ポートを開く必要がありますが、Hessian は必要ありません。

3.Burlap

Burlap と Hessian はどちらも Caucho Company のオープンソース製品ですが、Hessian はバイナリ形式を使用するのに対し、Burlap は XML 形式を使用します。テスト結果によると、データ構造が複雑でなく、データ量が中程度の場合、Burlap の効率はまだ許容可能ですが、データ量が多い場合、効率は急激に低下します。平均すると、Burlap のミリ秒あたりの呼び出し時間は RMI の 3 倍です。効率が悪い理由は2つあると思います、1つはXMLデータの記述内容が多すぎることと、同じデータ構造の送信量が非常に多いこと、もう1つはご存知のとおりXMLの解析が相対的に難しいことです。これは特に、大量のデータに当てはまります。

4.HttpInvoker

HttpInvoker は Spring Framework によって提供される JAVA リモート呼び出しメソッドであり、Java のシリアル化メカニズムを使用してオブジェクトの送信を処理します。テスト結果から判断すると、その効率は依然として許容可能であり、基本的には RMI と同じです。ただし、JAVA 言語間の通信にのみ使用でき、クライアントとサーバーの両方が SPRING フレームワークを使用する必要があります。さらに、HttpInvoker は実際にはテストされておらず、このプロトコルを適用するプロジェクトはまだ見つかっていません。

5.web サービス

このテストでは、WEB サービスの実装として Apache の AXIS コンポーネントを選択しました。AXIS は、WEB サービスの分野では比較的成熟しており、確立されています。データ送信、エンコード、およびデコードの時間のみをテストするために、クライアントとサーバーの両方でキャッシュが使用され、オブジェクトのインスタンス化は 1 回だけ必要になります。ただし、テスト結果によると、Web サービスの効率は依然として他の通信プロトコルに比べて 10 倍遅いことが示されています。同じオブジェクトを指す複数の参照の転送を考慮すると、Web サービスはさらに遅れます。 RMI、ヘッセ行列、およびその他のプロトコルは参照を渡すことができるため、Web サービスが持つ参照の数は、Web サービスが持つオブジェクト エンティティのコピーの数に依存します。 Web サービスによって送信される過剰な冗長情報が速度低下の原因の 1 つであり、モニタリングの結果、同じデータを記述した同じアクセス要求に対して、Web サービスから返されるデータ量はヘシアン プロトコルの 6.5 倍であることが判明しました。 。さらに、WEB SERVICE の処理にも時間がかかり、現在の XML パーサーは一般的に効率が悪く、xml <-> Bean の処理には多くのリソースが必要になります。テスト結果から、リモート呼び出しはローカル呼び出しよりも高速であり、主に XML ファイルのエンコードとデコードに時間が費やされていることがわかります。これは冗長情報よりも深刻で、冗長情報はネットワーク帯域幅を占有するだけであり、各呼び出しのリソース消費はサーバーの負荷容量に直接影響します。 (MS エンジニアは、WEB SERVICE は 100 人を超える同時ユーザーをロードできないと言っていたことがあります。) テスト中に、Web サービスのコーディングがあまり便利ではないこともわかりました。非基本型の場合、シリアル化クラスと逆シリアル化クラスは、次の方法で 1 つずつ登録する必要があります。スタブの生成は面倒で、Spring RMI/ヘシアン処理ほどスムーズで簡潔ではありません。さらに、Web サービスはコレクション型をサポートしておらず、配列しか使用できないため、不便です。

以上がJava 言語はどのようなプロトコルをサポートしていますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。