Por que um cliente enviaria um pacote RST como resposta a um SYN, ACK?

Question

Eu tenho um webservice HTTP onde às vezes a configuração da conexão falha de uma forma estranha:

• o cliente envia um pacote SYN
• o servidor envia uma resposta SYN, ACK
• o cliente responde com o RST

Em quais situações um sistema cliente pode decidir responder com o pacote RST? Eu poderia imaginar isso acontece quando o SYN, ACK contém por exemplo. números de seqüência incorretos (mas isso não parece se aplicar no meu caso - os números de seqüência parecem bons). Então, estou interessado em uma exaustiva lista :-) de casos em que um cliente enviaria um pacote RST após receber o pacote SYN, ACK.

Em particular, é possível que o código do aplicativo cliente (usando o API de soquete estilo BSD normal no Linux) cause esse pacote RST, por exemplo. chamando close() enquanto o handshake de 3 vias ainda está em andamento?

    

Answer 1

Para fechamento: o problema foi um erro estúpido no meu código (no cliente).

O cliente, neste caso, usa soquetes não-bloqueadores, então a chamada connect() retornará imediatamente enquanto o kernel espera pelo pacote SYN, ACK do servidor. Infelizmente, o código do cliente era muito impaciente: se a conexão não fosse estabelecida após algumas centenas de milissegundos, o cliente chamaria close() no soquete.

Em alguns casos raros, os pacotes SYN e ACK do servidor seriam atrasados por várias centenas de milissegundos no caminho pela rede. Quando a resposta atrasada finalmente chegava ao host do cliente, o kernel veria que o soquete já estava fechado e trataria a resposta SYN, ACK como pertencente a um soquete inválido. É por isso que ele responderia com um pacote RST ao servidor.

Então, sim, é possível que o código do aplicativo (usando API de soquete estilo BSD normal no Linux) cause este pacote RST: usando um soquete não bloqueador e fechando a conexão enquanto o handshake de três vias ainda está em andamento.