Définition de TIME_WAIT TCP

Question

Nous essayons de syntoniser une application qui accepte les messages via le protocole TCP et aussi utilise le protocole TCP pour certains c'est la messagerie interne. Alors que les tests de charge, nous avons remarqué que le temps de réponse se dégrade de façon significative (et puis s'arrête tout) comme de plus en plus de requêtes simultanées sont apportées au système. Pendant ce temps, nous voyons beaucoup de connexions TCP en TIME_WAIT statut et quelqu'un a suggéré que l'abaissement de l' TIME_WAIT variable d'environnement, il est par défaut de 60 secondes à 30.

À partir de ce que je comprends, l' TIME_WAIT réglage essentiellement définit le temps d'un TCP de ressources est mis à la disposition du système à nouveau après que la connexion est fermée.

Je ne suis pas un "réseau type" et savent très peu au sujet de ces choses. J'ai besoin de beaucoup de ce qui est dans le message lié, mais "abrutir" un peu.

• Je crois que je comprends pourquoi l' TIME_WAIT de la valeur ne peut pas être défini à 0, mais il peut en toute sécurité être fixé à 5? Ce 10? Ce qui détermine un "coffre-fort" réglage de cette valeur?
• Pourquoi est la valeur par défaut pour cette valeur de 60 ans? Je devine que les gens beaucoup plus intelligents que moi, avait de bonnes raisons pour choisir ce en tant que par défaut raisonnables.
• Que dois-je savoir à propos des risques potentiels et des avantages de la substitution de cette valeur?

Answer 1

Une connexion TCP est spécifié par le tuple (IP source, port source, adresse IP de destination, le port de destination).

La raison pour laquelle il y a un état TIME_WAIT session suivante de l'arrêt est parce que l'on peut encore vivre des paquets dans le réseau sur leur façon de vous (ou de vous qui peut solliciter une réponse de quelque sorte). Si vous étiez à re-créer le même tuple et l'un de ces paquets ont montré, il serait traité comme un paquet valide pour votre connexion (et probablement provoquer une erreur en raison de séquençage).

Donc le TIME_WAIT temps est généralement définie à double les paquets âge maximum. Cette valeur est la limite d'âge de vos paquets seront autorisés à obtenir avant le réseau des rejets.

Qui garantit que, avant que vous êtes autorisé à créer une connexion avec le même tuple, tous les paquets appartenant à des incarnations précédentes de ce tuple sera mort.

Que généralement détermine la valeur minimale que vous devez utiliser. Le maximum de paquets d'âge est dicté par les propriétés du réseau, par exemple, que le satellite durées de vie sont plus élevés que LAN durée de vie étant donné que les paquets ont encore beaucoup à faire.

Answer 2

Généralement, seul le point de terminaison qui émet un "actif près" doit aller dans l'état TIME_WAIT. Donc, si possible, demandez à vos clients de problème la fermeture active qui va laisser le TIME_WAIT sur le client et NON sur le serveur.

Voir ici: http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html et http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ pour plus de détails (le plus tard explique aussi pourquoi il n'est pas toujours possible en raison de la conception de protocoles qui ne prennent pas TIME_WAIT en considération).

Answer 3

Pax est correct quant aux raisons de TIME_WAIT et à la prudence avec laquelle vous devez réduire le paramètre par défaut.

Une meilleure solution consiste à modifier les numéros de port utilisés pour l'extrémité d'origine de vos sockets. Une fois que vous faites cela, vous ne vous souciez plus vraiment du temps d'attente pour les sockets individuelles.

Pour les sockets d’écoute, vous pouvez utiliser SO_REUSEADDR pour permettre au socket d’écoute de se lier malgré les sockets TIME_WAIT restants.

Answer 4

Dans Windows, vous pouvez changer cela dans le registre:

; Set the TIME_WAIT delay to 30 seconds (0x1E)

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters]
"TcpTimedWaitDelay"=dword:0000001E

---

Sous Linux, vous pouvez le modifier via des fichiers de configuration:

Afficher le délai d'attente:

[root@host ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout

60

Modifier temporairement:

[root@dev admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

Vous pouvez également modifier de façon permanente par l'ajout d' net.ipv4.tcp_fin_timeout=30 de /etc/sysctl.conf et selon la SF réponse, apparemment, même "l'éteindre".

Answer 5

TIME_WAIT pourrait ne pas être le coupable.

int listen(int sockfd, int backlog);

Selon Unix Réseau de Programmation Volume1, le carnet de commandes est défini comme la somme de la fin de la connexion de la file d'attente et d'une connexion incomplète de la file d'attente.

Disons que le carnet de commandes est de 5. Si vous avez 3 terminé les connexions (à l'état), et 2 connexions incomplètes (SYN_RCVD de l'état), et il y a une autre requête de connexion avec SYN. La pile TCP ignore le paquet SYN, sachant que ça va être retransmis à un autre moment. Cela pourrait être l'origine de la dégradation.

Au moins, c'est ce que j'ai lu. ;)