Architectures, systèmes et réseaux : de la puce à HTTPS

Un système sur puce, ou SoC, rassemble plusieurs fonctions dans un même circuit intégré. Sur le schéma, repère le processeur qui exécute des instructions, la mémoire locale, un accélérateur spécialisé et les contrôleurs qui communiquent avec l’extérieur. L’interconnexion fait circuler les informations entre ces blocs. Le processeur n’est donc qu’un composant du système, pas un synonyme de la puce entière.

Le contour de la puce compte autant que les blocs. Une mémoire vive externe, un écran ou un capteur peuvent rester hors du SoC tout en étant commandés par ses interfaces. L’intégration raccourcit certains échanges et peut réduire l’encombrement et l’énergie consommée. Elle ne signifie ni que toutes les mémoires sont internes ni que toute opération devient automatiquement plus rapide.

Pour traiter une image, on peut exécuter un programme sur un processeur généraliste ou confier une opération répétée à un accélérateur. La première solution se modifie facilement par le logiciel. La seconde peut gagner en vitesse et en énergie sur sa tâche, au prix d’une spécialisation, d’une surface et d’un effort de conception supplémentaires. Avant de comparer, impose le même résultat, les mêmes données et les mêmes conditions de fonctionnement.

Nos deux profils fictifs décrivent cette même tâche : surface en mm², énergie par image en µJ et latence en µs. La latence est le délai de traitement d’une image ; le débit serait le nombre d’images traitées par unité de temps. On n’additionne pas les latences de tous les blocs d’une puce : des opérations peuvent se recouvrir. Ici, chaque profil donne directement les trois mesures globales de l’architecture étudiée.

Le cahier des charges impose trois plafonds simultanés. Avec 18 mm², 40 µJ et 20 µs, le profil spécialisé respecte les trois ; le profil souple échoue sur l’énergie et le délai. Si plusieurs candidats passent, la décision nécessite une priorité supplémentaire, comme la facilité de modification. Le transfert recherche les profils non dominés : aucun autre n’est au moins aussi bon partout et strictement meilleur sur un critère.

Un programme est un ensemble d’instructions ; un processus est une exécution de ce programme avec son état propre. Deux exécutions peuvent donc avoir le même code mais des données et des identifiants différents. Le système d’exploitation prépare notamment l’espace mémoire et le contexte d’exécution, puis organise l’accès au processeur. Lors d’un changement de tâche, il conserve les informations nécessaires pour reprendre le travail.

Un processus peut en créer un autre par une demande au système. Son PID l’identifie ; le PPID désigne son parent dans les systèmes qui exposent cette relation. Les identifiants peuvent être réutilisés : ne déduis pas une chronologie certaine de leurs seuls numéros. Sous Linux, la commande en lecture seule ps -eo pid,ppid,stat donne un instantané sans les arguments des programmes. Repère un PID repris comme PPID d’une autre ligne : il identifie le parent de ce processus. Garde le relevé sur ta machine ; pour l’entraînement fourni, on utilise uniquement les tâches fictives P1 et P2.

Dans notre modèle, un processus prêt peut utiliser le processeur mais attend son tour. Actif, il exécute ses instructions. Bloqué, il attend un événement, par exemple la fin d’une lecture. Cet événement le rend prêt ; l’ordonnanceur décide ensuite de l’élire. Un processus terminé ne revient pas dans la file. Les états précis d’un outil système sont plus détaillés : sous Linux, R regroupe notamment l’exécution et l’attente du processeur.

Sur un processeur logique, notre modèle n’exécute qu’une tâche à la fois. L’alternance donne une exécution concurrente ; plusieurs cœurs peuvent permettre un véritable parallélisme. Avec le tourniquet, chaque tâche reçoit au plus un quantum, puis retourne en fin de file s’il reste du travail. Elle ne doit ni monopoliser le début de la file ni consommer un quantum complet quand elle peut finir plus tôt.

P1 demande cinq unités de calcul et P2 en demande trois. Avec un quantum de deux, la frise donne P1, P2, P1, P2, P1 : les deux derniers créneaux ne durent qu’une unité. La durée totale vaut huit. Le laboratoire suppose toutes les tâches prêtes à zéro, sans entrée-sortie ni coût de commutation ; la fonction séparée etat_suivant étudie les transitions, mais ne transforme pas la frise en simulateur d’entrées-sorties.

Le temps de réponse étudié va de l’arrivée au premier passage ; le temps d’attente cumule les moments prêts mais non actifs. Dans ce modèle sans blocage et avec arrivée à zéro, attente = date de fin − durée de calcul. Un petit quantum peut réduire la première attente, mais multiplie les changements de contexte sur une machine réelle. La file Python utilise pop(0) pour rester lisible ; ses décalages ne sont pas un coût de processeur simulé.

