Comment démarre un ordinateur

Comment démarre un ordinateur ? Ben tiens, j'appuie sur son interrupteur, pis j'ai Windows qui apparaît, c'est pas compliqué non ?

Bon, on peut effectivement se satisfaire de ce niveau de compréhension. Cependant, le jour où on voudra faire des choses un peu plus avancées avec sa machine, comme se débattre avec un système multi-boot récalcitrant, ou un "secure" boot trop restrictif, il pourra s'avérer utile d'avoir quelques notions.

En outre, vu la période actuelle où on est encore à cheval sur deux périodes (BIOS vs UEFI), les explications trouvées ici et là sur Internet peuvent être confuses, dépassées ou inadaptées à votre configuration . Il faudra alors plonger dans la documentation technique (la vraie, pas un article de blog), et là bon courage, c'est quand même assez hardcore pour le commun des mortels, et même pour la plupart des informaticiens "modernes" (c'est à dire assez ignorants du fonctionnement de leur outil de travail).

So, je me suis attelé à la tâche, et je vais essayer de résumer les choses dans les grandes lignes, histoire de fournir un premier niveau de compréhension pour faciliter une étude plus poussée...

Alors, un pré-requis absolu, sauf pour les purs et durs (mais que feraient ils ici ?) :
Le B-A BA de la gestion des disques

Et si vous êtes un curieux qui n'a pas froid aux yeux qui tente juste le coup, sans grande connaissance préalable en informatique, je vous conseille fortement aussi celui là :
Le B-A de l'assemblage (hardware). J'y explique les notions de base sur le matériel et le logiciel système (OS, Bios/Uefi)

C'est parti mon kiki.

Explication de la problématique

