Domaine principal
Infrastructure Internet
Au sein de la facette Domaine principal, l'analyse Infrastructure Internet regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.
Histoire d'Internet
La dernière ligne non compressée : quand IMAP changea le sens de tous les octets suivants
La réponse du serveur n'avait rien d'extraordinaire: une étiquette, `OK`, quelques mots, puis CRLF. Pourtant, c'était la dernière ligne lisible de cette manière. Après l'acceptation de COMPRESS, l'octet suivant ne relevait plus directement de la grammaire IMAP, mais d'un flux…
Histoire d'Internet
La salutation qu’il fallut répéter : STARTTLS et la remise à zéro de la confiance SMTP
La première présentation du client avait circulé en clair, tout comme la liste des capacités du serveur. Ajouter TLS au milieu de la même connexion ne pouvait pas rendre ces paroles antérieures fiables après coup. SMTP choisit donc une règle plus nette: une fois le tunnel établi…
Histoire d'Internet
L’identifiant qui ne pouvait pas signer le message : comment SMTP AUTH borna l’identité de soumission
Un identifiant ouvrait la porte du serveur de soumission; il n’apposait aucune signature sur la lettre. SMTP AUTH rendit le courrier mobile praticable en conservant cette limite: le serveur savait qui avait établi la session et ce que ce compte pouvait faire, sans prétendre…
Entreprises institutionnelles mondiales
linuxptp et la boucle de contrôle du temps de précision
linuxptp transforme un hôte Linux, une horloge matérielle et une source de synchronisation réseau en système de temps de précision. Ses démons coordonnent l'état IEEE 1588, les estampilles de paquets, les servos et les horloges système, mais le logiciel seul ne peut pas fabriquer…
Universitaires
Laurent Vanbever et le réseau qui doit être testé pendant qu'il change
Les travaux de Laurent Vanbever traitent la configuration réseau comme un logiciel exécutable dont les défaillances peuvent apparaître avant, pendant ou après le déploiement. De la migration sûre du routage et de la synthèse de configuration à la détection BGP à l'exécution et…
Histoire d'Internet
L’adresse qu’aucun relais ne pouvait rétrograder : comment SMTPUTF8 lia le nom à son chemin
Un nom d’affichage accentué pouvait traverser l’ancien courrier parce qu’il entourait une adresse ASCII. Un nom de boîte non ASCII était la destination elle-même. SMTPUTF8 obligea chaque relais à prouver qu’il pouvait transporter cette identité sans en inventer une autre.
Universitaires
Katerina Argyraki et la recherche de preuves dans la transmission des paquets
Les recherches de Katerina Argyraki suivent un problème qui se complexifie à mesure que les réseaux deviennent plus programmables: un système de traitement des paquets peut être rapide et flexible, tandis que les opérateurs et les utilisateurs disposent de peu de preuves de son…
Entreprises institutionnelles mondiales
FreeRADIUS et les décisions de confiance derrière l’accès réseau
Une connexion réseau peut se décider en quelques paquets, mais la confiance qui la sous-tend peut englober certificats, annuaires, équipements d’accès, partenaires d’itinérance et systèmes de comptabilité. FreeRADIUS rend cette politique inspectable et programmable, tout en…
Créateurs
Dave Maltz et la pile opérationnelle qui sous-tend le réseau d’Azure
Le rôle de Dave Maltz chez Microsoft se comprend par l’étendue de l’organisation qu’il dirige. Azure Networking couvre les services destinés aux clients, le DNS, la sécurité, le contrôle distribué, le déport côté hôte, les logiciels de commutation, les fabriques de centres de…
Histoire d'Internet
Le récépissé qui ne pouvait promettre la livraison
Avec DSN, SMTP transforma le rebond en preuve structurée sans abolir sa limite: l’expéditeur pouvait demander un rapport, mais aucun rapport ne pouvait attester au-delà de ce que le système avait observé.
Histoire d'Internet
Le huitième bit devait obtenir la permission à chaque relais : ce que 8BITMIME changea dans SMTP
Un courrier pouvait décrire correctement une lettre accentuée sans que tous les relais sachent transporter ses octets. 8BITMIME transforma ce doute en engagement local: annoncer la capacité, puis conserver chaque bit accepté.
Histoire d'Internet
Les commandes parties avant leurs réponses : comment SMTP PIPELINING changea l’attente
Le SMTP des débuts imposait une pause après presque chaque commande. Sur une liaison lointaine, le silence entre deux lignes pouvait coûter davantage que leur transport. PIPELINING réduisit cette attente, au prix d’une discipline nouvelle: l’ordre devait rester le registre exact…
Histoire d'Internet
La méthode qui refusait le malentendu : HTTP 510
RFC 2774 empêchait qu’un serveur ignore une extension obligatoire tout en annonçant un succès. Le destin de 510 révèle le coût d’une sémantique vérifiable.
Histoire d'Internet
Le message mesuré avant de partir : comment SMTP SIZE avança le refus
Le SMTP d’origine pouvait transporter un message entier avant d’apprendre que le serveur ne le garderait jamais. L’extension SIZE ne promit pas la livraison: elle permit à deux relais de confronter une charge annoncée à une capacité locale avant d’en payer tout le transfert.
Histoire d'Internet
Le réseau a répondu à la place de l’origine : pourquoi HTTP avait besoin de 511
Un client a interrogé un serveur et reçu la réponse du réseau intermédiaire. HTTP 511 a tenté de nommer cette substitution sans céder au portail l’identité de l’origine. Ses limites expliquent le passage ultérieur vers une API captive annoncée et authentifiée.
Histoire d'Internet
Le serveur qui cessa de rappeler : comment le FTP passif franchit le pare-feu
Le FTP ne fut pas adapté aux pare-feu par une refonte spectaculaire. Une décision plus modeste suffit: le serveur attendrait le second appel au lieu de le lancer. Ce renversement conserva les deux voies du protocole tout en redonnant aux extrémités la charge de savoir à qui elles…
Histoire d'Internet
La requête était trop grande avant même son corps : pourquoi HTTP avait besoin de 431
Une requête HTTP peut être refusée avant la lecture de son contenu. Ce n'est pas qu'Internet ait fixé une taille universelle: un récepteur a décidé quelle quantité de contexte de contrôle il acceptait de traiter. Le code 431 a rendu cette limite locale intelligible.
Histoire d'Internet
L’hôte qui apprit une petite table de routage : comment IPv6 classa les premiers sauts
IPv6 ne transforma pas chaque terminal en routeur. Il permit d’exposer quelques choix temporaires, puis laissa l’hôte combiner préfixe le plus long, joignabilité observée et politique locale. La limite faisait partie du mécanisme.
Histoire d'Internet
Le serveur qui comptait avant de répondre : pourquoi HTTP a eu besoin de 429
Le cinquante et unième appel peut être aussi correct que les cinquante précédents et recevoir pourtant un refus. HTTP 429 a rendu cette décision compréhensible sans prétendre définir l’identité comptée, la portée du quota ni la justice du partage.
Histoire d'Internet
Le silence qui autorisa une adresse : ce que DAD pouvait prouver
IPv6 DAD fonda une décision importante sur une absence observée: aucun rival ne se manifesta pendant une épreuve locale et bornée. Restait à limiter la portée de ce silence.