ビューのコンテンツ/ファンクションポイントからの通信
分散スケジューリングで使用されるRPCは、HTTPのWeb環境に適用され、
多くの異なる機能的な観点からではなく、通信およびメッセージングミドルウェアのRPCの組み合わせは、多くの場合、分散スケジューリングを実装します
ビューの使用方法の観点から
、両方のC / Sの構造、ない大きな違い
観点から達成するために
基本的なプロトコルの種類を
パフォーマンスの観点からは
1、それはRPC長いリンクを聞いて、HTTPは、3ウェイハンドシェイクです。
接続数が制限を持っているかどうかに長いリンクが、コストがTCPを低減することができ、それは、新しい相対的不利益をインポートしますか？
2、マルチソケット接続よりも何も3回、HTTP以外のRPCパフォーマンスの場合。もし（例えば、竜巻）のノンブロッキングIO httpサーバの組み合わせは、これら3つのは本当に何も接続オーバーヘッド消費。
もちろん、ネットワークは少しの消費を持つことになります。ノンブロッキングIO RPCサーバのパフォーマンスギャップがhttpで平準化することができます
リンクコストからは、パフォーマンスの問題を比較し、これは間違っている、両方のさまざまな問題を解決するには、この問題には全くもつれする必要はありません。以下をお読みください
概念的には
、RPCリモート呼び出しの
HTTPハイパーテキスト転送プロトコル
どのように選択するには？
1は、私たちが最も簡単な方法を使用する必要があり、この問題を考えると、そのプロトコルの設計者は、（結局、合意が受け入れを表す）、我々は唯一それが解決しどのような問題に焦点を当て、それが直面している問題を解決する最善の方法を選択します。
RPCの問題を解決？リモートコール。「コール」の内部手続きの中で属しています。合計がちょうどパスの簡単なパラメータを呼び出すことはできません、標的配列を含むであろう、
オブジェクトは、コードの開発にあるバーの2セットを使用されることはありません、サーバーとクライアントが一緒に属しているコンポーネントである可能性が高いです。
2、接続の数は、考慮すべき事柄を「コール」であってはなりません。あなたがグローバルな接続を作成した後、あなたは、多くの場合、接続を作成しません。サービスとしてRPCは、頻繁に接続のシーンがそれに適していない場合
要約
1度Cの密接な関係
プログラム、CSの近くの内側部分との間のRPCリモート呼び出し。
異なるコンポーネント、CS独立した関係に適したHTTP、。
2、接続の数は、
それが適切ではない、呼び出すために頻繁に接続のシーンを呼び出すRPC
ウェブ環境のアプリケーションはhttp、これは頻繁に接続のシーンです