P1 utilise une ressource dont P2 a besoin. P2 attend, mais si P1 finit son travail et libère la ressource, cette attente a une issue. Un interblocage apparaît lorsque des tâches ne peuvent plus avancer parce qu’elles attendent mutuellement des ressources qu’elles conservent. Pour comprendre la situation, écris d’abord qui détient chaque ressource et qui demande quoi.

Considérons deux verrous exclusifs, chacun disponible en un seul exemplaire : R1 et R2. P1 détient R1 et demande R2 ; P2 détient R2 et demande R1. Les deux tâches attendent tout en conservant leur premier verrou. Sans libération forcée ni autre intervention, aucune ne peut atteindre l’instruction qui libérerait ce que l’autre réclame. On a une attente circulaire.

Le graphe d’attente représente les processus, pas les ressources : une flèche P1 → P2 signifie que P1 attend une ressource détenue par P2. Le cycle P1 → P2 → P1 révèle ici l’interblocage. Le critère est lié à nos hypothèses : ressources à une instance, exclusives, non retirables de force et demandes nécessaires pour poursuivre. On ne transpose pas automatiquement ce test à des ressources disponibles en plusieurs exemplaires.

Les verrous étudiés sont non réentrants : les demander à nouveau quand on les détient déjà peut bloquer la même tâche. Le graphe conserve donc P1 → P1, témoin d’auto-interblocage. Une ressource libre, notée None, ne crée au contraire aucune flèche. Une ressource inconnue est une erreur d’entrée, pas une ressource supposée libre ; le laboratoire la refuse.

La recherche de cycle distingue les sommets déjà visités de ceux encore présents dans le chemin en cours. Rejoindre un sommet du chemin ferme un cycle ; rejoindre un sommet complètement exploré ne suffit pas. Pour prévenir l’attente circulaire, toutes les tâches peuvent respecter le même ordre strict d’acquisition, R1 avant R2. Cet ordre retire une condition de l’interblocage ; il ne prouve pas que chaque tâche sera servie rapidement.

Un routeur transmet un paquet vers une destination en consultant sa table de routage. Une ligne indique notamment la destination, le prochain saut et une métrique. Le prochain saut est un voisin, pas le chemin entier. Des routes peuvent être configurées manuellement ; un protocole de routage permet aussi de les actualiser par échanges entre routeurs. RIP et OSPF sont des protocoles de routage interne à un système autonome.

Dans RIP, les routeurs échangent des estimations de distance avec leurs voisins. Avec un coût d’un saut par liaison, si B annonce D à distance 2, A calcule une possibilité de distance 3 via B. A conserve une meilleure possibilité pour chaque destination. Le nombre de sauts est la métrique étudiée : un chemin plus court en sauts n’est pas nécessairement plus rapide en secondes.

Les métriques utilisables sont limitées à 15 ; 16 signifie inaccessible. La distance candidate est donc plafonnée à 16. Dans notre graphe de routeurs, un routeur se connaît à distance zéro et ses voisins à distance un. Les réseaux destinataires et les interfaces d’une vraie table sont ici représentés par des noms de routeurs pour isoler le calcul. Ne transforme pas la valeur spéciale 16 en une route à emprunter.

Sur A–B–C–D, A connaît d’abord B, pas encore C ni D. Après un échange, il apprend C via B ; après le suivant, D via B. Chaque tour de simulation lit uniquement les tables du tour précédent, puis remplace toutes les tables ensemble. Cela rend l’expérience reproductible et permet de compter les tours. À égalité, notre modèle choisit le voisin au nom le plus petit : c’est sa convention, pas une règle universelle de RIP.

Une panne n’efface pas instantanément les anciennes annonces de toutes les machines. Sans précautions, deux routeurs peuvent croire chacun que l’autre connaît une route disparue et faire monter la métrique jusqu’à 16 : le comptage à l’infini. Des mécanismes comme l’horizon partagé et les annonces inversées empoisonnées réduisent certaines boucles. Le laboratoire calcule une topologie fixe ; le transfert retire un lien et recommence depuis zéro pour comparer les routes possibles, sans simuler les délais réels de convergence.

Avec un protocole à état de liens, les routeurs diffusent des informations sur leurs liaisons. Dans une même zone OSPF stabilisée, chacun dispose d’une base décrivant la topologie de la zone. Chaque routeur effectue ensuite son propre calcul en prenant sa position comme départ. Il ne reçoit donc pas simplement une distance finale du voisin comme dans le modèle à vecteur de distance.

