Por que vejo um pacote IP com tamanho 2960, muito acima da configuração de MTU de 1500 na interface e ele passa?

Question

Estou analisando o tráfego entre um cliente e um servidor Linux em execução em um servidor blade HP, o cliente às vezes fica parado esperando por mais dados quando o servidor da Web fechar a conexão.

O servidor web executa o apache2 que, por alguma razão, escolhe rodar o HTTP / 1.1 com conexão fechada em vez de permitir que o cliente envie múltiplas requisições na mesma conexão e feche a conexão, como o padrão HTTP / 1.1 (Isso é outra história .. Mas deixa o servidor com vários milhares de sockets TIME_WAIT em vez de empurrar esse estado para o cliente) ...

De qualquer forma, às vezes, um pedido HTTP é interrompido, ainda não sei onde ele realmente quebra. No lado do servidor tudo parece bem, exceto que o cliente começa a enviar um monte de pacotes RST, entre os acks.

Eu tenho capturas do tcpdump do servidor web e do NAT pelo qual o cliente passa, eu suspeitaria do NAT se não fosse por um comportamento muito estranho no servidor web.

Quando o servidor da Web atende a solicitação HTTP GET, o primeiro pacote de saída é 2960 bytes em carga IP, 2974 em conexão. Isso é muito estranho já que no cliente final no NAT o cliente recebe dois pacotes de 1514 bytes com 1460 bytes de carga TCP.

Os próximos e futuros pacotes que deixam a interface no servidor da web usam uma carga útil de 1460 (1514 on wire) que está dentro do MTU.

Acredito que alguma mágica é feita no SLB (Cisco) que fica entre o servidor da Web e a rede, de modo que o primeiro pacote DF do 2960 é espremido pelo SLB e magicamente é dividido no SLB por alguma interceptação avançada do L3.

Q1) Por que a pilha apache webserver / tcp tentaria até mesmo empurrar um pacote de 2960 bytes em uma interface que tenha MTU configurada para 1500?

Q2) Como é que a rede chega ao cliente como dois pacotes?

Q3) Como o webserver sabe que o MTU deve ser diminuído para 1460, mesmo que nenhum ICMP chegue com o conjunto "Fragmentation needed", já que todos os pacotes têm o bit DF definido.

Não me pergunte por que eu faço essas perguntas, eu sou apenas um cara em uma grande organização tentando entender por que as coisas às vezes não funcionam.

Eu tenho alguns logs tcpdump interessantes que eu posso postar se necessário, eu só tenho que substituir adições IP públicas e tal ...

    

Answer 1

Se você estiver capturando pacotes no servidor, poderá ver o TCP enviando segmentos maiores que o MTU. Os pacotes no fio, no entanto, serão apenas o tamanho da MTU. Você pode verificar isso capturando em um dispositivo de rede (switch) etc. Alternativamente, a captura de pacotes na máquina remota (cliente) revelará que cada pacote é < = MTU.

Esse comportamento se deve ao fato de que com o TSO / GSO ativado, o segmento TCP é dividido em pacotes de tamanho MTU pelo hardware da NIC. Como o tcpdump captura na camada de software, ele vê segmentos maiores do que o MTU sendo enviado para a placa NIC para posterior transferência.

Se você desativar o tso / gso para a NIC, verá todos os pacotes de saída com o tamanho < = MTU (mais provavelmente o tamanho do pMTU).

    

Answer 2

Q1: Eu realmente não acho que o apache tenha qualquer conhecimento do que ele faz lá. Ele lidará com conexões TCP e deixará o restante para a pilha TCP do sistema operacional;)

Q2: fragmentação. O pacote é recusado no caminho, um "enviar novamente, menor" é enviado de volta, o servidor (não o apache - isto é pilha de ip) o envia novamente menor.

Q3: isso não acontece. Realmente, eu não acho, novamente, o apache lida com a pilha tcp em um nível mais baixo, e o MTU etc. é bem menor. A pilha TCP do servidor é responsável por isso, e se as configurações adequadas estiverem definidas (não é necessário apenas "fragmentação", mas também um tamanho menor correto - O parâmetro que você vê no TCP MSS).

Tecnicamente, isso parece com algum equipamento quebrado e / ou alguma implementação TCP quebrada, já que o parâmetro MSS no pacote SYN parece conter um tamanho maior que o permitido OU o computador emissor simplesmente ignora o valor do MSS.

link é uma boa referência inicial. Parece que a descoberta de MTU falha (ou o resultado é ignorado) e, em seguida, um tamanho não padrão é usado.