ソケットプログラミングとWebサービスの違いは？[closed] 質問する

Web サービスは、その大きな関心と、開発者ツール、ライブラリ、フレームワークによるサポートのおかげで、一般的に「簡単に」実行できます。

ただし、特にペイロードが小さい場合 (一般的な SMS やツイートのサイズのメッセージなど)、Web サービスで発生するオーバーヘッドは法外なものになります。GPRS や UMTS などのワイヤレス ネットワークで送信されるバイトは、ケーブルや ADSL で伝送されるバイトと比較して、依然として非常に高価です。また、Web サービスには、エンド カスタマーが支払う必要のある目に見えない情報が何層も含まれています。

したがって、ユースケースが短いメッセージに基づいている場合は、少なくとも帯域幅のシミュレーション計算を実行し、帯域幅の節約とアプリの複雑さの増加に基づいて決定することをお勧めします。

ソケットについて調べる際には、UDP も見てみましょう。基本的に誰かにパケットを投げ、プロトコルに何らかの ack メカニズムを設計しなければメッセージが到着したかどうかは決してわからないという事実を受け入れられるのであれば、接続を作成して維持するためのトラフィックがないため非常に効率的であり、かなり長いメッセージでも 1 つの UDP パケット内で十分に転送できます。

コメントに基づいて編集:

• ストリーム ソケット: ストリームをどのように定義するかはわかりませんが、私にとってストリームとメッセージは 2 つの非常に異なる概念です。ストリームは通常、送信されるデータの長いシーケンスですが、メッセージは送信され、オプションで受信者によって確認または応答されるエンティティです。
• 帯域幅シミュレーション：私が話していることを理解する最も簡単な方法は、ワイヤーシャークそして、非常に短い文字列の単純なリクエストを実行するためにネット上で転送されるすべてのものを合計します。エンドユーザーが支払うトラフィックである管理情報の複数のレイヤー（つまり、異なるプロトコルレイヤーを動作させるために存在する、目に見えないもの）が表示されます。次に、UDPを使用して同じメッセージを転送する小さなモックサービスを作成するか、次のようなツールを使用します。ネットキャット、良いチュートリアルここ、転送されるバイト数を合計します。交換されるバイト数にかなり大きな違いがあることがわかります。

編集2、言い忘れていましたが、モバイルネットワークはかつてはオープンで透過的なネットワークで、デバイスはパブリック IP アドレスで識別されていました。NAT モバイルネットワークへの急速な進化により、この「壁で囲まれた庭園」の内外のデバイス間の通信方法に影響が出ています (NATトラバーサル）。コミュニケーション チャネルを設計する際には、この点を考慮する必要があります。

チャットアプリケーションでのストリームの使用については、概念的な利点がいくつかありますが、UDPの上にチャットアプリケーションを重ねることもできます。ここまたはここ