Como o MTU é 65535 no UDP, mas o ethernet não permite tamanho de quadro superior a 1500 bytes

Question

Estou usando uma ethernet rápida de 100 Mbps, cujo tamanho de quadro é inferior a 1500 bytes (1472 bytes para carga útil de acordo com o meu livro). Nessa, eu era capaz de enviar e receber um pacote UDP de 65507 bytes de tamanho de mensagem, o que significa que o tamanho do pacote era 65507 + 20 (IP Header) + 8 (UDP Header) = 65535.

Se o tamanho do payload do frame em si é de 1472 bytes (como no meu livro), como o tamanho do pacote do IP pode ser maior do que o que aqui é 65535?

Eu usei o código do remetente como

char buffer[100000];
for (int i = 1; i < 100000; i++)
{
    int len = send (socket_id, buffer, i);
    printf("%d\n", len);
}

Código do destinatário como

while (len = recv (socket_id, buffer, 100000))
{
     printf("%d\n". len);
}

Eu observei que send returns -1 on i > 65507 e recv imprime ou recebe um pacote de maximum of length 65507 .

    

Answer 1

Os datagramas UDP têm pouco a ver com o tamanho de MTU que você pode torná-los tão grande quanto você gosta até o máximo de 64K mencionado acima. Você pode até enviar um deles em um pacote inteiro, contanto que você esteja usando quadros jumbo com um tamanho maior do que o datagrama grande.

No entanto, os quadros jumbo devem ser suportados por todos os equipamentos que o quadro irá passar e isso é um problema. Para fins práticos, os quadros Ethernet são o tamanho de transporte mais comum, o MTU para estes é de cerca de 1500 bytes, vou dizer 1500 para frente, mas nem sempre é. Quando você cria um datagrama UDP maior que o MTU subjacente (que, como indicado, geralmente é ethernet), ele será silenciosamente dividido em um número de quadros de 1500 bytes. Se você tcpdump este tráfego você verá um número de pacotes quebrados no limite de MTU que terá o sinalizador de mais fragmentos definido junto com um número de fragmento. O primeiro pacote terá um número de fragmento de 0 e mais fragmentos definidos, e o último terá um número de fragmento diferente de zero e mais fragmentos não definidos.

Então, por que se importar? O detalhe da implementação realmente importa. A fragmentação pode prejudicar o desempenho na rede, não sendo mais um grande problema, mas de se estar ciente. Se um enorme tamanho de datagrama usado então deveria perder qualquer fragmento, todos os datagramas precisarão ser reenviados. Igualmente em volumes elevados e hoje estes são volumes perfeitamente alcançáveis então a associação incorreta de quadros na remontagem é possível. Também pode haver problemas ao obter pacotes UDP fragmentados para percorrer configurações de firewall corporativo nas quais os balanceadores de carga distribuem os pacotes, se um fragmento estiver em um firewall e outro em um diferente, o tráfego será descartado como incompleto.

Portanto, não crie datagramas UDP maiores que a fragmentação do tamanho da MTU, a menos que seja necessário especificar se a infra-estrutura que está sendo comunicada está próxima (com o mesmo fechamento de sub-rede). .

    

Answer 2

A camada IP fragmentará seu pacote no final de envio e, em seguida, o remontará novamente no destino, antes de passá-lo para o UDP. Da camada UDP, você não pode realmente dizer que o pacote foi fragmentado. Se você usar uma ferramenta de captura de pacotes como o Wireshark , poderá ver que seu computador está recebendo pacotes IP limitados ao MTU.

    

Answer 3

Acontece que permitir que a pilha TCP / IP fragmente pacotes conforme necessário é muito mais baixa do que enviar pacotes individuais.

    

Answer 4

Para responder à sua pergunta, "Se o tamanho da carga útil do quadro é de 1472 bytes (como no meu livro), como o tamanho do pacote de IP pode ser maior do que o que aqui é 65535?"

É devido a um recurso de descarregamento chamado UFO (UDP Fragmentation Offload). Consulte o este link .

Você pode verificar e ativar os recursos de descarregamento via ethtool -k ethX e ethtool -K ethX, respectivamente.

    

Answer 5

Se você estiver monitorando quadros de saída, é possível que seu adaptador de rede suporte o descarregamento de segmentação e ele está ativado. Com o descarregamento de segmentação ativado, a própria placa de rede manipula a segmentação do pacote / quadro no tamanho apropriado, em vez da pilha de rede. Isso libera a CPU no computador para executar outras tarefas, melhorando o desempenho. No linux, "ethtool -k [device]" mostrará os flags de offload.