Empilement de protocoles

Non, vous n’avez pas 24Mb/s. Dans l’idéal, si vous n’avez aucune perte et si vous utilisez le maximum théorique de votre ligne, vous avez entre 15 et 16Mb/s. Le tour de passe passe c’est qu’on ne parle pas de la même chose. 24Mb/s c’est le débit possible en ATM. ATM c’est le protocole utilisé en interne par votre FAI pour faire passer vos données.

Ce que vous utilisez vous c’est de l’IP. Il va falloir encapsuler vos données IP dans un flux ATM, en gros jouer aux poupées russes. Votre poupée à vous c’est la petite à l’intérieur, et s’il faut faire transiter la grosse extérieure, vous vous rendez bien compte que vous allez pouvoir en faire passer moins que prévu. En réalité la perte est entre 20 et 25%. Chez Free.fr, si on en croit les chiffres publiés sur leurs publicités, c’est 22% de moins.

Bref, 24Mb/s ? que dalle, c’est dans les 18Mb/s. En réalité encore moins parce que dans un trafic IP il y a aussi une partie liée au protocole. En prenant TCP et IP, on perd alors minimum 2 à 3% par paquet. En réalité nombre de paquets ne sont pas remplis au maximum, et il faut aussi compter des paquets de contrôle. Pour une utilisation « web » (hors vidéos et téléchargements) c’est dans les 90% de trafic utile seulement. Nous voilà tombés à 16Mb/s.

Qualité de ligne

Tout le monde n’a pas ces 16Mb/s non plus. C’est un débit théorique au plus proche du DSLAM. Malheureusement la courbe du débit théorique en fonction de la distance n’est pas proportionnelle. Après 1km le débit chute drastiquement. Un petit graphique vaut mieux qu’un long discours.

Des DSLAM il n’y en a pas sur toutes les rues. Même à Paris il est assez facile de dépasser le kilomètre. En plus petite ville, et particulièrement en bordure d’une ville de moyenne importance, la distance peut facilement exploser, et le débit faire l’opération inverse. 16Mb/s ? oubliez, beaucoup sont à moins de 8Mb/s. Demandez autour de vous de faire des tests de débits, vous pourriez être surpris.

Reste qu’on parle toujours d’un débit théorique sur une ligne optimale. Votre ligne n’est pas optimale. Suivant le diamètre de votre cuivre qui vous connecte au DSLAM et son environnement électromagnétique, vous pouvez avoir plus ou moins de bruit parasite. L’ADSL est génial dans le sens qu’il gère ce bruit et sait tout seul diminuer la bande passante pour assurer la qualité de la communication, mais ça fait autant en moins sur votre bande passante.

Pas que l’ADSL

Plus répandus, il y a une grande partie des internautes qui sont connectés par WIFI. Là aussi la qualité de la ligne compte, et non vous n’avez jamais les 54Mb/s promis. Si vous en avez le tiers vous pouvez être heureux. Le wifi b encore très répandu c’est 11Mb/s théorique, 6 réels dans de bonnes conditions. Ajoutez quelques murs, un étage, et les dégats commencent même si vous êtes à 200 mètres du DSLAM.

En progression il y a aussi la 3G et les terminaux mobiles. C’est du 3,6Mb/s théoriques, rarement plus de 2Mb/s en pratique car là aussi il y a un affaiblissement avec la distance. Cette bande passante est attribuée par cellules pendant un certain laps de temps. Vous êtes loin ? vous utilisez plus de cellule. Vous faites juste une requête ? la cellule vous est quand même attribuée. Vous ne demandez pas beaucoup de bande passante ? vous risquez d’utiliser des tranches de façon incomplète.

Je suis sympa, en réalité il y a encore des entreprises avec des lignes 256kb/s (ne vous moquez pas, la garantie de fonctionnement n’est pas la même) et des particuliers avec du RTC.

Empilement des requêtes

Allons encore plus loin. Levez la main ceux qui ont un client P2P qui tourne ? ceux qui ont la fille ou la petite soeur qui regarde ses vidéos ? ceux qui regardent la TV par ADSL ? ou simplement ceux dont le conjoint surfe aussi à partir d’une autre machine ?

