Comment fonctionnent les backbones Usenet

Un backbone Usenet est l'infrastructure qui reçoit, stocke, indexe et sert les articles Usenet. Il se situe entre le réseau Usenet mondial et l'utilisateur final. Quand vous vous connectez à votre fournisseur et téléchargez un article, cet article est posé quelque part sur un backbone.

Certains fournisseurs exploitent leur propre backbone. Ils possèdent les serveurs, exploitent le stockage, gèrent les connexions de peering et contrôlent tout le cycle de vie de l'article, de l'ingestion à la livraison. Ce sont des fournisseurs Tier-1.

D'autres fournisseurs ne possèdent aucune infrastructure backbone. Ils louent l'accès aux serveurs d'un opérateur Tier-1 et revendent cet accès sous leur propre marque. Ce sont des revendeurs. Le site, les tarifs et le support du revendeur lui appartiennent, mais les articles que vous téléchargez viennent du matériel de quelqu'un d'autre.

La distinction compte parce que les fournisseurs sur le même backbone portent les mêmes articles. Si un article est retiré chez l'un, il disparaît chez tous. Si un article n'a jamais été ingéré par ce backbone au départ, aucun revendeur qui s'y appuie ne l'aura. Notre page sur l'indépendance couvre les implications commerciales. Cette page couvre les implications techniques.

Comprendre les backbones commence par comprendre ce qui arrive à un article, du moment où il est publié au moment où vous le téléchargez.

Étape 1 : publication

Un utilisateur compose un article (message texte ou fichier binaire encodé) dans son lecteur de news et clique sur « publier ». Le lecteur de news se connecte au fournisseur de l'utilisateur via NNTP et envoie l'article avec la commande POST ou IHAVE. Le serveur front-end du fournisseur le reçoit, lui attribue un Message-ID si aucun n'était fourni, et le stocke localement.

Étape 2 : ingestion et indexation

Le système d'ingestion du backbone prend le nouvel article et l'écrit dans le stockage spool. L'article est indexé par Message-ID, newsgroup(s), date et headers. Cet index permet à votre lecteur de news de chercher et de récupérer les articles plus tard. La vitesse et la qualité de ce système d'indexation font partie des choses qui séparent un bon backbone d'un médiocre.

Étape 3 : peering (propagation)

Le backbone propose le nouvel article à ses partenaires de peering. Chaque partenaire consulte son propre index pour voir s'il a déjà un article avec ce Message-ID. Sinon, il accepte l'article et le stocke sur son propre spool. Si oui, il refuse l'offre. Cet échange se produit en continu, des milliers de fois par seconde, entre chaque paire de backbones de peering du réseau. Notre plongée peering couvre les détails techniques de cette négociation au niveau du protocole.

Étape 4 : récupération

Quand vous cherchez ou téléchargez un article, votre lecteur de news envoie une requête au serveur front-end de votre fournisseur. Le front-end cherche l'article dans l'index, le localise sur le stockage spool et vous le renvoie en flux sur votre connexion NNTP. Si SSL est activé (et ça devrait l'être), tout cet échange est chiffré.

Étape 5 : expiration

À un moment donné, un article vieillit au-delà de la fenêtre de rétention du backbone. Le logiciel de spool le marque pour expiration et libère finalement le stockage. Chez NewsDemon, cette fenêtre est actuellement de 5 695+ jours et elle grandit d'un jour chaque jour. Notre système de filtrage assisté par IA supprime également le rebut, le spam et le sporge avant qu'ils n'atteignent le spool, ce qui nous permet de garder l'archive propre et le stockage efficace.

Un backbone Usenet n'est pas une seule machine. C'est un système distribué avec des couches distinctes, chacune prenant en charge une partie différente de la charge de travail.

Serveurs front-end (transit et lecture)

Ce sont ceux auxquels votre lecteur de news se connecte. Ils gèrent l'authentification NNTP (votre nom d'utilisateur et votre mot de passe), vos connexions, vos requêtes de recherche et de téléchargement, et vous renvoient les articles en flux. Les serveurs front-end sont optimisés pour les connexions simultanées et le débit. Un backbone chargé peut avoir derrière une seule adresse DNS comme news.newsdemon.com des dizaines de serveurs front-end en équilibrage de charge.

