要求されたファイルを、別のネットワークで実行されている他の内部アプリケーションまたはコンポーネントに提供できる Web サービスを実装する必要があります。ファイルは、さまざまな場所にあるさまざまなサーバーに分散されており、サイズが数ギガバイトになることもあります。
ファイルを検出し、HTTP 要求を別の場所にある別の Web サービスにリダイレクトし、HTTP 経由でファイルを送信するための実装を持つ RESTful Web サービスを作成することを考えています。
HTTP 経由でファイルを送信するのは良い考えですか、それとも Web サービスがファイルをリクエスタ コンポーネントがアクセスできる場所にコピーする方が良いでしょうか?
HTTP 経由で大きなファイルを配布する際の最大の問題は、それを妨げるあらゆる種類の制限に遭遇することです。簡単な例として、WCF では最大ペイロード サイズを構成できますが、最大 2 GB までしか構成できません。スタックのすべてのレイヤーで、このような問題に遭遇する可能性があります。それらのいずれかが克服できないとは思えません (上記の制限を回避するには、ファイル全体ではなく、ファイルのチャンクをストリーミングできますが、それはそれ自体の問題を引き起こします)、多くのタイムアウトとランダムな失敗が発生する可能性がありますこれまたはそのサービスまたはクライアントの構成を微調整することで修正されました。
また、大きなファイルを扱う場合は、転送中に避けられない障害 (ネットワークの切断など) にどう対処するかを慎重に検討する必要があります。使用する特定のテクノロジーによっては、「レジューム」機能が含まれている場合がありますが、コミットする前に、これが信頼できるものであることを確認する必要があります。
1 つの可能性は、Facebook が大規模なバイナリを配布するときに行うこと、つまりBitTorrent を使用することです。したがって、Web サービスは、ファイル自体ではなく、ファイルの torrent を提供します。BitTorrent の大きな利点は、非常に堅牢で、拡張性に優れていることです。検討する価値はありますが、環境と特定のワークロードに大きく依存します。
提供するファイルが頻繁に変更されない、またはまったく変更されない場合は、RB のアドバイスに従って多くの戦略を使用するか、部分的なデータ操作をサポートする純粋な HTTP を使用できます。RFC 2616を参照してください。
ただし、使用シナリオによっては、Amazon Web Services - S3 (Simple Storage Service)も検討することをお勧めします。これは、おそらくあなたがやろうとしていることをすでに実行しており、安価で高可用性を備えています。