Par Mark Stacey
T/TCP est une extension expérimentale au protocole TCP. Elle a été conçue pour remédier au besoin d'un protocole de transport basé sur les transactions dans la pile TCP/IP. TCP et UDP sont les solutions actuellement disponibles pour les applications transactionnelles. Toutes deux ont leurs avantages et leurs inconvénients. TCP est fiable mais peu efficace pour les transactions alors que UDP est exactement l'inverse. T/TCP se situe entre les deux, constituant ainsi une option de plus pour certaines applications.
Actuellement, quelques déclinaisons d'UNIX gèrent T/TCP. SunOS 4.1.3 (un noyau dérivé de Berkeley) en a connu la toute première implémentation et a été disponible dès septembre 1994. Ensuite est venue celle de FreeBSD 2.0, diffusée en mars 1995. Pour mon projet de fin d'année, j'ai réalisé celle de Linux pour l'Université de Limerick en avril 1998. On peut trouver le code source sur http://www.csn.ul.ie/~heathclf/fyp/.
Dans cet article, j'examinerai le mode opératoire ainsi que les avantages et les inconvénients de T/TCP. Ceci permettra aux développeurs de savoir quand T/TCP est approprié pour leurs applications en réseau. Je présenterai aussi les résultats que j'ai obtenus lors d'une analyse comparative entre T/TCP et TCP, basée sur le nombre de paquets par session pour chaque transaction, ainsi que mes conclusions sur un cas d'étude quant à l'impact possible de T/TCP sur le World Wide Web.
Le modèle TCP/IP fait référence à la spécification d'une pile réseau pour ordinateur. Son objet est de fournir aux développeurs réseau une base commune. Ceci permet une interconnexion plus facile entre les différents réseaux propriétaires tout en réduisant le coût d'installation de réseaux totalement nouveaux, afin qu'ils puissent fonctionner les uns avec les autres.
L'implémentation la plus répandue de la couche de transport du modèle de référence est le protocole TCP (Transmission Control Protocol), qui repose sur un mode connecté. L'autre implémentation courante est le protocole UDP (User Datagram Protocol) qui lui fonctionne en mode non connecté.
Chacun a ses avantages et ses inconvénients. Les deux principales particularités de ces protocoles les rendent utiles dans différents domaines. Du fait de son fonctionnement en mode non connecté, UDP suppose toujours que l'hôte destinataire a reçu les données correctement. C'est la couche applicative située juste au-dessus qui s'occupe de la détection et de la correction d'erreurs. Même si UDP n'est pas fiable, il est plutôt rapide et pratique pour les applications telles que le DNS (Système de Nom de Domaine) où on préfère la vitesse à la fiabilité. D'un autre côté, TCP, eu égard à son aspect intrinsèquement fiable et son mode connecté, effectue lui-même le traitement des erreurs. Si un problème est détecté, les données sont automatiquement retransmises. Le revers de la médaille étant une plus grande lenteur par rapport à UDP.
Ces dernières années, avec l'explosion d'Internet, le besoin d'une nouvelle spécification s'est fait sentir. Les protocoles de transport actuels étaient soit trop riches, soit pas assez fiables. Il en fallait un qui soit plus rapide que TCP et plus fiable que UDP. En ce qui concerne ces deux caractéristiques, chacun d'eux se trouve à un bout de l'échelle : TCP possède la fiabilité aux dépends de la vitesse et c'est le contraire pour UDP. Il fallait un standard qui assure le transfert de données avec un débit plus rapide que sous TCP. Il pourrait permettre à la fois de réduire la bande passante nécessaire et d'augmenter le débit de transmission des données.
TCP pour Transactions (T/TCP) se veut le successeur aussi bien de TCP que de UDP pour certaines applications. C'est un protocole transactionnel basé sur un minimum de transferts de segments, ainsi il n'est pas affecté par les problèmes de vitesse associés à TCP. Reposant sur ce dernier, il ne pâtit pas du manque de fiabilité de UDP. Ayant ceci à l'esprit, la RFC1379 a été publiée en novembre 1992. Elle abordait les concepts qu'impliquait l'extension de TCP afin de permettre un service transactionnel, par opposition aux services connecté et non connecté, respectivement pour TCP et UDP. Parmi les principaux sujets évoqués dans la RFC, l'escamotage de la négociation tripartite et le raccourcissement de l'état d'attente TIME-WAIT de 240 à 12 secondes. T/TCP élague une bonne partie de la détection d'erreurs et de la négociation superflues de l'actuel protocole TCP, et par corollaire, augmente la vitesse de connexion et réduit la bande passante nécessaire. Dix-huit mois plus tard, la RFC1644 contenant les spécifications de Transaction TCP était publiée.
On peut considérer T/TCP comme une surcouche du protocole TCP. La raison en est que T/TCP est conçu pour fonctionner avec les machines TCP actuelles de façon transparente. Si un hôte TCP tente de se connecter à un hôte T/TCP, ce dernier lui répondra en utilisant la négociation tripartite originelle. Ce qui suit est un bref descriptif de T/TCP et de ce en quoi son mode opératoire diffère de celui de l'actuel standard TCP.
Le terme transaction correspond à une requête envoyée par un client à un serveur ainsi que la réponse de celui-ci. La RFC955 énumère quelques-unes des caractéristiques communes des applications de traitement transactionnel.
La croissance de l'Internet a mis à mal la bande passante et la vitesse des réseaux. Avec toujours plus d'utilisateurs, le besoin d'une forme de transfert de données plus efficace s'est fait jour.
Une transaction requiert un strict minimum de deux paquets : une requête suivie d'une réponse. Au sein de la pile TCP/IP, UDP est le seul protocole qui le permette mais au prix, hélas, d'une transmission non fiable.
T/TCP résoud ces problèmes dans une large mesure. Il possède la fiabilité de TCP et approche de très près l'échange en deux paquets (trois en fait). Il s'appuit sur le modèle de TCP pour sa synchronisation et la réémission des données tout en introduisant un nouveau concept propre à réduire le nombre de paquets.
Même si c'est trois paquets qui sont expédiés sous T/TCP, les données ne sont transportées que sur les deux premiers. Ainsi, les applications peuvent en disposer à la même vitesse que sous UDP. Le troisième paquet contient l'accusé de réception du client au serveur, ce qui donne bien la fiabilité inhérente à TCP.
Figure 1. Synchronisation d'une transaction client/serveur sous T/TCP
Considérez un système de DNS dans lequel un client envoit une requête à un serveur et attend en retour une faible quantité de données. La figure 1 présente un diagramme de la transaction. Il ressemble beaucoup à une requête UDP. Si nous comparons avec la négociation tripartite de TCP de la figure 2, nous pouvons constater qu'un même nombre de paquets est nécessaire dans les deux cas. Alors qu'avec TCP il faut des transferts de trois paquets simplement pour établir la connexion (neuf au total), il suffira en tout et pour tout de trois paquets par transfert pour l'ensemble du processus (une économie de 66% en terme de paquets transmis par rapport à TCP). Evidemment, dans les cas de transferts de quantités importantes de données, davantage de paquets seront nécessaires, ce qui diminuera ce pourcentage. Des chronométrages ont montré un léger avantage de UDP sur T/TCP, mais c'est dû aux performances de la machine, pas au réseau. A mesure que les ordinateurs deviendront plus puissants, cette différence tendra à s'amenuiser.
Figure 2. Négociation tripartite TCP
L'ouverture accélérée TCP (TCP Accelerated Open - TAO) est un mécanisme introduit par T/TCP et conçu pour diminuer le nombre de paquets requis lors de l'établissement d'une connexion avec un hôte.
T/TCP inaugure un certain nombre de nouvelles options. Celles-ci permettent d'établir une connexion avec un hôte utilisant la TAO. T/TCP a recours à un nombre d'identification appelé un comptage de connexion (CC). Cette option est incluse dans la partie options d'un segment T/TCP, Figure 3. Des valeurs croissantes de CC sont attribuées à chaque connexion établie par un hôte, aussi bien active que passive.
On peut sauter la négociation tripartite grâce au champ CC. Du côté serveur, chaque hôte garde en mémoire (ou dans un fichier) cache la dernière valeur de CC valide reçue de chaque hôte-client différent. Elle est envoyée avec le segment SYN initial au serveur. Si la valeur de CC originelle d'un client particulier est plus grande que celle qui se trouve dans le cache, la propriété des options CC (le nombre croissant) s'assure que le segment SYN est nouveau et peut être accepté immédiatement.
Le test de TAO échoue si la valeur de l'option CC qui arrive dans le segment SYN est inférieure à la dernière reçue et mise en cache par l'hôte, ou si une option newCC est envoyée. Ensuite, le serveur entame une négociation tripartite TCP/IP classique. Ainsi, le test de TAO constitue une amélioration de TCP, la négociation normale permettant d'assurer la compatibilité ascendante et la fiabilité.
Lors de la fermeture d'une connexion, toutes les connexions TCP basculent dans un état d'attente (TIME-WAIT). Sa longueur est de 240 secondes, ceci afin de permettre à tout segment en double provenant de la connexion précédente et encore présent sur le réseau d'arriver à expiration. L'option CC sous T/TCP autorise le raccourcissement de l'état TIME-WAIT. Elle fournit une protection contre la remise d'anciens doublons à la mauvaise identification d'une connexion donnée.
Cependant, ce raccourcissement est soumis à des contraintes. Comme la valeur du champ CC reçu de l'hôte augmente mécaniquement, les nombres peuvent reboucler du côté client. Cependant, cette troncature fait l'objet de contraintes temporelles. Il est possible de rencontrer une valeur de CC égale à celle de segments en double venant de l'identification précédente. En règle générale, le raccourcissement ne peut être effectué que si la durée de la connexion est inférieure à la durée de vie maximale d'un segment (MSL). On recommande une MSL de 120 secondes. Comme c'est le cas avec le TCP originel, l'hôte qui envoit le premier FIN doit rester dans l'état TIME-WAIT pendant deux fois la MSL une fois que la connexion est totalement fermée des deux côtés. Ceci implique que l'état TIME-WAIT du TCP initial soit de 240 secondes, même si certaines implémentations le règlent à 60. Stevens indique comment cet état peut être réduit à 12 secondes pour T/TCP.
Les réseaux à haut débit peuvent poser des problèmes aux options CC. Cela arrive rarement sur les installations un peu anciennes, mais le FDDI et l'Ethernet gigabit devenant de plus en plus fréquents, le bouclage d'une valeur de CC va l'être aussi. Dans une telle situation, on peut rencontrer des problèmes si ce bouclage est assez rapide. Alors que les options CC peuvent ne pas suffire dans certains cas, l'option protection contre les séquences bouclées (PAWS - protection against wrapped sequences) ajoute une couche de sécurité supplémentaire pour y remédier.
Certaines des applications qui reposent sur TCP ou UDP peuvent trouver un intérêt à T/TCP. Actuellement, beaucoup sont basées sur la transaction plutôt que sur la connexion, mais sont néanmoins dépendantes de TCP et du surcoût associé. L'autre solution est UDP, mais ce protocole n'intégrant pas les mécanismes d'expiration et de retransmission, il incombera aux développeurs d'applications d'y pourvoir. T/TCP étant transactionnel, il n'y a aucun délai de mise en route et d'arrêt, ce qui permet aux données d'être transmises au processus avec un minimum de temporisation.
L'accès aux pages web au sein du Worl Wide Web est régi par le protocole Hypertext Transfer Protocol (HTTP). Il utilise plus d'allers et retours qu'il n'en faut. L'emploi de T/TCP peut servir à réduire le nombre de paquets requis.
HTTP est une application typique du modèle transactionnel. Le client envoit une brève reqête au serveur pour lui demander un document ou une image puis ferme la connexion. Ensuite, le serveur retourne les données au client. T/TCP peut servir à améliorer cette procédure et à réduire le nombre de paquets qui transitent sur le réseau.
Alors qu'avec TCP, la transaction est effectuée en se connectant au serveur (négociation tripartite), en demandant le fichier (GET file), puis en fermant la connexion (par envoi d'un segment FIN), T/TCP lui se connecte au serveur, demande le document et ferme la connexion en un seul segment (TAO). Il est évident que de la bande passante a été économisée.
Les appels de procédure distants (RPC - Remote Procedure Calls) se conforment également au principe de la transaction. Un client envoit une requête à un serveur pour qu'il exécute une fonction. Les résultats en sont retournés en réponse au client. Seule une faible quantité de données est transmise par les RPC.
Le système de noms de domaine (DNS - Domain Name System) est employé pour la traduction des noms de machines en adresses IP qui servent à localiser l'hôte. Pour ce faire, le client envoit une requête contenant l'adresse IP ou un nom d'hôte au serveur. Celui-ci répond en envoyant un nom ou une adresse, selon ce qui est nécessaire. Ce protocole repose sur UDP.
De ce fait, l'échange est rapide mais pas fiable. En outre, si la réponse du serveur excède 512 octets de données, le client reçoit les 512 premiers octets avec un indicateur tronqué. Il doit ré-émettre sa demande, cette fois-ci avec TCP, n'ayant aucune garantie que le destinataire saura ré-assembler un datagramme IP de plus de 576 octets. Pour plus de sûreté, beaucoup de protocoles limitent les données utilisateur à 512 octets.
T/TCP est le parfait postulant pour le DNS grâce à sa rapidité et à sa fiabilité.
T/TCP fournit un mécanisme simple qui permet de réduire le nombre de segments impliqués dans un transfert de données, le TAO. Avec ce test, un client pourra ouvrir une connexion, envoyer des données et fermer la connexion en un seul segment, ce qui nécessite trois processus parfaitement distincts avec TCP.
C'est avec de petites quantités de données que le gain est le plus important. Cela accrédite la thèse selon laquelle T/TCP est bien adapté à HTTP, RPC et DNS, qui nécessitent des échanges peu volumineux.
Afin d'évaluer les avantages et les inconvénients de cette implémentation de T/TCP, il est important à la fois de tester son fonctionnement et de le comparer à celui de TCP/IP. J'ai procédé à ces essais avec un noyau Linux 2.0.32 intégrant des modifications T/TCP et un FreeBSD 2.2.5 qui en contenait déjà une version.
Cette section expose le mode opératoire du protocole dans différentes situations.
Dans ce cas de figure, j'ai relancé le client et le cache de TAO a été réinitialisé.
Lorsqu'il tente une connexion avec un serveur, il s'aperçoit que la valeur du dernier champ CC qu'il en a reçu est indéfinie. Il envoit alors une option CCnew pour lui faire savoir qu'il y a besoin d'une négociation tripartite.
La séquence de segments qui suit se conforme à l'implémentation du protocole.
elendil.ul.ie.2177 > devilwood.ece.ul.ie.8888: SFP 3066875000:3066875019(19) win 15928 <mss 1460,nop,nop,ccnew 10> (DF)
devilwood.ece.ul.ie.8888 > elendil.ul.ie.2177: S 139872882:139872882(0) ack 3066875001 win 17424 <mss 1460,nop,nop,cc 3, nop,nop,ccecho 10> (DF)
elendil.ul.ie.2177 > devilwood.ece.ul.ie.8888: F 20:20(0) ack 1 win 15928 <nop,nop,cc 10> (DF)
devilwood.ece.ul.ie.8888 > elendil.ul.ie.2177: . ack 21 win 17405 <nop,nop,cc 3> (DF)
devilwood.ece.ul.ie.8888 > elendil.ul.ie.2177: FP 1:31(30) ack 21 win 17424 <nop,nop,cc 3> (DF)
elendil.ul.ie.2177 > devilwood.ece.ul.ie.8888: . ack 32 win 15928 <nop,nop,cc 10> (DF)
Une fois que le client a terminé sa première transaction avec le serveur, le champ CC dans le cache de TAO contiendra un nombre. Cela va lui permettre d'envoyer une option CC normale, indiquant par là même au serveur qu'il peut sauter l'étape de négociation tripartite si nécessaire.
Le client et le serveur détiennent tous deux des données d'état l'un sur l'autre, par conséquent dès que le test de TAO réussit, l'échange minimal en 3 segments devient possible.
elendil.ul.ie.2178 > devilwood.ece.ul.ie.8888: SFP 2021229800:2021229819(19) win 15928 <mss 1460,nop,nop,cc 11> (DF)
devilwood.ece.ul.ie.8888 > elendil.ul.ie.2178: SFP 164103774:164103804(30) ack 2021229821 win 17424 <mss 1460,nop,nop,cc 4, nop,nop,ccecho 11>
(DF)
elendil.ul.ie.2178 > devilwood.ece.ul.ie.8888: . ack 32 win 15928 <nop,nop,cc 11> (DF)
Si le serveur est redémarré après les deux tests précédents, les données d'état concernant l'hôte seront perdues.
Quand la requête du client arrive avec une option CC normale, le serveur force une négociation tripartite puisque la valeur du champ CC reçu est indéfinie. Le segment SYNACK ne force la négociation que quand le SYN du client est validé sans les données.
elendil.ul.ie.2141 > devilwood.ece.ul.ie.8888: SFP 2623134527:2623134546(19) win 15928 <mss 1460,nop,nop,cc 9> (DF)
arp who-has elendil.ul.ie tell devilwood.ece.ul.ie
arp reply elendil.ul.ie is-at 0:20:af:e1:41:4e
devilwood.ece.ul.ie.8888 > elendil.ul.ie.2141: S 25337815:25337815(0) ack 2623134528 win 17424 <mss 1460,nop,nop,cc 2, nop,nop,ccecho 9> (DF)
elendil.ul.ie.2141 > devilwood.ece.ul.ie.8888: F 20:20(0) ack 1 win 15928 <nop,nop,cc 9> (DF)
devilwood.ece.ul.ie.8888 > elendil.ul.ie.2141: . ack 21 win 17405 <nop,nop,cc 2> (DF)
devilwood.ece.ul.ie.8888 > elendil.ul.ie.2141: FP 1:31(30) ack 21 win 17424 <nop,nop,cc 2> (DF)
elendil.ul.ie.2141 > devilwood.ece.ul.ie.8888: . ack 32 win 15928 <nop,nop,cc 9> (DF)
Si la requête initiale dépasse la taille maximale de segment (MSS - Maximum Segment Size) autorisée, elle devra être fragmentée.
Quand le serveur reçoit le SYN initial avec les données mais pas de FIN, en fonction des délais d'expiration, il répond soit par un SYNACK immédiat, soit il attend que le bit FIN arrive avant d'envoyer le SYNACK qui accuse réception de l'ensemble des données. Le serveur s'occupe ensuite de transmettre la réponse en plusieurs paquets si nécessaire.
localhost.2123 > localhost.8888: S 2184275328:2184278860(3532) win 14128 <mss 3544,nop,nop,cc 5> (DF)
localhost.2123 > localhost.8888: FP 2184278861:2184279329(468) win 14128 <nop,nop,cc 5>: (DF)
localhost.8888 > localhost.2123: S 1279030185:1279030185(0) ack 2184278861 win 14096 <mss 3544,nop,nop,cc 6,nop,nop,ccecho 5>
localhost.2123 > localhost.8888: F 469:469(0) ack 1 win 14128 <nop,nop,cc 5> (DF)
localhost.8888 > localhost.2123: . ack 470 win 13627 <nop,nop,cc 6> (DF)
localhost.8888 > localhost.2123: FP 1:31(30) ack 470 win 13627 <nop,nop,cc 6> (DF)
localhost.2123 > localhost.8888: . ack 32 win 14128 <nop,nop,cc 5> (DF)
T/TCP étant une surcouche de TCP, il doit être capable de communiquer de façon transparente avec les autres machines ne l'utilisant pas.
Voici différents scénarii répondant à cette situation. Dans quelques implémentations, les données sont conservées dans le segment SYN jusqu'à ce que la négociation tripartite soit achevée. Dans ce cas, le client ne doit ré-émettre que le segment FIN afin d'informer le serveur que toutes les données ont été envoyées, lequel répondra ensuite en utilisant la sémantique TCP classique.
En d'autres occasions, le segment SYN est éliminé dès qu'il a été traité, ainsi que les données expédiées dans le segment SYN initial. Le serveur envoit un SYNACK accusant réception uniquement du SYN envoyé. Le client expire après un moment et ré-émet données et FIN, après quoi le serveur poursuit normalement.
En testant cette compatibilité ascendante, j'ai découvert une caractéristique (bogue) peu courante de Linux. Quand un SYN est envoyé avec le bit FIN positionné, l'hôte Linux répond non seulement par un SYNACK, mais aussi par un bit FIN mis à un. De ce fait, le client croit à tort que le serveur lui a retourné la réponse.
L'origine de ce problème réside dans la façon qu'a Linux de construire son segment SYNACK. Il copie l'en-tête du SYN originel (et donc tous les indicateurs) puis les positionne à l'exception de FIN, ce qui amène l'hôte Linux à envoyer un FIN à son insu. Je l'ai fait remarquer aux développeurs du noyau Linux. D'après eux, T/TCP rend les hôtes vulnérables à une attaque massive de SYN et, de ce fait, ne devrait pas faire partie des protocoles majeurs. Finalement, il s'est avéré qu'une simple vérification a suffi à régler le problème.
elendil.ul.ie.2127 > skynet.csn.ul.ie.http: SFP 520369398:520369417(19) win 15928 <mss 1460,nop,nop,ccnew 7> (DF)
skynet.csn.ul.ie.http > elendil.ul.ie.2127: SF 2735307581:2735307581(0) ack 520369399 win 32736 <mss 1460>
elendil.ul.ie.2127 > skynet.csn.ul.ie.http: F 20:20(0) ack 1 win 15928 (DF)<\n>
skynet.csn.ul.ie.http > elendil.ul.ie.2127: . ack 1 win 32736 (DF)
elendil.ul.ie.2127 > skynet.csn.ul.ie.http: FP 520369399:520369418(19) win 15928 <mss 1460,nop,nop,ccnew 7> (DF)<\n>
skynet.csn.ul.ie.http > elendil.ul.ie.2127: . ack 21 win 32716 (DF)
skynet.csn.ul.ie.http > elendil.ul.ie.2127: P 1:242(241) ack 21 win 32736 (DF)
skynet.csn.ul.ie.http > elendil.ul.ie.2127: F 242:242(0) ack 21 win 32736
elendil.ul.ie.2127 > skynet.csn.ul.ie.http: . ack 243 win 15928 (DF)
Afin d'examiner les performances de T/TCP par rapport à celles du TCP/IP originel, j'ai compilé un certain nombre d'exécutables qui renvoyaient au client des données de différentes tailles. Les deux hôtes concernés étaient elendil.ul.ie (sous Linux) et devilwood.ece.ul.ie (sous FreeBSD 2.2.5). J'ai fait une moyenne des résultats, chaque requête ayant été envoyée 50 fois. Dans chaque cas, la taille maximale de segment est de 1460 octets.
L'étalon utilisé pour évaluer le niveau de performance était le nombre moyen de segments par transaction. The metric measured used for performance evaluation was the average number of segments per transaction. C'est Tcpdump qui m'a servi à observer les paquets échangés. Notez que celui-ci n'est pas d'une précision absolue. Pendant les échanges rapides, il a tendance à perdre quelques paquets en route pour pouvoir tenir la cadence, d'où quelques incohérences dans les résultats.
Figure 4. Nombre de segments par rapport à la taille des données transmises
La figure 4 montre le résultat de la confrontation de T/TCP contre TCP/IP en ce qui concerne le nombre de paquets transmis. Il est tout de suite évident qu'on en économise cinq en moyenne, lesquels sont la conséquence de la négociation tripartite et de l'envoi des paquets destinés à mettre un terme à une connexion. Ce sont les paquets perdus et les retransmissions qui perturbent le graphique.
Lorsque l'on utilise un client TCP avec un serveur T/TCP, on gagne quand même un segment. Une transaction TCP normale en demande neuf, mais comme le serveur exploitait T/TCP, le segment FIN était raccroché au segment de données terminal, réduisant le nombre de segments d'une unité. Ainsi, on obtient une diminution des segments même si une seule des deux parties reconnaît T/TCP.
Figure 5. Pourcentage d'économies en fonction de la taille des données transmises
La figure 5 présente le pourcentage d'économies réalisé pour les différentes tailles de paquet. Le nombre qui en est économisé est assez constant, mais en raison de l'augmentation du nombre d'échanges, le gain total décroît. Cela tend à prouver que T/TCP tire meilleur parti d'échanges de données de faible taille. Les résultats de ces test ont été obtenus depuis deux hôtes situés sur le même intranet. Afin de pouvoir comparer, ils ont été refaits avec un hôte sur l'internet : www.elite.net. La figure 6 montre les résultats des requêtes pour des données de taille identique qui ont été envoyées au serveur web. Ce graphique n'est pas aussi lissé que celui de la figure 4 en raison d'un pourcentage de paquets perdus et retransmis plus important.
Figure 6. Number of Segments versus Size of Data Transfer for Internet Host
La principale fuite de mémoire de l'implémentation réside dans la table de routage. Sous Linux, pour chaque machine avec laquelle l'hôte entre en contact est créée une entrée dans la table de routage. Ceci s'applique à une connexion aussi bien en sauts de puce que directe. L'accès à cette table se fait via la structure rtable. L'implémentation de T/TCP y ajoute les deux nouveaux champs CCrecv et CCsent.
En tout, la structure fait 56 octets. Ce n'est pas une grosse dévoreuse de mémoire sur un système isolé et de taille modeste. Par contre, elle peut l'être sur un serveur fortement chargé qui communique avec plusieurs milliers d'hôtes par heure. Linux possède un mécanisme grâce auquel une route qui ne sert plus peut être retirée de la mémoire. Périodiquement, une vérification est effectuée pour faire le ménage parmi les routes inutilisées ou en suspens depuis un moment.
L'ennui ici, c'est que la table de routage contient le cache de TAO. Ainsi, à chaque fois qu'une route contenant le dernier champ CC d'un hôte est détruite, l'hôte local doit réinitialiser la négociation tripartite avec un segment CCnew.
On pourrait créer un cache pour conserver les valeurs de TAO, mais la table de routage reste la solution la plus pratique. Il est également possible d'ajouter une vérification lors du nettoyage des entrées de routage de la présence d'une valeur de CC autre que zéro (indéfinie). Dans ce cas, on peut conserver la route soit pendant une durée de temps plus longue, soit à titre permanent.
Les bénéfices de cette dernière option sont évidents. Son utilisation la plus probable serait dans le cas où un hôte ne s'adresse qu'à un groupe particulier d'hôtes étrangers et refuse tout accès à ceux qui lui sont inconnus. Alors, il devient intéressant de garder en mémoire un enregistrement permanent afin de pouvoir sauter la négociation tripartite plus souvent.
La spécification originelle (RFC1644) du protocole a qualifié T/TCP d'expérimental. Depuis la publication de la RFC, aucune mise à jour n'a été apportée au protocole pour remédier à certains des problèmes. Par rapport à TCP, les gains sont évidents mais est-ce une manifestation des inconvénients qui l'emportent sur les avantages ?
Un des plus gros problèmes avec T/TCP est qu'il rend l'hôte vulnérable à certaines attaques par refus de service. L'engorgement par SYN (voir http://www.sun.ch/SunService/technology/bulletin/bulletin963.html pour plus de détails) est le terme employé pour désigner une forme d'attaque par refus de service dans laquelle l'agresseur envoit continuellement des paquets SYN à un hôte. Celui-ci crée une structure de sock pour chacun des SYN, réduisant ainsi le nombre de ces structures pouvant être mises à la disposition d'utilisateurs légitimes. Au bout du compte, cela peut même faire planter l'hôte si suffisamment de mémoire est consommée. Les cookies SYN ont été implémentés dans le noyau Linux pour contrevenir à cette attaque et impliquent l'envoi d'un cookie à l'émetteur pour s'assurer que la connexion est valide. Ils sont la cause de problèmes avec T/TCP, aucune option TCP n'y étant insérée et toute donnée arrivant dans le SYN initial ne pouvant être utilisée immédiatement. L'option CC de T/TCP fournit bien quelque protection de son crû, mais ce n'est pas encore assez sûr.
Lors d'investigations, un autre problème important est apparu : un agresseur peut contourner l'authentification du rlogin. Pour ce faire, il va créer un paquet contenant une fausse adresse IP connue de l'hôte de destination. Une fois envoyé, les options CC lui permettent d'être accepté immédiatement et les données d'être transmises. Ensuite, l'hôte destinataire envoit un SYNACK à l'adresse IP d'origine. Quand il arrive, l'hôte initial envoit un reset, vu qu'il ne se trouve pas dans un état de SYN-SENT. Mais c'est trop tard, la commande ayant déjà été exécutée chez l'hôte de destination. Tout protocole utilisant une adresse IP en guise d'authentification peut être sujet à ce genre d'attaque. (cf http://geek-girl.com/bugtraq/1998_2/0020.html). Il existe des remèdes à ces trous de sécurité.
Kerberos est un protocole d'authentification de tierce partie mais qui nécessite la présence d'une autorité de certification ainsi qu'une augmentation du nombre de paquets transmis. La couche IP incorpore d'origine de l'authentification et de la sécurité. Avec la standardisation de la nouvelle version, IPv6, l'authentification des paquets IP deviendra possible sans intervention extérieure. On y parvient par l'entremise d'un en-tête d'authentification qui fournit authentification et intégrité sans confidentialité.
La RFC1644 recèle également un problème de double transaction. Cela peut se révéler très gênant pour des applications non idempotentes (les transactions à répétition sont très peu prisées). On peut considérer que demander l'heure à un serveur de temps est idempotent car cela n'induit pas d'effets secondaires néfastes aussi bien côté client que côté serveur si la transaction est répétée. Par contre, dans le cas d'un système bancaire, si une transaction sur un compte venait à être accidentellement réitérée, le titulaire se verrait débité ou crédité de deux fois plus qu'escompté. Cette anomalie peut survenir dans T/TCP si une requête est envoyée à un serveur et que celui-ci traite la transaction, mais que le processus plante avant qu'il n'ait pu retourner un accusé de réception. Du côté client, le délai d'attente arrive à expiration et il retransmet la requête, mais si le processus du serveur se reprend à temps, il est susceptible de répéter la même transaction. La cause de ce problème est que les données d'un SYN peuvent être immédiatement passées au processus, alors que dans TCP, pour qu'elles puissent être utilisées, il faut que la négotiation tripartite soit achevée. Le recours à des connexions et des transactions en deux phases doit permettre de l'éviter.
Ce chapitre illustre les fonctionnalités requises de T/TCP pour Linux ainsi que ses avantages en termes de rapidité et d'efficacité par rapport au TCP classique.
C'est un fait acquis, T/TCP est affecté de quelques problèmes graves, mais ceux-ci ne s'appliquent pas à toutes les situations. T/TCP peut être utilisé sans craintes partout où les hôtes bénéficient de quelque forme de protection (autre que basée sur de la pure sémantique T/TCP) et où des précautions élémentaires de sécurité sont prises.
Le World Wide Web étant de nos jours le principal exemple de traitement transactionnel client-serveur, cette section mettra l'accent sur les bienfaits de T/TCP pour l'efficacité du Web.
Actuellement, le protocole HTTP réside dans la couche applicative du modèle de référence TCP/IP. Il fait appel au protocole TCP pour mener à bien tous ses traitements, UDP étant trop peu fiable. Une latence non négligeable fait partie du transfert de données, avec, par exemple, la négociation tripartite et les échanges de fermeture de connexion explicites. Les critères définis à la section 2.1 font apparaître clairement le côté transactionnel des opérations du World Wide Web.
Sur un échantillon de 2,6 millions de documents web épluchés par le moteur de recherche Inktomi (cf. http://inktomi.berkeley.edu), leur taille moyenne s'établissait à 4,4 Ko, avec environ 2 Ko pour la plupart et un maximum à 1,6 Mo.
Si on se réfère à la figure 3.2, on peut voir que plus la taille du segment est réduite, plus T/TCP est performant par rapport à TCP/IP. Avec des documents d'une taille moyenne de 4,4 Ko, on obtient un gain moyen d'un peu plus de 55% en nombre de paquets. Si on prend en compte la taille la plus fréquente, on gagne à peu près 60%.
Sur la durée, on constatera une augmentation de la vitesse, en fonction, bien sûr, de la fiabilité du réseau.
Un certain nombre de suggestions ont été avancées pour améliorer le traitement de HTTP et réduire le temps et la bande passante nécessaires pour récupérer des données. La plupart sont basées sur la compression et/ou l'encodage delta.
Actuellement, toutes les pages Web sont transmises sous une forme purement textuelle, ce qui ne demande que peu d'efforts, du côté du serveur comme de celui du client, pour les afficher.
Afin de pouvoir introduire la compression dans le protocole HTTP, il faut régler un certain nombre de problèmes.
En tout premier lieu, celui de la compatibilité ascendante, le Web s'étant tellement étendu de par le monde, le passage à la compression se ferait sur une longue période. Les navigateurs doivent être programmés pour gérer les pages compressées et les serveurs Web configurés pour compresser les données demandées avant de les envoyer. L'introduction d'un standard de compression devrait être une tâche évidente pour l'IETF (Internet Engineering Task Force). It would then be up to the vendors and application writers to modify the browsers and servers for the new standard.
Autre problème : la charge induite sur le serveur lorsqu'il lui faut compresser les données. Beaucoup de serveurs très occupés n'auraient pas la puissance nécessaire pour traiter ce surcroît de travail. C'est aussi valable dans une moindre mesure pour le client, avec un minimum de surcharge dûe à la décompression de quelques pages à la volée.
Dans leur article "Network Performance Effects of HTTP/1.1, CSSI and PNG", les auteurs se sont penchés sur l'effet de l'introduction de la compression au sein du protocole HTTP. Ils ont découvert que cela permettait de gagner 64% en vitesse de téléchargement, avec une diminution de 68% du nombre de paquets requis. Considérant le TCP/IP de base, ceci amène les échanges de paquets et la taille des données au niveau où T/TCP devient intéressant. De ce fait, une stratégie qui mêlerait à la fois la compression et T/TCP pourrait engendrer des gains énormes en temps et en bande passante.
Dans le cas présent, delta correspond aux différences existant entre deux fichiers. Sur des systèmes Unix, on peut utiliser la commande diff pour créer un delta entre deux fichiers. Grâce à celui qui est modifié et au delta, il est possible de régénérer le fichier originel, et vice versa.
Sur le web, l'encodage delta commence par une requête du client au terme de laquelle il reçoit le document demandé. En se basant sur T/TCP et sur la taille de document la plus fréquente, on gagne environ 55%. Une fois que le client a la page, celle-ci peut être mise en cache et stockée . La prochaine fois qu'il la demandera, le navigateur en détiendra déjà l'original dans son cache. Avec l'encodage delta, le navigateur fournira au serveur web la date de la dernière modification du document. Ensuite, le serveur détermine s'il a été mis à jour depuis que la copie a été mise en cache, et dans ce cas, un delta du document côté serveur est créé, puis transféré, de préférence au document original.
Bien sûr, quelques écueils devront être pris en considération.
Si cette méthode était employée avec T/TCP, on pourrait gagner jusqu'à 66% de plus sur les paquets transférés, pour un total de 94%.
Cependant, il convient de noter que c'est un scénario idéal. Ici, le document est déjà dans le cache à la fois du serveur et du client, et ceux-ci auront précédemment accompli la négotiation tripartite afin de faciliter les tests de TAO.
La RFC2068 décrit une modification apportée à HTTP qui maintient une connexion ininterrompue à un serveur HTTP et permettant de servir des requêtes multiples : P-HTTP. Ceci remédie au problème d'avoir à se reconnecter continuellement à un serveur web pour y télécharger plusieurs images issues d'une même page. Les reconnexions incessantes finissent par engendrer un surcroît de traitement inutile.
Quelques avantages sur le protocole originel HTTP :
A l'aide des résultats obtenus à la section 3 et des caractéristiques de documents disponibles sur le World Wide Web, la présente étude traite des bénéfices que l'on peut attendre de T/TCP et donne également quelques suggestions sur la façon d'améliorer le protocole HTTP.
L'aspect le plus important dans l'introduction de la compression et de l'encodage delta est la réduction du volume des données à transmettre. Les résultats issus de l'analyse de l'efficacité de T/TCP semblent indiquer que l'on gagnerait plus en transférant de faibles quantités de données. Des concepts de compression et d'encodage delta découlent des données suffisamment compactes pour tenir dans un seul paquet. Dans ces conditions, c'est T/TCP qui fonctionne le mieux.
P-HTTP met en avant l'idée d'une connexion semi-permanente, à l'inverse du système d'ouverture/fermeture actuellement employé par HTTP. Dans ce cas de figure, T/TCP ne fonctionnera pas du tout en raison de son approche transactionnelle.
La programmation pour T/TCP est légèrement différente de celle des sockets.
Par exemple, la suite d'appels-système nécessaires pour implémenter un client TCP s'établirait comme suit :
La programmation sous T/TCP et sous UDP sont très proches.
Au départ, T/TCP a été conçu pour combler le besoin d'un protocole plus efficace pour les applications transactionnelles. Ceux qui étaient définis à l'origine dans le modèle de référence TCP/IP étaient soit trop verbeux, soit pas assez fiables.
T/TCP s'appuie sur le protocole TCP et introduit quelques nouvelles fonctionnalités qui permettent à la négociation tripartite d'être contournée dans certaines situations. Quand cela arrive, la transaction peut presque se contenter du nombre de segments minimum requis pour un transfert de données. T/TCP peut réduire le nombre moyen de segments impliqués dans une transaction de 9 (TCP) à 3 grâce au test de TAO. Ceci a un effet bénéfique potentiel sur des réseaux surchargés où un protocole plus efficace devient nécessaire.
L'analyse de T/TCP montre que l'on gagne plus avec des transferts transactionnels de faible volume qu'avec des échanges de données de taille importante. Le World Wide Web, les appels de procédure distants (RPC) et le DNS présentent des exemples de transactions. Ces applications peuvent tirer profit de T/TCP aussi bien en efficacité qu'en vitesse pure. T/TCP réduit en moyenne à la fois le nombre de segments impliqués dans une transaction et le temps nécessaire à son accomplissement.
Comme T/TCP n'est encore qu'un protocole expérimental, certains problèmes restent à traiter. En matière de sécurité, la vulnérabilité aux attaques par engorgement de SYN et le contournement de l'authentification du rlogin. D'un point de vue opératoire, la possibilité que des transactions apparaissent en double. Parmi d'autres moins fréquemment rencontrés, l'empaquetage de champs CC sur des connexions à haut débit qui aurait pour conséquence de faire accepter à un hôte destinataire des segments sur la mauvaise connecxion.
Beaucoup de gens admettent le besoin d'un protocole qui facilite le traitement transactionnel et sont prêts à accepter T/TCP comme solution. Les réflexions quant à la sécurité amènent à conclure que T/TCP serait plus utile dans un environnement contrôlé, c'est à dire qui soit peu sujet à une agression éventuelle exploitant les faiblesses du standard. Citons comme exemples de tels environnements fermés des Intranets d'entreprises et des réseaux abrités derrière un pare-feu. Beaucoup d'entreprises considérant le Web comme l'avenir pour faire des affaires, aussi bien en interne qu'en externe, un système utilisant T/TCP et quelques-unes des améliorations apportées à HTTP, telles que la compression et l'encodage delta, aurait pour effet une augmentation spectaculaire de la vitesse au sein d'un Intranet d'entreprise.
Pour les développeurs prêts à accepter T/TCP comme solution pour leurs applications, celles-ci n'auront à subir que de légères modifications pour devenir compatibles avec T/TCP. La programmation côté client nécessitera l'élimination des appels de fonction connect() et shutdown() qui pourront être remplacés en ajoutant l'indicateur MSG_EOF à la commande sendto(). Sur le serveur, seule cette dernière modification suffira.
En conclusion, les recherches dans le domaine de T/TCP donnent à penser que ce protocole est presque prêt, il y a encore à faire, pour prendre en charge un traitement transactionnel généralisé. S'agissant spécifiquement de T/TCP, des efforts restent à accomplir pour le développer plus avant et régler les problèmes de sécurité et de fonctionnement. Il est possible de remédier aux problèmes de sécurité par le biais d'autres protocoles d'authentification, tels que Kerberos, et des facilités offertes dans ce domaine par IPv6. Le fonctionnement quant à lui, pourra être traité grâce à une plus grande fiabilité des transactions incluse dans les applications même qui utiliseront T/TCP, comme par exemple, une historisation des logs de transaction et de commit.
Les développements futurs de cette branche pourraient inclure la promotion de T/TCP comme alternative aux protocoles TCP et UDP pour certaines applications. Le décollage de T/TCP a été difficile. L'implémentation sur plate-forme PC la plus répandue tourne sous FreeBSD. A présent que Linux le reconnaît aussi, l'incitation à employer le protocole n'en sera que plus importante. On peut facilement modifier les applications pour qu'elles utilisent T/TCP quand il est disponible, chacune faisant appel à une connexion d'ouverture/fermeture peut en tirer parti efficacement, les exemples les plus flagrants seraient les navigateurs et les serveurs Web, ainsi que les applications client/serveur DNS. Dans une moindre mesure, des programmes tels que les démons time, finger et whois peuvent également trouver un intérêt à T/TCP. Beaucoup des utilitaires réseau disponibles peuvent bénéficier de l'efficacité du protocole, tout ce qu'il faut, c'est l'envie de s'y mettre. Cependant, le port de T/TCP au sein du nouveau noyau Linux 2.1.x semble constituer une tâche plus prioritaire.
Braun H W, Claffy K C, "Web Traffic Characterization: An Assessment of the Impact of Caching Documents from NCSA's Web Server", Proceedings of the Second World Wide Web Conference '94: Mosaic and the Web, October 1994
Mogul J C, Douglis F, Feldmann A, Krishnamurthy B, "Potential Benefits of Delta Encoding and Data Compression for HTTP", ACM SIGCOMM, September 1997
Prud'Hommeaux E, Lie H W, Lilley C, "Network Performance Effects of HTTP/1.1, CSSI and PNG", ACM SIGCOMM, September 1997
Stevens W R, TCP/IP Illustrated, Volume 3, TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols, Addison-Wesley, 1996
Copyright © 1999, Mark Stacey
Published in Issue 47 of Linux Gazette, November 1999.