La bande passante est partagée. Le P2P est un énorme consommateur de bande passante, avec une utilisation très peu efficace. La vidéo, ou même le surf, c’est autant de moins pour vous. Vous êtes 3 ? divisez par 2 la bande passante si vous surfez. Même chose si vous surfez avec plusieurs onglets en train de charger en parallèle, ou si vous cumulez plusieurs logiciels qui font appel au réseau. Si les autres font du téléchargement ou de la vidéo c’est facilement par 5 ou 6 qu’il faudra tout diviser. La TV par ADSL c’est 5Mb/s qui partent en fumée (et là ce n’est pas du maximum théorique, c’est du mesuré).

C’est vrai pour votre ADSL, ça l’est encore plus pour le WIFI ou la 3G. Là les fréquences sont limitées. Si quelqu’un utilise la 3G ou le WIFI, c’est tout le monde qui est impacté. Pour le WIFI peu importe que ce soit une autre borne wifi qui est utilisée, ce sont les mêmes fréquences, la même bande passante commune. Il ne vous reste plus qu’à espérer que personne ne regarde une vidéo en boucle par wifi dans votre immeuble.

Encore des contraintes techniques

Voilà votre 24Mb/s bien réduit. Une peau de chagrin qu’il reste avec tout ça. Parce que nous parlons toujours de bande passante maximale. En réalité vous n’atteignez pas la bande passante maximale qui vous reste.

Le serveur web en face ne délivre pas du 10Mb/s à tout le monde. En fait hors les quelques très gros sites, c’est déjà bien s’il a 10Mb/s garantis à partager entre tous ses clients. Les plus gros c’est 100Mb/s par serveur, à partager entre 50 à 300 clients simultanés. Faites le compte vous même.

Après vous ajoutez les contraintes de TCP/IP, qui font que la bande passante idéale entre le serveur et le client n’est pas utilisée immédiatement. Sur des petits contenus vous ne l’atteignez pas, quoi qu’il se passe.

Le résultat ?

Le résultat c’est que vous n’avez très probablement pas plus de 10Mb/s sur votre ligne ADSL, moins sur votre WIFI, et moins de 2Mb/s sur du 3G. Que tout ça est à partager entre tout le monde et avec votre TV sur votre modem ADSL, ou avec tout votre quartier pour le WIFI et la 3G. Et que vous n’utiliserez pas efficacement ce qu’il vous reste si ce que vous faites c’est du surf web.

24Mb/s.. vous rigolez ? c’est de la communication, pas de la réalité.

Il va être fréquent d’avoir assez peu. Pour mes tests je prend fréquemment 2Mb/s comme référence. Je sais que je suis bien au dessous de ce que les geeks ont, ceux qui choisissent leur appartement en grande ville en fonction du DSLAM, mais j’ai encore peur d’être au dessus du débit pratique médian d’une session de surf.

Là bien sûr je parle d’une représentation du public français. Pour de l’international ce serait encore pire, car quoi qu’on vous dise la France est plutôt en avance de ce côté là.

Oh, dernière chose … On parle en Mb/s, mega bits par secondes. Pour obtenir des Mo/s, il faut diviser par 8. Oui, mes 2Mb/s c’est 250ko/s.

Avec ces statistiques la recommandation était de répartir les téléchargements sur deux domaines, quatre maximum. On arrive donc à 4 ou 8 requêtes simultanées. Plus consomme inutilement du processeur et provoque un surplus inutile de requêtes DNS.

Ces différents domaines peuvent être des sous domaines ou pas, peuvent ou pas être des sites virtuels qui mènent en réalité à au même serveur physique, voire au même contenu. L’important est que le navigateur voit des URLs au domaine différent. Par contre ne faites jamais des liens aléatoirement vers un domaine ou un autre, vous perdriez tout le bénéfice du cache entre deux visite car les URLs changeraient à chaque fois.

Une évolution des navigateurs

Depuis deux ans le parc des navigateurs a évolué. Internet Explorer 8 fait une percée non négligeable. Les utilisateurs de Firefox utilisent quasiment tous la version 3 et représentent maintenant une proportion importante du trafic. Safari et Chrome font plus parler d’eux. On passe de 2 à 4 (Safari), 6 (Firefox 3, Internet Explorer 8, Chrome) voire 9 (dernière version d’Opera). Steve Souders a un bon résumé des capacités des différents navigateurs par rapport aux performances, pour ceux que ça intéresse.

A t’on encore besoin d’utiliser plusieurs domaines ?

Clairement quatre domaines représentent alors entre 16 et 24 requêtes simultanées. C’est clairement trop ou inutile. Surtout avec l’apparition des terminaux mobiles et autres netbook avec une connexion wifi ou 3G pas excellente et une puissance processeur réduite.

