PHP アップロード ブレークポイントの再開

コントロールを使用せずに、フラッシュだけで実現できるようですか?

ディスカッションへの返信（解決策）

もちろんです。 PHPはサポートしていないのでしょうか？

コントロールを使用しない場合は、Flashのみを使用できるようですか？ 基本的に、コントロールなしで実装することは困難です。 QQ メールボックス、Baidu Netdisk、DBank (Huawei Netdisk)、115 Netdisk、および 360 Netdisk の大きな添付ファイルのアップロード機能を確認してください。ブレークポイント再開機能はすべて自社開発のコントロールによって実装されています。それを実現するために Flash を使用するのではなく。

コントロールを使わずに、フラッシュだけで実現できるようですか？ 実際のネットワーク環境では、通常、コントロールを使用して約 30MB のファイルを実現する必要があります。それは、国内のネットワーク環境が不安定であることと、サーバーの負荷が原因であることが考えられます。
一般に、当社のウェブサイトユーザーの中には、チャイナテレコムのネットワークを使用する人、チャイナユニコムのネットワークを使用する人、教育ネットワークを使用する人、南部にいる人、北部にいる人がいる可能性があり、この複雑なネットワーク環境によりウェブサイトにアクセスすることがあります。速度が異なります。たとえば、テレコム ユーザーがテレコムのコンピュータ ルームにアクセスする場合、大きなファイルを問題なくアップロードできる人もいます。ただし、チャイナユニコムからチャイナテレコムのコンピュータ室へのアクセスが遅くなる場合があり、大きなファイルをアップロードする際にアップロードのタイムアウトや切断などの問題が発生する可能性があります。

サーバー負荷の問題に関しては、現在の通常のファイルアップロード技術では依然としてサーバーに大きな負荷がかかります。通常の HTML で 1G ファイルをアップロードするには、サーバーは最初に 1G のメモリを割り当て、次に長い接続を開き、クライアントがアップロードを完了するのを待つ必要があります。この期間中に、他のユーザーも 1G ファイルをアップロードしたい場合、サーバーはさらに 1G のメモリを割り当てます。ユーザーが多すぎると、サーバーが問題を処理できなくなることが考えられます。 swfupload やその他の Flash コントロールなどの Flash を使用する場合でも、使用されるテクノロジは通常の HTML と同じです。

Tencent はこの問題を検討しており、コントロールを使用してこの問題を解決しています。このコントロールを使用して、1G などの大きなファイルを多数の小さな部分 (それぞれの小さな部分は約 128 KB) に分割し、アップロードが完了するまでループしてアップロードします。この利点は、サーバーへの負荷が軽減され、サーバーの負荷容量が向上し、サーバーがより多くのユーザー要求を処理できるようになることです。コストも節約できます。

コントロールを使用せずに、フラッシュだけで実現できるようですか? 従来の HTML 方式では、非常に大きなファイルをアップロードするニーズを満たすことができなくなりました。 100MB は言うまでもなく、50MB はサーバーにとって非常に大きいため、サービスは専用のソケット接続を開いてファイルがアップロードされるのを待つ必要があるだけでなく、ファイルを保存するために同じサイズのメモリを割り当てる必要があるため、かなりの負荷がかかります。ユーザー数が増加するにつれて、この圧力は幾何級数的に増加します。 Flash を使用する場合でも、現在の Flash はブレークポイント再開操作をサポートしておらず、Flash のアップロード原理も従来の HTML のアップロード原理と同じであるため、機能しません。 Flash を使用して 100MB の画像をアップロードするには、サーバーも 100MB のメモリを割り当てる必要があります。 10 人のユーザーが同時に 100MB のデータをアップロードすると、1G のサーバー メモリが消費されます。
Flash をアップロードすると、ファイル全体がメモリに追加されます。これは深刻な問題です。ユーザーが 5G ファイルをアップロードしたい場合、Flash はすべての 5G ファイルもメモリにロードするためです。これはユーザーの操作体験に重大な影響を与えます。なぜなら、この時点でユーザーのコンピュータは仮死状態になるからです。平均的なユーザーのコンピュータには 2G しか搭載されていないため、メモリ不足またはメモリ オーバーフローが原因で直接ハングします。

