Porque é que a perda de pacotes torna uma ligação de servidor doméstico rápida mais lenta?

A perda de pacotes desacelera uma ligação de servidor doméstico que seria rápida porque a velocidade da ligação mede a rapidez com que a interface pode transmitir bits, enquanto o rendimento útil depende da quantidade de dados da aplicação que chegam corretamente e de como o protocolo de transporte reage quando os pacotes desaparecem.

Os transportes fiáveis repetem os dados em falta e geralmente reduzem a sua taxa de envio porque a perda pode sinalizar congestionamento. Uma interface 1GbE ou 10GbE pode assim manter-se totalmente negociada enquanto uma cópia de ficheiro, uma cópia de segurança remota, uma sessão web ou um fluxo de media entrega apenas uma fração do seu desempenho útil esperado.

Porque é que a velocidade da ligação pode manter-se alta enquanto o rendimento útil cai?

A largura de banda é a capacidade nominal do caminho, enquanto o bom rendimento conta apenas a carga útil útil da aplicação entregue com sucesso. Num experimento controlado de qualidade de caminho, o rendimento útil pode colapsar antes de a velocidade da ligação mudar porque mesmo uma pequena taxa de perda interrompe repetidamente o fluxo de transporte.

Bytes retransmitidos, dados duplicados, cabeçalhos e lacunas de recuperação consomem tempo sem avançar o ficheiro concluído ou a resposta da aplicação. Os contadores da interface podem ainda mostrar tráfego substancial mesmo quando o recetor recebe dados úteis lentamente.

Um teste de velocidade também pode ocultar o problema ao usar vários fluxos paralelos, um servidor próximo ou um intervalo de teste curto. Uma transferência única e prolongada para um ponto final distante está mais exposta a perdas repetidas e recuperação de ida e volta.

Que trabalho é que o transporte fiável repete após uma perda?

O TCP e os fluxos QUIC fiáveis monitorizam quais os dados que chegaram ao recetor. Quando é detetada uma lacuna, os dados perdidos devem ser transmitidos novamente, consumindo largura de banda adicional e atrasando a conclusão.

O emissor pode detetar a perda através de reconhecimentos duplicados, reconhecimentos seletivos, um temporizador de perda QUIC ou um tempo limite de retransmissão. A deteção rápida limita a pausa, enquanto um tempo limite pode adicionar um atraso muito maior antes do emissor tentar novamente.

A retransmissão não substitui apenas um pacote em falta isoladamente. O pacote original já utilizou a capacidade da ligação, a substituição volta a utilizá-la, e pacotes próximos também podem ser retransmitidos quando o emissor não consegue identificar a perda com precisão.

Porque é que o TCP reduz a sua taxa de envio após a perda de pacotes?

O TCP clássico trata a perda como evidência de que demasiados dados podem estar a entrar no caminho. o controlo de congestionamento baseado em perdas reduz a taxa de envio para que o emissor pare de alimentar um possível gargalo à taxa anterior.

A janela de congestionamento controla a quantidade de dados não reconhecidos que podem permanecer em trânsito. Reduzir essa janela pode diminuir o débito muito mais do que a percentagem de pacotes realmente perdidos, porque o emissor tem depois de aumentar a janela novamente em rondas de reconhecimento posteriores.

Diferentes algoritmos reagem de forma diferente: Reno, CUBIC, variantes BBR e implementações QUIC não usam sinais ou reduções idênticas. O limite geral mantém-se que um link físico rápido não pode entregar a sua capacidade quando o transporte limita deliberadamente os dados em trânsito.

Como é que o tempo de ida e volta amplifica a recuperação de perdas?

Um emissor fica a saber da entrega através de feedback que viaja até ao recetor e volta. um RTT mais elevado prolonga cada ciclo de recuperação porque cada ajuste da janela e confirmação de retransmissão consome outra parte do RTT.

