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 mémoire confiée au client : comment les tickets TLS ont déplacé l’état du serveur
Un serveur TLS pouvait cesser de garder un dossier pour chaque visiteur en plaçant les éléments de reprise dans un objet chiffré rendu au client. Ce déplacement a allégé la mémoire locale, mais rendu plus décisifs les clés de ticket, leur durée de vie et le périmètre des machines…
Histoire d'Internet
Deux chemins ne font pas deux destinataires
Une route de secours peut sauver une demande qui n'est pas arrivée. Elle ne donne pas le droit de poser à nouveau la même question à un téléphone qui a déjà répondu. SIP Outbound a dû inscrire cette différence dans la manière même de reconnaître les terminaux enregistrés.
IETF
Eric Vyncke et la sonde qui s’identifie sans devenir digne de confiance
Une équipe réseau ne reçoit pas d’abord l’intention du chercheur, mais un paquet inattendu et l’alerte qu’il a déclenchée. À travers le RFC 9511, Eric Vyncke et ses coauteurs proposent une façon sobre de rendre une sonde joignable et explicable, tout en refusant de confondre…
Histoire d'Internet
Le tiers qu’on ne contactait plus : ce que déplaçait l’agrafage OCSP
Faire vérifier un certificat pouvait obliger le visiteur à ouvrir une autre connexion. L’agrafage OCSP permettait au site de lui remettre une réponse déjà signée. Le détour disparaissait, mais ni l’autorité du signataire ni le travail nécessaire pour garder cette réponse…
Histoire d'Internet
La vraie fiche pouvait rester derrière le cache
Une zone DNS pouvait encore publier de véritables informations sur une machine, tandis qu’un client recevait à leur place une petite fiche fabriquée pour une autre question. Le mécanisme n’avait pas supprimé la fiche originale: il avait occupé sa place dans un cache. Ce risque…
Histoire d'Internet
Le bénéfice était dans la mémoire du voisin
L’émetteur déplaçait les en-têtes; le destinataire devait économiser des copies. Cette répartition inhabituelle du travail explique les encapsulations à en-têtes déportés, dites « trailers », décrites par BSD dans les années 1980. Modifier l’ordre sur le câble ne suffisait…
Histoire d'Internet
Une altitude exacte, mais au-dessus de quoi ?
Inscrire un lieu dans le DNS exigeait davantage que trois nombres. Avec LOC, les concepteurs ont séparé le point représenté, la taille de l’objet et l’incertitude de sa position. Ils ont aussi choisi une surface de référence pour l’altitude. Une carte qui ne garde que l’épingle…
Récits
RIPE RIS a généré l’instantané BGP. Sa livraison a pourtant échoué
L’incident du 25 août ne commence pas par un collecteur de routes à l’arrêt. Selon le RIPE NCC, les fichiers bview de 16 h UTC avaient été générés, mais ils n’ont pas atteint l’archive publique après un basculement. Cette distinction déplace la question: où se termine réellement…
Tendances mondiales des services cloud
Deux fournisseurs reçoivent 38,6 % des courriels de domaines populaires. La vraie inconnue est la reprise
Le DNS public indique où un domaine souhaite recevoir ses messages. Il ne dit rien du temps nécessaire pour déplacer tout ce qui rend cette réception fiable.
Histoire d'Internet
Quand PPPoE a quitté le PC, les huit octets sont restés
Déplacer une session vers la passerelle résidentielle simplifiait la vie des machines du réseau local. Cela déplaçait aussi une limite. L’extension PPP-Max-Payload raconte comment une migration d’accès a rendu nécessaire de distinguer ce que les extrémités annonçaient, ce…
Histoire d'Internet
Des labels dans le message, des labels autour du message : le double voyage d’ICMP
Un message d’erreur peut transporter une pile MPLS comme pièce jointe et emprunter lui-même une encapsulation MPLS pour rentrer. Les nombres se ressemblent; leurs fonctions diffèrent. L’histoire de cette distinction explique ce qu’un traceroute enrichi a réellement gagné: une…
Histoire d'Internet
Un refus pouvait révéler un pair : le Magic-Number de PPP
Dans PPP, un refus d’option peut apporter une information qu’un simple retour de données ne fournit pas: un autre entité a réagi. Cette déduction tient à une obligation réciproque très précise. Elle ne transforme ni un nombre aléatoire en identité, ni une liaison qui répond en…
Histoire d'Internet
Le message que SMTP pouvait oublier sans raccrocher : comment RSET délimita la transaction
Un serveur peut avoir accepté un expéditeur et un destinataire quand le client décide finalement de renoncer au message. `RSET` a donné à SMTP une sortie étroite mais décisive: effacer cette transaction inachevée, en recevoir confirmation, puis continuer sur la même connexion.
Histoire d'Internet
Lire dans un autre ordre : les champs empruntés de DHCP
L’ordre des octets dans un paquet ne donne pas toujours l’ordre dans lequel il faut reconstruire un paramètre. En réutilisant les anciens champs de démarrage, DHCP a conservé leur emplacement mais changé leur fonction. Une déclaration explicite et une règle de lecture commune ont…
Histoire d'Internet
Copier sans comprendre : le pari du NSID dans le DNS
Pour retrouver le serveur qui a produit une réponse DNS, un nom lisible n'est pas toujours le meilleur indice. En 2007, NSID a normalisé le transport d'une suite d'octets que l'usager pouvait transmettre sans savoir la déchiffrer. À condition qu'elle accompagne la bonne réponse.
Histoire d'Internet
Quatre serveurs, deux interprétations : ce que vérifiait le nonce ECN
Une poignée de machines utilisant deux marquages ne suffisait pas à prouver le déploiement d'un protocole. L'histoire du nonce ECN tient dans cette prudence: rendre un retour de congestion vérifiable, sans confondre une discordance avec une faute ni une inscription technique avec…
Histoire d'Internet
Un nom derrière le port 1 : le pari local de TCPMUX
Au lieu de réserver un numéro commun à tout l’Internet pour chaque nouveau service, TCPMUX proposait de demander son nom à l’entrée d’une machine. Cette économie de coordination avait un prix: il fallait savoir exactement où s’arrêtait le répartiteur et où commençait…
Histoire d'Internet
Le bit qui ne pouvait pas maintenir un service en vie : l’impasse de DNS WKS
Un annuaire peut annoncer qu’un serveur devrait répondre. Il ne peut pas le faire répondre. WKS a appris cette différence au DNS en donnant trop de poids à un bit absent.
Histoire d'Internet
La réponse qui ne pouvait nommer que ce qu’un serveur connaissait : pourquoi le DNS a retiré IQUERY
Une ancienne requête DNS se présentait sans question. Elle plaçait déjà un enregistrement de ressource dans la section Answer et demandait au serveur de retrouver les noms auxquels cette valeur appartenait. L’idée semblait rétablir une symétrie: si une interrogation ordinaire va…
Histoire d'Internet
L’accusé qui ne pouvait nommer le paquet arrivé : quand Karn apprit à TCP à refuser une mesure
Deux départs peuvent conduire au même accusé de réception. Un segment a été émis, son délai a expiré, puis les mêmes octets ont été réémis. Quand l’ACK progresse enfin, il confirme la réception du préfixe, mais ne désigne pas l’envoi qui l’a provoqué. L’algorithme de Karn a fait…