TCP cet illustre inconnu

A l’origine, des télécoms, les transmissions étaient orientées « circuit » : on réservait entièrement un canal entre A et B, et on y faisait passer les informations avec beaucoup de réussite. Réussite couteuse puisqu’il fallait totalement dédier ces moyens télécom pendant toute la durée de la communication.

Lorsqu’on a voulu partager les moyens de transmissions entre beaucoup de de terminaux et serveurs et rendre le réseau plus souple et résistants (plusieurs chemins possibles), on a développer des protocoles de transmission orientés « paquet ». L’information est tronçonnée et transmise par petits paquets dans un réseau que l’on peut cette fois partager.

TCP/IP est une famille de protocoles issue de cette recherche, à l’origine et faisant l’essence même de l’Internet.

Mais à cette époque, dans les années 70-80, les réseaux de télécom n’étaient pas très fiables, il y avait beaucoup de pertes des informations transportées. Ces pertes étaient, par exemple, des erreurs de transmission (perturbations électromagnétiques, piètre traitement du signal des émetteurs/récepteurs, etc.), des collisions de messages sur des médias (les supports de transmission tels que les ondes radio ou des câbles avec une porteuse partagée) qui étaient essentiellement half-duplex (le canal de communication est le même pour envoyer et recevoir, il faut donc alterner) et finalement, les pertes par congestions dans le réseau de faible capacité où un goulet d’étranglement voyait ses mémoires tampons d’un équipement d’extrémité déborder et… jeter des informations !

Il fallait donc fiabiliser les protocoles qui géraient les paquets de l’Internet puisqu’ils allaient forcément rencontrer des pertes sur un maillon dégradé ou congestionné du réseau. Dans TCP/IP, IP se charge d’aiguiller (on dit « router ») les paquets dans les mailles du réseau entre expéditeur et destinataire, mais c’est à TCP que l’on doit la réussite du transport !

TCP, un héro incompris

TCP a un rôle très difficile et très complexe. Et pourtant, il se fait désormais totalement voler la vedette par IP (d’ailleurs on parlait dans les années 80/90 de TCP/IP alors qu’on ne parle plus aujourd’hui que des réseaux « IP »).

Le modèle protocolaire TCP/IP fonctionne en couches avec chacun sa responsabilité dans la chaîne de communication. Dans le standard OSI à 7 couches, voici la représentation de TCP/IP :

C’est ainsi qu’en parlant de « Reseaux IP », on parle de la couche réseau, la numéro 3. Celle-ci a donc ses ingénieurs, ses architectes et ses opérateurs de services. Dans les Directions des Systèmes d’Information (DSI) d’entreprise, c’est le département « Réseau et Télécom » qui s’en occupe. Bref, le « réseau », c’est là !

Mais TCP alors ? Et bien TCP, c’est l’oublié du débat, il est devenu un illustre inconnu ! Qu’un client s’adresse à un opérateur de réseau et celui-ci lui dira que son réseau est super extra fiable, SLA de performance à l’appui tels que Packet Loss Rate, Round Trip Delay, etc. et qu’il est totalement transparent à tout IP. En clair, mettez tout ce que vous voulez dessus, tant que c’est de l’IP, ça marche. TCP, on s’en fiche. Au mieux, l’opérateur vous offre des Classes de Services (CoS) avec des niveaux différents de Qualité de Service (QoS) pour les différentes applications ou la Voix sur IP, on s’intéresse donc à une discrimination des flux impliquant une reconnaissance de niveau supérieur dont les ports TCP, mais c’est tout.

Et les applications en réseau alors, ce sont elles qui ont besoin de la fiabilité du transport ! Elles ne s’y intéressent pas, elles, à TCP ? Et bien non. Les applications utilisent des API, véritables « boites noires » d’accès aux services réseaux de plus ou moins haut niveau, mais « standard », c’est à dire, in fine fournies par le Système d’Exploitation. En clair, les applications s’en lavent les paquets, et c’est à Microsoft, Unix, Linux, Mac OS, iOS, etc. de s’occuper de « ça »…

Et ça… c’est pour 95% des applications, c’est TCP !

Mais alors, c’est quoi TCP ?

Le vernis que la plupart des gens de l’IT possèdent sur TCP, c’est d’abord un en-tête de transport des données. Avec quelques caractéristiques connues : les ports source et destination, des numéros de séquences, des acquittements (pour dire que tout va bien).

TCP Header

Mais en fait, TCP, c’est surtout une ribambelle de mécanismes qui lui permettent de remplir sa mission de contrôle du transport de bout en bout. Sans ces mécanismes, TCP ne serait que… UDP ! L’autre principal protocole de transport, non fiable, lui.

