Eu teria problemas se um download for mais rápido que a velocidade de gravação do dispositivo para o qual ele está gravando?

Question

E se eu estivesse baixando um arquivo diretamente para um dispositivo que tenha uma velocidade de gravação consideravelmente mais lenta que a velocidade de download da conexão com a Internet.

• Os dados de gravação pendente foram movidos para um buffer ou armazenamento temporário?

• Esse comportamento depende do sistema operacional ou do navegador ou talvez de alguma outra coisa?

E se houver algum problema, há algo que eu possa fazer para evitar isso?

    

Answer 1

Até certo ponto, o que acontece depende do SO e da aplicação. No entanto, pode-se fazer a seguinte sequência de previsões:

1. Primeiro, a pilha 's janela de recepção irá encher, com algo um pouco menor que a taxa de dados completa da rede. Ele preenche mais lento que a taxa de linha da rede devido ao algoritmo de início lento do TCP e outros efeitos da maneira como pilhas TCP / IP se comportam.

   A janela TCP pode ter até 128 KiB (menos 1 byte) na minha caixa Linux. (Diga sysctl net.core.rmem_max para obter o valor da caixa .) Geralmente, ele é menor que esse valor máximo. O padrão é 4 KiB na minha caixa. (Diga sysctl net.ipv4.tcp_rmem para obter esse valor.)

2. Seu aplicativo terá algum buffer próprio. Pode ser de apenas 1 byte, mas não pode ser zero. O Linux precisaria de um syscall de cópia zero como recvfile() para evitar a necessidade de buffer de aplicativo, e ele não tem isso.

   O tamanho do buffer é totalmente do programador da aplicação. Nos programas que escrevi, usei de cerca de uma dúzia de bytes até 64 KiB, dependendo das necessidades do aplicativo. Inferi o uso de buffers muito maiores (Mi1 MiB) em outros aplicativos, observando como eles se comportam.

3. O aplicativo certamente usará algum tipo de mecanismo de E / S em buffer para gravar o arquivo, como C 's stdio . Isto é tipicamente pelo menos 1 KiB, e pode ser vários KiB. Na minha caixa aqui, parece que o padrão é 8 KiB.

   É possível que o aplicativo esteja usando E / S sem buffer ou esteja constantemente liberando os buffers de E / S para o disco, mas isso é incomum.

4. O driver de dispositivo para o dispositivo de armazenamento pode ter algum buffer. Provavelmente não é muito, mas um buffer página de 4 KiB não seria irracional.

5. O próprio dispositivo de armazenamento quase certamente tem algum cache. Os discos rígidos modernos têm caches na ordem de algumas dezenas de megabytes, por exemplo. Se você estiver escrevendo em um dispositivo RAID, pode haver um cache de write-back ainda maior também.

Todos os cinco desses buffers precisam ser preenchidos antes que o desempenho bruto de E / S do dispositivo de armazenamento subjacente possa ter algum efeito. Como eles poderiam facilmente adicionar até 100 MiB ou mais, você precisará testar com um tamanho de transferência maior do que isso, se quiser ter certeza de que não está apenas testando o comportamento combinado desses buffers.

Depois de abordar tudo isso, responderei à sua pergunta de nível superior: contanto que você esteja usando um protocolo de rede com mecanismo de controle de fluxo - por exemplo TCP - não deve haver nenhum problema resultante do cenário que você propõe. No entanto, se você estiver usando um protocolo de rede não confiável como UDP , e o protocolo de aplicação construído sobre ele não fornece seu próprio mecanismo de controle de fluxo, o aplicativo pode ser forçado a soltar pacotes nesta situação.

    

Answer 2

O que eu esperaria que acontecesse é de uma a duas coisas:

1. O processo que solicita os dados armazenaria o "excesso" na memória.

   ou mais provável:

2. O processo que solicita os dados só solicitaria dados quando fosse possível processá-los, de modo que a velocidade de download fosse efetivamente reduzida à velocidade de gravação do dispositivo.

O que realmente acontece depende do aplicativo que faz as operações de download e gravação, a menos que você tenha um aplicativo específico em mente, a segunda parte da sua pergunta não pode ser respondida.

    

Answer 3

OS / app simplificarão a velocidade de download. Basta baixar um arquivo de uma LAN de 1 Gbit para um pendrive USB1 antigo e ver por si mesmo.

    

Answer 4

Se o protocolo subjacente for TCP (por exemplo, HTTP), não haverá problema. Seu downloader tem um buffer na memória onde armazena temporariamente os dados que foram baixados. Ele continuamente grava dados desse buffer em disco. Se o disco estiver lento, o buffer ficará cheio e o downloader não solicitará que o sistema operacional receba mais dados do servidor remoto. Isso significa que um buffer semelhante no driver TCP do Windows é preenchido. O protocolo TCP garante que você não terá problemas se os buffers de alguém ficarem cheios:

link

TCP uses an end-to-end flow control protocol to avoid having the sender send data too fast for the TCP receiver to receive and process it reliably. Having a mechanism for flow control is essential in an environment where machines of diverse network speeds communicate. For example, if a PC sends data to a smartphone that is slowly processing received data, the smartphone must regulate the data flow so as not to be overwhelmed.

TCP uses a sliding window flow control protocol. In each TCP segment, the receiver specifies in the receive window field the amount of additionally received data (in bytes) that it is willing to buffer for the connection. The sending host can send only up to that amount of data before it must wait for an acknowledgment and window update from the receiving host.

Assim, quando o buffer do driver TCP estiver cheio, ele não reconhecerá ao outro computador que está pronto para receber mais dados.

Se o protocolo subjacente é algo mais especial / proprietário, então todas as apostas estão desativadas - porque esta é uma característica do TCP.