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.

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…

Histoire d'Internet
Le masque que le silence fit mal deviner : comment ICMP amorça un sous-réseau
Une machine vient de démarrer. Elle possède une adresse IPv4, mais ignore encore où finit son voisinage direct. Elle diffuse une demande de masque et n’entend rien. L’ancien protocole lui permet alors d’adopter provisoirement le masque non sous-réseauté de sa classe d’adresse…

Histoire d'Internet
L’étiquette qu’un pare-feu ne pouvait effacer sans risque : l’option de sécurité IPv4 en réseau fermé
Un équipement intermédiaire retire une option IPv4 qu’il juge archaïque. Le paquet continue sa route, mais le geste n’est pas neutre: dans un réseau à plusieurs niveaux de sécurité, l’étiquette disparue pouvait commander l’admission du contenu. À l’arrivée, l’absence peut…

IETF
Le paquet marqué avant d’être perdu : la longue controverse de l’ECN sur la congestion
L’ECN a introduit un geste presque paradoxal dans le réseau: prévenir de la congestion sans détruire le paquet qui porte l’avertissement. Derrière deux bits d’en-tête se trouve pourtant une chaîne de responsabilités beaucoup plus vaste, du gestionnaire de file au destinataire, du…

Histoire d'Internet
Le test qui réussissait sans rien dire : ce que Discard pouvait réellement prouver
Le poste d’essai envoie un flux connu vers le port 9. Aucun accusé ne revient, aucun compteur n’est annoncé, aucun message ne clôt l’expérience. C’est exactement le comportement demandé par RFC 863. La difficulté n’est donc pas d’obtenir une réponse, mais d’empêcher le silence…

Histoire d'Internet
L’horloge sans grammaire : pourquoi Daytime s’adressait aux humains
Le port 13 répond, la ligne est lisible et le serveur ferme proprement la connexion. Pourtant, rien dans la norme ne permet d’affirmer que le prochain serveur placera l’année, le mois ou le fuseau au même endroit. Avec Daytime, réussir l’échange ne signifiait pas obtenir une date…

Histoire d'Internet
Les réponses une pour une qui ne s'arrêtaient plus : la boucle formée par Echo et Chargen
Un troisième entité a organisé l'échange, puis s'est tu. Chargen répond à l'adresse d'Echo; Echo renvoie les octets à Chargen; chaque réponse justifie la suivante. Pris séparément, aucun service ne produit plus d'un datagramme. Ensemble, ils fabriquent une cause qui se renouvelle…

Histoire d'Internet
L’octet nul qui donnait un sens au retour chariot : la ponctuation invisible de Telnet
Le caractère le moins spectaculaire du flux pouvait être le plus décisif. Après un retour chariot, `NUL` ne faisait rien sur l’imprimante virtuelle; pourtant, il disait exactement ce que `LF` ne devait pas faire. Grâce à ce silence explicite, deux machines différentes pouvaient…

Histoire d'Internet
Le serveur qui changeait de métier en pleine connexion : comment NNTP rendit les rôles explicites
Le client interroge un serveur NNTP et découvre des commandes de transit entre pairs. Il envoie `MODE READER`, puis redemande les capacités: le même canal présente désormais un service de lecture. Le point de contact n’a pas changé; le mandat de la session, si.
