Si une connexion TCP est établie entre deux hôtes (A & B) et dire que l'hôte A a envoyé 5 octets d'hôte B, puis l'hôte B se bloque (en raison de la raison inconnue). L'hôte A attendra des accusés de réception, mais de ne pas les obtenir, renverra des octets et réduira également la taille de la fenêtre de l'expéditeur. Cela répétera quelques fois que la taille de la fenêtre se rétrécit à zéro à cause de la perte de paquets. Ma question est que ce qui va arriver ensuite?
5 Réponses :
Dans ce cas, TCP a finalement été mis à l'attente de l'ACK et retourne une erreur à l'application. L'application doit lire / RECV à partir de la prise TCP pour en savoir plus sur cette erreur, un appel d'écriture / envoi ultérieure échouera également. Jusqu'au point que TCP a déterminé que la connexion est partie, écrivez / envoyer des appels n'échoudra pas, ils réussiront de la part de l'application ou du bloc si le tampon de prise est plein.
Dans le cas, votre hôte B disparaît après avoir envoyé ses ACKS, l'hôte A N'aimera pas à ce sujet jusqu'à ce qu'elle envoie quelque chose à B, ce qui finira éventuellement à terminer ou à donner une erreur ICMP. (En règle générale, le premier appel d'écriture / envoi ne manquera pas que TCP n'échoue pas la connexion immédiatement et ne respectera pas que les appels d'écriture / d'envoi n'attendent pas les ACK jusqu'à ce qu'ils complètent).
Remarque également que la retransmission ne réduit pas la taille de la fenêtre.
Veuillez suivre cette lien
Maintenant une réponse très simple à votre question à mon avis est que la connexion sera expirée et sera fermée. Une autre possibilité qui existe est que certaines erreurs ICMP puissent être générées en raison de la machine non réactive dû.
En outre, si la machine écrasée est à nouveau en ligne, la procédure décrite dans le lien que je viens de coller ci-dessus sera observée.
dépend de la mise en œuvre du système d'exploitation. En bref, il attendra ACK et renvoyera des paquets jusqu'à ce que cela puisse sortir. Ensuite, votre connexion sera déchirée. Pour voir exactement ce qui se passe dans Linux look ici Autres oses suivent un algorithme similaire.
Dans votre cas, une ailette sera générée (par le nœud survivant) et la connexion finira par migrer vers l'état fermé. Si vous conservez Grep-ing pour la sortie NetStat sur l'adresse IP de destination, vous allez regarder la migration de l'état établi vers chronométrée_wait, puis disparaître enfin.
Dans votre cas, cela se produira depuis que TCP conserve une minuterie pour obtenir l'ACK pour le paquet qu'il a envoyé. Cette minuterie n'est pas assez longue, la détection se produira assez rapidement.
Toutefois, si la machine B décède une fois que possible ACK et après cela n'a rien envoyé, la minuterie ci-dessus ne peut pas détecter le même événement, mais une autre minuterie (appels inactifs) détectera cette condition et la connexion. va fermer alors. Cette période de délai d'attente est élevée par défaut. Mais normalement, ce n'est pas le cas, la machine A essayera d'envoyer des objets entre et détectera la condition d'erreur dans le chemin d'envoi.
En bref, TCP est suffisamment intelligent pour fermer la connexion par elle-même (et laissez-la savoir à ce sujet), à l'exception d'une case (délai d'inactivité: qui par défaut est très élevé).
CFLEFUN
Comment la machine à mourir peut-elle générer une ailette si elle meurt?
@EJP: une ailette TCP peut être générée par les deux extrémités: la manipulation des erreurs de survie peut effectuer une fermeture active dans sa mise en œuvre et vous pouvez regarder FIN_WAIT_1 STATE EN SORTIE NETSTAT pour cette connexion dans le nœud survivant.
Mais que se passe-t-il si cela meurt avant de générer l'aileron?
@EJP: Mais Node1 est le nœud survivant qui peut générer la nageoire! Prenez ce cas: Il existe une connexion TCP entre Node1 et Node2 Node2, mais Node1 obtient un délai d'erreur due à l'un de ses mécanismes de délai d'expiration: tout ce que je dis que la manipulation des erreurs de Node1 transigea l'état à FIN_WAIT_1 et fermez finalement la connexion: Si vous interrompez tous les états de connexion de la manutention des erreurs dans le code de connexion le plus bas de la connexion au noyau, vous pouvez regarder cette transition de l'état.
Le nœud survivant ne générera pas d'aileron à moins que l'application ferme la prise ou la ferme vers le bas. Il ne générera pas de nageoire pour une connexion cassée ou réinitialisée. Il générera éventuellement une réinitialisation interne, s'il y avait des données en suspens pour être envoyées.
@EJP: application dans ce cas obtiendra une erreur d'envoi et la plupart des applications de socket lors de l'obtention d'une erreur d'envoi fermeront la connexion / l'arrêt de la connexion, ce qui tentera d'envoyer des ailerons, mettra l'état de la connexion en Fin_wait-1, qui n'obtiendra pas une aigue dans ce cas et finira par délai d'attente et finalement, elle sera fermée. Il y a beaucoup d'autres façons qu'il puisse être nettoyé, mais ne pensez-vous pas que c'est une solution possible? Si vous êtes d'accord s'il vous plaît, rendez-vous sur mon Hard gagné deux points :-) Bravo, Cforfun :-)
Laissez-nous Continuer cette discussion en chat
L'application , pas le noeud , générera une nageoire si elle envoyait et s'il reçoit une erreur d'envoi et s'il réagit à l'erreur d'envoi en fermant la prise. Si l'application lit sans délai, il y restera pour toujours et le «nœud survivant» ne générera jamais de nageoire.
@EJP: À droite, vous pouvez voir les deux manières: application fonctionnant sur le
@EJP: À droite, on dirait que vous avez répondu à votre propre question. Revenons maintenant à votre question initiale pour laquelle vous avez fait une "-1" sur ma réponse. Vous avez dit: "Comment la machine à mourir peut-elle générer une ailette si elle meurt?" Vous avez répondu: "Application [J'ai ajouté: En cours d'exécution sur le nœud survivant] peut générer l'aileron" et j'ai dit plus tôt: une ailette sera générée (jamais ladite finale sera générée par la machine à mourir): j'espère que cela clarifie ce vide que nous avions . Je me repose mon cas!
Une ailette peut être générée . Jetez un coup d'œil à tout le «si dans mon commentaire précédent.
Dans les cas normaux, chaque côté mettant fin à sa fin de la connectivité en envoyant un message spécial avec un ensemble de bits d'aileron (finition). Le dispositif recevant cette ailette répond avec une reconnaissance à la nageoire pour indiquer qu'elle a été reçue. La connexion dans son ensemble n'est pas considérée comme terminée tant que les deux appareils complètent la procédure d'arrêt en envoyant une nageoire et en recevant un accusé de réception.