la reconnaissance par TCP ne garantit pas que les données ont été livrées

11

Dans la RFC 793, il y a une partie sur l'accusé de réception des segments TCP:

Lorsque le TCP transmet un segment contenant des données, il place une copie dans une file d'attente de retransmission et démarre un temporisateur; lorsque l'accusé de réception de ces données est reçu, le segment est supprimé de la file d'attente. Si l'accusé de réception n'est pas reçu avant la fin du temporisateur, le segment est retransmis.

Un accusé de réception par TCP ne garantit pas que les données ont été transmises à l'utilisateur final , mais seulement que le TCP destinataire a pris la responsabilité de le faire.

Maintenant, c'est intéressant. Dans notre NOC, nous résolvons souvent les problèmes de connectivité entre notre réseau et le réseau client externe et chaque fois que nous reniflons du trafic sur un pare-feu et voyons les bits SYN et ACK envoyés et reçus dans les deux directions, nous supposons que la connectivité est établie et que le problème n'a rien à faire avec le réseau.

Mais maintenant, cette RFC m'a fait penser - que dois-je vérifier (sans configurer Wireshark) si la connexion TCP est établie mais que les utilisateurs rencontrent toujours des problèmes de connectivité?

kamokoba
la source
5
Ce que signifie cette phrase est simplement le sens littéral anglais de la phrase: le fait que le pilote de réseau a reçu les données (et a accusé réception) ne garantit pas que l'utilisateur final reçoit les données. Il pourrait y avoir un bogue sur le serveur Web, par exemple. En ce qui concerne votre dernière question: la seule façon de savoir si l'utilisateur final a reçu les données, c'est de les appeler et de les demander.
Jörg W Mittag

Réponses:

24

Cette partie de la RFC consiste à transférer la responsabilité au système d'exploitation ou à la prochaine étape du processus. Il est fondamentalement concerné par la séparation des couches.

Un accusé de réception par TCP ne garantit pas que les données ont été transmises à l'utilisateur final, mais seulement que le TCP destinataire a pris la responsabilité de le faire.

J'y ai toujours pensé de cette façon:

  • L'OS pourrait se bloquer entre l'envoi de l'ACK et les données atteignant le processus client ("client" signifie ici client de l'OS, pas "client réseau")
  • Le processus client peut être bogué ou tomber en panne, ou tout simplement beaucoup plus lent que prévu pour gérer ses données entrantes, ou même les lire uniquement dans des circonstances non évidentes.
  • Si le client envoie les données, peut-être vers un fichier disque, le fichier n'a peut-être pas encore été écrit ou vidé
  • Si le client envoie les données par TCP, le TCP distant peut ne pas avoir transmis les données, reçu un ACK ou le processus distant a correctement consommé les données

Tout ce qu'il dit, c'est qu'il s'agit d'un accusé de réception de couche 3 ("J'entends vos octets") et non d'un accusé de réception de couche supérieure . Considérez par exemple la différence entre TCP ACK, le SMTP 250 OKaprès que la passerelle de messagerie du saut suivant accepte un message, un message de réception de message (par exemple selon RFC 3798 ), un pixel de suivi ouvert par message, une note de remerciement d'un PA, et une réponse disant "Oui, je le ferai."

Un autre exemple concret serait une imprimante:

  • Il doit ACK les données tôt avant de savoir ce que contient leur fin (peut être un fichier Postscript commençant par une bibliothèque incluse plus grande que la fenêtre de transmission TCP)
  • Il peut contenir une requête d'état ("avez-vous du papier?", Qu'il peut évidemment exécuter)
  • Il peut contenir une commande d'impression ("veuillez imprimer ceci", ce qui peut échouer en cas de manque de papier)

Je suggérerais que si les utilisateurs voient et envoient des ACK mais rencontrent toujours des problèmes de connectivité, il est plus probable qu'il y ait des problèmes d'encombrement, de système d'exploitation ou d'application que tout ce qui est strictement lié au réseau.

Pour diagnostiquer, je suggère de rechercher des retransmissions plutôt que les ACK en particulier.

jonathanjo
la source
Un autre élément de puce: même si le processus client fonctionne correctement, il n'a peut-être pas encore lu les données.
Barmar
1
Le processus client (s'il se sent paresseux ou pervers) peut simplement ne jamais appeler recv()le socket, auquel cas les données reçues resteront indéfiniment dans le tampon de réception du socket TCP.
Jeremy Friesner
Merci à tous les deux, mis à jour pour suggérer que le processus client peut être lent, bogué, volage.
jonathanjo
Vous ne pouvez pas compter sur ACK pour vous assurer que l'application a traité votre entrée, vous devez implémenter un ACK ou une vérification de couche application. Pour mettre cela dans un autre contexte. Pour les réseaux de contrôle industriels utilisant TSN avec une pile IP côté client, le TCP ACK n'est pas suffisant pour garantir que les variables de processus ont été verrouillées. Autrement dit, vous ne pouvez pas compter sur TCP ACK pour mettre le système dans un état sûr ou réparable, vous devez avoir la confirmation d'un service de couche application qu'il est sûr de mettre la main dans la machine.
crasic
10

Du point de vue RFC, "l'utilisateur final" est l'application. Il n'y a aucune garantie que l'application a obtenu les données, juste que le processus TCP les a reçues.

Du point de vue de votre NOC, le réseau fonctionne et les données ont atteint l'hôte final. Vraisemblablement, c'est tout ce dont vous vous souciez.

Ron Trunk
la source
0

Vous pouvez le voir de cette façon.

Vous êtes M.Smith et vous souhaitez envoyer une lettre à M.Toto (les personnes sont la couche application).

Pour envoyer la lettre, vous allez à votre bureau de poste local A qui enverra la lettre au bureau de poste local M.Toto B (les bureaux de poste sont la couche TCP).

Tout pourrait bien se passer entre vous, le bureau de poste A et le bureau de poste B - B enverront un ACK au bureau de poste A. Mais rien ne garantit que la lettre parviendra à M.Toto. Tout pouvait arriver entre le bureau de poste B et M.Toto.

C'est essentiellement ce que dit RFC.

toto
la source