Limite máximo prático (vs teórico) do tamanho do pacote TCP

Question

Sou um desenvolvedor da Web bastante novo no setor. Eu fui presenteado com um desafio de codificação para uma entrevista de emprego onde eu preciso projetar um sistema de mensagens e arquitetar um sistema para como ele lida com mensagens, mensagens mal-formadas, diferentes tipos de mensagens, registro de status, etc ...

A minha pergunta é sobre o tamanho do pacote através do TCP.

As mensagens recebidas estão em uma taxa de 10.000 mensagens / segundo em um tamanho de 2 KB por mensagem. Eu tenho tentado encontrar a limitação máxima, max-safe ou max-prática do tamanho do pacote. Eu vi em vários lugares não verificados (ou seja, não em documentação técnica) que o tamanho máximo teórico é 64KB. Isso está correto? Nesse caso, meu exemplo de envio de mensagens de 2 KB se encaixaria facilmente em um único pacote e reduziria a complexidade desse sistema.

Se 64 KB é um número incorreto, qual seria o número correto? Além disso, não estou simplesmente tentando entender o tamanho máximo teórico, mas o tamanho máximo prático. Eu quero cobrir casos de borda em que as mensagens podem ser um pouco maiores que as de 2 KB, além de deixar espaço para os vários cabeçalhos que o TCP precisa.

    

Answer 1

A Ethernet sempre influenciou nos tamanhos dos pacotes TCP / IP. A Ethernet tem uma MTU padrão de 1500 bytes, que, depois de uma sobrecarga típica de cabeçalho de 20 bytes e uma sobrecarga típica de cabeçalho de 32 bytes (costumava ser 20 bytes, mas adicionamos uma opção de 12 bytes de timestamp hoje em dia), resulta em um TCP Tamanho máximo do segmento de 1448 bytes .

O PPPoE, popular entre os ISPs baseados em DSL, adiciona outros 8 bytes de sobrecarga, de modo que as conexões TCP que atravessam um link PPPoE acabam com um MSS TCP de 1440 bytes . Outras tecnologias podem adicionar mais sobrecarga.

A maioria das pilhas TCP / IP modernas executam o "Path MTU Discovery" (PMTUD) para que nunca tenham que confiar na fragmentação de IP. Infelizmente alguns sites bloqueiam as mensagens ICMP necessárias para o PMTUD funcionar, acidentalmente criando "buracos negros PMTUD" onde o PMTUD não funciona. Para permitir que as pessoas por trás dos buracos negros PMTUD ainda se conectem aos seus serviços, os sites do Google escolhem negociar um MSS TCP muito conservador de 1380 bytes (última vez que verifiquei).

Então, eu diria que alguém poderia argumentar muito bem que, se você quiser adaptar o que seu aplicativo faz, para garantir que eles preencham um único pacote na maior parte do tempo, faça com que suas gravações não excedam 1448 bytes. e talvez não seja maior que 1380 bytes.

Os datagramas IPv4 podem ter até 64 KibiBytes, mas pouquíssimos caminhos pela Internet têm um MTU de 64 KiB, então esse número é irrelevante para a maioria dos planejamentos de tamanho de pacote. Seu servidor de protocolo de mensagens teórico provavelmente está conectado a uma rede semelhante à Ethernet, que provavelmente usa quadros padrão de 1500 bytes, então a pilha IP do seu servidor teria que fragmentar 64KiB em 46 ou mais pacotes separados antes mesmo de começar a transmiti-los no primeiro salto. Até mesmo as redes Ethernet configuradas para usar "jumbo frames" não padronizados geralmente excedem as MTUs de 9000 bytes. No topo da minha cabeça, eu não posso nem nomear uma tecnologia de rede de link físico / de dados (camada 1/2) que permita MTUs de 64 KiB. Talvez IP over Thunderbolt.