mai 6th 2011
Le web, un danger pour Internet ?
J’aime bien les titres honteusement racoleurs. Et si j’écris celui-ci, c’est pour faire part d’une réflexion plutôt technique sur les usages du réseau des réseaux.
Tout d’abord, pour ceux qui ne seraient pas totalement au fait de la situation, je préfère clarifier les termes suivants :
- Internet est un réseau. C’est un immense maillage composé de millions de machines (ça englobe aussi bien le serveur au frais dans un datacenter de Google que le vieux PC de madame Michu, en passant par les routeurs de votre opérateur mobile qui vous ment en vous parlant d’Internet sur le réseau 3G). Chacune de ces machines est, du point de vue du réseau, sur le même niveau. Il n’existe aucune hiérarchie technique sur Internet. Par principe, ce réseau est donc neutre (mais sa distribution l’est souvent moins).
À l’intérieur d’Internet, il y a des protocoles. Plein (la couche TCP/IP). Sur 7 niveaux, les plus élevés dépendant des plus bas. Ainsi, l’Ethernet (qui donne son nom aux cables RJ-45 que vous utilisez probablement pour connecter vos machines sur le réseau) est de niveau 2, dit de liaison. Au-dessus, au niveau de transport (le 4), se trouvent les protocoles TCP et UDP (entre autres). Ces protocoles définissent des ports utilisables par les niveaux supérieurs : la norme veut que certains protocoles applicatifs (mettons HTTP) soient historiquement attachés aux mêmes ports. Ainsi, le HTTP emprunte généralement le port 80 TCP. - Le web est grosso modo une application du protocole HTTP(s). Il désigne le transfert par HTTP de sites web, qui sont des ensembles de ressources comprenant essentiellement des pages HTML. Le web est donc une partie d’Internet, mais la réciproque est évidemment fausse.
Maintenant, si on regarde l’évolution d’Internet, on remarque rapidement que le web a pris une importance exponentielle. Il y a 15 ans, il était utilisé pour publier des documents simples. Voilà ce qu’étaient les sites. Aujourd’hui, on publie et visionne des vidéos, on discute avec ses amis, on lit ses mails, on fait ses courses… Les usages n’ont plus rien à voir. Finalement, le web est devenu une sorte de plateforme de déploiement rapide d’applications.
Cependant, j’en viens à me demander si c’est une bonne chose. En informatique (comme en science, en général), les choses aiment bien être à leur place. Et, finalement, ce détournement de l’idée initiale de HTTP est un hack de très grande ampleur. Cependant, faut-il rester sur cet état ? Ne faut-il pas, dans un souci d’optimisation des protocoles, dédier chaque tâche à ce qui est réellement pensé pour elle ? Je pense notamment aux mails. Le mail, ce sont les protocoles POP, IMAP et SMTP (ainsi que leurs variantes encapsulées dans SSL/TLS). Mais un webmail (une page web permettant de consulter ses mails dans un navigateur), c’est du HTTP(s). Là où, lorsqu’on utilise un client logiciel, l’utilisateur utilise directement les protocoles adaptés à son besoin, il va rajouter une couche de HTTP pour joindre son webmail, qui joue le rôle de passerelle. Ainsi, la communication avec le serveur mail est abstraite, et on rajoute un niveau de lourdeur aux requêtes.
Le protocole IP est conçu pour que les paquets puissent emprunter le plus court chemin entre deux hôtes. Je suis convaincu que le même raisonnement devrait être appliqué à ce genre d’applications. Les utilisateurs de webmails justifient souvent leur choix (lorsqu’il est volontaire) par le besoin de pouvoir lire leurs mails en déplacement. Or, le protocole IMAP permet parfaitement de gérer cet usage. Même le POP permet de garder les messages sur le serveur. Et la nature ouverte des protocoles permet d’utiliser l’application cliente de son choix, voire d’en utiliser plusieurs (par exemple, selon l’endroit d’où on se connecte). Ainsi, je ne vois pas ce qui pourrait justifier l’usage d’un webmail face à une application native, d’un point de vue d’utilisateur. On peut arguer que le premier consomme bien moins de ressources, mais personnellement, quand je vois la consommation mémoire de mon navigateur (Firefox), je ne suis pas vraiment d’accord. Le fait est qu’utiliser un webmail rajoute un transport, une couche qui, comme tout logiciel ou protocole, peut avoir des faiblesses. Et, plus on complexifie la communication, plus elle faiblit (en termes de sécurité et performance).
J’ai pris l’exemple du mail, mais ça vaut pour une majorité d’usages qui sont fait du web aujourd’hui : les forums de discussions, les agrégateurs de RSS… Ces usages bénéficient d’un protocole (voire, pour le RSS, d’un simple format). Mais le commerce électronique ? Le microblogging ? Ce sont des applications qui n’existent que sous forme de sites web. Je pense que ces usages mériteraient d’avoir des protocoles propres, et évidemment ouverts, pour optimiser l’usage du réseau.
Prenons l’exemple du e-commerce. Celui-ci obéit à des normes invisibles, qui indiquent par exemple qu’une boutique dispose généralement de liste de produits, de panier d’achat, de procédure de commande. Pourquoi ne pas plancher sur un protocole spécialement pensé pour ça ? Ainsi, une boutique en ligne ne serait plus nécessairement un site web, mais pourrait être une application, et même plus : un utilisateur pourrait utiliser son propre logiciel pour interagir avec les boutiques de son choix, comme on le fait aujourd’hui avec un client mail et n’importe quel fournisseur.
Je pense que cet exemple peut s’appliquer à énormément d’usages actuels du web. Et je pense que le réseau ne s’en porterait que mieux : un protocole direct de e-commerce, ça serait l’assurance de l’interopérabilité, du fonctionnement, de l’optimisation… Par exemple, la plupart des interfaces de paiement en ligne fournies par les banques indiquent, dans leur page d’attente de la validation du paiement « ne retournez pas en arrière, ne rechargez pas cette page ». Pour moi, c’est juste un patch très sale pour dire à l’utilisateur « le protocole que vous utilisez actuellement n’est pas très adapté pour ce qu’on est en train d’en faire ». Dans ce cas, une logique froide voudrait qu’on développe un protocole pour ça, qui n’aurait pas à s’embarrasser d’avertissements de ce genre…
Alors, bien évidemment, la conception, la validation, l’adoption à grande échelle et l’implémentation d’un nouveau protocole est une tâche extrêmement ardue. Mais je ne pense pas qu’il soit sain pour l’avenir de se contenter d’une solution de facilité, qui fonctionne, certes, mais dont la logique n’est pas parfaite.