Le protocole TCP a été conçu pour prendre en charge les connexions de bout en bout, c'est-à-dire la communication directe entre deux hôtes. Certes, il y avait des ponts et des routeurs entre les deux, mais ces dispositifs ne modifiaient ni l'en-tête TCP ni la charge utile. Ce n'est toutefois plus le cas aujourd'hui. Nous avons désormais des dispositifs tels que les traducteurs d'adresses réseau, les pare-feu, les systèmes de prévention des intrusions et les accélérateurs de réseau. Tous ces dispositifs peuvent soit modifier l'en-tête TCP, envoyer des accusés de réception ou des réinitialisations, soit simplement jeter le paquet à la poubelle. Pour aggraver les choses, ces dispositifs se trouvent à chaque extrémité du réseau et parfois aussi au milieu.
Imaginons le cas d'un hôte A sur le réseau B, connecté à l'hôte Y sur le réseau Z. En amont du réseau B se trouve un accélérateur WAN qui augmente le débit en simulant les accusés de réception provenant de l'hôte Y. Cela permet à l'hôte A d'envoyer des données aussi vite qu'il le peut. L'accélérateur se charge de toute la mise en mémoire tampon et des retransmissions. Malheureusement, le système de prévention des intrusions situé en amont du réseau Z rejette un paquet inoffensif mais d'apparence suspecte provenant de l'hôte A. L'hôte Y ne le voit jamais et ne l'accuse donc pas de réception. L'accélérateur WAN situé en amont du réseau B retransmet le paquet, mais celui-ci est bien sûr à nouveau rejeté. L'accélérateur finit par expirer et envoie une commande de réinitialisation à l'hôte A et à l'hôte Y.
Que constate l'administrateur système de l'hôte A lorsqu'il tente de comprendre ce qui se passe après qu'un utilisateur s'est plaint ? Il constate que les paquets envoyés depuis l'hôte A sont accusés réception par l'hôte Y, mais qu'il n'y a aucune réponse au niveau de la couche application de la part de l'hôte Y, puis que l'hôte Y réinitialise la connexion, sans qu'aucun élément n'indique un problème ou explique pourquoi l'hôte Y a réinitialisé la connexion. Que voit l'administratrice système de l'hôte Y ? Elle constate que l'hôte A a simplement cessé d'envoyer des paquets, puis a envoyé une commande de réinitialisation ; là encore, rien n'indique qu'il y ait un problème ni pourquoi l'hôte A a réinitialisé la connexion.
L'hypothèse selon laquelle l'hôte A communique directement avec l'hôte Y est erronée, et cette hypothèse conduit chaque administrateur à attribuer la responsabilité de l'échec de la connexion à l'autre système.
Pour comprendre ce qui se passe, vous devez prêter attention aux valeurs des champs « sans intérêt » dans les données de traçage de l'en-tête IP, tels que « Type of service », ID, Flags et « Time to Live » (TTL). Les changements dans ces champs, par exemple le fait que les paquets contenant des données aient un TTL de 47 et ceux sans données un TTL de 127, peuvent vous indiquer que les paquets proviennent de deux sources différentes.
La comparaison des traces provenant à la fois de l'hôte A et de l'hôte Y peut mettre en lumière le problème. Non seulement vous pouvez repérer dans une trace des paquets qui ne figurent pas dans l'autre, mais les variations observées dans tous ces champs d'en-tête IP sans importance, ou au niveau des numéros de port TCP ou des numéros de séquence, indiqueront avec une certitude absolue que ces hôtes ne communiquent pas directement entre eux.
Il n'est peut-être pas possible de désactiver l'accélérateur réseau ou le système de prévention des intrusions (et ce n'est sans doute pas une bonne idée non plus), mais le simple fait de savoir qu'ils sont là et de comprendre leur fonctionnement vous permet de mieux cerner et résoudre les problèmes lorsqu'ils surviennent.