NewsDemon exploite des serveurs front-end dans trois régions géographiques : US East (Virginie), US West (Californie) et UE (Pays-Bas). Cela vous donne, où que vous soyez, un point de connexion proche, ce qui réduit la latence et améliore la vitesse de téléchargement.

Serveurs back-end (stockage spool)

Ils contiennent les données d'articles proprement dites. Le spool est l'endroit où vivent les pétaoctets. Les backbones modernes utilisent un stockage à plusieurs niveaux : des disques NVMe rapides pour les articles les plus récents et les plus demandés (le niveau « chaud ») et des disques haute densité pour les contenus plus anciens (le niveau « froid »). Certains opérateurs utilisent également des archives sur bandes pour des contenus très anciens. NewsDemon utilise des jeux de spools NVMe qui délivrent une latence article inférieure à 3 ms sur les contenus chauds.

Le logiciel de spool est le cerveau de l'opération. Il décide où écrire les nouveaux articles, comment les indexer pour une récupération rapide, quand déplacer les articles du stockage chaud vers le froid, et quand les expirer. Différents opérateurs de backbones font tourner des logiciels de spool différents. Certains utilisent des solutions open source comme Diablo ou Cyclone. D'autres font tourner des systèmes propriétaires qu'ils ont construits en interne. Le logiciel de spool est le plus grand facteur de différenciation de performance d'un backbone, et c'est ce que vous ne voyez jamais en tant qu'utilisateur final.

Serveurs de feeder (peering)

Une couche séparée gère l'échange d'articles avec les partenaires de peering. Les serveurs de feeder maintiennent des connexions persistantes avec d'autres backbones et négocient le flux constant de nouveaux articles dans les deux sens. Un serveur de feeder chargé peut traiter des millions d'offres d'articles par heure. Nous couvrons cela en détail sur la page peering.

Le spool est le cœur de tout backbone. C'est le système de stockage physique qui contient chaque article que le backbone a ingéré et qui n'a pas encore expiré. À l'échelle d'un backbone Usenet moderne qui traite ~500 To de nouveau contenu par jour, l'ingénierie du spool n'est pas triviale.

Échelle

Un backbone avec 5 000+ jours de rétention stocke une quantité stupéfiante de données. Le chiffre exact dépend de la proportion du flux entrant que l'opérateur conserve (certains filtrent agressivement, d'autres stockent presque tout) et de la façon dont la déduplication est gérée. NewsDemon utilise un filtrage assisté par IA pour éliminer le rebut et les doublons avant que les articles n'atteignent le spool, ce qui maintient notre stockage plus propre et plus efficace qu'une approche « tout stocker ».

Stockage à plusieurs niveaux

Tous les articles n'ont pas besoin de la même vitesse d'accès. Un message d'hier est demandé des milliers de fois. Un message de 2015 est demandé une fois par mois. Les opérateurs de backbones en tirent parti en hiérarchisant le stockage. Les articles récents et populaires vont sur des disques NVMe ou SSD rapides. Les articles plus anciens migrent vers des disques haute densité optimisés pour la lecture séquentielle. La transition entre les niveaux est gérée par le logiciel de spool en fonction des schémas d'accès et de l'âge.

Les jeux de spools NVMe de NewsDemon délivrent une latence de récupération inférieure à 3 ms sur les articles chauds. Les articles froids sur disques rotatifs sont plus lents mais restent parfaitement fonctionnels pour le téléchargement. L'expérience utilisateur est que le neuf se télécharge à pleine vitesse et l'ancien un peu plus lentement, mais tout est là.

Logiciel de spool

Le logiciel qui gère le spool est sans doute l'élément le plus important de la pile technologique d'un backbone. Il gère les écritures d'articles (depuis l'ingestion), les lectures (depuis les requêtes utilisateur), l'indexation (par Message-ID, newsgroup, date), la hiérarchisation (le déplacement d'articles entre les couches de stockage) et l'expiration (la suppression des articles au-delà de la fenêtre de rétention). Les options open source populaires incluent Diablo (plus ancien, éprouvé) et Cyclone (plus récent, plus rapide sur le matériel moderne). Certains opérateurs de backbones, y compris parmi les plus grands, font tourner des systèmes de spool entièrement propriétaires, ajustés à leur matériel et à leur charge de travail spécifiques.

