私は現在、JavaとSpring MVCを使用して、ユーザーがビデオファイルをアップロードできるサービスを開発しています。これらは後でAPIを介して取得できます。
APIを介してビデオファイルが読み込まれると、ファイルが完全に送信されます。ダウンロードとして、ストリーミングやマルチパートはありません。これは、特定のファイルサイズに達するまでしか機能しないことを理解しています。誰かが最大ファイルサイズがどうあるべきかについての推奨事項を持っていますか？つまり、代わりにどのファイルサイズでビデオストリーミングサービスの使用を開始する必要がありますか？
実際には、考慮すべき要素が複数あるため、これはかなり複雑な質問です。各アプローチの長所と短所をリストし、最終的には代替ソリューションを提供します。
ファイル全体を一度にダウンロード/アップロード：
->長所： プログラミングが簡単
->短所： ユーザーが2ギガバイトのファイルをアップロードしようとするとすぐに、このファイルはサーバーのメモリに保存されてから、ファイルシステムまたは保存場所に保存されます。100人のユーザーがそれを行うと、サーバーがクラッシュすることを想像できます。サーブレットコンテナレベルでリクエストのサイズを制限できますが、その場合はユーザーを制限することになります。もう1つの方法は、アプリケーションレベルでも制限することですが、それでもユーザーを制限しています。数年前、Tomcatのアップロードのデフォルトサイズは2097152（2メガ）でした。現在の量はわかりませんが、10MBまたは100MBに上げても、前述の問題が発生します。複数のユーザーが大きなファイルをアップロードしようとすると、それらがメモリに保存されます。
ストリーミングを使用したファイルのダウンロード/アップロード
->長所： ストリーミングでは、保存する前にすべてのコンテンツがメモリに存在する必要はありません。これは、すべてを送信するよりもエレガントなアプローチであり、すべての点で間違いなく優れています。また、大きなファイルの送信、ファイアウォール、サーブレットコンテナの制限など、企業環境でのほとんどの問題を回避できる可能性があります。
また、プログレスバーを使用してストリーミングを実装する場合、システムに大きなファイルを送信するユーザーは、クラッシュしたとは思わないため、ユーザーエクスペリエンスが大幅に向上します。
->短所： それほど多くはありませんが、実装が少し難しいです。commonsのIOUtilsのようなライブラリを使用すると、ストリーミングソリューションの実装に問題はありません。
ご覧のとおり、ほとんどの場合、ファイルのサイズに関係なく、ファイルのコンテンツをストリーミングする方が適切ですが、ファイルソリューション全体を使用する場合は、その領域で10MB程度の制限を使用できます。それはあなたがあなたのビデオがどんなサイズであると期待するかによります。
注意すべき点の1つは、ストリーミングを使用してユーザーがビデオコンテンツを表示できるようにする場合は、サーブレットコンテナに、ビデオのストリーミングという想定外の処理を不必要に負担させることになるということです。サーブレットコンテナはhttpリクエストに応答するためのものであり、設計上、短期間のhttpリクエストを期待してスレッドを再利用するプールで作成されます。ある時点で、httpサーブレットコンテナがビデオのストリーミングとhttpリクエストの処理を同時に行うのに適していないことが明らかになる可能性があります。考えられる解決策は、ユーザーがAPIを使用してビデオサーバーにファイルをアップロードしてから、別の場所にあるビデオサーバーを使用してビデオをユーザーにストリーミングすることです。あなたはこれを見ることができます：http：//www.red5.org/
この設定から得られるものは次のとおりです。->httpサーバーの負荷を軽減し、それを本来の目的に使用します。httpリクエストを処理します->ストリーミング、再生、などは、アプリケーションではなく、ビデオサーバーによって処理されます。