TCP over TCP ?
Il est très courant de voir, dans des documentations concernant le tunneling, des recommandations concernant l'utilisation d'une solution se basant sur TCP. En fait, il s'agit généralement d'une mauvaise idée, en particulier lorsque ladite connexion est peu performante ou fortement "laguée".

Le protocole TCP fractionne le flux de données en segments. Ces morceaux de données sont transmis sous forme de datagrammes. Enfin, chaque datagramme intègre un numéro de séquence et un accusé réception (numéro de séquence du dernier datagramme). On dit alors que TCP est un protocole orienté connexion.
Comme vous devez le savoir, Internet a été conçu afin de permettre la transmission des datagrammes de manière à ce qu'une connexion puisse être établie, même dans les pires conditions. Ainsi, si un accusé réception manque à l'appel au bout d'une certaine durée, l'expéditeur du datagramme considérera celui-ci perdu et le ré-expédiera.

Afin de déterminer la perte d'un datagramme, un délai d'attente est décompté. Si se délai est dépassé, le datagramme est perdu. L'une des spécifications de TCP dans ce domaine est sa capacité à gérer un délai d'attente dynamique. Ainsi, un datagramme perdu sera ré-expédié avec un délai d'attente supérieur. Ceci permet l'établissement de connexions aussi bien sur des réseaux locaux (bonne bande passante) que sur des liaisons grande distance comme celles d'Internet. Le délai d'attente peut ainsi dépasser la minute dans certaines conditions.

Mais le protocole TCP va plus loin encore. En se basant seulement sur le principe du délai et de ré-expédition des datagrammes, le réseau pourrait rester bloqué dans l'attente des accusés réception. Voilà pourquoi TCP utilise un système plus complexe appelé le principe de fenêtre.

Ce principe permet à l'expéditeur d'envoyer un certain nombre d'octets (segments) avant d'avoir reçu l'accusé réception des précédents segments. La technique est toute simple, plutôt que d'attendre la réception au coup par coup (segment 1, ar 1, segment 2, ar 2, etc.), on détermine :

- le numéro du premier segment envoyé dont l'accusé réception n'est pas encore reçu ;
- le numéro du dernier segment que l'on peut envoyer sans attendre l'accusé réception du premier segment.

Nous obtenons donc une fenêtre de segments "envoyables". Voici un exemple :

Nous supposons ici que les segments 1 à 3 ont été envoyés et que les accusés réception ont été reçus. Le segment 4 a été envoyé, mais l'accusé réception est encore attendu. La fenêtre détermine pourtant que les segments 5 à 8 peuvent être envoyés :

>>>>>>>>>> tcpfen1.eps

Lorsque l'accusé réception du segment 4 arrivera, le dernier segment "envoyable" sera le 9, la fenêtre glissera.

>>>>>>>>>> tcpfen2.eps

Notez que le récepteur peut à souhait spécifier une taille de fenêtre dans l'accusé réception en fonction de ses besoins.

Un utilitaire sniffeur/analyseur de trames TCP/IP comme Ethereal vous permettra de visualiser tous les éléments des trames TCP.

>>>>>>>> ether.tif

Comme vous pouvez le voir, TCP utilise des techniques permettant une utilisation optimale du réseau par l'intermédiaire de mécanismes simples et efficaces.

Cela nous amène au problème du tunneling sur TCP. Les concepteurs du protocole TCP n'ont pas pris en compte cette possibilité (pourquoi l'auraient-ils fait ?). De ce fait, en faisant du tunneling grâce à PPP (encapsulation de TCP/IP) et SSH (chiffrement), on obtient un tunnel TCP fonctionnant sur du TCP. Conséquence : la gestion dynamique du délai est présente dans et en dehors du tunnel (voir figure 1).

Que se passe-t-il alors ? Comme l'explique Olaf Titz du projet CIPE, les deux connexions TCP utilisent une gestion des délais différente et asynchrone. De ce fait, si la connexion de base se dégrade et perd des paquets, TCP va ajuster les délais et renvoyer les datagrammes perdus. Dans le même temps, la connexion TCP à l'intérieur du tunnel fait également face à des dépassements de délai (timeout durant la retransmission des datagrammes perdus). Le résultat est catastrophique, la moindre perturbation du réseau va provoquer une augmentation très rapide des délais et la transmission se dégradera tout aussi rapidement.

En pratique, un réseau peu viable utilisé de manière classique restera utilisable. Si vous utilisez un tunnel TCP over TCP (comme PPP over SSH), la connexion deviendra trop lente et les coupures seront fréquentes. Le problème ne vient pas de votre réseau (ou seulement en partie), mais uniquement du fait de l'utilisation simultanée de deux protocoles TCP.

Moralité, quelle que soit l'application que vous utiliserez pour votre VPN, si vous disposez du choix TCP ou UDP, préférez UDP. Ce protocole est "sans connexion" et vous ne rencontrerez alors pas le problème.

Pour la petite histoire, c'est justement ce problème de performance qui a conduit Olaf Titz à lancer le projet CIPE utilisant UDP et non TCP.

Liens
Le protocole TCP
http://www.info.univ-angers.fr/pub/pn/poly/node44.html

La RFC 793
http://www.faqs.org/rfcs/rfc793.html