ダウンロードが書き込み先のデバイスの書き込み速度よりも速い場合、問題が発生しますか？

インターネット接続のダウンロード速度よりも書き込み速度がかなり遅いデバイスにファイルを直接ダウンロードしていた場合はどうなりますか。

• 書き込み保留データはバッファまたは一時ストレージに移動されていますか？

• この動作は、OSやブラウザ、あるいは他の何かに依存していますか？

また、問題がある場合、それを防ぐためにできることはありますか？

ある程度までは、OSとアプリケーションに依存します。ただし、次の予測シーケンスを作成できます。

1. 最初に、スタックの受信ウィンドウがいっぱいになり、ネットワークの完全なデータレートよりも少し低くなります。それはいっぱいに遅くによるネットワークのラインレートよりもTCPスロースタートアルゴリズムとTCP / IPスタックが振る舞う方法の他の効果。

   TCPボックスは、Linuxボックスでは最大128 KiB（1バイト未満）になります。（ボックスの値sysctl net.core.rmem_maxを取得するようにしてください。）ただし、通常はこの最大値よりも小さくなります。私のボックスでは、デフォルトは4 KiBです。（sysctl net.ipv4.tcp_rmemその値を取得すると言います。）

2. アプリケーションには、独自のバッファリングがあります。最小1バイトですが、ゼロにすることはできません。Linuxではrecvfile()、アプリケーションのバッファリングの必要性を回避するために、ゼロコピーシステムコールが必要になりますが、それはありません。

   バッファサイズは、アプリケーションプログラマ次第です。私が書いたプログラムでは、アプリケーションのニーズに応じて、およそ12バイトから64 KiBまでの範囲で使用しました。他のアプリの動作を観察することで、他のアプリで非常に大きなバッファー（約1 MiB）の使用を推測しています。

3. アプリケーションは、ほぼ確実に、Cのstdioなど、何らかの種類のバッファーI / Oメカニズムを使用してファイルを書き込みます。通常、これは少なくとも1 KiBであり、数KiBになる場合があります。このボックスでは、デフォルトで8 KiBに設定されています。

   アプリケーションがバッファなしI / Oを使用しているか、I / Oバッファを常にディスクにフラッシュしている可能性がありますが、これはまれです。

4. ストレージデバイスのデバイスドライバーには、バッファリングが含まれている場合があります。おそらくそれほど多くはありませんが、4 KiBの単一ページバッファーは不合理ではありません。

5. ストレージデバイス自体には、ほぼ確実にキャッシュがあります。たとえば、最近のハードドライブには数十メガバイトのキャッシュがあります。RAIDデバイスに書き込む場合は、さらに大きなライトバックキャッシュも存在する可能性があります。

これらの5つのバッファはすべて、基礎となるストレージデバイスの生のI / Oパフォーマンスが影響を与える前にいっぱいになる必要があります。最大100 MiB以上を簡単に追加できるため、これらのバッファーの組み合わせ動作をテストするだけではないことを確認したい場合は、これよりも大きい転送サイズでテストする必要があります。

すべてのことをカバーした、私はあなたのトップレベルの質問にお答えします：限り、あなたはとネットワークプロトコルを使用しているとして、フロー制御メカニズム-例えばTCPを -あなたは断定シナリオから生じる問題はないはずです。ただし、UDPなどの信頼性の低いネットワークプロトコルを使用しており、その上に構築されたアプリケーションプロトコルが独自のフロー制御メカニズムを提供していない場合、アプリケーションはこの状況でパケットのドロップを強制される可能性があります。

私が起こることを期待するのは、1つから2つのことです。

1. データを要求するプロセスは、メモリ内の「過剰」をバッファリングします。

   またはより可能性が高い：

2. データを要求するプロセスは、データを処理できた場合にのみデータを要求するため、ダウンロードの速度はデバイスの書き込み速度まで効果的に低下します。

実際に何が起こるかは、ダウンロードおよび書き込み操作を行うアプリケーションに依存するため、特定のアプリケーションを念頭に置いていない限り、質問の2番目の部分は答えられません。

OS /アプリは単にダウンロード速度を調整します。1Gbit LANから古いUSB1ペンドライブにファイルをダウンロードして、自分で確認してください。

基礎となるプロトコルがTCP（HTTPなど）の場合、問題はありません。ダウンローダーには、ダウンロードされたデータを一時的に保存するバッファーがメモリにあります。このバッファからディスクにデータを継続的に書き込みます。ディスクが遅い場合、バッファーがいっぱいになり、ダウンローダーはオペレーティングシステムにリモートサーバーからのデータの受信を要求しません。つまり、Windows TCPドライバーの同様のバッファーがいっぱいになります。TCPプロトコルは、誰かのバッファーがいっぱいになっても問題がないことを保証します。

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Flow_control

TCPは、エンドツーエンドのフロー制御プロトコルを使用して、送信者がデータを高速に送信してTCP受信者がデータを確実に受信および処理できないようにします。さまざまなネットワーク速度のマシンが通信する環境では、フロー制御のメカニズムを持つことが不可欠です。たとえば、PCが受信したデータをゆっくり処理しているスマートフォンにデータを送信する場合、スマートフォンはデータフローが圧倒されないように調整する必要があります。

TCPは、スライディングウィンドウフロー制御プロトコルを使用します。各TCPセグメントで、受信側は、受信ウィンドウフィールドで、接続用にバッファリングする追加受信データの量（バイト単位）を指定します。送信ホストは、受信ホストからの確認応答とウィンドウの更新を待機する前に、そのデータ量までしか送信できません。

そのため、TCPドライバーのバッファーがいっぱいになると、他のコンピューターにデータを受信する準備ができたことを認識しません。

基礎となるプロトコルがより特別/独自のものである場合、すべての賭けはオフです-これはTCPの機能であるためです。