非常に大きなHTTPリクエストと多くの小さなリクエスト
サーバーからクライアントに送信される2D配列（Jsonとして）が必要です。サイズは約400x400で、各エントリは約4文字のテキストです。したがって、約640KBのデータになります。
次の極端なアプローチのどれが優れていますか？
- 一度にすべてのデータの大きなHTTPリクエストを作成します。
- 400件のリクエストを作成します-それぞれが単一行を要求します（約1.6 KB）
最適なアプローチはどこか中間だと思います。誰もが私にこのデータの最適な単一のリクエストサイズは何であるかもしれないという考えを教えてもらえますか？
ありがとう。
遅い（very今日の標準では遅い）接続と本当にが必要な場合増分更新。1回のリクエストで実行します。
これにより、 応答の圧縮 の効率が向上し、 追加のHTTP要求と応答ヘッダー のオーバーヘッドが回避されます。
1つの大きいものといくつかの小さいものを選択する場合の考慮事項：
- 単一のリクエストの場合、データが到着すると、プログレッシブデータ処理を実行できません。何かを行う前に、完全なパケットが到着するのを待つ必要があります。失敗した場合は、すべてを最初からやり直す必要があります。
- 複数リクエストの場合、プログレッシブデータ処理を実行できます。ただし、ここで、複数の障害の可能性とそれらからの回復方法を考慮する必要があります。
- 複数のリクエストでは、リクエストごとにオーバーヘッドが発生します。これは、アプリが消費する追加の帯域幅です。
- 一部のHTTPエージェントは、同じサーバーへの同時要求の数を制限し、それを回避するためにいくつかのロジックを実行する必要がある場合があります。
- 応答の圧縮は、単一の要求の場合に適しています。
- 複数のリクエストでは、データに全メモリを割り当てる必要はありません。確かに、640KBはそれほど大きなメモリチャンクではないので、割り当てる頻度によっては、それほど大きな考慮事項ではないかもしれません。
- プロセスが早期に終了した場合（[キャンセル]ボタンまたはアプリが終了したか、ブラウザーがページから移動した場合）、単一の要求で完全な応答のダウンロードが完了します。ただし、複数のリクエストの場合、コードがまだ開始されていないリクエストは実行されません。
正直なところ、私は最後の2つについて心配する必要はなく、1）に基づいて選択します。プログレッシブデータ処理が重要です。 2）障害と部分的なデータに対するアプリの許容範囲。
また、サーバーには 大きなリクエストによる脆弱性 がある可能性があることに注意してください。