La vitesse de la lumière, ce n’est pas assez ! (pour une distribution efficace des données informatiques…)
Pourquoi une simple augmentation de la bande passante ne suffit pas pour réellement améliorer la distribution des données ?
La rapidité de l'accès aux données est un critère essentiel de productivité pour les collaborateurs distants. Cependant, malgré de sensibles augmentations de la bande passante des réseaux WAN, ou les nouvelles approches de distribution des applications (basées Web - souvent via un chiffrement SSL -, streaming, etc.), de nombreux utilisateurs distants se trouvent encore souvent en situation d'attente d'informations.
De plus en plus d'intervenants travaillent depuis un point éloigné du siège de leur entreprise, ce que confirme une récente enquête publiée par l'institut Nemertes, qui indique que « en moyenne, moins de 10% des utilisateurs informatiques de grandes entreprises travaillent au siège » a. Dans le même temps, les directions informatiques procèdent à la consolidation de leurs serveurs, afin de réduire les complexités d'administration et de satisfaire aux règlementations concernant les sauvegardes.
Seule limitation inévitable : la vitesse de la lumière
Il est indiscutable que, jusqu'à un certain point, un ajout de bande passante favorise la disponibilité des données, sachant que plus les utilisateurs distants sont nombreux, plus le bénéfice est sensible. Cependant, cette augmentation de bande passante se heurte à deux écueils : son prix, et le fait qu'elle ne soit forcément exploitée à son réel potentiel. Seule limitation inévitable : celle de la vitesse de la lumière.
La distance est l'ennemie des applications informatiques
La plus grande difficulté qui s'oppose aux applications est la distance qu'elles doivent parcourir, ou plus précisément leur cycle de transfert RTT ("round trip time"), qui se définit à partir des paramètres suivants :
Prenons un exemple : en se basant sur CIFS (protocole de services fichiers de Microsoft), un utilisateur transmet des paquets d'information de faible taille (64 Ko), puis doit ensuite attendre la confirmation de réception ("acknowledgment") du destinataire avant d'envoyer les autres paquets. D'autres protocoles réduisent même encore cette taille de paquets (MAPI, exploité avec Microsoft Exchange, utilise au maximum une taille de 32 Ko).
Conséquence : un fichier de 5 Mo nécessitera un minimum de 78 cycles (ou 156 s'il s'agit de MAPI !).
Ceci suppose par ailleurs que TCP exploite sa plus grande largeur de fenêtre, même si cette largeur est calculée et ajustée entre les périphériques en fonction du temps de réponse ; TCP ne dispose en l'occurrence jamais de fenêtres de 64 Ko sur les liens à grande latence.
Si la vitesse intrinsèque de la lumière (dans le vide) est très élevée - 299 792 km/seconde - elle se réduit de 30% lorsqu'elle transite via la fibre optique ou le câble cuivre b, pour se situer aux environs de 210 000 km/s.
Revenons à notre fichier de 5 Mo qui nécessitait 78 cycles RTT. Si l'on considère que le serveur se situe à Boston, aux Etats-Unis, et que l'utilisateur se trouve à Londres, la distance d'un cycle RTT sera de 10 558 km. 78 cycles représenteront par conséquent 823 524 km. Si vous divisez cette distance par 210 000, vous obtiendrez un délai de 4 secondes pour récupérer le fichier.
En théorie, notre cycle RTT entre Boston et Londres est de 50 millisecondes seulement (10 558 divisés par 210 000), mais la réalité nous oblige à (au minimum) doubler cette valeur. Pendant que je rédigeai cet article à Londres, j'ai testé le temps de cycle de trois sites Internet basés dans la région de Boston (c1-c2-c3) (sachant qu'à cette heure-là, les Etats-Unis étaient "endormis"), et j'ai mesuré des temps moyens de 129 millisecondes. Si l'on ne tient pas compte des retards de pare-feux ou de serveurs, de l'encombrement des lignes ou des tailles de fenêtres, on arrive à un délai minimum de 10 secondes pour qu'un fichier de 5 Mo me parvienne.
Voici quelques autres exemples de cycles RTT pour le même fichier de 5 Mo :
· San Francisco - Londres 16 secondes
· San Francisco - Sidney 23 secondes
· Dallas - Pékin 21 secondes
· Paris - New Delhi 12,5 secondes
La capacité de bande passante n'est donc pas le seul critère de performance. Quelle que soit la bande passante disponible, les données devront immanquablement souffrir du ralentissement causé par les "allers-retours" entre le serveur et l'utilisateur.
Il n'est évidemment pas possible d'augmenter la vitesse de la lumière : c'est bien pourquoi les entreprises doivent dès aujourd'hui se mettre en quête de solutions suffisamment pratiques et flexibles pour résoudre cette problématique, faute de quoi leurs applications deviendront inexploitables sur leurs sites distants.