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

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é?

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.

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.

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.