常に REST サービスにデータを投稿するクライアントがいくつかあります。REST サービスは、ネットワーク ロード バランサーの背後に置かれます。各クライアントは 1 日 100 ～ 500 MB を送信し、500 以上のクライアントをサポートする必要があります。
非常に大きなパケットを POST できます。これにより、TCP/IP セッションのセットアップと HTTP ヘッダーのオーバーヘッドが削減されます。ただし、これにより、1 つのクライアントが特定のサーバーにしっかりと結び付けられ、スケーラビリティ オプションが制限されます。別の方法として、小さな HTTP パケットを送信することもできます。これにより、負荷を適切に分散できますが、TCP/IP セッションのセットアップと HTTP ヘッダーのオーバーヘッドが増えます。
HTTP POST の推奨パケット サイズは? または、自分の環境でどのように計算できますか?
推奨サイズはありません。
HTTP POSTサイズはRFCによって制約されませんが、HTTPは要求/応答タイプのメッセージングを実装するコモディティプロトコルであるため、ほとんどのインフラストラクチャは、TCP接続が特に長くは続かない/大量のデータを伝送しないという考えに基づいて構成されます。つまり、サービスに影響を与える可能性のある制御外の要因があります。HTTPは応答の範囲要求をサポートしていますが、要求の結果はありません。
HTTPSを使用すると、これらの多く（すべてではありませんが）を回避できます。ただし、停止を検出/管理する方法について考える必要があります。TCPタイムアウトを待ってよろしいですか？
500以上のクライアントがおそらくシステムを非常に頻繁に使用している場合、輻輳回避の制限は問題になりません。TCPウィンドウのスケーリングが問題になる可能性があるかどうかは、システムの使用方法によって異なります。リクエストサイズをばかげたものに制限しない限り、HTTPハンドシェイクは問題になりません。
サービスがサーバーに大量のデータをプッシュするクライアントに大きく依存している場合は、クライアント上のデータの解析を検討することをお勧めします（ボリュームが与えられた場合、おそらくファイルからのものであり、署名されたJavaアプレットまたはJavaScriptを意味しますUniversalBrowserRead特権を使用して）、双方向通信チャネル（Webソケットなど）を介して送信します。
今のところそれはさておき、クライアントとサーバー間のルートがサポートするものを見つける唯一の方法は、それを測定し、監視することです。2Mbのアップロードサイズはほとんどどこでも機能しますが、10Mbのサイズは米国またはヨーロッパ内でほとんどの場合機能します。モバイルクライアントがない限り、これを50Mbに増やすことができます。
ただし、サービスの有効性を維持したい場合は、帯域幅、パケット損失、および接続の喪失を監視する必要があります。