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
Le succès qui rendait son propre flux caduc : comment XMPP redémarrait après TLS et SASL
Dans XMPP, réussir une négociation de sécurité ne permettait pas à l’ancien flux XML de poursuivre sa route. Cette réussite changeait au contraire les conditions de vérité du dialogue: la connexion TCP restait ouverte, mais les en-têtes, l’identifiant et les fonctions du flux…
Histoire d'Internet
Les caractères que la somme de contrôle n’a jamais vus : comment PPP nettoyait le trajet série avant de juger la trame
Sur une liaison série, tout octet observé n’appartient pas nécessairement à la trame voulue par l’émetteur. PPP a donc placé une frontière avant le contrôle d’intégrité: retirer l’habillage réversible du transport et quelques caractères de commande précisément désignés, puis…
Histoire d'Internet
L’en-tête qui n’apparaissait qu’en cas de gain : la décision locale d’IPComp
Une association IPComp pouvait être parfaitement valide et laisser passer le paquet suivant sans la moindre trace d’IPComp. Ce silence n’était pas une panne: lorsque la charge compressée et les quatre octets d’en-tête n’étaient pas plus petits que l’original, le protocole…
Histoire d'Internet
Le relais de datagrammes qui mourait avec un flux : comment SOCKS5 lia UDP à une association TCP
Un port UDP n’annonce jamais qu’une conversation est finie. SOCKS5 résolut ce manque sans inventer une fausse connexion entre les datagrammes: il fit dépendre le relais d’un dialogue TCP distinct. Quand ce dialogue disparaissait, l’autorité de relayer disparaissait avec lui, même…
Histoire d'Internet
La Key qui ne verrouillait rien : GRE a séparé le flux de la sécurité
Un champ de quatre octets s’est appelé Key avant de disposer d’une serrure, d’un secret ou d’une preuve d’identité. La normalisation de GRE n’a pas comblé ce vide par une promesse plus ambitieuse. Elle a donné au champ une fonction plus étroite: désigner un flux logique à…
Histoire d'Internet
L’octet que le rejet a su nommer : l’indice d’ICMP Parameter Problem
Un paquet rejeté ne disparaît pas toujours sans laisser d’adresse. Avec Parameter Problem, ICMP a donné au nœud qui abandonne l’analyse un moyen minimal de dire où elle s’est arrêtée. L’indice n’explique pas tout: il borne au contraire ce que le rapporteur sait, ce qu’il renvoie…
IETF
Peter Thomassen et la mise à jour qui exigeait chaque serveur faisant autorité
Dans le DNS, obtenir une réponse suffit souvent à poursuivre la résolution. Modifier une délégation exige une règle plus sévère: le parent doit savoir si la demande existe dans l’ensemble du service faisant autorité. Avec le RFC 9975, Peter Thomassen transforme cette différence…
Histoire d'Internet
Le premier paquet n’était qu’un candidat : comment RTP fit mériter la continuité
Un datagramme peut présenter toutes les apparences de la normalité: version correcte, type de charge connu, longueur cohérente, SSRC inédit. RTP ne lui accordait pourtant pas le droit de créer à lui seul l’histoire d’une source. Il fallait qu’un second paquet transforme une…
Histoire d'Internet
Le repère qui a survécu au chemin : comment NFS a rendu l’identité opaque et la péremption explicite
Dans un système de fichiers distribué, le nom indique où chercher; il ne suffit pas à dire ce que le serveur a trouvé. NFS a confié cette seconde fonction à un « file handle » opaque. Puis le protocole a précisé ce que ce repère devait traverser, ce qui pouvait le faire expirer…
IETF
Paul Hoffman et la copie de la racine qui ne répondait qu’à son propre hôte
Le service décrit par la RFC 8806 possède toute la zone racine, mais il lui est interdit de devenir un service pour le réseau. Il répond au résolveur installé sur sa propre machine, reproduit la racine publique sans la corriger à sa manière, valide les signatures et disparaît du…
Histoire d'Internet
Le compteur a baissé tandis que le trafic montait : comment SNMP a balisé les époques de mesure
Un compteur d’octets peut revenir vers zéro sans que le lien cesse de transporter des données. SNMP a rendu cette situation interprétable en distinguant le bouclage normal du nombre, l’élargissement de la fenêtre d’observation et la rupture déclarée de l’historique mesuré.
Histoire d'Internet
La socket s’est fermée avant la fin de la commande : comment FTP a confié le verdict à la connexion de contrôle
Dans un journal FTP, le silence de la connexion de données ressemble facilement à une conclusion. Les octets ne circulent plus, TCP s’est fermé proprement, le fichier existe. Mais FTP avait réservé le mot de la fin à une autre conversation: celle des commandes et des réponses…
Histoire d'Internet
Le nombre changeait, la session restait : comment SDP sépara identité et révision
Une description multimédia peut changer de codec, d’adresse ou de direction sans annoncer une nouvelle conversation. SDP rendit cette continuité vérifiable en donnant un repère à la session et un autre, distinct, à la révision de sa description.
IETF
Stuart Cheshire et la règle du demi-TTL qui commande le silence
Dans une capture mDNS, la question peut contenir une section « réponse ». Ce paradoxe apparent économise la capacité partagée: l’interrogateur y déclare ce qu’il a encore en cache, et les répondants évitent de le répéter. La RFC 6762 borne ce silence par le temps et par…
Histoire d'Internet
Le hachage qui resta quand les clés changèrent : comment SSH lia l’authentification à une session
Une connexion SSH peut renouveler les clés qui protègent ses paquets sans fermer le terminal ni recréer chaque canal. Pour que cette continuité ne soit pas une simple supposition, le protocole conserva une trace de son premier échange: un hachage que les renouvellements suivants…
Histoire d'Internet
Le nombre qui grandissait à chaque cache : comment HTTP Age mesurait une réponse, pas l’objet
Un document ancien de plusieurs années peut parvenir avec `Age: 120`. Ces deux minutes ne datent ni le texte ni la ressource: elles expriment l’estimation qu’un cache transmet sur une réponse produite ou validée par l’origine. HTTP a ainsi rendu le temps cumulable sans créer de…
Histoire d'Internet
Le bit qui fermait le message : comment ONC RPC redonna des limites au flux TCP
Un appel distant peut être découpé entre dix segments TCP, tandis qu’une seule lecture peut contenir plusieurs appels. La fiabilité conserve l’ordre, pas la ponctuation. ONC RPC ajouta donc une règle minuscule: une longueur pour chaque fragment et un bit qui ne fermait le record…
Histoire d'Internet
Le message arrivé en plusieurs messages : comment MIME a confié le réassemblage au destinataire
Dans le courrier électronique des années 1990, un même objet pouvait rencontrer plusieurs plafonds de taille sans qu’aucun relais ne voie l’ensemble du trajet. MIME n’a pas transformé le réseau en assembleur central: il a fait voyager des messages autonomes, puis donné au…
Histoire d'Internet
La condition qui transformait une plage en totalité : comment HTTP If-Range a gardé les fragments dans une même version
Après une coupure, le client possédait déjà le début d’une représentation. Demander la suite semblait n’être qu’une affaire de position. Mais si la ressource avait changé entre-temps, la même position ouvrait une autre suite d’octets. HTTP a résolu ce doute en donnant à une seule…
Histoire d'Internet
La trace qui grandissait à rebours : comment Path empêchait un relais Usenet de renvoyer l’article
Dans un réseau de diffusion par inondation, reconnaître un doublon ne suffisait pas: les octets avaient déjà fait l’aller-retour. Usenet inscrivit donc dans chaque article une trace modifiable, construite par les relais eux-mêmes, afin d’éviter le renvoi inutile sans transformer…