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 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.
Histoire d'Internet
Le retrait qui voyageait comme une nouvelle : comment Usenet confiait l’annulation à chaque site
Le même article de contrôle arrive sur trois serveurs. Le premier possède déjà le message visé et le retire. Le deuxième refuse d’exécuter la demande. Le troisième reçoit l’annulation avant le message original et conserve son Message-ID pour bloquer son arrivée tardive. Usenet ne…
Histoire d'Internet
La suppression qui attendait l’au revoir : comment POP3 séparait la marque de l’effacement irréversible
Le serveur vient de répondre `+OK message deleted`, mais la liaison tombe avant `QUIT`. À la connexion suivante, le message est toujours là. Ce retour n’annule pas la réponse précédente: dans POP3, `DELE` posait une marque réversible, tandis que l’effacement appartenait à un…
Histoire d'Internet
Les octets qui attendaient une permission : comment les littéraux IMAP ont déplacé le coût du refus
Un client IMAP pouvait annoncer `{11}`, terminer sa ligne, puis garder onze octets en réserve. Le nombre était connu, la connexion était ouverte, mais le serveur n’avait pas encore invité la suite. Cette invitation tenait dans un `+`. L’histoire de LITERAL+ puis de LITERAL…
Histoire d'Internet
Le point de reprise qui n'était pas un nombre d'octets : comment FTP apprit à continuer un fichier
Dans le premier mécanisme de reprise de FTP, le signe égal ne reliait pas deux nombres. La réponse `110 MARK ssss = rrrr` rapprochait deux descriptions locales: la position que l'émetteur saurait retrouver et celle que le récepteur venait de rendre durable. Cette précaution…
Histoire d'Internet
La requête vide qui énumérait tout le monde : quand Finger fit de la présence humaine une réponse réseau
Une connexion au port 79, puis seulement un retour chariot et un saut de ligne: dans NAME/FINGER, ce presque-rien signifiait « donnez-moi toutes les personnes présentes sur cette machine ». La réponse pouvait situer un terminal, mesurer l'inactivité et reproduire le message…
Histoire d'Internet
La seconde connexion demandait à qui appartenait la première : comment IDENT a borné l'autorité d'un nom d'utilisateur
Le nom `alice` peut être exact, utile et néanmoins insuffisant. Dans IDENT, il est fourni par la machine d'où vient une connexion TCP, après une seconde connexion en sens inverse et une recherche dans l'état local. Ce nom peut aider deux administrateurs à retrouver le même…
Histoire d'Internet
Le paquet d'heure qui ne donnait pas l'heure : comment le Kiss-o'-Death de NTP a rendu le refus exécutable
Un serveur saturé peut se taire. Mais le silence ne dit pas au client s'il doit changer de source, cesser tout accès ou simplement ralentir. NTP a donc recyclé une réponse familière: avec Stratum 0 et quatre caractères dans le Reference Identifier, elle ne mesure plus le temps…
Histoire d'Internet
Le fichier n’est pas venu du port 69 : comment TFTP a lié chaque transfert à ses propres extrémités
Une requête de lecture se dédouble en chemin. Le serveur la reçoit deux fois et répond par deux premiers blocs, chacun depuis un port différent. Le client ne doit ni les additionner ni abandonner le transfert déjà choisi: le premier couple accepté reste valable, le second reçoit…
Histoire d'Internet
La question à laquelle SMTP apprit à ne pas répondre : comment VRFY sépara l’acceptation du courrier de la divulgation d’annuaire
En 1982, une machine distante pouvait demander `VRFY Smith` à un serveur SMTP et recevoir le nom complet de Fred Smith ainsi que sa boîte aux lettres. La commande facilitait le diagnostic parce qu’elle rendait l’annuaire visible. Elle devint risquée pour exactement la même…
Histoire d'Internet
Le serveur a rendu le nouveau nom : comment UIDPLUS a rendu les mutations IMAP vérifiables
Deux logiciels consultaient la même boîte. Le premier avait marqué un message pour suppression; le second revenait après plusieurs heures hors ligne et voulait achever sa propre liste de suppressions. Avec `EXPUNGE`, les intentions se confondaient: toute marque `\Deleted` pouvait…
Histoire d'Internet
La commande qui cédait la connexion : pourquoi SMTP remplaça TURN par ETRN
Un site appelait son fournisseur et demandait à la ligne de se retourner. Le serveur pouvait alors renvoyer le courrier en attente sur la même connexion. Cette économie cachait un transfert de pouvoir: le correspondant avait prononcé un nom de machine, sans prouver qu’il avait le…
Histoire d'Internet
L’échéance que le relais ne pouvait remettre à zéro : le temps transmissible de SMTP DELIVERBY
Un délai n’est pas une voie rapide. RFC 2852 permit à l’expéditeur d’indiquer ce qui devait se produire lorsque le temps manquerait, sans lui donner le pouvoir d’ordonner la file d’un autre opérateur.