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.

Apple lui même met clairement en avant les performances de la navigation iPhone, au point de tricher dans ses publicités en montrant un scénario de navigation accéléré par rapport aux situations réelles (la publicité a d’ailleurs été interdite au Royaume Uni à cause de cela).

Reste que la bataille des performances n’est pas gagnée.

Encore il y a peu nous parlions d’un cache HTTP limité à 25ko par composant sur l’iPhone, 500ko au total. On parle de la taille une fois la ressource décompressée (sans gzip donc). 25ko c’est peu, la plupart des sites ont un composant qui dépasse cette taille. 500ko ce n’est pas beaucoup mieux, naviguez sur un ou deux sites et le cache aura complètement oublié vos précédentes visites. Pire, des bibliothèques javascript comme jquery dépassent les 25ko et donc ne passeront jamais dans le cache.

Moins de restriction par composant

La bonne nouvelle c’est que cette limite est désormais dépassée. Une présentation de Nicole Sullivan indique que la limite des 25ko a disparue, et que la taille globale du cache a été doublée.

Malheureusement je n’ai trouvé aucune autre source d’information, donc avec Anthony Ricaud nous avons lancé un petit test. Le résultat c’est que l’iPhone 3G (firmware 2.1) met bien en cache les images de plus de 25ko. Je n’ai pas tenté de trouver la limite, mais une image de 180ko part dans le cache correctement.

Mais un racisme anti-HTML

La mauvaise nouvelle c’est que dans nos tests Safari iPhone ne met jamais en cache la page HTML principale. Nous avons tenté des entêtes d’expiration explicites, des pages de 3ko. Rien n’y fait. la page elle-même est à chaque fois retéléchargée par l’iPhone alors que sur mon Safari Mac classique, lui, se sert bien du cache.

C’est un moindre mal, mais c’est une limitation assez peu compréhensible. Si quelqu’un me trompe une raison légitime de castrer le cache ainsi seulement sur le mobile, je suis preneur.

À vous pour la suite

Le cache de l’iPhone est définitivement différent de celui d’un Safari classique. Je n’ai malheureusement pas d’iPhone pour tester* donc à ceux que ça intéresse, je suis preneur des résultats suivants (pour la v1 et la version 3G) :

• quelles sont les nouvelles limites par composant ?
• quelle est la nouvelle limite globale ?
• ces limites sont-elles les même wifi et en 3G ?
• le HTML principal est-il mis en cache lors d’une connexion wifi ?
• nous avons testé avec une image, est-ce la même chose avec une feuille de style ou un javascript ?

Le protocole de test est assez simple, je vous met ici en copie une petite archive des fichiers PHP que j’ai utilisé pour mon test avec Anthony.

Bref, à vous de tester, et de commenter ici avec vos résultats (n’oubliez pas de faire un lien vers votre protocole de test et de donner la version exacte de votre iPhone, sans ça les résultats sont moins utiles).

(* Ceci est un message subliminal à celui qui veut financer mes recherches sur le sujet)

Par contre je me retrouve pile dans l’usage où la performance est nécessaire, indispensable. Au milieu du CEBIT, une borne wifi est ouverte. J’en profite pour tenter d’accéder aux sites d’information français pour me tenir au courant de l’actualité (non, je ne parle pas le turque). Sauf que cette borne il y a trop de monde dessus, je la reçois mal, et pour ne rien gacher la latence entre la Turquie et la France plombe tous les échanges.

Voilà un cas concret, réel, et vivant du problème. Je suis certain que le professionnel à l’étranger pour son travail représente une partie de la cible des sites comme de Le Monde ou du Figaro. Sauf que sérieusement, je suis incapable d’aller voir ce qu’il se passe là bas. J’ai abandonné le chargement des deux pages d’accueil avant d’en lire le contenu. J’aurai pu attendre mais joindre les pages d’article ainsi aurait été au dessus de mes forces.

À l’inverse mon Google Reader fonctionne parfaitement, alors que le contenu lui même est autrement plus important en volume. J’ai même pu taper ce présent billet. C’est donc bien que ce n’est pas que la faute de ma connexion, mais aussi et surtout des sites web eux même.

Des sites plus optimisés, sans tout l’inutile, m’auraient vraiment aidé. J’aurai même pu payer des PDF pour les lire dans l’avion (je ne sais pas si ça se vend ceci dit, vu que je n’ai pas pu charger la page d’accueil). Bref, des ventes en moins pour eux.

Finalement je suis aller sur leurs sites mobile, ceux pour téléphone portable même si je les visite avec un micro-ordinateur des plus classiques. Là j’ai du contenu, optimisé, et tout est instantané. Pourquoi ne pas faire pareil ? pourquoi ne pas au moins mettre en haut de la page d’accueil, un lien « connexion lente ? allez sur le site mobile ! ». C’est mon esprit geek qui a pris le dessus mais d’autres ne le feront pas. D’ailleurs, tiens, gmail me propose une version optimisé quand le chargement est lent, lui. Il y a encore des progrès à faire sur les sites français, là c’est inutilisable.

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.