TCP / IPアプリケーションとHTTPアプリケーションの比較[終了]

Javaで書かれた大規模なユーザー向けWebサイトの開発に興味があります。

設計に関しては、メインのWebアプリケーションに対するデータプロバイダーとして機能できる、独立したモジュラーサービスの開発を考えています。

これらのモジュラーサービス（データプロバイダー）の作成については、Springなどの既存のフレームワークを活用し、RESTfulデザインパターンに従ってこれらのサービスを開発し、JSONなどのメッセージ形式でHTTPを介してリソースを公開するか、既存のネットワークを活用できますNetty（http://netty.io/）のようなフレームワークとProtobufs（https://developers.google.com/protocol-buffers/docs/overview）のようなシリアル化形式、およびシリアル化されたprotobuf を送受信するTCPサーバーを開発するペイロード。

どちらを選択するかはいつですか？Protobufsのようなシリアル化形式を使用して、ワイヤを介してバイトストリームを送信する利点はありますか？JSONを使用するだけでオーバーヘッドが発生しますか？TCP / IPを使用してからHTTPを使用するまでのオーバーヘッドはどれくらいですか？そのようなサービスを構築するためにSpring over Nettyをいつ使用する必要がありますか？

JSONをREST経由で使用することと、バイナリプロトコルを使用するTCP / IPを直接使用することの長所と短所は間違いなくあります。どのくらい高速であるかを正確に伝えることはできません（これは多くの要因に依存します）が、1〜2桁の違いがあると思います。

一見、何かが他の何かよりも10〜100倍遅い場合、あなたはひざまずき反応をして、「速いこと」に進むかもしれません。ただし、この速度の違いはプロトコル自体のみです。サーバー側にデータベース/ファイルアクセスがある場合、転送レイヤーの選択によって影響を受けることはありません。場合によっては、転送レイヤーの速度が大幅に低下する可能性があります。

HTTP RESTとJSONは、いくつかの理由で優れています。

• 誰でも簡単に消費できます。Webアプリを作成してから、APIを有効にして公開し、世界中で使用できるようにします。誰でも同じエンドポイントにアクセスして、サービスにアクセスできるようになりました
• それらは簡単にデバッグできます。パケットスニファーを開くか、単に着信リクエストをテキストファイルにダンプして、何が起こっているかを確認できます。バイナリプロトコルではできません
• 簡単に拡張できます。後で属性とデータを追加して、古いクライアントとの互換性を損なうことはありません。
• javascriptクライアントが消費可能（protobuf JSパーサーがまだあるかどうかはわかりませんが、1つあるとは思わないでください）

TCP / IP上のProtobufs：

• 彼らは速いです

私の選択であれば、HTTP RESTとJSONを使います。他の多くの企業やウェブサイトがその道を進んだ理由があります。また、将来的には常に2つのエンドポイントをサポートできることに留意してください。設計が正しい場合、エンドポイントの選択は、サーバー側のビジネスロジックまたはデータベースから完全に切り離す必要があります。したがって、すべて/一部の要求に対してより高速が必要であることに気付いた場合、最小限の手間でprotobufsを追加できるはずです。ただし、REST / JSONを使用すると、すぐに地面から離れて、さらに先に進むことができます。

Netty対Springに関しては。私はNettyを直接使用したことはありませんが、Springはそれだけでなく多くの機能を提供するフレームワークであるため、単なる軽量のWebサーバーであると考えています。データアクセスレイヤー、バックグラウンドジョブスケジューリング、MVCモデル（と思う）があるため、はるかに重量があります。どちらを選ぶべきですか？HTTPを使用することにした場合、次の質問はおそらくアプリの標準です。標準的な型に合わないクレイジーなカスタムロジックを作成しようとしており、必要なものがHTTPサーバーレイヤーだけである場合は、Nettyを使用します。

ただし、アプリはそれほど特別なものではなく、Springが提供する多くの機能の恩恵を受ける可能性があります。ただし、これは、Springのフレームワークを中心にアプリを構築し、期待どおりに物事を行う必要があることを意味します。つまり、製品に飛び込む前に、Springについてさらに学ぶ必要があります。フレームワークは一般に素晴らしかったです。これもまた、より早く軌道に乗ることができますが、欠点は、独自の設計を行うのではなく、型に適合し、フレームワークが正常に機能することを期待することです。

（*）-過去に、私の投稿は全世界の意見を反映していないことが指摘されていたため、記録に進み、Nettyの経験が限られていることを追加します（以前にPlayフレームワークを使用したことがあります） Nettyに基づいています）またはSpring（私はそれについて読んだだけです）。だから私が言ったことを一粒の塩で取ってください。

これは実際には非質問です。インターネットプロトコルスイートによると、tcpはトランスポート層のプロトコルであり、httpはアプリケーション層のプロトコルです。まったく異なるものを互いに比較しています。（詳細はこちらをご覧ください：http : //en.wikipedia.org/wiki/Internet_protocol_suite）

実際、ほとんどのhttpはtcp / ip上にあります。質問に答えるには、tcp / ipを使用する必要があります。次に、その上にアプリケーション層プロトコル（httpなど）を追加し、次にデータ形式（json、xml、htmlなど）を追加します。Nettyではhttpを使用でき、protobuffはjson、xml、htmlと同じです。

それはすべて、要件が何であり、どのタイプのデータを転送する必要があるかによって異なります。プロトコルでセッションが必要ですか、ハンドシェイクでプロトコル構成を改善できますか、一度に送信するデータの量は、暗号化が必要ですか？これらは、アプリケーションプロトコルを選択するときに答える必要がある質問です。

データ表現形式（json、xml、html、protobuffなど）を選択する場合、帯域幅、読みやすさ、言語/ツールのサポートなどに依存します。

httpとtcpを比較することはできません。

速度がすべてではないことを忘れないでください。賢明な方法で自分を表現できない場合、速度は役に立ちません。