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

Question

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

Da perspectiva do usuário, ele se apresenta como um tempo de conexão realmente longo para nossos sites (> 11 segundos).

Conseguimos rastrear a assinatura técnica desse problema, mas não conseguimos entender 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 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 está tudo bem para o restante da conexão.

E, claro, o kicker para o problema: é intermitente e não acontece o tempo todo (embora isso aconteça entre 10 a 30% do tempo)

Estamos usando o Fedora 12 Linux como SO e Nginx como o servidor web.

Screenshot da análise wireshark

Atualização:

Desativar o dimensionamento de janelas no cliente impediu que o problema acontecesse. Agora eu só preciso de uma resolução do lado do servidor (não podemos fazer todos os clientes fazerem isso):)

Atualização final:

A solução foi desativar ambos os escalonamento da janela TCP e carimbos de data / hora TCP em nossos servidores que estão acessíveis ao público.

    

Answer 1

Tivemos exatamente o mesmo problema. Apenas desabilitar os timestamps TCP resolveu o problema.

sysctl -w net.ipv4.tcp_timestamps=0

Para tornar essa alteração permanente, faça uma entrada em /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 megabits / segundo terá uma transferência abaixo do ideal se o tempo de ida e volta (basicamente o mesmo do ping) for mais de 55 ms.

Realmente notamos esse problema quando havia vários dispositivos por trás do mesmo NAT. Eu suspeito que o servidor pode ter sido confundido ver timestamps de dispositivos Android e máquinas OSX ao mesmo tempo, uma vez que eles colocam valores completamente diferentes nos campos de timestamp.

    

Answer 2

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

sysctl -w net.ipv4.tcp_tw_recycle=0

Eu acho que é mais correto do que desabilitar timestamps TCP, pois os timestamps TCP são úteis afinal (PAWS, dimensionamento de janelas, etc).

A documentação sobre o tcp_tw_recycle declara explicitamente que não é recomendado habilitá-lo, já que muitos roteadores NAT preservam os timestamps e, portanto, o PAWS entra em ação, já que os timestamps 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.

    

Answer 3

Estou apenas imaginando, mas por que para o pacote SYN (frame # 539; o que foi aceito), os campos WS e TSV estão faltando na coluna "Info"?

O WS é o TCP Window Scaling e o TSV é Valor do Timestamp . 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 ressentido o pacote SYN diferente na 8ª tentativa e essa foi a razão pela qual foi subitamente reconhecido?

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

    

Answer 4

Acabamos de nos deparar com o mesmo problema (demoramos bastante tempo para o fixar ao servidor que não envia o syn-ack).

"A solução foi desativar o escalonamento de janelas TCP e os timestamps tcp em nossos servidores que estão acessíveis ao público."

    

Answer 5

Para continuar com o que Ansis afirmou, eu vi problemas como este quando o firewall não suporta TCP Windows Scaling. O que faz / modelo de firewall é entre esses dois hosts?

    

Answer 6

Acabei de descobrir que os clientes TCP do Linux alteram seu pacote SYN após três tentativas e removem a opção Window Scaling. Eu acho que os desenvolvedores do kernel acharam que esta é 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 janelas acontece depois de 9 segundos no meu teste breve com configurações padrão)

    

Answer 7

O SYN / ACK ausente pode ser causado por limites muito baixos da sua proteção SYNFLOOD no firewall. Depende de quantas conexões o usuário do seu servidor cria. Usar o spdy reduziria o número de conexões e poderia ajudar em situações em que a desativação do net.ipv4.tcp_timestamps não ajudasse.

    

Answer 8

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

O Ngnix permite que o argumento do backlog escute na configuração: link

listen 80 backlog = num

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

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

    

Answer 9

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