L’étude nécessite d’être refaite avec un échantillon d’utilisateurs plus représentatif de la période actuelle. Si encore une moitié des utilisateurs reste avec 2 connexions simultanées, il devient contestable de leur faciliter la vie si ça pénalise la seconde moitié de la population.

Intuitivement je changerai bien la règle en « deux domaines, mais surtout pas plus« , tout en diminuant l’importance de ce critère. En fait le second domaine est nécessaire de toutes façons pour pouvoir utiliser un CDN et diminuer la latence sur les ressources statiques. Pour un site en ssl/https les domaines surnuméraires deviendront d’autant plus coûteux à cause de la poignée de main ssl et tout garder sur un seul domaine dans ce cas là ne devient pas forcément si négatif que cela.

Je vois peu de raisons de garder plus que ces deux domaines (le domaine principal avec le contenu dynamique et le CDN avec les ressources statiques). C’est d’autant plus vrai avec les publicités, qui vous feront utiliser encore un ou deux domaines différents quoi que vous fassiez.

Il ne s’agit pas de revenir sur l’outil, mais de vous signaler une vidéo (en anglais) qui détaille pendant 25 minutes comment utiliser l’outil et ce qu’il propose. Si vous souhaitiez une introduction, la voici. On y parle non seulement de l’outil, mais des connexions TCP, des CDN, etc.

La seconde nouveauté c’est l’arrivé dans l’outil en ligne de nouvelles statistiques pour votre analyse. Tout d’abord une troisième vue, qui vous donne la répartition des téléchargement par type. Êtes-vous bloqués par vos CSS ? vos images ?

Ensuite, et c’est peut être le plus important, c’est une vue graphique du remplissage des différentes files de téléchargements. On y voit très clairement la limitation de nombre de connexions simultanées, quand un contenu bloque toutes les files, ou quand un serveur refuse les connexions persistantes. C’est finalement bien plus utile par certains points que le graphique en cascade. Vous trouverez ça juste en dessous du graphique en cascade.

C’est Jason Grigsby de cloudfour qui vient de donner une présentation « Going fast on the mobile web« . 

Les règles de base et les spécificités

En gros peu de surprises, les règles de base sont celles de Yahoo! et devraient être bien connues dans un contexte de faible bande passante : pas de cookie, minimisation, compression, cache agressif, moins de requêtes HTTP, etc. On voit deux spécificités : la mémoire et le processeur. On a donc quelques contraintes de plus :

• Limiter l’utilisation de la mémoire : Cela veut dire penser aussi à la taille HTML/CSS/JS une fois le code décompressé sans gzip, et penser à la taille des images une fois décompressées en bitmap. Pour l’iphone la limite c’est 25ko par exemple, sinon on ne passe pas dans le cache.
• Limiter l’utilisation du processeur : Cela veut dire entre autres avoir un HTML le plus simple possible, sans erreur à faire corriger par le navigateur, et si possible sans tableaux car ils sont très consommateurs.

Là où par contre je reste dubitatif c’est sur la recommandation d’utiliser json plutot que xml. Comme on l’a vu ce n’est pas si évident et ça doit être plus contestable vu les faibles ressources de ces systèmes. Malheureusement aucune raison ou explication n’est avancée sur la présentation.   

Connexions concurrentes

Pages 37 et 38 de la présentation on a un tableau intéressant à propos des navigateurs mobiles. Ils ont testé le fonctionnement de gzip, du cache, et le nombre de requêtes simultanées.

Pour gzip et le cache, dans l’ensemble le support est bon, même si à chaque fois il y a un ou deux navigateurs courants qui posent problèmes. Le navigateur Blackberry n’est par exemple pas très efficace.

Mis à part Opera Mobile 8.x, ils peuvent quasiment tous télécharger plus de deux fichiers simultanément sur le même domaine .C’est étonnant de voir combien de temps la limite de 2 requêtes par domaine a tenu sur les navigateurs de bureau alors qu’elle a déjà disparue sur les équivalent mobile, là où ça a le plus de sens à cause de la faible bande passante et des faibles ressources système.

Par contre beaucoup sont fortement limités aux nombre de requêtes simultanées tous domaines confondus (IE mobile est limité à 3, Blackberry est limité à 4, etc.). Entre ces limitations sur le nombre de connexions total et le fait que plus de deux connexions par domaine sont déjà autorisées, l’utilisation de plus de deux domaines séparés pour les fichiers est probablement inutile dans la plupart des cas.

