Execute Path MTU Discovery sem depender de erros ICMP, que muitas vezes não são entregues.
Este programa executa a descoberta de MTU do caminho da camada de empacotamento conforme descrito no RFC 4821, que é uma maneira mais confiável de detectar o tamanho do MTU na presença de buracos negros ICMP.
Embora as conexões TCP ajustem automaticamente o tamanho da MTU ao longo do tempo, dependendo de vários indicadores (desempenho da rede, perda de pacotes, mensagens de erro ICMP, ...), este não é o caso dos protocolos sem conexão.
Quando o desempenho é essencial, a taxa de transferência , a fragmentação de pacotes e a confiabilidade da rota são três indicadores-chave a serem analisados para otimizar o desempenho do fluxo. Como a confiabilidade da rota nem sempre depende de nós, devemos nos esforçar para maximizar o rendimento e NÃO realizar a fragmentação de pacotes , o que pode degradar gravemente o desempenho [1] .
A proposta original para Path MTU Discovery dependia de pacotes ICMP Fragmentation Needed
a serem entregues quando um pacote IPv4 com o campo Don't Fragment definido era muito grande para ser propagado. Infelizmente, alguns roteadores não geram esse tipo de erro, mas optam por ignorar silenciosamente pacotes grandes. Um cliente não tem como determinar a causa da perda de pacotes.
Como todos os hosts são obrigados a suportar consultas ICMP_ECHO, podemos explorar o fato de que as mensagens ICMP aceitam uma quantidade arbitrária de dados e enviam pacotes de tamanhos diferentes para o nosso servidor. Se ativarmos o campo Não fragmentar no pacote IPv4 e ouvirmos uma resposta, estaremos de fato aguardando um ACK (na forma de um pacote ICMP_ECHOREPLY) confirmando que esse tamanho de MTU é válido.
Agora basta realizar uma busca binária em relação ao tamanho dos pacotes para encontrar o tamanho máximo de MTU suportado por esta rota.
Quando no modo ICMP, algumas solicitações ICMP_ECHO de tamanhos diferentes são geradas.
ICMP Fragmentation Needed
), esse tamanho de MTU será declarado inválido e o limite será reduzido.O único requisito do modo ICMP é que o host seja capaz de responder às mensagens de ping.
O mesmo algoritmo se aplica aos pacotes UDP, mas você precisa executar um servidor ( udp_server.py ) no host receptor para enviar mensagens de confirmação.
Este programa deve funcionar bem na maioria das distribuições Linux e OSX.
gcc -Wall -Wextra mtu_discovery.c mtu.c -o plpmtu
Não deve relatar avisos/erros. Se isso acontecer, abra um problema.
Se você deseja executar no modo ICMP , digite:
sudo ./plpmtu -p icmp -s <server-ipaddr>
Se você quiser executar o modo UDP :
sudo ./plpmtu -p udp -s <server-ipaddr:port>
Direitos de administrador são necessários para usar soquetes brutos.
Especificador | Descrição |
---|---|
-p {icmp/udp} | Selecione em qual modo operar. |
-s <endereço[:porta]> | Especifique o endereço do servidor. Se estiver executando no modo UDP, você também deve especificar a porta de destino anexando ':port' (por exemplo -s 8.8.8.8:12345 ) |
-l <endereço:porta> | Opcional. Selecione em qual endereço vincular(); usado no modo UDP; poderá ser removido. |
-t <tempo limite> | Opcional. Selecione o tempo máximo de espera por uma resposta do servidor, o padrão é 1 segundo; o tempo é expresso em milissegundos. |
-r <max-reqs> | Opcional. Selecione o número máximo de tentativas malsucedidas necessárias para declarar um tamanho de MTU inválido; o padrão é 3 tentativas. |
sudo ./plpmtu -p icmp -s 184.12.26.131
Execute a descoberta de MTU (modo ICMP) com 184.12.26.131.
sudo ./plpmtu -p udp -s 184.12.26.131:24000 -t 1500 -r 5
Execute a descoberta de MTU (modo UDP) com 184.12.26.131 na porta 24000. Se uma resposta não for recebida dentro de 1,5 segundos por 5 vezes consecutivas, reduza o limite de MTU.