Pourquoi un serveur n'enverrait-il pas un paquet SYN / ACK en réponse à un paquet SYN
Dernièrement, nous avons pris connaissance d'un problème de connexion TCP qui est principalement limité aux utilisateurs Mac et Linux qui naviguent sur nos sites Web.
Du point de vue de l'utilisateur, il se présente comme un temps de connexion très long à nos sites Web (> 11 secondes).
Nous avons réussi à retrouver la signature technique de ce problème, mais nous ne pouvons pas comprendre pourquoi il se produit ou comment le résoudre.
Fondamentalement, ce qui se passe, c'est que 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 le client a envoyé de nombreux paquets SYN, le serveur répond finalement avec un paquet SYN/ACK et tout va bien pour le reste de la connexion.
Et, bien sûr, le coup de pied au problème: il est intermittent et ne se produit pas tout le temps (bien que cela 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
Mise à jour:
La désactivation de la mise à l'échelle de la fenêtre sur le client a empêché le problème de se produire. Maintenant, j'ai juste besoin d'une résolution côté serveur (nous ne pouvons pas obliger tous les clients à le faire) :)
Mise à jour finale:
La solution consistait à désactiver les deux mise à l'échelle de la fenêtre TCP et horodatages TCP sur nos serveurs accessibles au public.
Nous avons eu exactement le même problème. La désactivation de TCP a résolu le problème.
sysctl -w net.ipv4.tcp_timestamps=0
Pour rendre cette modification permanente, effectuez une entrée dans /etc/sysctl.conf.
Soyez très prudent lorsque vous désactivez l'option TCP Échelle de fenêtre. Cette option est importante pour fournir des performances maximales sur Internet. Une personne disposant d'une connexion à 10 mégabits/s transfert sous-optimal si le temps d'aller-retour (fondamentalement identique au ping) est supérieur à 55 ms.
Nous avons vraiment remarqué ce problème lorsqu'il y avait plusieurs appareils derrière le même NAT. Je soupçonne que le serveur aurait pu être confus en voyant les horodatages des appareils Android et des machines OSX en même temps car ils ont mis des valeurs complètement différentes dans les champs d'horodatage.
Dans mon cas, la commande suivante a résolu le problème avec les réponses SYN/ACK manquantes du serveur Linux:
sysctl -w net.ipv4.tcp_tw_recycle=0
Je pense que c'est plus correct que de désactiver TCP horodatages, car TCP horodatages sont utiles pour hautes performances (PAWS, mise à l'échelle des fenêtres, etc).
La documentation sur le tcp_tw_recycle indique explicitement qu'il n'est pas recommandé de l'activer, car de nombreux routeurs NAT préservent les horodatages et donc PAWS entre en action, car les horodatages de la même IP ne sont pas cohérents.
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.
Je me demandais juste, mais pourquoi pour le paquet SYN (frame # 539; celui qui a été accepté), les champs WS et TSV sont manquants dans la colonne "Info"?
WS est Mise à l'échelle de la fenêtre TCP et TSV est Valeur d'horodatage. Les deux se trouvent dans le champ tcp.options et Wireshark devrait toujours les montrer s'ils sont présents. Peut-être que la pile TCP/IP du client a renvoyé différents paquets SYN lors de la 8e tentative et c'est la raison pour laquelle elle a été soudainement reconnue?
Pourriez-vous nous fournir les valeurs internes du cadre 539? Est-ce que le SYN/ACK vient toujours pour un paquet SYN qui n'a pas activé WS?
Nous venons de rencontrer exactement le même problème (il a vraiment fallu un certain temps pour l'épingler au serveur n'envoyant pas syn-ack).
"La solution était de désactiver la mise à l'échelle des fenêtres TCP et les horodatages TCP sur nos serveurs qui sont accessibles au public."
Le SYN/ACK manquant pourrait être dû à des limites trop basses de votre protection SYNFLOOD sur le pare-feu. Cela dépend du nombre de connexions créées par l'utilisateur de votre serveur. L'utilisation de spdy réduirait le nombre de connexions et pourrait aider dans les situations où tourner net.ipv4.tcp_timestamps off n'aide pas.
Pour continuer ce qu'Ansis a déclaré, j'ai vu des problèmes comme celui-ci lorsque le pare-feu ne prend pas en charge TCP Windows Scaling. Quelle est la marque/le modèle de pare-feu entre ces deux hôtes?
Je viens de découvrir que les clients Linux TCP changent leur paquet SYN après 3 essais et suppriment l'option Window Scaling. Je suppose que les développeurs du noyau ont pensé que c'était une cause courante d'échec de connexion sur Internet
Il explique pourquoi ces clients parviennent à se connecter après 11 secondes (le SYN sans fenêtre TCP SYN se produit après 9 secondes dans mon bref test avec les paramètres par défaut)
C'est le comportement d'une socket TCP d'écoute lorsque son backlog est plein.
Ngnix permet à l'argument du backlog d'écouter d'être défini dans la configuration: http://wiki.nginx.org/HttpCoreModule#listen
écouter 80 backlog = num
Essayez de définir 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 complète est réellement votre problème, mais c'est une bonne première chose à vérifier.
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 exécutait ethtool -K veth0 rx off tx off a fait l'affaire.