一部の友人は、Flash ファイル アップロード コントロールを使用して非常に大きなファイルをアップロードしようとしましたが、アップロード タイムアウトやアップロード エラーが頻繁に発生しました。これは、現在の Flash ファイル アップロード コントロールが従来の HTML アップロード方法と同じテクノロジーを依然として使用しているためです。サーバーが接続を開いて、クライアントがファイルの転送を完了するまで待ちます。ただし、実際のネットワーク環境では、ユーザーのネットワーク速度はわずか 50KB/S で、200MB のファイルをアップロードするのに 2.8 時間かかる場合があります。ただし、サーバーの SESSION 接続がユーザーを 2.8 時間待つことは不可能であり、これはパケット損失などの複雑なネットワーク環境を考慮していません。パケットロスやネットワーク異常が発生した場合、ユーザーの以前の 100MB ファイルが無駄に転送されてしまいます。これはユーザーの時間を 1 時間無駄にしていることに相当します。ユーザーに非常に劣悪なエクスペリエンスをもたらします。
サーバーの場合、接続リソースは非常に限られており、サーバーがユーザーを 2.8 時間待機できる場合でも、ユーザーが広い領域にアクセスし、各ユーザーが接続を占有し、これほど長い時間がかかると、サーバーの同時処理能力が低下します。とても低くなってしまいました。他のユーザーが単純な 1KB の HTML ページをリクエストした場合でも、サーバーが前のユーザーのリクエストを処理するまで待たなければなりません。

同時に、Flash は非常に大きなファイルのアップロードのニーズを満たすことができません。非常に大きなファイルをアップロードする必要があるため、データ転送の安定性を確保することが要件の 1 つです。たとえば、ユーザーが 1G ファイルをアップロードし、既に 500MB をアップロードしたとします。この時点でネットワークが突然切断されましたが、ユーザーは次回ファイルをアップロードするとき、つまり最後にアップロードした位置からファイルが転送されることを期待します。 、転送は 500MB の位置から開始されます。1 つの要件は、Flash では実行できないことです。

QQ メールボックスの特大添付ファイルのアップロード機能、115 Netdisk、Huawei Netdisk (DBank)、および Kingsoft Express の特大添付ファイルのアップロード コントロールと同様に、これらはすべてコントロールを使用して特大ファイルのアップロード機能を実装しています。これは主に、サーバーへの負荷を軽減し (サーバーの応答時間が速くなり、同時処理能力が強化されます)、サーバーのメモリを節約します (サーバーは各ユーザーのファイルと同じサイズのメモリを割り当てる必要がなくなります)。 、同時にユーザー エクスペリエンスも向上します (ユーザーは、ネットワーク環境で非常に大きなファイルをアップロードするなどの複雑なタスクを処理できます)。

もちろん、技術的な観点から、このような有名なインターネット企業は、多数のユーザーをサポートするための分散ファイル ストレージ アーキテクチャの設計も検討しています。ファイル ストレージ サーバーを 1 つにすることはできず、ユーザー数の増加に応じて動的に増加するためです。

一部の友人が言ったように、Flash コントロールが非常に大きなファイルのアップロードの問題を解決できるのであれば、Tencent は QQ メールボックス専用のコントロールの開発にそれほど多くの労力を費やす必要はありません。

コントロールを使わずに、フラッシュだけで実現できるようですか？ PHP または Flash を使用してブレークポイント再開転送を実装する場合の最大の問題は、一度に 1GB のデータを Web サーバーに転送する方法です。 Flash はセキュリティの問題により、非常に大きなファイルの処理パフォーマンスに大きな問題を抱えています。

Flash もコントロールのカテゴリに属します
再開可能なアップロードは、再開可能なダウンロードよりも実装が簡単です

再開可能な限り、それは双方の問題であり、両端がそれをサポートする必要があります