Mitos e fatos sobre a velocidade da rede

Question

Eu gostaria de esclarecer algumas coisas, de uma vez por todas, para que eu possa descansar em paz e compartilhar esse conhecimento com outras pessoas sem me fazer de idiota:)

Meu provedor de internet afirma que sua velocidade de UL é de até 3 Mb / s. Eu li que a velocidade de rede (capacidade) de 3 Mb / s (3072 kb / s) é igual a ~ 384 KB / s como resultado de 3 * 1024/8 desde 1 byte = 8 bits. Agora vem as perguntas:

1. Por que os provedores de rede definem a capacidade da rede em bits / s, quando o que realmente nos importa são os bytes carregados / baixados?
2. Existem protocolos mais rápidos que o FTP para enviar arquivos grandes para / de um servidor remoto?

Espero ter sido claro, elaborarei meus pensamentos, se necessário

EDIT Fiz algumas pesquisas e isso revela que eu devo ter cometido alguns erros no cálculo devido ao mal-entendido das unidades, portanto, as duas primeiras perguntas sobre a velocidade UL são inúteis. Ainda restam dois ainda me bug

    

Answer 1

Especificando capacidade em bits / s -

David Schwartz está certo que bits / s são anteriores à Internet - e isso é parte da resposta - sistemas antigos nem sempre usam 8 bits para representar dados - Por exemplo, ASCII é de apenas 7 bits (Extended ASCII é 8 bits) .

