intégrateur ou développeur, stade ultime de la connaissance de la mécanique internet.
à vrai dire, le web n’est que la partie visible de l’iceberg. par « web », on entend généralement un ensemble de quelques éléments.
le protocole HTTP, qui permet d’échanger des données entre un navigateur (firefox, ie, opera, chrome, etc.) et un serveur web (apache, nginx, etc.) un protocole est une convention : si on me dit bonjour, je réponds bonjour. si on me demande le contenu de tel fichier, je le donne.
l’HTML, qui est le langage de balisage utilisé dans cet article, est transmis, via HTTP, du serveur au client. il arrive assez souvent que ce code HTML soit généré par des langages de programmation comme PHP, Python, Perl, etc. par le serveur.
le javascript quant-à-lui est généralement envoyé par le serveur au client. c’est du code qui est exécuté par le navigateur (à l’inverse, le PHP est executé par le serveur) et qui permet de récupérer les actions du clients (click, déplacement souris) et de manipuler le code HTML (qui, est alors utilisé sous forme d’arbre).
cependant, comme dit plus haut, tout ceci n’est qu’une infime partie de « l’Internet ». on parle d’ailleurs souvent des Internets.
plusieurs couches de protocoles s’exécutent les unes-au dessus des autres, selon un modèle défini par l’OSI (7 couches différentes, contenant chacune moults protocoles…) l’HTTP est un protocole dit /applicatif/, c’est-à-dire s’exécutant au niveau le plus haut de ce modèle (7ème couche).
ces couches correspondent en fait au contenu possible d’un « paquet ». un paquet est l’élément de base pour échanger de l’information entre deux machines. il existe tout un tas de conventions pour gérer le transfert de ces paquets : quand un navigateur web envoie un paquet à un serveur web, celui-ci va être « routé », c’est-à-dire transporté d’un routeur à l’autre jusqu’à arriver à sa destination. (un routeur est une machine chargé de prendre un paquet et de le retransmettre. il n’utilise les informations données par HTTP, mais d’autres, situées dans des couches plus basses (1 à 3) pour effectuer ce transfert)
imaginez un instant qu’un routeur recoive trop de paquets, et qu’il ne puisse plus en accepter d’autres ; que se passe-t-il si un client continue de lui en envoyer ?
c’est le genre de questions que se posent les personnes mettant en place et faisant de la recherche dans le domaine des réseaux.
le stade ultime de la connaissance de la mécanique d’Internet dépasse très largement les connaissances requises pour faire du développement web, à la louche et au bas mot d’un facteur 1000
(que les puristes me pardonnent les raccourcis honteux que j’emploie ici)
en espérant avoir réussi à vous éclairé d’avantage sur le fonctionnement intime de nos petites bebêtes éléctroniques !
il est intéressant de mentionner que le web tel qu’on le connaît, repose sur essentiellement sur un protocole (applicatif ; HTTP). ce n ’est cependant que la partie émergée de l’iceberg : d’autres protocoles existent pour mettre en communication deux utilisateurs, comme gopher.
cela permet la création de réseaux atlernatifs au monde du web, bien qu’utilisant la même architecture physique, et tout comme à la surface, s’agglomèrent des utilisateurs autour de sites web, des communautés se créent autour de ces protocoles et des services qu’ils fournissent.
certains d’entre eux (9P) permettent de réaliser des choses amusantes, de façon complétement transparente pour l’utilisateur : utiliser un lecteur audio situé sur une machine, pour lire un fichier situé sur une deuxième machine, et faire sortir le son par une troisième machine. l’utilisateur accède à un ordinateur virtuel, réparti sur plusieurs machines physiques.
à terme, ce genre de communication peut s’avérer utile, par exemple, jouer à un jeu sur un « smartphone », en réalisant les calculs (affichage, etc.) sur une machine distante. donc utiliser des outils portables modèstes, uniquement chargés de demander à des machines communes et puissantes d’effectuer le calcul. les coûts de déploiement sont réduits, l’administration est centralisée, donc simplifiée (les machines à administrer seront principalement les serveurs de calculs), etc.
le « problème », c’est que les données peuvent être stockées sur les serveurs de fessebouquetin, les calculs effectués chez grosgueule et le résultat envoyé à l’utilisateur sur un terminal loué, utilisant le réseau d’orange-seed ou d’apple-worm.
des liens s’il-vous-plaît ! parce que beaucoup de choses sont de notoriété publique de nos jours, et pas des plus jolies
comme César le disait, du pain et des jeux. ce que nos dirigeants semblent avoir oubliés, c’est que Rome est tombée, et que s’evertuer à la reconstruire conduira inévitablement à une semblable débacle.