Et ces mécanismes, ils ont de doux noms, de gentilles variables et de magnifiques algorithmes… jugez plutot : Slow Start, Congestion Control, Congestion Avoidance, Fast Retransmit, Fast Recovery, Sliding Window, Frozen Window, Selective ACK, Triple Duplicate ACK, Delayed ACK, Nagle, Sender/Receiver Window… j’en passe.

Le but, ici, n’est pas d’expliquer chacun d’eux en détails. Mais simplement de souligner l’implication qu’ils peuvent avoir dans la performance de vos applications et la complexité que représente leur bonne analyse… alors même que personne ne s’intéresse à eux dans les organisations IT !

Max TCP Send/Receive Windows & Slow Start & Congestion Avoidance :

Ceux-là en ont plusieurs à eux seuls 1. Démarrer doucement pour détecter la limite de débit utilisable. 2. Ralentir le trafic lorsqu’on atteint une limite du réseau (typiquement la saturation de la bande passante ou une congestion quelconque) pour ne pas jeter et retransmettre intempestivement des paquets. 3. Partager la bande passante équitablement entre plusieurs sessions TCP en cours.
Effets de bord :
– Les seuls paramètres de Max TCP Windows varient d’un OS à l’autre et d’une version à l’autre. Or leurs valeurs peuvent induire des limitations de bande passante dans les réseaux haut débit et à forte latence !
– L’algorithme de Congestion Avoidance est un peu lent et peut manquer d’efficacité sur des réseaux fiables et rapides. Il a d’ailleurs connu de nombreuses évolutions standard ou propriétaires.

TCP Frozen Window :

Très belle astuce du mécanisme de congestion avoidance ; TCP transporte à tout moment la taille de fenêtre TCP entre serveur et client, c’est à dire la quantité de données qui peuvent être transmises au réseau avant d’attendre les premiers acquittements du destinataire. Or cette fenêtre varie selon les aléas du transport et peut même tomber à 0, ce qui signifie que le récepteur n’arrive plus à stocker en mémoire de nouvelles informations, typiquement parce que l’application ne lui vide pas sa pile assez vite, et l’émetteur doit vite arrêter d’envoyer. Le transport est bloqué ! Que fait l’application ? Qui a dit que TCP n’était qu’un protocole réseau ?
SACK option :
Lorsqu’on perd plusieurs paquets, inutile de demander la retransmission de la totalité depuis la perte, SACK permet de n’informer que des numéros à retransmettre. A condition que client et serveur se mettent d’accord, c’est une option.

Triple Duplicate ACK :

Lorsqu’un destinataire se rend compte d’une perte de paquet en observant un « trou » dans les numéros. Plutôt que d’attendre que l’émetteur s’en aperçoive aussi par l’absence de ACK en retour, le destinataire envoie pro-activement 3 ACK identique du dernier paquet reçu, pour gagner du temps dans la retransmission. A condition que personne ne s’en mêle entre les 2.

Delayed ACK :

Ceci est une astuce pour économiser les ressources des routeurs et réseau : TCP va attendre jusqu’à 200 ms pour grouper l’envoi d’un ACK avec un SYN/PSH dans un même paquet.

TCP Nagle :

Encore une astuce pour remplir les paquets TCP avant envoi sur le réseau. Un effet de bord : dans certains cas cet algorithme Nagle combiné au précédent, Delayed ACK, avec des trains de paquets TCP impairs peut dégrader substantiellement les temps de réponse d’un application.

TCP Offload Engine :

Sans être tout à fait un mécanisme de TCP, c’est une fonction extrêmement courant sur les serveurs. Afin de libérer le CPU d’un travail répétitif de traitement des en-têtes TCP (gestion du découpage des datagrammes, des numéros de séquences, des ACK, etc.), l’encapsulation TCP est déléguée à des composants matériels spécialisés directement embarqués sur la carte réseau. Très pratique… quand tout va bien. Mais attention aux mises à jour des firmware de cartes, au groupement de cartes physiques en carte virtuelle, au partage des cartes physiques en virtualisation, etc…

Comme vous pouvez le constater, TCP, ce n’est pas une toute petite affaire. En cas de problème, il faut bien que quelqu’un s’en préoccupe ! Mais puisque je vous dis que personne ne s’intéresse à TCP… ce n’est donc la faute de personne !

C’est ainsi que nos histoires de Performance des Applications (sur lesquels vous comptez très probablement faire tourner votre business), si elles tombaient par malheur sur un problème impliquant cet illustre inconnu de TCP, et bien elles n’ont pas terminé de faire le ping-pong entre les équipes Télécom & Réseau et Système & Applications ; et d’empoisonner la vie du DSI qui ne trouve personne capable de les prendre en charge.

A moins de trouver quelqu’un ayant une vision suffisamment transverse Réseau et SI pour embarquer TCP avec lui.