Além disso, dispositivos seriais (e assim modems - que é como os dados eram transmitidos inicialmente de longa distância), tinham maneiras diferentes de representar dados (por exemplo N81 - Sem paridade, 8 bits de dados, 1 bit de parada, então um byte "de dados foi de 9 bits neste exemplo).

Então, claro, há compressão. Se você estivesse enviando texto padrão, poderia obter muito mais bytes na linha do que a taxa de bits declarada.

Em seguida, veio a Internet e agrupou os dados em pacotes - com sobrecargas adicionais para cada pacote. Dependendo do tamanho do pacote e do encapsulamento, a sobrecarga do pacote pode ser significativa.

Assim, o BPS é uma reflexão mais verdadeira do que está sendo vendido, em bytes / kilobytes por segundo.

Protocolos mais rápidos para enviar arquivos grandes

Não há uma única resposta correta para essa pergunta. Se o arquivo não puder ser compactado e o canal não estiver congestionado e as distâncias forem curtas, o FTP é muito bom.

Uma vez que você precisa lidar com o congestionamento, o jogo muda - Congestionamento geralmente significa perda de pacotes, o que sinaliza que o sistema deve ficar mais lento. Protocolos que se dividem em múltiplos fluxos fornecerão melhor rendimento (por exemplo, bittorrent, algumas implementações de downloads HTTP) e, é claro, compressão.

Dito isto, também há ajuste que às vezes pode fazer uma diferença significativa que fica abaixo do nível de TCP no qual o FTP funciona. (Esse é um tópico especializado, mas inclui coisas como MTUs maiores, mais buffer de pacote, tagging de QoS etc. - e o desempenho será tão bom quanto essas otimizações subjacentes permitirão.

    

Answer 2

Existem duas coisas diferentes que você pode medir. Uma é a velocidade da linha, normalmente medida em bits decimais por segundo. A outra é a taxa de dados efetiva, geralmente medida em bytes binários por segundo.

Por exemplo, o que é "gigabit Ethernet"? É Ethernet com uma velocidade de linha de um bilhão de bits por segundo. Quão rápido será o fluxo de dados através de Ethernet gigabit? Bem, 1.000.000.000 bits = 1.000.000.000 / 8 bytes. Então, 125.000.000 bytes por segundo fluirão a cada segundo. Como há 1.024 bytes em um kilobyte, são 122.070 KB por segundo. Dividindo novamente por 1.024, obtemos 119,2 MB / s.

Essa distinção antecede os ISPs. ISPs fornece linhas e seguiu a convenção existente para especificar taxas de linha.

    

Answer 3

Tem certeza que está obtendo 3 megabytes por segundo no seu torrent? Isso seria impossível em uma conexão de 3 megabits sem alguma compressão realmente boa. Eu suspeito que seu programa torrent está relatando em 3 megabits (Mb / MBit / Mbit) por segundo. Se você não tiver certeza, divida o tamanho do arquivo em megabytes pelo tempo que levou para fazer o download, que deve corresponder à sua velocidade média de download.

Os provedores medem a velocidade em bits porque existem várias maneiras diferentes de usar bits de codificação para obter seus bytes - alguns com mais eficiência do que outros. O melhor que você pode esperar para descompactar é 8 bits por byte, mas geralmente há alguma sobrecarga que pode variar dependendo de múltiplos fatores. Alguns protocolos de download têm mais correção de erros, o que consome mais bits por byte. Algumas pessoas estão usando VPNs, o que exige colocar dados dentro de outros dados. Alguns protocolos verificam o status com mais frequência do que outros, o que também aumenta a sobrecarga.

Independentemente de quão eficientemente ou ineficientemente os bytes são codificados, a velocidade máxima é determinada por quantos bits podem ir pelo pipe de cada vez, e é isso que os provedores usam.

Pense nisso como quando você está comprando um 32 oz. bebida da fonte no posto de gasolina. Eles te vendem uma taça que contém muito. Algumas pessoas usam muito gelo e algumas pessoas usam pouco ou nenhum. Pense no refrigerante como seus dados e no gelo como sobrecarga. Há boas razões para usar gelo e boas razões para ignorá-lo, mas o fato é que quanto mais você usa, menos refrigerante você se encaixa no copo. Não é do interesse da loja cobrar-lhe com base no que coloca no copo. Vai ser uma combinação de refrigerante, gelo e ar que não exceda 32 onças fluidas.

    

Answer 4

Why do net providers define the network capacity in bits/s, when what we really care about are the actual bytes uploaded/downloaded?

• O hardware de rede (e todo o hardware realmente) funciona fundamentalmente no nível de bits. Qualquer método de comunicação digital está preocupado em transmitir uma sequência de uns e zeros, e qualquer coisa mais abstrata que isso (por exemplo, 8 bits = 1 byte, etc.) é do interesse do remetente e do destinatário. Então, do ponto de vista dos projetistas de hardware de rede, olhar para as coisas como um fluxo de bits é mais importante do que como os aplicativos potenciais irão analisá-las.

• Todos os protocolos têm sobrecarga. Você pode transmitir 4Kbytes via TCP, mas devido aos cabeçalhos de protocolo, etc., os dados reais transferidos são mais de 4Kbytes. Para obter 4 reais Kbytes / seg. para você via TCP, a velocidade real tem que ser ligeiramente maior do que 4Kbytes por segundo. Com a variedade de protocolos em uso (TCP, FTP que adiciona mais sobrecarga, HTTP que adiciona mais sobrecarga, SSL que adiciona um pouco mais de sobrecarga, etc.), é difícil simplesmente responder a isso para usuários não técnicos.

• Além disso, parece melhor para ISPs contar números maiores para os não tecnicamente orientados - "esta conexão é de 3 milhões de bits por segundo" do que "3 megabytes por segundo"

Are there any protocols faster than FTP for sending large files to/from a remote server?

• Bittorrent é mais rápido se vários hosts tiverem o arquivo, porque ele pode fazer o download de várias fontes simultaneamente. Se apenas um host tiver o arquivo, ele não lhe dará uma vantagem de velocidade, mas será muito robusto.

• Compacte seus arquivos.

• Use protocolos que enviem somente informações delta quando possível, se você estiver fazendo algo como sincronizar arquivos. rsync faz isso.

• O FTP depende do TCP, que enfatiza a confiabilidade em relação ao desempenho. O UDP, devido à maneira como funciona, enfatiza o desempenho acima da confiabilidade. Não há um método comum de transferência de arquivos baseado em UDP bem suportado além do TFTP que você não deve usar na Internet. Você pode olhar para este , mas não é algo que eu tentei (EDIT: olhando para isso um pouco mais não tenho certeza se a linha de comando ou outras ferramentas existem para isso, parece ser uma biblioteca.)