Sans limite ?

On ne peut pas non plus tout télécharger en parallèle. Si chaque contenu met une seconde à se télécharger, il est plus intéressant de les voir arriver un à un chaque seconde séquentiellement. En parallèle ils pourraient mettre tous dix secondes et on les verrait tous arriver simultanément à la fin.

Ce serait consommateur de ressources, sur le poste du client et sur le serveur. Nos dix requêtes simultanées prendraient dix processus sur le serveur pendant dix secondes au lieu d’un processus qui traite séquentiellement les requêtes. C’est dix fois plus de mémoire par exemple.

Enfin, le nombre optimum de connexions simultanées dépend de la bande passante disponible. Pas la peine de lancer vingt connexions simultanées. C’est plus de charge sur le serveur, plus de charge sur le client, un peu plus de r&seau utilisé à cause de l’établissement des connexions, mais aucun gain.

Il faut une limite, tout en parallèle n’est intéressant pour personne.

Quelle limite ?

La RFC de HTTP 1.1 nous propose un maximum de deux requêtes persistantes simultanées par serveur. Les navigateurs jusqu’à récemment ont traduit ça en « deux requêtes persistantes simultanées par serveur qui répond en HTTP 1.1″.

• Firefox : 2 connexions simultanées par domaine par défaut, mais Firefox 3 prévoit d’en autoriser 6.
• Internet Explorer : 2 connexions simultanées par domaine, sauf pour Internet Explorer 8 qui planifie d’en autoriser 6 aussi.
• Opera 9 et Safari 3 autorisent chacun 4 connexions simultanées par domaine.

Ces nombres sont augmentés si le serveur refuse les connexions persistantes, s’il répond en HTTP 1.0, ou si on passe par un proxy. Inversement, Microsoft Internet Explorer 8 tente de détecter si vous utilisez une connexion par modem RTC et revient alors à 2 requêtes simultanées par domaine pour ne pas saturer la ligne.

Plusieurs domaines

Jusqu’à récemment le conseil était d’étaler les ressources sur plusieurs domaines, de préférence 2. Cela permet de parallèliser les téléchargements puisque les limites sont « par domaine ». Au delà de 4 domaines l’équipe de performance Yahoo! a remarqué qu’entre une trop grande parallélisation et la multiplication des requêtes DNS, l’effet commençait à devenir négatif.

La question mérite d’être reposée sachant que Firefox et Microsoft Internet Explorer vont tripler le nombre de requêtes. Nous retrouverons par défaut dans le cas « ressources étalées sur 3 domaines » sans rien avoir à faire, et ceux qui utilisaient déjà plusieurs domaines voient leur traffic simultané multiplié d’autant.

La voie d’AOL

AOL a lui choisit une politique particulière mais pas forcément mauvaise : son serveur répond en utilisant le protocole HTTP 1.0. Cela a des implications, comme l’impossibilités d’utiliser des Etags, mais ces derniers posent presque plus de problème qu’ils n’en résolvent.

Le HTTP 1.0 leur suffit. Ils profitent alors automatiquement de plus de connexions simultanées de la part des navigateurs sans avoir à multiplier les domaines et les requêtes DNS. Ils n’auront du coup aucun problème du au changement de configuration par défaut des navigateurs : ils étaient déjà dans une configuration avec beaucoup de requêtes simultanées.

La recommandation

En attendant des mesures de performances plus concrètes prenant en compte les configuration des nouveaux navigateurs, garder la recommandation de l’équipe de performance Yahoo! est probablement le plus sage : étaler vos ressources sur deux domaines différents.

Un seul domaine, même en HTTP 1.0 comme AOL, ne vous permet pas d’utiliser un CDN pour diminuer la latence réseau. Plus de deux domaines risque de surcharger vos utilisateurs avec plus de connexions simultanées qu’il n’est bénéfique.

Le cadeau bonus c’est qu’en séparant les ressources statiques et dynamiques sur deux domaines, vous pouvez avoir une optimisation plus simple des ressources statiques : CDN, pas de cookie (c’est ça de gagné en traffic réseau), et entêtes d’expiration configurées globalement sur tout le domaine ; et une optimisation différente pour les ressources dynamiques : pas de keep-alive et entête imposant la revalidation des contenus pour éviter le cache.