Alors, un ordinateur c'est grosso-modo un processeur qui exécute des suites d'instructions en langage machine (le seul qu'il comprend donc).

Cependant quand on l'allume l'ordinateur, ben il faut encore lui donner à manger au processeur, à savoir charger en mémoire les instructions qu'il est censé exécuter, puis le prendre par la  main et l'emmener sur la première instruction de la (longue) liste, puis lui donner une petite poussée dans le dos. Après c'est bon, il va dérouler les instructions les unes derrière les autres (exécuter le programme quoi), et normalement vous allez avoir votre écran d'accueil Windows au bout d'un certain temps, voire d'un temps certain.

Et ces instructions, ben faut bien aller les chercher sur un support physique où elles sont mémorisées, en l’occurrence un disque dur (ou SSD on s'en fout, même une clé USB ou un DVD si vous voulez).

Hé ben tout ça, ça ne se fait pas tout seul par magie, ça résulte de l'exécution d'un programme. Or, le programme habilité à lancer des programmes c'est le système d'exploitation. Or, il n'est pas lancé le système d'exploitation quand on démarre l'ordinateur. On est donc face à un niéme problème du type "qui de la poule et l'oeuf..." (courant en informatique).

Et là tout de suite ça devient plus drôle. Enfin façon de parler, car on est obligé de se pencher un peu dans les entrailles de la bête et ça devient vite pénible quand on ne calcule pas de tête en hexadécimal, qu'on ne programme pas en assembleur depuis ses 8 ans, et qu'on n'a pas de formation en électronique. Mais on peut y arriver, je suis là pour vous aider.

Alors déjà, il faut savoir que le processus de démarrage, à partir de maintenant on dira boot car c'est moins long à écrire, diffère sensiblement selon le type de votre carte mère : une carte mère avec un firmware conforme à la norme BIOS et une carte mère conforme à la nouvelle norme UEFI ne bootent pas de la même façon.

update 11/2016 > 
Petite précision utile. Les PC modernes sont tous équipés de firmware UEFI, il y a déjà pas mal d'années qu'on ne trouve plus de machines équipées de firmware BIOS. Pour autant, connaître la distinction entre le fonctionnement de BIOS et d'UEFI reste importante car un firmware UEFI est susceptible de booter dans deux modes : le mode standard (UEFI way) qui permet de booter depuis un disque de plus de 2.2 To et d'activer le secure boot, ou le mode BIOS (appelé selon les cartes et les documentations : legacy, hérité, CSM). La façon dont le mode est déterminé est spécifique à chaque modèle de carte mère donc je ne peux guère en parler, et ce d'autant que c'est généralement assez opaque. Il est généralement possible de forcer le mode de démarrage via l'appui sur une touche ou une option dans le setup du firmware (ce qui est indispensable pour permettre par exemple de démarrer un installeur Windows en mode UEFI afin qu'il puisse installer l'OS sur un disque partitionné en GPT)

La séquence de Boot

Quand l'ordinateur démarre, il exécute automatiquement le programme inscrit dans la ROM de la carte mère (le firmware). C'est tout simplement inscrit dans le marbre, par fabrication.

Alors, je ne le répéterais pas à chaque fois, pour exécuter un programme, il faut le charger dans la mémoire, puis dire au processeur d'exécuter les instructions qui démarrent à l'adresse mémoire de la première instruction. Il va l'exécuter et toutes celles qui suivent jusqu'à ce qu'il n'y ait plus rien. Et si la dernière instruction c'est "retourne à la première instruction", le programme tournera éternellement, du moins tant qu'on ne coupera pas le courant.

Notre premier programme est stocké dans la ROM et est donc limité en taille et en fonctionnalités pour des raisons techniques sur lesquelles je ne m'étendrais pas.

Alors ce programme, il va faire tout ce qu'il peut mais le pauvre est limité : il va savoir gérer à peu près correctement les disques de façon pas optimale, mais bon ça suffira pour le moment, il saura afficher des caractères à l'écran, pas de façon sexy mais bon ce sera lisible, il sera même capable de reconnaître le clavier et la souris (si si, la souris), même quand ils sont branchés en USB (si votre système est pas trop ancien) et quelques autre trucs de base.

Avec tout ça, il va déjà faire l'essentiel, à savoir initialiser l'ensemble du matériel, compter ses petits, vérifier que la mémoire fonctionne bien etc... C'est la phase de POST (Power On Self Test, auto test automatique au démarrage dans la langue de Molière).

Puis une fois l'ordinateur prêt (tout le monde est réveillé, prêt à travailler, rien n'est tombé en panne depuis le dernier boot), on va devoir passer aux choses sérieuses et là le malheureux firmware il va arriver à ses limites le pauvre. 

C'est pas lui qui va vous afficher des jolies fenêtres avec des effets de transparence, jouer des clips vidéo et vous permettre de faire un partie de Candy Crush. Pour tout ça, il faut un programme beaucoup plus sophistiqué, écrit dans un langage évolué, et qui est bien trop gros pour tenir dans la ROM, un système d'exploitation quoi !

Donc notre firmware va rendre la main. Sa dernière activité va consister à charger en mémoire, non pas le système d'exploitation directement, mais un programme chargé de charger le système d'exploitation (le bootloader). Après c'est fini pour lui. 

Alors vous devez vous dire, ils sont bien tarés ces informaticiens : pourquoi charger un programme qui va charger l'OS et pas directement charger l'OS ? Hé bien tout simplement car il existe différents OS et qu'ils se chargent tous différemment. Du coup, comme on veut pouvoir utiliser l'ordinateur avec différents OS, il nous faut un programme intermédiaire ; comme ça, il nous suffira de mettre celui qui va bien par rapport à l'OS qu'on veut utiliser. Alors, vous allez me rétorquer, pourquoi ne pas modifier directement le premier programme, le firmware ? Ben la réponse c'est que c'est pas possible et vous vous en contenterez (bon ok, il est spécifique au matériel, il faudrait autant de versions de programme que de systèmes multiplié par le nombre de cartes mères différentes).

La suite vous la connaissez.

Vous avez votre interface utilisateur (les fenêtres sous Windows, la ligne de commande sous d'autres systèmes), et ça vous permet de dire à l'ordinateur ce que vous voulez qu'il fasse. Et pour vous satisfaire, il chargera des programmes en mémoire et les fera exécuter par le processeur, plus pleins de truc qu'il fait sans que vous en ayez conscience (transmettre votre code de carte bleue à un réseau de pirates russes, se faire passer pour vous et pénétrer le réseau du Pentagone, télécharger des images pédophiles pour vous faire envoyer en prison avec des co-détenus très sympas etc.).

Alors BIOS et UEFI font la même chose, mais il le font de façon un peu différente. 

Le bootloader appelé par le BIOS est écrit en langage assembleur (donc directement en langage machine pour faire simple) ; autant dire que c'est pas un poème car écrire en assembleur est quelque chose de très difficile. Cependant ça a un énorme avantage (plusieurs en fait) : c'est très rapide car parfaitement optimisé pour le processeur, et encore mieux ça fait des programmes tout petits (et ça tombe bien car on a toujours un problème de place). 

Le bootloader appelé par UEFI lui est écrit en langage C, un langage évolué beaucoup plus simple (tout est relatif) et du coup il sait faire plus de choses, et comme il permet de faire plus de choses, on lui en fait faire plus (et il n'a pas les mêmes contraintes de taille).

En prime, comme UEFI est plus récent il sait dépasser les capacités du BIOS qui a été conçu il y a 30 ans, pour les matériels d'il y a 30 ans (tiens au hasard, pour des disques durs de capacité beaucoup moins importante). Mais ça vous le savez déjà si vous avez lu l'article sur la gestion des disques.

Vous avez peut être remarqué que l'écran de configuration du firmware que vous pouvez appeler au démarrage de l'ordinateur en appuyant sur une touche (suppr souvent, ou F2 ou autre encore), il est beaucoup plus sexy avec une carte mère UEFI qu'avec une carte mère BIOS ? Ben c'est grâce au langage de programmation C supporté par UEFI qui permet de faire ça sans lancer un chantier de 3 ans avec 50 programmeurs.

the BIOS way of life

C'est la partie la plus simple, ça existe depuis 30 ans, on trouve pleins d'explications sur Internet. Je vais donc faire rapide. Et en plus, ça va être de moins en moins utile.

Petit avertissement ; j'ai en partie rétro-conçu l'algorithme à partir de diverses sources et par intuition, il doit y avoir des variantes et des subtilités, mais pour autant je pense être dans le vrai.

Bon alors c'est pas compliqué, du moins dans l'esprit, et si on se garde de trop plonger dans les détails.

Sur chaque disque de la machine, les 512 premiers octets sont réservés. On appelle cette zone le MBR (Master Boot Record). Dans cette zone, on trouve principalement deux choses : la table de partitions bien mal dénommée MBR également, et un tout petit programme qui dispose de quelques centaines d'octets seulement. Ce programme c'est le bootloader, c'est lui qui sera chargé de charger le système d'exploitation.

Pour charger le système (c'est à dire le lire sur le disque et l'écrire en mémoire, en informatique on en revient toujours aux entrées-sorties), il faut déjà déterminer où il se cache. Ben oui, potentiellement l'ordinateur a plusieurs disques, et chaque disque peut avoir plusieurs partitions. Et le système, il est quelque part là dedans, mais où ? Comme en plus, le système ça peut être n'importe quoi (le premier qui dit que Windows c'est n'importe quoi prend la porte), il ne peut même pas essayer d'en détecter la présence en reconnaissant sa tête.

Rappelez vous que dans l'écran de configuration du BIOS/UEFI, on peut dire quels sont les disques à partir desquels on peut booter, et quel est l'ordre de préférence.

Le firmware, a lu cette information. Il va donc commencer par le premier disque, il va regarder si les 512 premiers octet de ce disque constituent un MBR valide (il contrôle la présence d'une valeur particulière résultant d'une convention par défaut dans le 511 et 512 éme octets, la "boot signature" dans notre schéma). Si tel est le cas, il lit la table des partitions. Si une des partitions est flaguée "bootable", bingo il sait qu'il va y trouver un système d'exploitation. Dans ce cas, il charge en mémoire le bootloader (le programme stocké dans la MBR, le "bootstrap code" dans notre schéma) puis il lui passe la main. Le bootloader s'exécute, il charge en mémoire le système d'exploitation depuis la partition qui lui a été communiquée par le firmware, et roule ma poule.

Si le premier disque n'a pas de MBR, ou pas de partition bootable, le firmware va tenter le coup avec le second disque dont on a indiqué dans la configuration qu'il pouvait servir à démarrer, etc. Si à la fin il ne trouve rien, il affiche un message d'erreur et l'ordinateur est inutilisable.

Déjà ici vous devez comprendre pourquoi vous devez contrôler ou changer l'ordre du boot dans le BIOS/UEFI quand vous voulez démarrer depuis un DVD (pour installer un nouvel OS le plus souvent) ; il faut que le lecteur de DVD soit en premier avant le disque qui a votre système déjà installé, sinon vous démarrerez toujours depuis votre disque dur et jamais de votre DVD.

Alors quelques déductions. Le bootloader est nécessairement spécifique au système d'exploitation chargé (sinon il ne saurait pas quoi charger). Windows à le sien, Linux à le sien etc. Chaque système vient avec ses outils pour inscrire son bootloader dans le MBR et peut potentiellement écraser celui de son petit copain si on ne fait pas attention. Pour Windows, ça dépend des versions mais avec une version moderne c'est NTLDR (NT Loader, NT étant un ancien nom des Windows actuels), pour Linux il en existe plusieurs, LILO et GRUB semblent être les plus utilisés.

Multi-boot : si vous avez plusieurs systèmes d'exploitation installés sur plusieurs partitions, vous avez sans doute envie de pouvoir choisir sur lequel démarrer. Si ce sont tous des Windows, NTLDR fera l'affaire, par contre si vous mixez Windows et Linux, il faudra utiliser GRUB ou LILO (GRUB semble plus utilisé de nos jours), ou encore un autre. Tous ces outils requièrent un peu de configuration.

the UEFI way of life

Le fonctionnement est similaire mais diffère de façon significative sur plusieurs aspects. 

J'ai eu beaucoup de difficulté à trouver des informations sur ces sujets, si certains points sont clairement établis (ESP, GPT), d'autres sont plus sujets à caution (mais ce n'est guère important). Ma principale référence pour les curieux est celle ci.

Déjà, dans un système UEFI, il y a une partition cachée (vous ne la voyez pas, sauf à utiliser des outils d'administration) qu'on appelle ESP (EFI System Partition). 

Cette partition permet de stocker les programmes qui seront appelés par le firmware à l'issue du POST. Du coup, on n'a plus la contrainte du MBR qui ne laissait que quelques centaines d'octets au bootlader dans le BIOS. Du coup, on peut écrire les programmes avec un langage évolué comme le C car on n'a plus la même contrainte de taille (un programme écrit en langage évolué comme le C sera toujours beaucoup plus gros qu'un programme directement écrit en assembleur). Et aussi, on peut faire des programmes plus évolués et plus riches fonctionnellement (pour le bootloader qui ne fait pas grand chose c'est pas très important, par contre pour l'outil de configuration du UEFI c'est sympa).

Cette partition est référencée, comme toutes les partitions, dans la table des partitions. Et ce n'est pas un problème car contrairement au BIOS avec son MBR qui nous limitait à 4 partitions maximum (et de 2.2 To Max, je sais je suis lourd), UEFI s'appuie sur une table GPT plus évoluée (128 partitions possibles, ça devrait aller).

Ensuite, le firmware ne se base pas sur la lecture du premier secteur des disques (les premiers 512 octet) pour détecter la présence de partitions contenant un système bootable. A la place, il se base sur une série de variables dont il obtient la valorisation en lisant la ROM. Certaines de ces variables lui indiquent la présence de programmes stockés dans l'ESP et qui ont la capacité à charger un système d'exploitation (bootloader), ou un programme qui se chargera à son tour de charger un système (donnant éventuellement la possibilité de choisir parmi plusieurs).

Ces variables sont normalement valorisées à l'installation des systèmes d'exploitation. Quand un OS s'installe, il est censé faire le job (copier son bootloader dans l'ESP dans un certain répertoire et avec un certain nom, et mettre à jour la variables d'environnement dans la mémoire permanente où elle est stockée). A priori, il semblerait qu'il y ait encore pas mal de soucis, en particulier pour faire cohabiter un système Windows et Linux sur la même machine (mais on peut le faire, chez moi je fait cohabiter un Windows 10 et un Linux Mint, mais bon j'ai eu quelques frayeurs et j'ai du bidouiller en serrant les fesses). Bref, il est bon de savoir qu'il y a parfois des problèmes de jeunesse potentiellement très délicats à résoudre (voire impossible parfois). 

La gestion du multi-boot est censée pouvoir être assurée directement par le firmware via un menu qu'il gère directement mais ceci est variable selon les contructeurs (par exemple, la carte mère UEFI de mon PC, une ASUS P8Z77-V LX2, ne le permet pas). Ce n'est pas gênant car il existe des bootloader qui gèrent très bien cette problématique.

secure boot : le secure boot, ou boot "sécurisé" a fait couler beaucoup d'encre. C'est une nouvelle fonctionnalité apporté par UEFI. Sans entrer dans le détail de mise en oeuvre des techniques de cryptographie (je prévois des articles là-dessus), il permet de vérifier qu'un programme chargé par le firmware (un bootloader) n'a pas été modifié de façon malicieuse par un virus. En effet, les virus intervenant au niveau du bootloading sont particulièrement pernicieux : ils sont chargés avant le système d'exploitation et sont donc totalement indétectables et ont toute liberté d'action.


Le souci est que cette vérification s'appuie sur une empreinte numérique et que cette technique implique que le bootloader chargée par le firmware ait été signé numériquement, et que le certificat du tiers de confiance ayant réalisé cette prestation soit installé sur la machine ; et ceci pose des soucis pour les os open source, à tel point que Microsoft (à l'origine de la spécification UEFI) a été publiquement accusé de mettre en place une technique visant à empêcher les consommateurs de mettre en place un système alternatif à Windows sur les machine vendues pré-équipées en Windows (depuis la version 8), ce qui serait effectivement gravissime. Ceci dis, les choses semblent être en voie de résolution à cette date. En tout état de cause, la spécification UEFI précise que le secure boot doit pouvoir être désactivé (via le programme de setup UEFI).

Conclusion

Bon finalement, c'était pas si compliqué ? Heu si un peu quand même.

Bon, l'idée ici était de donner un premier niveau de compréhension générale afin de pouvoir  lire des ressources techniques plus détaillées en ayant une chance raisonnable d'y comprendre quelque chose. J'espère être arrivé à cet objectif.

Le B-A BA de la gestion des disques

Alors, cet article de vulgarisation aborde des sujets largement abordés sur Internet. Néanmoins, j'ai trouvé que les articles disponibles étaient soient beaucoup trop techniques, entrant dans des détails rebutants, soit beaucoup trop légers et sources de confusion.

Comme j'ai besoin que ces concepts soient bien compris en pré-requis d'autres articles, j'ai choisi de faire une n-iéme explication, à ma sauce, et toujours en essayant d'être le plus clair possible pour les néophytes.

En pré-requis, il faut maîtriser quelques notions de base sur ce que sont un ordinateur et un système d'exploitation. Bien que l'article en question soit bien plus large dans son objet, vous pouvez utilement lire cet article : Le B-A BA de l'assemblage (hardware)

Disque, Partition, Formatage, Système de fichier

Disque physique et disque logique

Un ordinateur est équipé de un ou plusieurs disques : un  ou plusieurs disques sont installés dans le boitier et connectés sur la carte mère (et au bloc d'alimentation électrique).  Un disque est découpé en un certain nombre de secteurs de taille fixe (512 Octets généralement).

Un disque pour être utilisable doit subir une opération appelée partitionnement ; cette opération consiste à organiser l'espace disponible sur le disque en une ou plusieurs partitions. Une partition s'étend sur un certain nombre de secteurs (plus il y a de secteurs, plus la partition est grande).

Chaque partition sera vue par le système d'exploitation comme un disque distinct, comme si chaque partition était un disque distinct. Pour cette raison on appelle souvent les partitions des disques (ou unités) logiques (par opposition au disque ou unité physique).

Pourquoi partitionner ? Pour de multiples raisons d'ordre pratique. Déjà, il faut séparer le système d'exploitation et les données pour la performance et surtout la maintenance du système (on peut ainsi réinstaller le système en cas de problème, sans toucher aux données). Ensuite, on peut avoir des partitions  de données dédiées à des usages distincts : une pour les vidéos, une pour les fichiers sérieux par exemple, ainsi on pourra sauvegarder de façon distincte l'une et l'autre. Enfin, pour des usages plus avancés comme la mise en oeuvre de systèmes RAID ou de file system distincts selon l'utilisation de la partition (file system expliqué plus loin).

Sous Windows, une lettre est affectée à chaque partition : A et B sont réservés pour des lecteurs de disquettes et ne sont plus utilisés de nos jours (car plus personne n'utilise de tels périphériques totalement dépassés et sans intérêt depuis qu'il existe des clés USB), la première partition reçoit la lettre C, la seconde la lettre D etc... Certaines partitions spéciales n'ont pas de lettre attribuée et sont donc inutilisables pour l'utilisateur (usage spécial pour le démarrage et parfois pour conserver une copie de secours du système permettant de restaurer une machine endommagée).

On voit ici que le vocabulaire utilisé couramment est source de confusion car on parle sous Windows de disque C, disque D, disque E etc. alors qu'il s'agit en fait de partitions. Nous utiliserons dans cet article le bon vocabulaire ; disque pour un disque physique, partition pour un disque logique.

Sous Unix ou Linux, le fonctionnement est différent, l'utilisateur ne voit pas les partitions. Chaque partition est en fait associée à un répertoire (on parle de point de montage) et quand l'utilisateur se déplace dans ce répertoire, il change de partition sans s'en rendre compte. C'est totalement invisible, seul l'administrateur de la machine est au fait du partitionnement.

Formatage, Système de fichier (fs)

Chaque partition dispose de ce qu'on appelle un système de fichier, ou file système, FS en abrégé. Pour faire simple, c'est le système de rangement des fichiers dans la partition. Il en existe différents selon le système d'exploitation utilisé, l'usage qui est fait de le partition, et l'ancienneté de la technologie. Sous Windows, on a eu successivement FAT et FAT32, aujourd'hui la norme est NTFS. Sous Linux/Unix, on a ext3, ext4, swap etc...

Le choix du système de fichier utilisé sur une partition est effectué au moment du formatage de la partition (et non du disque comme on entend tout le temps). Le formatage est une opération qui prépare la partition pour son utilisation et elle est obligatoire pour pouvoir l'utiliser.

Pourquoi autant de fs distincts ? Les fs les plus anciens géraient leur index, c'est à dire la liste de vos fichiers et répertoires (un numéro étant associé à chacun) avec des entrées de petite taille qui étaient largement suffisantes à l'époque où un disque dur de 10 Mo (oui, oui vous avez bien lu 10 Mo) faisait l'admiration des foules et dont l'achat nécessitait un emprunt à la Banque de France. Aujourd'hui, on trouve couramment de disques de 4 To pour des prix très raisonnables. Du coup, l'index de ces fs était incapable de les gérer, et il a fallu à plusieurs reprises créer de nouveaux fs pour pouvoir s'adapter à l'évolution du matériel. En outre, les fs modernes ont des caractéristiques plus évoluées et bénéficient des progrès des technologies ces 30 dernières années.

Pourquoi vous ne savez pas tout ça ? Aujourd'hui les disques sont vendus avec une partition unique déjà créée et déjà formatée en NTFS, car c'est l'usage principal qui en est fait par le grand public (sous Windows donc). Ceci ne convient pas à tous les usages, en particulier pour utiliser le disque sous Linux, ou dans le cas où on assemble un PC et qu'on veut découper le disque en partitions suivant selon les bonnes pratiques (séparation système et données etc.).

Table de partition, MBR,GPT

Par défaut un programme (je dirais uniquement les programmes de très bas niveau : bootloader et os, le bootloader étant un programme chargé de charger l'os au démarrage de l'ordinateur) n'a aucun moyen de savoir de quelle façon un disque a été découpé en partitions. Il faut lui fournir cette information d'une façon normalisée afin qu'il puisse en prendre connaissance.

Cette information c'est ce qu'on appelle la table de partition. C'est simplement un fichier présent sur chaque disque et qui liste les partitions avec quelques informations ; où elles commencent sur le disque (à quelle adresse de secteur), quelle est leur longueur, quel est leur système de fichier, et quelques indications complémentaires (on parle de flags ou drapeaux). En particulier, on a un flag "bootable" qui indique si la partition sert à stocker les fichiers du système d'exploitation (cette information sera nécessaire à l'allumage du PC).

Où ça devient amusant, façon de parler, c'est qu'il existe deux type de tables de partitions (en fait bien plus mais je me limite à ceux utilisés sur les ordinateurs compatible PC). 

Le plus ancien s'appelle MBR (Master Boot Record, le nom est très mal choisi et source de confusion) et est utilisé depuis l'origine des PC ; il a un certain nombre de limites qui ont fini par devenir trop gênantes, raison pour laquelle il n'est plus utilisé sur les ordinateurs récents. Il a été remplacé par GPT (Global Unique IDentifier Partition Table), mais ce changement est encore récent et comme l'ancien a existé pendant plus de 30 ans on en trouve encore des traces partout.

Les principales limites de MBR étaient qu'on ne pouvait avoir que 4 partitions ; cependant, pour dépasser cette limite, il avait été inventé le concept tordu de partition primaire et de partition étendue : en déclarant une des 4 partitions comme "étendue", on pouvait à son tour la découper en n partitions, au prix de quelques gymnastiques. Mais surtout, MBR ne pouvait pas gérer des partitions d'une taille supérieure à 2.2 To (car la zone dans laquelle il rangeait ses informations était trop petite, même punition que pour les anciens fs).

Les lecteurs assidus de de blog feront peut être le lien avec la limitation de taille maximale de disque à 2.2 To levée par l'adoption de la norme UEFI en lieu et place du bon vieux BIOS. En fait, la norme GPT a été élaborée seule dans un premier temps puis a été incorporée dans la norme UEFI, ceci explique donc cela.

Et là, je ne suis pas totalement sur de moi, mais j'aurais très fortement tendance à penser que l'utilisation de MBR ou de GPT dépend du fait que votre carte mère est équipée d'un BIOS (vieille techno, il utilisera MBR), ou d'un UEFI (techno moderne, il utilisera par défaut GPT, sachant qu'il offre la possibilité de fonctionner en MBR par un mode de compatibilité appelé CSM - Module de support de la compatibilité -).  Je suppose que le mode de compatibilité permet de brancher sur une carte mère moderne (UEFI) des disques déjà partitionnés en MBR pour diverses raisons (réutilisation de disques d'une ancienne machine par exemple, pouvoir les partitionner en MBR car c'est un pré-requis pour le système d'exploitation qu'on veut installer sur la machine car il ne sait pas lire GPT).

En fait, c'est le firmware embarqué dans le BIOS/UEFI qui doit être capable de lire la table de partition afin de pouvoir initialiser le chargement du système d'exploitation à l'allumage de la machine (je prévois un article dédié sur le sujet, c'est très amusant à comprendre, mais très bas niveau et donc assez complexe). Ca semble assez logique car le code à charger en mémoire (pour que le processeur puisse l'exécuter) est stocké sur un disque et que pour pouvoir accéder au disque, il faut en connaitre les partitions et donc pouvoir lire la table des partitions (CQFD).

Les informations de la table de partition sont lues également par le système d'exploitation. Il doit donc savoir lire le format MBR ou GPT. Or, GPT est plus récent. De ce fait, il ne sera pas possible d'installer un système trop ancien (genre Windows XP sauf erreur de ma part) sur un disque partitionné selon la norme GPT. L'inverse ne posera pas de problème car les systèmes modernes savent fonctionner aussi bien avec une table MBR que GPT (selon le grand principe de compatibilité ascendante qui veut que les nouvelles versions restent compatibles avec les vieux trucs, du moins le plus longtemps possible, ce qui nous complique bien la tâche).

Voilou, c'est une explication un peu lapidaire mais l'essentiel est là je pense.

Pour l'explication de ce qui se passe au démarrage d'un PC, voir ici :
Comment démarre un ordinateur

Quelques compléments 

Si cette petite introduction vous a donné faim, voici un très bon article en Anglais un peu plus détaillé sur l'utilisation des partitions étendues pour dépasser la limite de 4 partitions en MBR (orienté Linux mais peu importe).

Appels mobile vers les numéros spéciaux

Une petite brève. Et une bonne nouvelle, c'est rare.

Il y a quelques mois, j'ai quitté mon emploi, et je n'ai donc plus de téléphone mobile de société. Je paye donc mon abonnement téléphonique comme tout un chacun.

Et, chaque mois je voyais ma facture exploser alors que j'avais un forfait de communications illimité. Comme ce n'était pas de grosses sommes et que j'étais en train de gérer un déménagement et un changement de vie, j'ai laissé filer.

Puis, j'ai eu des soucis de santé, je suis passé en arrêt maladie, mes revenus ont diminué fortement, du coup j'ai fait un peu plus attention. Et je me suis penché sur l'origine de ces frais.

Et j'ai découvert, comme plein de monde, que quand j'appelais un service "gratuit" depuis mon téléphone portable, mon opérateur me facturait au prix fort l'acheminement de la communication (le temps passé au téléphone donc). Le diable se cache dans les détails, là c'était une mention du genre "appel gratuit hors surcoût éventuel selon opérateur". La bonne blague c'est le "éventuel".

Alors ces services c'était du basique, rien à voir avec de la voyance en ligne ou je ne sais quelles conneries : Direct Energie pour mes abonnement gaz et électricité dans mon nouveau logement, Pole Emploi pour le suivi de mon inscription, Numéricable pour mon accès Internet Haut Débit dans mon nouveau logement, le service client de La Poste, etc.

Il y avait en fait une belle arnaque bien organisée, particulièrement utilisée par les opérateurs low cost, et bien connue comme je m'en suis rendu compte après coup.

Mais bonne nouvelle, la loi vient de changer. Depuis le 01/10/2015, les opérateurs n'ont plus le droit de facturer ces communications hors forfait : vous ne paierez désormais que le coût du service, le cas échéant, facturé à la minute ou par appel (si bien sur la communication téléphonique en elle même entre dans votre forfait, sinon vous la payerez au tarif  d'une communication normale). C'est donc plus clair désormais.

J'ai vérifié la grille tarifaire de mon fournisseur (La Poste Mobile, oui je sais c'est pas glorieux, j'ai géré ça vite fait sans trop réfléchir), et effectivement ils ont aligné leur grille tarifaire sur cette nouvelle loi (bon avec un mois de retard, c'est La Poste quand même, faut pas déconner non plus).

Plus de détail sur le site de l'INC.

Cerise sur le gâteau, il existe un annuaire inversé (gratuit bien sur) qui vous permet de vérifier les conditions de tarification de tout service payant.

Les bases pour comprendre le Web - Episode 3

Cet article est le dernier d'une série de 3 articles. La lecture des deux premiers article est pré-requis :
Les bases pour comprendre le web - Episode 1
Les bases pour comprendre le web - Episode 2

Dans ces deux premiers articles, nous avons expliqué les bases d'Internet, dans ce troisième volet nous mettons le focus sur le Web.

C'est quoi le Web ?

Web c'est une abréviation de World Wide Web, toile mondiale en bon Français.

Alors World Wide, on l'a bien expliqué par la nature d'Internet qui est une interconnexion de réseaux locaux au niveau mondial.

Par contre que vient faire cette histoire de toile ?

En fait, on parle de toile car si on tirait un trait entre toutes les pages Web qui sont chaînées entre elles par des liens hypertextes, ça donnerait, en théorie du moins,  quelque chose qui ressemble à une toile.

Au passage, vous savez maintenant pourquoi la plupart des sites internet sont préfixés par www (www.google.com, www.facebook.com etc.). www c'est juste l'acronyme pour world wide web ; et comme nous l'avons vu, c'est juste une habitude, on pourrait avoir monserveurhttp.google.com ou toto.google.com, si la fantaisie avait pris les gens de google de dénommer ainsi leur serveur http dans le système DNS.

Nous allons maintenant expliquer les technologies qui permettent l'existence du web.

Les technologies du web

HTTP : Hyper Text Transfer Protocol, un protocole trop simple !

Alors HTTP est un protocole qui permet pour l'essentiel à un client de télécharger (downloader) un fichier stocké sur un serveur (machine) distant qui exécute une logiciel serveur implémentant le protocole http (un serveur web donc).

Les fichiers en question peuvent être de n'importe quelle nature : texte ou binaires, fichiers de données ou programmes exécutables. Ce n'est pas le problème du serveur http. On lui demande des fichiers, il les donne. Ce qu'en fera le client, c'est le problème du client, chacun sa merde, non mais sans blague.

Pour obtenir un fichier, un client établit donc une connexion réseau via tcp/ip avec le serveur. Il faut voir cette connexion (socket dans la jargon informatique) comme un tuyau temporairement branché entre le client et le serveur.

Une fois le tuyau en place (la connexion réseau établie), le client exprime sa requête : il demande par le verbe "GET" une ressource dont il fournit une identification via une URL. Puis il signifie qu'il a fini de parler. On peut faire la parallèle avec une communications radio où une personne dît un truc du genre "terminé" ou "over" quand elle a fini de parler pour que l'autre en face puisse parler à son tour et répondre.

Le serveur comprend que GET veut dire "envoie moi ce fichier" (ben oui, c'est un serveur http, il parle donc le http couramment), il lit l'URL et en extrait la partie qui l'intéresse (le nom et le chemin du fichier), puis il regarde sur son disque dur si il a ça en boutique. Si tel est le cas, il répond au client par un code "200" qui veut dire "OK, j'ai ton machin je te l'envoie" puis il lit le fichier sur son disque et en écrit le contenu dans le tuyau qui le relie, puis a son tour signifie qu'il a fini de parler. Si il n'a pas le fichier demandé, il va répondre par un code d'erreur "404" qui veut dire "Fichier non trouvé" puis signaler qu'il a fini de parler. Il existe d'autres codes d'erreurs correspondant à différents cas d'erreurs possibles, citons l'inénarrable "500" qui veut dire "Erreur Interne du Serveur", en gros "y a une couille dans le potage".

Quand le client entend le "j'ai terminé" du serveur, la connexion réseau est fermée, le client et le serveur ne peuvent plus se parler (sauf à établir une nouvelle connexion et redémarrer à zéro, pour cette raison le protocole http est qualifié de stateless - sans état -).

A ce stade, le client dispose du fichier que le serveur lui a envoyé. Il doit maintenant décider quoi en faire.

HTTP : Hyper Text Transfer Protocol : une histoire de bits

Attention, tout mauvais esprit est interdit !

Comme nous venons de le voir, le client http (le navigateur le plus souvent) demande au serveur web (le serveur http) de lui envoyer un ficher et si tout se passe bien, il reçoit le fichier.

Et là désolé, je vais devoir employer quelques gros mots. En informatique, toutes les informations sont représentées sous forme d'une suite de 0 et de 1, ce qu'on appelle des chiffres binaires, en anglais binary digit, abrégé en bit.

Ces suites de 0 et de 1 sont combinées en paquets de 8 chiffres, et on appelle ces nombres des octets, bytes en anglais. Ne me demandez pas pourquoi des paquets de 8 et pas de 6 ou de 10, à priori il n'y a pas vraiment de raison hormis que ça dû sembler être une bonne idée à un ingénieur un jour quelque part.

Ce nombre de 8 bits permet d'exprimer 256 valeurs différentes soit 2 élevé à la puissance 8. Ce calcul est simple à comprendre, en faisant le parallèle avec le système décimal à 10 chiffres (de 0 à 9 donc) que nous utilisons tous sans même y faire attention : dans le système décimal (à base 10 d'où le "déci"), avec un chiffre, on peut exprimer 10 valeurs (0 à 9), avec 2 chiffres on peut exprimer 100 valeurs (0 à 99), avec 3 chiffres on peut exprimer 1000 valeurs (0 à 999) etc. Si on généralise, on voit que quel que soit le système (binaire et décimal par exemple), on peut exprimer un nombre de valeur égal à la base (2 pour le binaire, 10 pour le décimal) élevé à la puissance du nombre de chiffres utilisé (2 chiffres en décimal = 10 puissance 2 = 100 valeurs ; 8 chiffres en binaire = 2 puissance 8 = 256 valeurs).

Donc à ce stade, le navigateur a reçu un paquet de 0 et de 1, il les a assemblés en paquet de 8 et il se retrouve donc avec une série d'octets. C'est bien beau mais tout ça n'a encore aucun sens.

Pour que ça puisse en prendre un, il faut en fait interpréter cette série de chiffres selon une convention.

Par exemple, si la convention est que chaque octet représente une valeur numérique entière et positive, chaque octet exprimera une valeur entre 0 et 255 ; si à chaque valeur entre 0 et 255 on fait correspondre un caractère spécifique (lettre minuscule, lettre majuscule, chiffre, signe de ponctuation etc.), on est capable d'interpréter cette suite de 0 et de 1 comme du texte. Mais si on prend une autre convention cette suite de 0 et de 1 peut représenter le dernier tube de Nirvana (du son donc), la sextape de Paris Hilton (de la vidéo du coup), une suite d'instruction (un programme informatique), et en bref tout ce qu'on veut dès lors qu'on a établi une convention pour représenter une information sous forme binaire (ou sous forme de texte qui est lui même interprété selon une convention ...)

Bon super, on sait maintenant que dès qu'on sait quelle convention utiliser, cette suite de 0 et de 1 peut prendre un sens.

Mais ... comment le navigateur sait il quelle convention utiliser ? Ha ha ! Quelle suspense ...

Hé bien, ici encore pas de mystère, si la navigateur le sait, c'est tout simplement que le serveur le lui a dit. Quand ils se sont causés, le serveur avant de lui envoyer les données, lui a précisé la nature des informations. En fait le protocole qu'ils utilisent pour se parler prévoit que le serveur fournisse d'une certaine façon, convenue à l'avance et définie par le protocole, cette information (et d'autres, je vous épargne les détails). Pour les plus curieux, c'est un header (entête) de la réponse http qui s'appelle Content-Type qui contient une valeur exprimée selon une n-iéme norme qu'on appelle le type mime.

Par exemple "text/html" ça veut dire qu'il faut interpréter les 0 et 1 comme du texte, et plus précisément que ce texte est du code html. Autre exemple, "image/gif" ça veut dire que la suite de 0 et de 1 ce sont des données binaires qui représentent une image au format gif (et là, bien sur, le navigateur connait le format gif, faut de quoi il ne pourrait pas afficher l'image) etc.

Quand on vous dit que l'informatique c'est pas compliqué !

HTTP : Hyper Text Transfer Protocol : que faire des données ?

Donc le navigateur a reçu des données, et il en connait la nature. Et maintenant que va il en faire ?

Ben comme c'est un navigateur et que c'est sa principale raison d'exister, si il reçoit du HTML il va l'afficher (le langage HTML permet de décrire des pages, nous allons détailler ça plus loin). De la même façon, il y a un certain nombres de contenus liés à la gestion des pages web qu'il va savoir utiliser de la bonne façon (des images affichées dans la page par exemple)

Mais, il peut aussi recevoir des données qu'il ne sait pas traiter de base ; dans ce cas, il regarde si il dispose d'un plugin (parfois appelé greffon ou extension) qui étend ses fonctionnalités et qui sait traiter ce format ; si tel est le cas, il passe ça au plugin qui va par exemple afficher le contenu d'un fichier pdf (une facture, un bon de commande, un billet de train ...) ou jouer une vidéo. Nous détaillons ce mécanisme de plugin plus loin.

Et pour finir, il se peut que le navigateur ne sache pas quoi faire du fichier, et qu'il ne dispose d'aucun plugin adéquat. Dans ce cas, il va simplement vous afficher une boite de dialogue et vous proposer d'enregistrer le fichier, voire de l'afficher (mais dans ce dernier cas, il va l'interpréter comme du texte et comme ce n'en est pas, le résultat ne voudra rien dire, vous aurez un tas de caractères incohérents à l'écran). Le comportement ici peut varier un peu selon les navigateurs et leur configuration.

Bon vous devez maintenant comprendre pourquoi certains liens fonctionnent dans certaines navigateurs et pas dans d'autres (par exemple, un lien vers un fichier pdf fonctionnera sur un navigateur équipé d'un plugin qui lit le pdf, et ne fonctionnera pas sur un autre qui n'a pas ce plugin).

HTTP : Hyper Text Transfer Protocol : les autres verbes 

Le protocole HTTP comprend quelques autres verbes que GET mais qui ne nous intéressent pas pour le moment, dans le cadre d'une utilisation basique du web, hormis un second : POST.

Si le verbe GET permet à un client de recevoir (lire) des données stockées sur un serveur distant (download), le verbe POST permet à l'inverse à un client d'envoyer (écrire) des données sur un serveur distant (upload) ; c'est donc l'opération inverse.

Le verbe POST permet donc d'uploader des fichiers du client vers le serveur, mais il permet également d'envoyer des données. Le cas d'utilisation le plus classique du verbe POST est l'envoi de données saisies via un formulaire sur un site web (et bien sur l'upload de fichiers).

Il existe une seconde façon pour un client d'envoyer des données au serveur, en conservant l'utilisation du verbe GET. Il ajoute simplement les données qu'il veut envoyer au bout de l'URL par exemple : http://www.toto.com?do=create&id=40. Si vous vous rappelez la description de la norme URL, ceci doit vous parler (sinon, relisez l'article précédent). En fait dans ce cas, le serveur reçoit deux données, une qui s'appelle "do" et qui a la valeur "create" et une autre qui s'appelle "id" et qui a la valeur "40".  Si vous voyez des trucs du genre %C3%A8 c'est parce que certains caractères sont représentés d'une façon spéciale pour des raisons techniques que je vais vous épargner (histoire qu'on reste concentrés sur notre http plutôt que sur de sordides détails d'encodage de caractères non ascii - disons non américains pour prendre un raccourci assez exact - et de calcul hexadécimal...)

Vous devez vous demander ce que fait le serveur quand il reçoit des données de cette manière, ou par une requête POST ? Ou encore quand il reçoit un fichier ?

Hé bien, dans ce cas il ne fait rien par lui même. En effet, la seule chose qu'il sait faire c'est envoyer des données qu'on lui demande et réceptionner des données qu'on lui transmet (mais pas les traiter). Et dès lors qu'on lui envoie des données à traiter, il ne peut que faire appel à un autre programme qui, lui, sera écrit spécifiquement pour gérer ce cas de figure. Le recours à la programmation est donc indispensable ici (contrairement au simple traitement de requêtes d'envoi de fichier qui ne nécessitent que l'installation et la configuration du serveur web).

Ce programme peut être un module interne directement exécuté par le serveur web en son sein (un programme écrit selon certains règles précises pour pourvoir s'exécuter dans le même processus que le serveur http), ou le plus souvent (du moins pour l'informatique professionnelle) ce sera un programme externe avec lequel le serveur web via dialoguer, toujours dans notre fameux mode client/serveur.

Le serveur http va donc être à son tour un client, de ce programme, avec qui il va dialoguer : il va lui envoyer les données qu'il a lui même reçu et attendre une réponse du programme, réponse qu'il enverra ensuite à son propre client. Pour ce faire, le serveur web devra avoir été spécifiquement configuré afin d'être capable de parler au programme en question, via son propre protocole. Le programme en question pourra s'exécuter sur la même machine que le serveur web, il y aura alors une communication inter-processus, ou sur une machine distante, il y aura alors une seconde communication réseau.

Si je rajoute que le programme serveur appelé par le serveur web peut lui même faire appel à un ou plusieurs autres serveurs, qui à leur tour peuvent faire appel à d'autres serveurs etc., la notion d'informatique distribuée devrait vous apparaître plus clairement. Et maintenant, vous comprenez pourquoi vous n'avez parfois jamais de réponse quand vous cliquez sur un lien, ou que c'est très lent (détail important, quand vous cliquez sur un lien, votre navigateur envoie une requête http GET).

HTML/CSS and co

HTML (Hyper Text Markup Language) est un langage qui permet de décrire sous forme textuelle à la fois des données et la façon dont on veut présenter les données

Le langage a connu plusieurs versions et est normalisé par un organisme appelé le world wide web consortium et généralement désigné sous l’acronyme w3c. La version actuelle est la version 5 et elle apporte beaucoup de nouveautés et modernise fortement le langage.

Le HTML est un langage à base de balises. Une balise est une information non affichable qui est destinée à être interprétée par un interpréteur HTML et qui donne des informations sur l’utilisation à faire de la donnée. Exemples :

• <b>ce texte sera restitué en gras</b>. Les balises <b> et </b> indiquent que le texte compris entre elles devra être affiché en gras (gras = bold en anglais)

• <i>ce texte sera restitué en italique</i>

• <a href=http://www.amazon.com/livres/sf/1984.pdf>1984</a>. Ici les balises <a> et </a> indiquent que le texte « 1984 » devra être affiché et géré comme un lien hypertexte. Un lien hypertexte est un texte sur lequel on peut cliquer. Le fait de cliquer sur le lien provoque l’établissement d’une connexion avec le serveur mentionné dans l’URL spécifiée par le paramètre href en vue d’obtenir la ressource spécifiée par l’URL. Cette balise <a> justifie le « Hyper Text » de HTML et sous son aspect anodin explique la notion même de WEB.

Une page HTML comprend deux parties, un entête (Head) qui contient des informations de nature techniques destinées au navigateur (et qui ne seront pas affichées), et un corps (Body) qui contient les informations et la description de leur mise en page.

Une page HTML mélange joyeusement des informations "pures" (données) destinées à être affichées et des informations de mise en page (balises html) destinées à être interprétées par le navigateur. Ceci rend l'écriture et surtout la maintenance des pages très complexes. Pour cette raison, le w3c a élaboré dans un second temps une norme complémentaire qui permet d'écrire des règles de mise en page dans des feuilles de style appelées CSS. Ainsi, le document HTML au lieu de décrire toutes les informations de mise en page, référence simplement les styles décrits dans une feuille associée à la page (via une balise dédiée située dans la partie HEAD). Le document HTML est ainsi plus lisible, les styles peuvent être mutualisés (réutilisés) sur plusieurs pages, et c'est bien plus maintenable (en modifiant la définition du style a un seul endroit, dans la feuille de style, on impacte automatiquement toutes les pages qui utilisent ce style).

Le Javascript

Une page HTML permet uniquement d'afficher des informations (en couple avec CSS), et c'est bien normal car c'était là la vocation initiale du web et la raison pour laquelle il a été inventé (par un chercheur en physique nucléaire qui voulait simplement partager ses travaux avec ses collègues un peu partout dans le monde).

Mais quand le web a commencé à être utilisé par le grand public, on a voulu en faire d'autres usages, et est vite apparu la nécessité de pouvoir embarquer un peu de code informatique dans les pages.

Ce code est nécessaire pour améliorer l'interaction avec l'utilisateur et avoir une meilleure ergonomie. Prenons un exemple tout bête. Vous remplissez un formulaire avec par exemple votre numéro IBAN, vous êtes susceptibles de vous tromper dans la saisie. Sans javascript, le seul moyen de vérifier que votre saisie est correcte, c'est d'envoyer une requête POST au serveur web, qui va la passer à un programme, qui va faire le contrôle et renvoyer une page HTML avec écrit en gros, gras et rouge "IBAN invalide" si vous vous êtes trompé. Tout ceci prend du temps car on a fait un aller/retour avec le serveur qui est peut être à l'autre bout de la planète, et que lui même a du faire un échange réseau avec le programme chargé de valider la saisie. A l'inverse, si on peut embarquer un bout de programme (du code informatique) directement dans la page, il sera possible de vérifier votre saisie avant tout échange avec le serveur ; ainsi en cas d'erreur vous le saurez tout de suite au lieu d'attendre 2 ou 3 secondes et on aura économisé de la bande passante, de la CPU serveur etc.

C'est un exemple basique mais il y a des tas d'autres cas d'usage tels que la modification dynamique d'un formulaire de saisie en fonction de votre saisie (par exemple si vous indiquez "sexe masculin", on va enlever le champ "nom de jeune fille").

Avec ce qu'on a appelé le web 2.0 (ce qui au passage ne veut pas dire grand chose, c'est juste un terme marketing qui ne fait référence à aucune norme), les applications web ont énormément gagné en souplesse d'utilisation et en fonctionnalités ; tout ceci est dû pour l'essentiel au progrès des navigateurs en matière d'exécution de code javascript, et surtout au progrès des outils utilisés par les développeurs.

Etant donné la vocation grand public d'Internet, le langage Javascript a été conçu pour être "simple" et accessible à des non professionnels. Pour ma part, je suis plus que critique sur ce choix car il en résulte un langage truffé de défauts ; quoi qu'il en soit ce n'est que mon avis et de toute façon, on n'a pas le choix car c'est aujourd'hui un standard incontournable. Fort heureusement, les outils professionnel dédiés au développement javascript (éditeurs, librairies, frameworks, surcouches syntaxiques diverses) ont permis de largement améliorer les choses (maintenabilité, productivité du développement, testabilité).

Maintenant vous devez comprendre pourquoi désactiver le support du javascript dans votre navigateur est la dernière chose à faire ...

Le navigateur

Le navigateur est à la croisée des chemins. C'est lui qui permet le fonctionnement du Web en combinant l’utilisation de HTTP, HTML (et sa balise <a>) et URL.

Un navigateur est un logiciel sophistiqué qui combine de nombreuses fonctions :

• Le navigateur est un client HTTP. Il sait établir une connexion réseau (socket) avec un serveur HTTP (serveur web) et dialoguer avec lui. Il demande des fichiers et quand il les obtient il en fait l’usage qui convient ou éventuellement relaie un message d’erreur renvoyé par le serveur HTTP

• Le navigateur est un interpréteur HTML. Il est capable de comprendre les balises contenues dans les fichiers HTML renvoyés par le serveur HTTP et d’afficher la page HTML. C’est lui qui fait qu’un texte encadré par les balises <b> et </b> sera affiché en gras. C’est lui qui gère le fait de déclencher une requête http quand on clique sur un lien hypertexte (verbe GET du protocole HTTP). Bien sur, il comprend également le CSS

• Le navigateur gère des formulaires de saisie (balise HTML <form>) et la transmission dans la requête http des données saisie (verbe POST du protocole HTTP)

• Le navigateur est un interpréteur JavaScript. Il comprend et exécute les programmes javascript inclus dans une page (directement ou indirectement via une balise html), voire si tel est le cas les programmes javascript qu'il a téléchargé directement (sans passer par une page html)

• Le navigateur est capable d’afficher les images embarquées dans les pages par la balise <img> dans différents formats, de gérer un cache local des pages HTML pour éviter des appels au serveur (source de nombreux problèmes), de gérer un historique de navigation (source de nombreux problèmes), de lire directement des flux audio et vidéo (HTML 5), d'exécuter des plugins qui étendent ses fonctionnalités, et plein d'autres choses encore

L'image ci-après illustre son fonctionnement basique.

.

L'image ci-après illustre le fonctionnement quand il appelle un serveur web qui lui même appelle un programme pour traiter des données qui ont été envoyées.

Dans cet exemple, le programme dialogue avec une base de données (SBGDR = base de données). C'est le cas le plus fréquent (par exemple pour afficher la liste de produits dans un catalogue).

Plus de détail sur le navigateur

Le navigateur est donc un élément essentiel puisque sans lui le web n'existerait pas, il est à la croisée de tous les chemins. Du coup, ça vaut le coup de creuser un peu plus le sujet.

w3c

W3C, ou World Wide Web Consortium, est une organisation qui est en charge de rédiger les spécifications des normes qui permettent le fonctionnement du web, en particulier HTML, CSS, DOM (expliqué plus loin).

Les normes du w3c sont censées être respectées par les différents navigateurs.

Moteur de rendu HTML, DOM

Le moteur de rendu est un des composant majeurs du navigateur. Il est en charge d'interpréter le code HTML et d'afficher la page décrite par ce code.

Le traitement se passe en deux temps :

• analyse de la page HTML et élaboration d'une représentation mémoire sous forme d'un graphe d'objet (un objet est la description d'un élément de la page, comme un texte ou un lien), selon la norme DOM (Document Object Model). 

• affichage du contenu du DOM (donc affichage de la page)

On voit donc que ce qui est affiché, ce n'est pas le HTML, mais l'interprétation qui en a été faite, à savoir un DOM. Ceci n'est pas un détail car c'est ce qui permet d'expliquer les techniques modernes popularisées par le web 2.0 ; ces techniques ont pour caractéristique (notamment) qu'elles permettent de mettre à jour ce qui est présenté à l'écran sans devoir recharger une nouvelle page, ce qui permet d'avoir des applications avec une ergonomie et une réactivité sans commune mesure avec ce qui existait à l'origine du web. En fait ces applications modifient directement le contenu du DOM (en javascript) et comme c'est le DOM qui est affiché, toute mise à jour du DOM entraîne une mise à jour de l'affichage.

Le moteur de rendu est un composant informatique qui existe indépendamment du navigateur et qui peut être utilisé dans d'autres contextes ; vous avez déjà remarqué sans doute qu'il n'y a pas que les navigateurs qui savent afficher du code HTML.Par exemple, un client de messagerie est capable d'afficher des mails au format HTML car il s'appuie, lui aussi, sur un composant "moteur de rendu html", parfois le même que le navigateur.

Il existe différents moteurs de rendu développés par différentes organisations, et ces moteurs s'améliorent continuellement. Tous les navigateurs n'utilisent pas le même moteur de rendu, ceci explique qu'une même page s'affichera différemment dans deux navigateurs différents, et que parfois deux navigateurs afficheront exactement la même chose (quand ils utilisent le même moteur de rendu).

Le navigateur Chrome utilise le moteur WebKit développé par Google (mais également les navigateurs Opera et Safari, et de nombreux navigateurs pour smartphones), le navigateur Firefox utilise le moteur Gecko développé par la fondation Mozilla, Internet Explorer a utilisé le moteur Trident (développé par Microsoft) jusque IE11 et utilise maintenant EdgeHTML avec son nouveau navigateur Edge (apparu avec Windows 10).

Les moteurs de rendu sont censés respecter de façon stricte les normes HTML, CSS et DOM. Le respect de ces normes est un critère important de qualité d'un moteur, avec sa vitesse d'affichage. Il existe des tests spécialisés qui permettent de vérifier la conformité d'un navigateur (en fait de son moteur de rendu HTML) à ces normes.

A ce jour, il est toujours très difficile pour les développeurs Web d'écrire des sites qui fonctionneront sur tous les navigateurs en raison des différences de comportement des différents moteurs ; ces différences sont dues soit à des interprétations différentes des normes w3c qui ne sont pas toujours assez précises, soit simplement à des bugs. Cependant, la situation s'est largement améliorée depuis 2 ou 3 ans et continue à s'améliorer.

Vous devez maintenant comprendre pourquoi quand un site ne fonctionne pas avec un navigateur, vous devez essayer avec un autre navigateur, et qu'il faut donc en avoir au moins deux ou trois sur votre PC.

Moteur d'exécution JavaScript

Le moteur d'exécution javascript est un autre composant informatique utilisé dans les navigateurs. Comme son nom l'indique, il est chargé d'exécuter les programmes javascript.

Le moteur d'exécution est un composant informatique qui existe indépendamment du navigateur et qui peut être utilisé dans d'autres contextes ; vous avez peut être déjà remarqué qu'il n'y a pas que les navigateurs qui savent exécuter du code javascript.

Il existe différents moteurs d'exécution développés par différentes organisations, et ces moteurs s'améliorent continuellement. Tous les navigateurs n'utilisent pas le même moteur, ceci explique qu'un même site fonctionnera différemment sur deux navigateurs (le plus souvent, il fonctionnera avec un moteur et ne fonctionnera pas avec un autre).

Le navigateur Chrome utilise le moteur V8 développé par Google, le navigateur Firefox utilise le moteur SpiderMonkey développé par la fondation Mozilla, Internet Explorer a utilisé le moteur Trident (développé par Microsoft) jusque IE8, puis Chakra depuis IE9.

Sans trop rentrer dans la technique, le langage javascript est un langage assez "rudimentaire" (il était destiné initialement à être aisé de prise en main par des non spécialistes) ce qui a diverses conséquences fâcheuses, et en particulier une nette propension à la lenteur et aux fuites mémoire : les programmes écrits en javascript sont plus lents que ceux écrits dans d'autres langages, et sont plus difficile à coder proprement pour ne pas gaspiller les ressources mémoire.

Fort heureusement, ces dernières années les interpréteurs javascript (moteurs d'exécution, c'est la même chose) ont fait des progrès spectaculaires (V8 de Google a lancé la danse, Microsoft a fait très fort avec la dernière version de Chakra utilisée dans Edge) ; et il était plus que temps car le web 2.0 fait un usage immodéré des technologies javascript pour offrir une ergonomie sophistiquée et modernes aux sites actuels, qui parfois n'ont plus grand chose à envier aux applications natives.

Les moteurs de rendu sont censés respecter de façon stricte la norme EcmaScript (en fait, javascript n'est qu'une implémentation de la norme EcmaScript ; il en existe d'autres mais c'est bel et bien javascript qui est employé aujourd'hui). Il existe des tests spécialisés qui permettent de vérifier la conformité d'un navigateur (en fait de son moteur js) à cette norme, ainsi que des tests de performance.

Vous devez maintenant comprendre pourquoi quand un site ne fonctionne pas avec un navigateur, vous devez essayer avec un autre navigateur, et qu'il faut donc en avoir au moins deux ou trois sur votre PC.

Plugins

Le terme plugin est assez générique en informatique, il désigne un logiciel facultatif qui vient compléter un logiciel principal et lui apporter des fonctionnalités supplémentaires. Le logiciel principal existe indépendamment de ses plugins dédiés et a été conçu pour être extensible par ce mécanisme de plugin. Le plugin quant à lui ne peux fonctionner dans un autre contexte que celui qui est fourni par le logiciel principal.

Les navigateurs sont donc conçus de façon a ce qu'on puisse y installer des plugins qui leur apportent des fonctionnalités supplémentaires, vous en utilisez tous les jours sans en avoir conscience :

• le plugin "lecteur pdf", souvent Acrobat Reader, permet de lire directement dans le navigateur des fichiers au format pdf

• le plugin Flash Player permet de lire des vidéos au format Flash directement dans le navigateur

Le support ou non de tel ou tel plugin par les navigateurs est important car il conditionne la capacité du navigateur à supporter certaines fonctions (lire un fichier pdf, diffuser une vidéo au format flash).

Le paysage en matière de plugins évolue fortement ces derniers temps, aussi nous faisons un focus sur ce point.

Flash vs HTML5 : Flash Player a été un standard de fait depuis très longtemps car c'était la principale solution qui permettait de diffuser de la vidéo dans les pages web, technique sans laquelle des sites comme youtube n'existeraient même pas. Cependant, ce produit ne répond à aucune spécification publique et officielle, le format est propriétaire (pas une norme w3c mais une technologie appartenant à une société privée). La situation a évolué avec la version 5 de la norme HTML qui standardise un format et des mécanismes de streaming vidéo ; une fois cette version largement implémentée par les navigateurs couramment utilisés  (ce qui est le cas actuellement), la plupart des sites ont commencé à migrer vers ce nouveau format rendant Flash Player bien moins intéressant. Par ailleurs, Flash Player n'est pas supporté sur certaines smartphones (Iphone Apple, Windows Phone) pour diverses raisons (techniques ou politiques) et du coup Adobe (l'éditeur de Flash) a abandonné le support Android (système d'exploitation de très nombreux smartphones, à commencer par les Samsung). Le résultat de tout ceci est que cette technologie est en train de mourir et ne sera à terme plus supportée par les navigateurs.


Abandon du support NPAPI : Un autre changement important concerne l'abandon du support NPAPI par les principaux éditeurs de navigateurs (Microsoft depuis la sortie de Edge, Google pour Chrome depuis la mi 2015, et bientôt Mozilla pour Firefox). NPAPI était une interface de programmation datant de l'aube des navigateurs Internet (N vient de Netscape, l'ancêtre de tous les navigateurs). En gros, ça définit comment doit être écrit un plugin ; du coup tout plugin qui respecte ces règles peut s'exécuter dans tout navigateur qui supporte NPAPI, c'est à dire tous les navigateurs jusque il y a peu. Or, comme les éditeurs de navigateurs ont annoncé que leurs navigateurs ne supporteraient plus cette norme, tous les plugins écrits avec cette norme ne fonctionnent plus ou ne fonctionneront bientôt plus avec tous les principaux navigateurs. Les éditeurs de plugin ont toujours la possibilité de réécrire leurs plugins pour qu'ils supportent les nouvelles normes, mais il est peu probable que ça se fasse pour diverses raisons : déjà ça coûte cher et les plugins sont fournis gratuitement aux utilisateurs, ensuite il n'y a pas une API unique pour tous les navigateurs ce qui multiplie le nombre de développements à réaliser, certains navigateurs n'offrent même pas d'API pour plugin (Edge en particulier), et enfin les plugins indispensables (lecture pdf et flash dans une période intermédiaire) sont d'ores et déjà fournis directement par les éditeurs des navigateurs.

Le principal impact va donc être que tous les sites basés sur certains plugins largement utilisés à une période ne vont plus fonctionner et devront être réécrits... Si il ne sont pas réécrits, leurs utilisateurs n'auront d'autre alternative que d'utiliser d'anciens navigateurs (IE11 pour l'essentiel) qui supportent encore les vieux plugins. Or on ne peut rester longtemps avec un vieux navigateur sans problème, en particulier de sécurité. Les sites en question sont ceux qui font usage d'applets Java (composant développés dans la langage Java et exécuté par un moteur Java appelé par le navigateur), qui sont basés sur SilverLight (équivalent des Applets Java chez Microsoft), ou encore d'ActiveX (technologie Microsoft encore assez répandue). Les sites grands public font peu d'usage de ces technologies, par contre de nombreuses applications fournies par des éditeurs, ou applications en entreprise, sont encore basée sur ces technologies.

Par exemple, l'interface d'administration de mon antivirus AVG est développée en SilverLight, AVG va devoir réecrire entièrement son outil, et je devrais me mettre à jour. Un site de régie de transports de Reims qui calcule des itinéraires en bus est développé avec des Applets, il ne fonctionnera bientôt plus. Etc.

Pour le fun : avant que le couple infernal HTML5/javascript ne s'impose définitivement comme plateforme de développement pour les années à venir, il y a eu une période récente (disons il y a 3  ou 4 ans) où l'industrie hésitait à s'orienter vers une solution basée sur une généralisation de l'usage de plugins évolués permettant d'offrir des applications modernes et ergonomiques au sein du navigateur. Ceux qui ont fait ce choix doivent aujourd'hui le regretter amèrement, et pourtant ils n'ont rien à se reprocher car la situation était tout sauf lisible. A titre personnel, j'ai vu une grande banque Française devoir mettre à la poubelle des années/homme de développements et de R&D suite à l'abandon de Flex (une évolution de Flash Player pour faire simple) par Adobe qui a décidé brutalement de se recentrer sur HTML5.

Fonctions cryptographiques

Le protocole http est un protocole non crypté, et en outre particulièrement simple.

Conséquence, le premier ado boutonneux venu peut s'amuser à sniffer des trames réseau (écouter les informations qui circulent sur Internet, comme on peut espionner des communications téléphoniques) et récupérer toutes sortes d'informations. Les outils pour faire ça sont largement accessibles, et si on peut considérer que le hacking est un passe temps largement préférable à la drogue, aux tournantes et courses sauvage avec la voiture volée à papa, j'en connais certains qui ont eu la mauvaise surprise de voir débouler la gendarmerie chez eux pour une perquisition et la saisie de tous leurs ordinateurs.

Plus sérieusement, le développement du Web comme plateforme pour le commerce électronique était impossible tant qu'on ne pouvait pas garantir un minimum de sécurité. Ceux qui se sont fait pirater leur CB une fois voient de quoi je veux parler.

Alors, je ne vais pas entrer dans le détail, ce serait un peu long, mais disons simplement que les navigateurs modernes embarquent divers algorithmes sophistiqués et des bases de certificats de sécurité (émis par les organismes de certifications). Tout ceci permet de faire fonctionner le protocole HTTPS. Le "S" en plus c'est pour dire SECURE http, et cette sécurisation s'appuie sur un cryptage du protocole http par une technologie appelée SSL (Secure Socket Layer) ou TLS (nouveau nom de SSL).

L'intérêt est que ce cryptage intervient sur la couche transport et est donc totalement transparent pour le protocole http lui même (qui est sur la couche application). Bon, si vous ne comprenez pas cette phrase ce n'est pas grave. Ce qu'il faut retenir c'est que rien ne change, hormis un peu de configuration au niveau des serveurs et un peu de travail administratif (achat et déploiement de certificats SSL auprès de tiers de confiance, aka organismes certificateurs). Par contre, pour les utilisateurs, tout est identique : simplement un petit cadenas apparaîtra dans le navigateur et l'url démarrera par HTTPS au lieu de HTTP.

Le seul souci est que dans la course aux armements entre missile et blindage, il est nécessaire de faire évoluer régulièrement les algorithmes de cryptographie utilisés, et d'autres éléments, au fur et à mesure que la NSA et autres groupes mafieux (non je ne peux pas blairer les yankees) arrivent à casser les codes.

Du coup, il est parfois requis de changer de navigateur, les navigateurs trop anciens étant insuffisamment sécurisés. C'est comme si vous rouliez avec un char en blindage de 30 quand Daech dispose de missiles qui percent du 40 : il vous faut prendre un char en blindage de 50.

Si les choses sont stables depuis un bon moment et que ce problème ne concerne que ceux qui tournent avec de très vieux systèmes, il va cependant revenir sur le devant de la scène en 2016:2017 suite à l'abandon de SHA-1 au profit de SHA-2 (des chercheurs en mathématique ont démontré que l'algo SHA-1 utilisé depuis des années était dépassé et pouvait être cassé sans nécessiter des moyens techniques hors de portée des groupes mafieux, et Snowden a balancé le fait que la NSA a dépensé les milliards requis pour pouvoir casser les cryptages actuels).

J'ai prévu, quand j'aurais un peu de courage, un article pour vulgariser les notions de base en cryptographie (mais là j'ai pas le temps, j'ai déjà une série à finir sur le montage d'un NAS maison et c'est du boulot, et pleins d'autres idées).


Plus de détail sur le reste ...

Ascii ?

Bon, je développe cette histoire de ascii quand même.

Nous avons vu qu'on exprimait du texte en binaire en attribuant une valeur numérique décimale à chaque caractère et en exprimant cette valeur décimale en binaire.

Et la fameuse convention qui dit que la lettre "a" par exemple vaut la valeur 97 (01100001 en binaire), ben elle s'appelle Ascii (American Standard Code for Information Interchange, convention américaine pour l'échange d'information) et comme son nom l'indique elle est américaine ...

Or les américains, bien centrés sur leur nombril de yankee, ont juste oublié qu'ils n'étaient pas seuls au monde et que dans les pays civilisés (le reste du monde en gros, le premier qui dis que je n'aime pas les usa a gagné un bon point), on utilisait des caractères accentués (é è à â etc.. rien qu'en France, ajouter là-dessus les tildes espagnols, umlaut allemand et des tas d'autres trucs).

Du coup, quand on a voulu les traiter dans les systèmes informatiques initialement basés sur ce code Ascii ça a soulevé des tas de problèmes amusants avec lesquels on est encore en train de galérer 30 ans après (mais ça s'améliore grâce à une norme appelée Unicode qui prend en compte tous les caractères de tous les alphabets du monde).

Bref, je ferme cette parenthèse car il faudrait toute une série d'articles rien que pour expliquer tout ça en détail. Si vous ne comprenez pas, ne vous inquiétez pas, je connais des tas de gens avec des diplômes d'ingénieur en informatique et qui ne savent même pas ça :-(

Déjà, vous devez comprendre pourquoi les caractères accentués ne sont pas lisibles directement dans les URL (ils sont ré-encodés avec d'autres conventions), ou pourquoi il peut arriver que quand vous lisez des fichiers envoyés par un collègue étranger, certains caractères soient perdus et remplacés par d'autres.

Conclusion

A ce stade, vous savez déjà tout ce qu'il faut pour comprendre le fonctionnement du web, et même un peu plus.

Cependant, sur cette base, il est possible d'aller un peu plus loin pour ceux qui sont intéressés. Je prévois quelques articles davantage destinés aux étudiants en informatique ou aux débutants dans la profession d'informaticien. Je ne pourrais pas tout vulgariser car c'est un travail trop long et fastidieux compte tenu de tous les pré-requis mais je vais essayer de faire en sorte que ça reste accessible aux curieux.

A suivre donc !