Como transferir dados entre duas redes eficientemente

0

Eu gostaria de transferir arquivos entre dois lugares pela internet. Agora eu tenho uma VPN e consigo navegar, baixar e transferir arquivos. Então, minha pergunta não é como transferir os arquivos; Em vez disso, eu gostaria de usar a abordagem mais eficiente, porque os dois lugares compartilham constantemente muitos dados.

A razão pela qual eu quero me livrar da VPN é porque ela é duas lenta. Ter alta velocidade de upload é muito cara / impossível em locais residenciais, então eu gostaria de usar uma abordagem diferente.

Eu estava pensando em usar programas como o link . O problema com o Dropbox é que a versão gratuita vem com apenas 2 GB de armazenamento. Eu acho que os acordos que eles oferecem estão OK e eu posso estar disposto a pagar para obter esse aumento de velocidade. Mas estou preocupado com a velocidade de transferência de dados. O Dropbox fará o upload do arquivo para o servidor e o enviará do servidor para o outro local. Eu gostaria que fosse ainda mais rápido.

Enfim, eu estava pensando por que não criar um programa sozinho. Este é o algoritmo que eu estava pensando. Deixe-me saber se parece muito louco.

(Lembre-se de que meu objetivo é transferir os arquivos o mais rápido possível)

Coisas que vou usar neste algoritmo:

  • Servidor na internet chamado S (Tem velocidade de download e upload rápido. Pago para hospedar um site e alguns serviços lá. Quero aproveitar isso.)
  • Cliente A no local 1
  • Cliente B na localização 2

Então, vamos dizer na localização 1, 20 arquivos grandes são criados e precisam ser transferidos para o local 2.

  • O cliente A compacta os arquivos com a maior taxa de compactação possível.
  • O cliente A começa a enviar dados via UDP para o cliente B.
  • Como estou usando o UDP, incluirei o número de sequência em cada pacote.
  • O servidor S ajuda a acelerar as coisas. Por exemplo, toda vez que um pacote é perdido, podemos usar o Servidor S para informar ao cliente A que ele precisa reenviar um pacote.

De qualquer forma, acho que essa abordagem aumentará a taxa de transferência. Não sei se é possível começar a enviar dados enquanto está sendo compactado. Ou se é possível começar a descomprimir dados mesmo se não terminarmos de receber o arquivo inteiro. Talvez seja mais rápido começar a enviar os arquivos imediatamente sem compactar. Se eu soubesse que sempre enviarei arquivos de texto grandes, obviamente usarei a compactação. Eu preciso disso como um algoritmo geral.

Então, eu acho que minha pergunta é eu poderia aumentar o desempenho usando UDP em vez de TCP e usando um servidor extra para acompanhar os pacotes perdidos? E como devo compactar arquivos antes de enviar? A compactação de um arquivo de 1 GB com a maior taxa de compactação leva cerca de 1 hora! Eu gostaria de aproveitar esse tempo enviando-o enquanto ele está sendo compactado.

    
por Tono Nam 05.09.2012 / 05:29

1 resposta

3

Use rsync . É muito eficiente no uso do TCP, transfere apenas os arquivos que foram alterados e você pode optar por usar a compactação se quiser.

Você não encontrará uma maneira de superar um aplicativo que usa o TCP com eficiência. O TCP foi definido e refinado ao longo dos últimos 40 anos por muitas pessoas realmente inteligentes, então é muito difícil de superar.

As pilhas TCP modernas que suportam SACK são muito eficientes na detecção e no envio de relatórios de pacotes perdidos entre si. apenas os pacotes perdidos são retransmitidos. Colocar um servidor no meio não acelera nada, apenas adiciona latência.

A única maneira de superar o TCP no desempenho de transferência de dados é agravando o congestionamento da rede. TCP vai o mais rápido possível, mas recua momentaneamente quando há sinais de congestionamento. Se você criou um protocolo baseado em UDP que não se importava com o quanto ele acrescentava ao congestionamento de links que ele percorresse, você poderia explodir pacotes que causam muitos problemas de congestionamento, mas em média obter uma taxa de transferência um pouco maior do que o TCP.

    
por 05.09.2012 / 10:42