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

Dernièrement, nous avons pris conscience d’un problème de connexion TCP qui se limitait principalement aux utilisateurs de Mac et Linux qui naviguaient sur nos sites Web.

Du point de vue de l'utilisateur, il se présente comme un temps de connexion très long avec nos sites Web (> 11 secondes).

Nous avons réussi à retrouver la signature technique de ce problème, mais nous ne savons pas pourquoi cela se produit ni comment le résoudre.

En gros, ce qui se passe, c'est que la machine du client envoie le paquet SYN pour établir la connexion TCP et que le serveur Web le reçoit, mais ne répond pas avec le paquet SYN / ACK. Une fois que 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, la solution 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 Wireshark

Mise à jour:

La désactivation de la mise à l'échelle de la fenêtre sur le client a permis d'éviter le problème. 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 la mise à l'échelle TCP et la mise à l'échelle des fenêtres et les horodatages TCP sur nos serveurs accessibles au public.

Nous avons eu exactement le même problème. Le simple fait de désactiver les horodatages TCP a résolu le problème.

sysctl -w net.ipv4.tcp_timestamps=0

Pour rendre ce changement permanent, entrez une entrée dans /etc/sysctl.conf.

Faites très attention à la désactivation de l'option TCP Window Scale. Cette option est importante pour offrir une performance maximale sur Internet. Quelqu'un avec une connexion de 10 mégabits / s effectuera un transfert sous-optimal si le temps aller-retour (essentiellement identique à celui du ping) est supérieur à 55 ms.

Nous avons vraiment remarqué ce problème lorsqu'il y avait plusieurs périphériques derrière le même NAT. Je soupçonne que le serveur a peut-être été dérouté de voir les horodatages des appareils Android et des ordinateurs OSX en même temps, car ils inséraient des valeurs complètement différentes dans les champs d'horodatage.

Dans mon cas, la commande suivante a résolu le problème de 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 les horodatages TCP, car ceux-ci sont utiles pour des performances élevées (PAWS, dimensionnement de fenêtre, etc.).

La documentation sur tcp_tw_recycleindique explicitement qu'il n'est pas recommandé de l'activer, car de nombreux routeurs NAT conservent les horodatages et donc, le démarrage de PAWS, car les horodatages de la même adresse 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 simplement, mais pourquoi pour le paquet SYN (trame # 539; celle qui a été acceptée), les champs WS et TSV sont manquants dans la colonne "Info"?

WS correspond à TCP Window Scaling et TSV correspond à Timestamp Value . Les deux d'entre eux se trouvent dans le champ tcp.options et Wireshark devrait toujours leur montrer s'ils sont présents. Peut-être que la pile TCP / IP du client a envoyé un paquet SYN différent lors de la 8ème tentative et que cela a été la raison pour laquelle il a été soudainement reconnu?

Pourriez-vous nous fournir les valeurs internes du cadre 539? Est-ce que SYN / ACK vient toujours pour un paquet SYN sur lequel WS n'est pas activé?

Nous venons tout juste de rencontrer exactement le même problème (il a vraiment fallu un certain temps pour l’épingler au serveur sans envoyer de syn-ack).

"La solution consistait à désactiver la mise à l'échelle des fenêtres TCP et les horodatages TCP sur nos serveurs accessibles au public."

Pour continuer sur ce que 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. Quel est le pare-feu de marque / modèle entre ces deux hôtes?

Le SYN / ACK manquant peut être dû à des limites trop basses de votre protection SYNFLOOD sur le pare-feu. Cela dépend du nombre de connexions créées par votre utilisateur sur le serveur. L'utilisation de spdy réduirait le nombre de connexions et pourrait aider dans les cas où net.ipv4.tcp_timestampséteindre n'aide pas.

C'est le comportement d'un socket TCP à l'écoute lorsque son backlog est plein.

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

écouter 80 backlog = num

Essayez de définir num sur un paramètre supérieur à la valeur par défaut, par exemple 1024.

Je ne garantis pas qu’une file d’écoute complète est votre problème, mais c’est une bonne première chose à vérifier.

Je viens de découvrir que les clients Linux TCP changent 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 Internet.

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

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écuter ethtool -K veth0 rx off tx off a fait l'affaire.