Le coût d’une route est la somme des coûts de ses liens. Ces valeurs configurables sont sans unité et peuvent être choisies à partir du débit des interfaces ; elles ne mesurent pas directement la latence du trajet. Avec une référence choisie de 100 Mbit/s, la règle d’exercice référence / débit donne 1 pour 100 Mbit/s et 10 pour 10 Mbit/s. Il faut conserver les mêmes unités dans le rapport. Cette formule est un choix de configuration, pas l’unique définition d’OSPF.

Sur l’anneau A–B–C–D–A, AB, BC et CD coûtent chacun 1 ; AD coûte 10. En nombre de sauts, A rejoint D directement. En somme des coûts, le chemin A–B–C–D coûte 3 et gagne contre 10. Le dessin juxtapose les deux décisions sur les mêmes liaisons. La longueur d’un trait sur la page n’a aucune valeur dans le calcul.

L’algorithme de Dijkstra part de la source à distance zéro et des autres sommets à l’infini. Il choisit parmi les sommets non fixés celui de distance provisoire minimale, le fixe, puis essaie d’améliorer ses voisins. La positivité des coûts permet de rendre cette distance définitive. Notre implantation simple balaie les candidats à chaque tour ; elle illustre le raisonnement, pas l’organisation complète d’un routeur.

Le laboratoire représente des liaisons symétriques de coût entier strictement positif et vérifie toute la carte, y compris une composante inaccessible. La source doit exister. Les égalités sont départagées de façon reproductible par les noms lors du choix des sommets ; une distance égale ne remplace pas un prédécesseur déjà trouvé. OSPF peut réellement conserver plusieurs routes de même coût. Si aucune route n’existe, la distance reste infinie et le chemin reconstruit est vide.

Le chiffrement symétrique utilise un secret partagé pour chiffrer et déchiffrer. Dans le chiffrement asymétrique à clé publique, on chiffre pour le destinataire avec sa clé publique ; sa clé privée permet de déchiffrer. Une signature a un autre rôle : la clé privée signe, la clé publique vérifie. La confidentialité d’un message et l’authentification de son auteur sont donc des propriétés différentes.

Un échange de clés établit des secrets communs sans les envoyer en clair. Il faut aussi authentifier l’autre partie, sinon un intermédiaire pourrait établir deux échanges séparés. Pour HTTPS, le certificat lie notamment une identité de serveur à une clé publique. Le client vérifie le nom demandé, la période et la chaîne de confiance, puis la preuve que le serveur possède la clé privée correspondante. Une signature valide sur un certificat d’un autre nom ne suffit pas.

Le schéma suit une connexion TLS 1.3 avec échange éphémère et certificat serveur, sans reprise ni données anticipées. ClientHello et ServerHello permettent de choisir les paramètres et de dériver des clés pour la négociation. Le serveur transmet ensuite ses paramètres, son certificat et sa preuve de possession, protégés pendant l’échange ; les messages Finished confirment notamment l’intégrité de la négociation. Les données applicatives utilisent ensuite des clés de trafic.

TLS 1.3 n’envoie pas une clé de session chiffrée par RSA comme le faisaient certains anciens modes. Le certificat peut porter une clé utilisée pour signer, tandis que l’établissement du secret utilise ici un échange éphémère. Les données sont chiffrées et authentifiées : une altération est détectée. Cela protège le canal, pas la véracité d’une page ni l’honnêteté de son auteur. HTTP sur TLS donne HTTPS ; les routeurs continuent d’acheminer les paquets.

Le laboratoire sépare volontairement deux mécanismes faciles à calculer : un tout petit exemple RSA transporte un nombre et XOR transforme les octets d’un texte. Les paramètres publics (3, 33) et privés (7, 33) sont des constantes d’exercice, pas des clés sûres. La lettre é et un emoji doivent d’abord être encodés en UTF-8 : un caractère Unicode n’est pas nécessairement un octet. Modifier un octet chiffré peut modifier le message sans alerte, ce qui montre l’absence d’intégrité de ce jouet.

La clinique de bogue rassemble des contrôles fictifs de certificat avec des noms réservés en .invalid. Les booléens de chaîne et de signature sont des résultats supposés, pas des vérifications cryptographiques réalisées par ce code. Leur intérêt est logique : tous les contrôles doivent réussir, et le nom doit correspondre entièrement. Pour une vraie communication, le logiciel s’appuie sur sa bibliothèque TLS et conserve ses vérifications ; aucun code de ce laboratoire ne sert à protéger des données.