Se ignorarmos a compactação de arquivos da camada de aplicativo (como Mega ou iCloud compactando um arquivo antes da transferência), o conteúdo de um arquivo afeta a velocidade de transferência?
ou seja - todas as coisas sendo iguais, a camada subjacente de internet/roteadores/phy, se importa se está transportando 1 GB de zerosvs 1 Gb de dados aleatórios de alta entropia?
Eu entendo que pode haver compactação, mas estou perguntando especificamente sem isso ativado.
Não, um byte sempre leva o mesmo tempo para ser transmitido, independentemente de seu valor, e um pacote de um determinado tamanho e tipo sempre leva o mesmo tempo para ser tratado, independentemente de sua carga útil.
No entanto, existem outras diferenças possíveis além da velocidade de transferência:
Algumas camadas físicas se importam. Uma longa sequência de bits idênticos pode fazer com que eles se dessincronizem, pois dependem da transição ocasional entre 0s e 1s, de modo que podem perder o controle de onde um bit, um byte ou um símbolo começa e onde termina. Para evitar que isso cause problemas, uma camada superior precisa embaralhar os dados (criptografá-los, de certa forma) para aumentar a entropia. Por exemplo, SONET tem esse problema.
Juniper: habilitando o embaralhamento de carga útil SONET
Cisco: Quando a codificação deve ser habilitada em circuitos virtuais ATM?
Wikipedia: codificação 64/66b – duração da execução ; Cisco Press: Pacote sobre SONET
"Um scrambler anterior usado no Packet over SONET/SDH (RFC 1619) tinha um polinômio curto com apenas 7 bits de estado interno que permitia que um invasor malicioso criasse um ataque de negação de serviço transmitindo padrões em todos os 2 7 −1 estados , um dos quais foi garantido para dessincronizar os circuitos de recuperação de clock. Essa vulnerabilidade foi mantida em segredo até que o comprimento do scrambler fosse aumentado para 43 bits (RFC 2615), tornando impossível para um invasor mal-intencionado bloquear o sistema com uma sequência curta."
Isso não se aplica a todas as camadas físicas, apenas a algumas.
Por exemplo, a Ethernet de fibra não é afetada devido ao uso da codificação 8b/10b . Em outros casos (como na Ethernet de cobre), o scrambling é construído diretamente na camada física, de modo que as camadas mais altas não precisam se preocupar com isso (assim como não deveriam).
Os links seriais (RS-232) usam 'bits de início/parada' explícitos pelo mesmo motivo.
Camadas mais altas não se importam. Todos eles foram construídos para transportar cargas arbitrárias e não há nenhuma razão específica para que, por exemplo, um segmento TCP contendo todos os 0s seja tratado de forma diferente do resto. (E mesmo esse segmento ainda tem um cabeçalho TCP e um cabeçalho IP que não são claramente nulos.)
Obviamente, isso também não é um problema se seus dados forem criptografados por uma camada intermediária (como sendo transferidos por TLS ou via Wi-Fi seguro), o que sempre faz com que pareçam de alta entropia para o exterior.
Como outros já disseram, a maioria das tecnologias de transmissão modernas são bastante determinísticas, e uma sequência de bits X sempre levará o mesmo tempo para transmitir, como está, ou se uma camada inferior exigir embaralhamento, mas aplicando uma proporção fixa.
No entanto, existem alguns casos em que pode haver um pequeno efeito, se alguns caracteres precisarem ser escapados. Este é, por exemplo, o caso de PPP, onde pelo menos
0x7De0x7Eprecisa ser escapado (o primeiro sendo o prefixo de escape e o último sendo o delimitador de quadro). Caracteres adicionais podem precisar ser escapados se o link exigir. Para esses caracteres, levará o dobro do tempo para transmiti-los. Como o PPP ainda é a base para PPPoA e PPPoE e usado em alguns cenários de última milha, isso pode ter um efeito muito pequeno. A menos, é claro, que seu arquivo seja apenas uma repetição de0x7Dou0x7E, nesse caso levará o dobro do tempo em comparação com um arquivo que não contém esses caracteres.Há também o caso de preenchimento de bits como usado, por exemplo, por HDLC e USB: o esquema de codificação NRZI não muda de nível quando uma série de uns é enviada, então depois de muitos uns, um zero é inserido para garantir que a sincronização não seja perdida. O pior caso aqui é que, se você enviar apenas um (ou seja, seu arquivo é apenas uma repetição de
0xFF), levará 20% a mais (HDLC, bit extra após 5 unidades) ou 17% mais longo (USB, bit extra após 6 unidades) do que se você enviar todos os zeros ou qualquer sequência que nunca inclua uma sequência de uns de 5 ou 6 bits.Antigamente, quando nem todos os links eram transparentes de 8 bits, os dados transmitidos podiam precisar de codificação em algumas situações (por exemplo, base64 para dados binários) e não em outras (por exemplo, ASCII puro enviado como está), com coisas como Quote-printable em entre (por exemplo, texto com alguns caracteres acentuados). Portanto, dependendo do que você enviou, exigiria mais ou menos caracteres/bits no fio. Mas isso deve ser extremamente raro hoje em dia (e era principalmente um problema para o correio).
Em todos esses casos, não é realmente a entropia que importa, mas o conteúdo real que corresponde a sequências específicas. Se você tiver dados de alta entropia (por exemplo, dados compactados ou criptografados), obterá uma velocidade média relativamente consistente , mesmo nesses casos. Se você tiver sequências específicas de dados (você envia 1 GB de
0x7DPPP ou 1 GB de0xFFHDLC, por exemplo), pode demorar mais. Se você evitar essas sequências completamente, pode ser mais curto.Observe que algumas camadas inferiores introduzem compactação mesmo que você não a use nas camadas superiores. Novamente, nos velhos tempos dos modems POTS (dial-up), os modems podiam usar compressão V.42bis entre eles. Existem provavelmente algumas outras tecnologias de transmissão que incluem compressão em uma camada relativamente baixa.
Muitas vezes há algo nessa música. Alguns exemplos:
.é maior que a taxa de dados de_, e esse não é o único protocolo com 0 e 1 exigindo tempo diferente.Geralmente, a compactação em tempo real seria possível em qualquer nível. E, na prática, pode acontecer abaixo da camada do aplicativo se sua conexão incluir o encaminhamento de porta ssh
ssh -C(habilitar a compactação, inclusive para encaminhamento de porta e X11).A compactação SSH usa apenas gzip, não um algoritmo moderno mais rápido como zstd ou lz4 projetado, então só vai acelerar as coisas com uma CPU rápida em comparação com a velocidade do link.
Protocolos de camada física/de link padrão como 802.3 ethernet ou 802.11 Wifi não usam compressão; custaria latência, exigiria hardware poderoso para acompanhar as taxas de dados de gigabit e qualquer ganho de tamanho em alguns casos pioraria o pior caso. O mesmo vale para protocolos de nível de link usados em links de fibra óptica de longa distância.
A compactação funciona muito melhor no nível do aplicativo, ou pelo menos para um túnel do tipo VPN em vários links de nível inferior.
As únicas coisas que podem acelerar a transferência são enviar menos pacotes (compressão no nível do aplicativo), enviar pacotes menores (menos bons e o que você provavelmente obteria com a compressão hipotética no nível do link após o enquadramento em quadros TCP) ou pacotes menores taxas de perda se fossem diferentes de zero.
A resposta do user1686 trouxe a possibilidade de alguns padrões de dados serem um problema para as codificações de nível de link, por exemplo, possivelmente você poderia criar pacotes que levam alguns equipamentos ao ponto de falha de comunicação, se eles já estiverem próximos de suas tolerâncias de tempo. Geralmente não é algo que você precisa se preocupar na Internet, AFAIK. Os links de fibra do mundo real geralmente são bem mantidos e têm uma taxa muito baixa de introdução de erros de bits que levariam a uma falha de checksum TCP, e isso provavelmente não depende de dados em nenhum grau significativo. (E depois de embaralhar, não depende de longas execuções de 0s ou 1s; isso acontece em dados não compactados da vida real, portanto, as funções de embaralhamento são projetadas para garantir que não sejam um problema.)