55 votes

Pourquoi un serveur n'enverrait-il pas un paquet SYN/ACK en réponse à un paquet SYN ?

Récemment, nous avons été informés d'un problème de connexion TCP qui se limite principalement aux utilisateurs de Mac et de Linux qui naviguent sur nos sites web.

Du point de vue de l'utilisateur, cela se traduit par un temps de connexion très long à nos sites web (>11 secondes).

Nous avons réussi à identifier la signature technique de ce problème, mais nous n'arrivons pas à comprendre pourquoi il se produit ni comment le résoudre.

En fait, la machine du client envoie le paquet SYN pour établir la connexion TCP et le serveur web le reçoit, mais ne répond pas avec le paquet SYN/ACK. Après que le client a envoyé de nombreux paquets SYN, le serveur répond finalement par un paquet SYN/ACK et tout se passe bien pour le reste de la connexion.

Et, bien sûr, le nœud du problème : il est intermittent et ne se produit pas tout le temps (bien qu'il se produise entre 10 et 30 % du temps).

Nous utilisons Fedora 12 Linux comme système d'exploitation et Nginx comme serveur web.

Capture d'écran de l'analyse wireshark

Screenshot of wireshark analysis

Mise à jour :

La désactivation de la mise à l'échelle des fenêtres sur le client a empêché le problème de se produire. Il ne me reste plus qu'à trouver une solution côté serveur (nous ne pouvons pas obliger tous les clients à le faire) :)

Dernière mise à jour :

La solution a consisté à désactiver les deux Mise à l'échelle de la fenêtre TCP et Horodatage TCP sur nos serveurs accessibles au public.

1voto

JamEngulfer Points 153

C'est le comportement d'une socket TCP à l'écoute lorsque son carnet de commandes est plein.

Ngnix permet de définir dans la configuration l'argument backlog de listen : http://wiki.nginx.org/HttpCoreModule#listen

listen 80 backlog=num

Essayez de régler num sur quelque chose de plus grand que la valeur par défaut, comme 1024.

Je ne garantis pas qu'une file d'attente d'écoute pleine soit à l'origine de votre problème, mais c'est une bonne première chose à vérifier.

1voto

Je viens de découvrir que les clients TCP de Linux modifient leur paquet SYN après 3 tentatives et suppriment l'option Window Scaling. Je suppose que les développeurs du noyau ont compris qu'il s'agissait d'une cause fréquente d'échec de connexion sur l'internet

Cela explique pourquoi ces clients parviennent à se connecter après 11 secondes (le SYN TCP sans fenêtre se produit après 9 secondes dans mon bref test avec les paramètres par défaut).

0voto

Baroudi Safwen Points 111

J'ai eu un problème similaire, mais dans mon cas, c'est la somme de contrôle TCP qui a été mal calculée. Le client était derrière un veth et l'exécution de ethtool -K veth0 rx off tx off a fait l'affaire.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X