Récemment, alors que j'utilisais Golang pour écrire un programme de communication TCP, j'ai rencontré une étrange erreur de fermeture, je l'ai enregistrée et partagée.
Background
Dans le programme de communication TCP que j'ai écrit, j'ai utilisé le package net de la bibliothèque standard Go pour me connecter au serveur via la fonction DialTCP. Une fois la communication terminée, utilisez la méthode Close pour fermer la connexion. Dans la plupart des cas, ce processus réussit. Mais parfois, lors de l'appel de la méthode Close, une erreur étrange est générée et le programme plante.
Description de l'erreur
- Erreur lors de la fermeture de l'appel TCP -
Description : réinitialisation par un homologue`
Le journal des erreurs montre que lors de l'utilisation de When la méthode Close ferme la connexion, une erreur "reset by peer" est signalée, ce qui signifie que le serveur ferme activement la connexion.
Dépannage
Dans la première étape, j'ai vérifié le code source et confirmé que la connexion n'était pas fermée avant d'appeler la méthode Close. Dans la deuxième étape, j'essaie d'analyser le problème du point de vue du code, puis d'éliminer les défauts du code.
La troisième étape, j'ai recherché ce problème et trouvé des cas similaires. Dans la communauté open source Github, de nombreuses personnes ont rencontré des problèmes similaires. Certaines personnes pensent qu'il s'agit d'un problème lié à l'implémentation de la spécification TCP par le système d'exploitation, et d'autres pensent qu'il s'agit d'une erreur dans le pilote de la carte réseau. Après avoir vu ces informations, j'ai vérifié les spécifications du protocole TCP et j'ai constaté qu'il y avait effectivement un temps TIME_WAIT pour attendre l'opération de fermeture de la connexion.
Plus précisément, après la fermeture d'une connexion TCP, le système d'exploitation attendra un certain temps jusqu'à ce qu'il confirme que la connexion a été complètement fermée avant de libérer les ressources associées. Cette durée est généralement de 2 MSL (Durée de vie maximale du segment) et la valeur par défaut est de 60 secondes sous Linux. Si pendant ce temps d'attente, il y a une nouvelle demande de connexion avec la même adresse et le même port, le segment RST sera déclenché, c'est-à-dire que l'autre partie fermera la connexion plus tôt et une erreur de « réinitialisation par homologue » se produira.
Alors, comment résoudre ce problème ?
Solution
Pour ce problème, il existe deux solutions :
Modifiez les paramètres du noyau Linux pour prolonger le temps TIME_WAIT. Attendre plus longtemps peut garantir que la connexion est complètement fermée. Bien entendu, pendant cette période prolongée, le nombre de connexions du système qui sont dans l'état TIME_WAIT depuis longtemps augmentera également.
Lors de la fermeture de la connexion, activez l'option SO_REUSEADDR pour rendre l'adresse de connexion réutilisable. De cette façon, une fois la connexion fermée, la prochaine nouvelle connexion peut directement réutiliser l'adresse d'origine, évitant ainsi les erreurs de « réinitialisation par homologue ». La méthode d'implémentation spécifique est la suivante :
conn, err := net.DialTCP("tcp", nil, tcpAddr) err = conn.SetReuseAddr(true) err = conn.Close()
Summary
Ce qui précède est un cas d'une étrange erreur de fermeture que j'ai rencontrée lors de l'écriture d'un programme de communication TCP dans Golang. La raison en est que la connexion n'est pas libérée immédiatement en raison du temps TIME_WAIT requis dans la spécification TCP. En prolongeant le temps d'attente ou en activant l'option SO_REUSEADDR, nous pouvons éviter ce type d'erreur. Dans le même temps, cela nous rappelle également que lors de la programmation réseau, nous devons prêter attention à certains détails de la spécification TCP pour éviter des erreurs inutiles.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!