PHP アップロード ブレークポイント再開ソリューション

PHP アップロード ブレークポイント レジューム
はコントロールを使用せず、フラッシュでのみ実現できるようですか?

共有先:
-----解決策---------
もちろんです。 PHP はサポートしていません
-----解決策---------

引用:

コントロールを使用しない場合は、フラッシュのみを使用できるようですか?

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

引用:

コントロールを使用しない場合は、フラッシュのみを使用できるようですか?

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

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

Tengxun はこの問題を検討し、制御を使用してこの問題を解決しました。このコントロールを使用して、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 はセキュリティの問題により、非常に大きなファイルの処理パフォーマンスに大きな問題を抱えています。
------解決策---------
フラッシュもコントロール カテゴリに属します
アップロードを再開するのは、ダウンロードを再開するよりも簡単です

送信がブレークポイントから再開される限り、それは双方の問題であり、両端がそれをサポートする必要があります