Como ler a perda de pacotes antes de culpar o cabo

Uma perda de dois por cento ao longo de uma sequência longa de ping parece um número sobre o qual se pode agir, e raramente é. Ele não diz onde as respostas desapareceram, se desapareceram juntas nem como uma aplicação concreta viveu aquele intervalo. Uma perda distribuída uniformemente por um minuto e uma perda concentrada dentro de uma única troca produzem resultados muito diferentes para a mesma percentagem.

Compare três medições em vez de confiar numa: o que a sonda viu, o que os contadores da interface fizeram e o que a aplicação realmente esperou.

O que uma percentagem de ping realmente mede

Uma sonda de eco testa uma direção de um protocolo com um tamanho de pacote, ao ritmo que tiver escolhido. Um túnel que transporta um envio grande faz algo completamente diferente, e uma ligação que descarta sondas pequenas não é necessariamente a ligação que está a prejudicar a transferência. A percentagem também esmaga a informação de tempo que mais importa, porque dez respostas perdidas numa rajada não são o mesmo que dez respostas perdidas com uma hora de intervalo. Também não lhe pode dizer que lado do túnel descartou algo.

Guarde o resultado da sonda como uma pista sobre o caminho. Depois procure o momento e o limite que o produziram.

Compare diferenças de contadores, não totais de vida

Recolha leituras com marca temporal antes e depois da janela em que o sintoma apareceu, em ambas as extremidades e em qualquer porta de comutador que controle. Registe o volume de tráfego juntamente com erros, descartes e alterações de estado da ligação, porque um total diferente de zero acumulado ao longo de meses descreve história, não este incidente. Um contador que se moveu em três durante a pausa é uma observação diferente de um contador que marca três mil e nunca mudou.

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

Os pacotes descartados por erros de receção e os pacotes descartados por outros motivos vivem em contadores separados, e essa distinção altera o seguimento. Os contadores de erros apontam para a camada física ou para a camada do controlador, enquanto a pressão das filas e os descartes por política apontam para algum lugar acima. Preserve também a direção e o nome da interface, porque um aumento de erros de receção numa ligação ascendente e um contador de pacotes de túnel não são intercambiáveis.

Se um controlador expuser contadores físicos detalhados, leia-os através da documentação desse adaptador. Atribuir um único significado a cada campo chamado “drop” em dois fabricantes é como uma peculiaridade contabilística normal se transforma num diagnóstico de hardware.

Como um segmento perdido se torna uma espera longa

Uma aplicação pode esperar muito mais do que uma única viagem de ida e volta depois de perder um segmento. O TCP estima o tempo de ida e volta, calcula um temporizador de retransmissão a partir dessa estimativa e recua quando uma retransmissão também falha, pelo que um único segmento perdido no momento errado pode parar um pedido durante um intervalo notório. Esse mecanismo está especificado no RFC 6298, e explica porque é que uma taxa de perda que parece trivial ainda pode ser sentida.

No entanto, nem toda a pausa é um limite de tempo de retransmissão. A mesma espera pode vir da resolução de nomes, de um servidor lento ou de uma aplicação que tenta novamente o seu próprio pedido após uma falha. Separe esses casos alinhando a operação falhada com as observações de transporte e com os eventos de sessão do próprio túnel. Uma interrupção no caminho de dados sem reconexão é um evento diferente de um novo aperto de mão e de uma troca de credenciais.

Onde a captura é permitida, mantenha-a estreita. O que precisa é de saber se os pacotes ou confirmações esperados param num limite concreto, não o facto de existir alguma retransmissão em algum lugar de um registo ocupado.

Altere um limite sem mover os outros

Se as provas apontarem para uma ligação local, substitua um cabo ou porta aprovados como comparação controlada e deixe todo o resto em paz. Mantenha a extremidade, a aplicação e a carga de trabalho comparáveis, e altere exatamente um limite por tentativa. Comparar um portátil com cabo com um sem fios enquanto também muda saídas e protocolos não lhe diz nada que possa atribuir.

Contadores locais limpos não certificam o resto do caminho. Limitam a parte que vê, e o relatório honesto diz que limites foram observados e quais não foram. O que quer no final é uma afirmação de que uma observação mudou quando ocorreu uma intervenção, não uma anedota sobre um cabo mau elevada a regra universal.