Por que um servidor não enviaria um pacote SYN / ACK em resposta a um pacote SYN

Ultimamente, tomamos conhecimento de um problema de conexão TCP que se limita principalmente a usuários de Mac e Linux que navegam em nossos sites.

Do ponto de vista do usuário, ele se apresenta como um tempo de conexão muito longo para nossos sites (> 11 segundos).

Conseguimos rastrear a assinatura técnica desse problema, mas não conseguimos descobrir por que isso está acontecendo ou como corrigi-lo.

Basicamente, o que está acontecendo é que a máquina do cliente está enviando o pacote SYN para estabelecer a conexão TCP e o servidor da Web a recebe, mas não responde com o pacote SYN / ACK. Depois que o cliente enviou muitos pacotes SYN, o servidor finalmente responde com um pacote SYN / ACK e tudo fica bem pelo restante da conexão.

E, claro, o pontapé inicial do problema: é intermitente e não acontece o tempo todo (embora ocorra entre 10 a 30% do tempo)

Estamos usando o Fedora 12 Linux como sistema operacional e o Nginx como servidor da web.

Captura de tela da análise do wireshark

Atualizar:

Desativar o dimensionamento da janela no cliente interrompeu o problema. Agora eu só preciso de uma resolução do lado do servidor (não podemos fazer com que todos os clientes façam isso) :)

Atualização final:

A solução foi desativar o dimensionamento da janela TCP e os registros de data e hora do TCP em nossos servidores acessíveis ao público.

Tivemos exatamente o mesmo problema. A desativação do registro de data e hora do TCP resolveu o problema.

sysctl -w net.ipv4.tcp_timestamps=0

Para tornar essa alteração permanente, faça uma entrada /etc/sysctl.conf.

Tenha muito cuidado ao desativar a opção TCP Window Scale. Esta opção é importante para fornecer o máximo desempenho pela Internet. Alguém com uma conexão de 10 megabit / s terá uma transferência abaixo do ideal se o tempo de ida e volta (basicamente o mesmo que o ping) for superior a 55 ms.

Percebemos realmente esse problema quando havia vários dispositivos atrás do mesmo NAT. Suspeito que o servidor possa ter ficado confuso ao ver registros de data e hora de dispositivos Android e máquinas OSX ao mesmo tempo, pois eles colocam valores completamente diferentes nos campos de registro de data e hora.

No meu caso, o seguinte comando corrigiu o problema com respostas SYN / ACK ausentes do servidor Linux:

sysctl -w net.ipv4.tcp_tw_recycle=0

Eu acho que é mais correto do que desativar os carimbos de data / hora TCP, pois os carimbos de hora TCP são úteis para alto desempenho (PAWS, redimensionamento de janelas, etc.).

A documentação tcp_tw_recycleafirma explicitamente que não é recomendável habilitá-lo, pois muitos roteadores NAT preservam os carimbos de data e hora e, portanto, o PAWS entra em ação, pois os carimbos de data e hora do mesmo IP não são consistentes.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.

Apenas imaginando, mas por que, para o pacote SYN (quadro 539; o que foi aceito), os campos WS e TSV estão ausentes na coluna "Informações"?

WS é TCP Window Scaling e TSV é Timestamp Value . Ambos são encontrados no campo tcp.options e o Wireshark ainda deve mostrá-los se estiverem presentes. Talvez a pilha TCP / IP do cliente tenha se ressentido de pacotes SYN diferentes na 8ª tentativa e essa foi a razão pela qual foi subitamente reconhecida?

Você poderia nos fornecer os valores internos do quadro 539? O SYN / ACK sempre vem para um pacote SYN que não possui o WS ativado?

Acabamos de encontrar exatamente o mesmo problema (realmente demorou um pouco para fixá-lo no servidor que não está enviando o syn-ack).

"A solução foi desativar o dimensionamento de janelas TCP e os carimbos de data e hora TCP em nossos servidores acessíveis ao público".

Para continuar o que a Ansis declarou, vi problemas como este quando o firewall não suporta o TCP Windows Scaling. O firewall de marca / modelo está entre esses dois hosts?

O SYN / ACK ausente pode ser causado por limites muito baixos da proteção do SYNFLOOD no firewall. Depende de quantas conexões o usuário do servidor cria. O uso de spdy reduziria o número de conexões e poderia ajudar em situações nas quais net.ipv4.tcp_timestampsdesligar não ajuda.

Esse é o comportamento de um soquete TCP de escuta quando seu backlog está cheio.

O Ngnix permite que o argumento da lista de pendências seja escutado na configuração: http://wiki.nginx.org/HttpCoreModule#listen

listen 80 backlog = num

Tente definir num para algo maior que o padrão, como 1024.

Não garanto que uma fila de escuta completa seja realmente o seu problema, mas é uma boa primeira coisa a verificar.

Acabei de descobrir que os clientes TCP do Linux alteram o pacote SYN após três tentativas e removem a opção Window Scaling. Eu acho que os desenvolvedores do kernel descobriram que essa é uma causa comum de falha de conexão na Internet

Explica por que esses clientes conseguem se conectar após 11 segundos (o TCP SYN sem janela acontece após 9 segundos no meu breve teste com as configurações padrão)

Eu tive um problema semelhante, mas no meu caso, foi a soma de verificação TCP que foi calculada incorretamente. O cliente estava atrás de um veth e executando o ethtool -K veth0 rx off tx off fez o truque.