Aucun backbone unique ne voit chaque article publié sur Usenet. Les articles se propagent entre backbones par le peering, un système d'accords bilatéraux d'échange d'articles entre opérateurs.

Le processus fonctionne à peu près ainsi : le backbone A reçoit un nouvel article (soit d'un utilisateur qui publie directement, soit d'un autre partenaire de peering). Le backbone A vérifie si le backbone B a déjà cet article en envoyant un lot de Message-IDs. Le backbone B répond avec ceux qu'il veut. Le backbone A envoie les articles demandés. Le backbone B fait de même dans l'autre sens. Cela se produit en continu à travers des dizaines de relations de peering simultanément.

Les accords de peering varient. Certains sont en feed complet (les deux côtés échangent tout). Certains sont partiels (seulement certaines hiérarchies de newsgroups). Certains sont unidirectionnels. La qualité et l'étendue des relations de peering d'un backbone influent directement sur son inventaire d'articles. Un backbone avec un peering solide sur de nombreux partenaires aura un pool d'articles plus complet qu'un autre avec un peering limité.

C'est aussi pourquoi les backbones indépendants portent des articles différents. Même avec un bon peering, aucune paire de backbones n'a un contenu identique. Des articles sont publiés sur un backbone et peuvent ne pas se propager à un autre en raison du timing, du filtrage ou d'un peering sélectif. Cette différence est ce qui rend utile de combiner des fournisseurs sur des backbones différents. Pour le détail technique complet, voyez notre plongée peering.

Un opérateur de backbone (fournisseur Tier-1) exploite sa propre infrastructure : serveurs front-end, stockage spool, serveurs de feeder, connexions de peering. Il contrôle chaque partie du cycle de vie de l'article.

Un revendeur ne possède pas d'infrastructure backbone. Il achète l'accès aux serveurs d'un opérateur Tier-1, généralement dans le cadre d'un accord de gros, et revend cet accès sous sa propre marque. Le revendeur s'occupe du marketing, de la facturation et du support, mais les articles viennent du spool d'un autre.

Du point de vue de l'utilisateur, l'expérience avec un revendeur peut être parfaitement correcte. La vitesse, la rétention et la complétion que vous voyez sont celles du backbone, livrées sous le branding du revendeur. Le problème surgit quand vous comparez des fournisseurs et ne réalisez pas que deux (ou cinq, ou dix) d'entre eux revendent le même back-end. Ils auront des prix et des sites différents, mais des pools d'articles identiques.

La question « sur quel backbone est ce fournisseur ? » est plus utile que « combien de jours de rétention ce fournisseur revendique-t-il ? ». Notre page sur l'indépendance couvre l'angle de la propriété, et notre guide de sélection de fournisseur parcourt le cadre de décision complet.

Nous exploitons notre propre backbone sur trois régions de serveurs. Le montage est simple, mais coûteux à construire et à entretenir.

Serveurs front-end en US East (Virginie), US West (Californie) et UE (Pays-Bas), équilibrés en charge derrière news.newsdemon.com. Chaque connexion est chiffrée en SSL 256 bits. 50 connexions simultanées par compte.

Stockage spool NVMe pour les articles chauds (récupération sous 3 ms). Disques haute densité pour le stockage froid. Le filtrage assisté par IA supprime spam, rebut et sporge avant que les articles n'atteignent le spool. La déduplication d'articles garde l'archive propre.

Connexions de peering avec plusieurs flux en amont. Nous avons aussi récupéré une grande collection d'articles issus des archives sur bandes magnétiques remontant à plus de 20 ans. Ces articles n'ont jamais été migrés par les autres opérateurs et sont exclusifs à notre spool.

Détenu de manière indépendante. K&L Technologies, Inc. Aucune maison mère, aucun lien de propriété partagé avec d'autres marques Usenet, aucune entité extérieure qui décide du contenu ou des prix.