Numa ligação Ethernet local curta, uma retransmissão rápida pode completar-se rapidamente a ponto de ser quase impercetível. A mesma perda numa VPN, backup remoto, montagem na cloud ou ligação transcontinental pode atrasar o progresso por dezenas ou centenas de milissegundos.

A largura de banda elevada torna a penalização mais surpreendente porque mais dados poderiam estar em trânsito durante cada viagem de ida e volta. A perda esvazia ou reduz esse pipeline, e um caminho mais longo precisa de mais tempo para o reabastecer.

Porque é que um pacote em falta pode atrasar dados que já chegaram?

O TCP apresenta um fluxo de bytes ordenado à aplicação. um segmento em falta pode bloquear dados posteriores mesmo quando pacotes posteriores já chegaram ao recetor.

Esses bytes posteriores podem esperar num buffer de receção até que a lacuna seja reparada. Para HTTP/2, vários pedidos lógicos partilham uma ligação TCP, por isso uma perda ao nível do transporte pode atrasar streams de resposta independentes transportados atrás dos bytes em falta.

O QUIC evita o bloqueio de cabeça de linha no transporte entre streams porque os streams podem recuperar de forma independente, mas a perda ainda consome capacidade de retransmissão e orçamento de controlo de congestionamento. Remover um mecanismo de paragem não torna os pacotes perdidos gratuitos.

Porque é que as transferências de ficheiros, streams e aplicações UDP falham de forma diferente?

TCP e UDP expõem a perda de forma diferente. Uma transferência de ficheiros espera pelos bytes exatos, enquanto uma chamada ao vivo pode preferir um quadro danificado ou ignorado em vez de esperar por dados que já chegam tarde para serem reproduzidos.

A perda TCP aparece como débito mais baixo, buffering ou atraso na conclusão de páginas e ficheiros. A perda UDP pode aparecer como falhas de áudio, artefactos de blocos, jitter de controlo, telemetria perdida ou tentativas a nível de aplicação, dependendo da correção de erros e design de recuperação.

o tráfego local e da internet pode partilhar um único gargalo. Por isso, a perda de pacotes deve ser interpretada pelo caminho e carga de trabalho: uma cópia limpa na LAN não prova que o caminho remoto está limpo, e uma interface rápida não prova entrega fiável da aplicação.

Perguntas Frequentes

Pode 1% de perda de pacotes realmente causar uma queda muito maior no débito?

Sim, em algumas condições, especialmente para um fluxo TCP com RTT significativo. O impacto exato depende do algoritmo de controlo de congestionamento, padrão de perda, RTT, tamanho da janela, fluxos paralelos e funcionalidades de recuperação.

A perda de pacotes significa sempre que a rede está congestionada?

Não. O congestionamento é comum, mas a perda também pode resultar de interferência Wi-Fi, cabos danificados, óticas defeituosas, hosts sobrecarregados, NICs com falhas, problemas de MTU ou limites de software e drivers.

Porque é que um teste de velocidade paralelo pode parecer normal?

Múltiplos fluxos recuperam independentemente e podem coletivamente preencher a ligação mesmo quando cada fluxo tem desempenho fraco. Uma única ligação de aplicação pode não receber o mesmo benefício.

O UDP evita o custo de desempenho da perda de pacotes?

O UDP evita retransmissão incorporada e entrega ordenada, mas a aplicação perde dados ou tem de adicionar o seu próprio mecanismo de recuperação, ocultação, redundância ou tentativa.

Conclusão Final

A perda de pacotes transforma uma ligação rápida numa via de aplicação lenta ao desperdiçar capacidade de transmissão, forçar a recuperação fiável, reduzir as janelas de congestionamento e atrasar a entrega ordenada. A interface física pode manter a velocidade máxima enquanto os dados úteis chegam lentamente. O RTT, o protocolo de transporte, o padrão de perda e a carga de trabalho determinam se o resultado parece um débito baixo, buffering, latência longa ou falta de media em tempo real.