Existe algum padrão “típico” ou “de fato” para o tamanho da MTU?

Question

1. Ao escrever um software de rede, existe um padrão, típico ou padrão de fato para tamanho de MTU, do qual eu deveria estar ciente? Se assim for, o que é?

2. É um tamanho de MTU de 1500 (conforme sugerido aqui: Qual é o Máximo MTU suportado em Padrões DSL ) uma boa regra prática?

3. Além disso, estou pensando demais sobre esse problema? Esta é uma daquelas coisas que as pessoas pensam ser importantes quando escrevem software de rede, mas em termos práticos e reais, não acaba importando muito, já que o TCP cuidará dos detalhes para você? / p>

Eu pergunto aqui, em vez de no StackOverflow, porque eu quero o ponto de vista do sysadmin quando se trata de problemas reais de suporte relacionados ao tamanho da MTU.

UPDATE: com base em alguns comentários e respostas iniciais, estou estreitando um pouco o foco:

• O aplicativo que estou escrevendo se comunicará entre desktops / servidores por uma conexão WAN
• É um software típico de desktop / servidor (ou seja, não móvel) e, embora seja possível que um laptop conectado use esse software em uma rede móvel, não estou preocupado com isso
• Nem sequer tentará lidar com qualquer camada da pilha TCP, além da camada de aplicação, para otimização
O
• sobrecarga de VPN pode ser descartado para o escopo desta questão

Answer 1

Você não deve se preocupar com o MTU, pois a pilha de rede cuidará das otimizações necessárias. Se você estiver usando TCP, a pilha pode usar métodos para o cálculo do Tamanho Máximo do Segmento (MSS), o que, por sua vez, idealmente resultará em pacotes menores que o MTU mais baixo no caminho. Uma delas é a descoberta da PMTU .

Em geral, você não deve tentar enganar a pilha - a arquitetura em camadas do TCP / IP emprega as abstrações por boas razões. A menos que você tenha melhores, você deve deixar a funcionalidade de segmentação e fragmentação onde foi projetada.

Como outros escreveram, não há "MTU seguro" para assumir além da MTU mínima definida para pacotes IP - que é 68 bytes e, portanto, tem um valor prático bastante baixo devido à enorme sobrecarga.

Problemas típicos de suporte devido às limitações do MTU são principalmente duplos:

• fragmentação desnecessária e, portanto, maior sobrecarga de protocolo e maiores latências para os protocolos de pingue-pongue
• transmissões interrompidas devido a administradores de firewall ignorantes filtrarem o ICMP e, assim, interromperem a descoberta da PMTU ao longo do caminho

Ambos os fatores não são nada com os quais você deve lidar em um aplicativo.

    

Answer 2

Essa é uma questão bastante ampla.

1500 é comum? Sim, absolutamente, para Ethernet tradicional em uma LAN.

É seguro assumir 1500 ou esperar por alguma conexão? Não. Usuários móveis que se conectam de qualquer lugar podem ter MTUs diferentes em momentos diferentes.

Às vezes, reduzimos o MTU para servidores de datacenter que podem fornecer serviços a escritórios remotos em uma conexão VPN.

As conexões VPN em geral provavelmente terão uma MTU reduzida, e elas estão em todo lugar. Pode ser 1410, 1390, 1362 ou algum outro número curioso.

Se você estiver interessado no tamanho máximo de carga útil para uma determinada conexão tcp, provavelmente encontrará o Tamanho máximo negociado do segmento mais significativo. Para uma conexão LAN padrão de 1500 MTU, normalmente seria 1460, mas o resultado é que ela deve refletir o tamanho aceitável para ambos os hosts.

Para conexões que atravessam muitos saltos, pode ser irreal esperar que todos os saltos tenham uma MTU "padrão" ou que a MTU possa ser determinada de maneira confiável. Veja as discussões sobre o Path MTU Discovery no tópico.

Descoberta MTU do caminho link

Problemas de detecção de MTU do Circumventing Path com o MSS Clamping
link

    

Answer 3

Em resposta a:

1. É difícil responder a isso, porque sempre haverá um resumo das coisas que afetam o desempenho do software quando ele toca a rede. Um MTU otimizado para switchport para comunicação switchport não fará muito bem com um link WAN ou, pior ainda, com uma VPN que irá adicionar sobrecarga e potencialmente fragmentação.
2. Sim, mas você não pode realmente controlar o que é a montante em todas as situações!
3. Sim, você está pensando demais, você está realmente escrevendo software que vai voltar para a camada 2 para otimização? Se você estivesse escrevendo, digamos ... um driver iSCSI, então sim, você provavelmente precisará considerar coisas como essa.

Answer 4

Atenha-se aos requisitos do protocolo e assuma que pode passar os dados facilmente. No entanto, tente evitar o uso de blocos de comprimento fixo apenas sobre o MTU ou um pequeno múltiplo dele.

1. A MTU padrão é 1500, que é o valor máximo utilizável na Internet. Valores menores podem ser necessários ao encapsular o tráfego. A maior parte do tráfego será fragmentada e remontada, excedendo a MTU máxima disponível no link. Somente se a opção DNF (Do Not Fragment) estiver definida, os pacotes devem ser menores ou iguais ao MTU. A MTU local define um limite superior para a MTU utilizável.
2. Como a maioria dos hosts tem um MTU de 1500. É um bom valor padrão a ser usado. Alguns ISPs fornecem links usando protocolos de encapsulamento como PPPOE, que fornecem uma MTU menor. Da mesma forma, muitos dos primeiros usuários do IPv6 podem estar usando um túnel e podem ter um MTU menor.
3. Você provavelmente está pensando demais no problema. No mundo real, você não pode confiar na MTU local para determinar a MTU do link. Você também não pode contar com um valor estático. Se necessário, os pacotes serão fragmentados e remontados. Por exemplo, o tamanho do bloco para NFS é tipicamente 4096 e geralmente é enviado em fragmentos.