Wie Usenet-Backbones funktionieren

Ein Usenet-Backbone ist die Infrastruktur, die Usenet-Artikel empfängt, speichert, indiziert und ausliefert. Er sitzt zwischen dem globalen Usenet-Netzwerk und dem Endnutzer. Wenn Sie sich mit Ihrem Anbieter verbinden und einen Artikel herunterladen, liegt dieser Artikel irgendwo auf einem Backbone.

Manche Anbieter betreiben einen eigenen Backbone. Ihnen gehören die Server, sie betreiben den Speicher, verwalten die Peering-Verbindungen und kontrollieren den gesamten Lebenszyklus eines Artikels von der Einspielung bis zur Auslieferung. Das sind Tier-1-Anbieter.

Andere Anbieter besitzen keine Backbone-Infrastruktur. Sie mieten Zugang zu den Servern eines Tier-1-Betreibers und verkaufen diesen Zugang unter eigener Marke. Das sind Reseller. Die Website, die Preise und der Support des Resellers gehören ihm, aber die Artikel, die Sie herunterladen, kommen von fremder Hardware.

Der Unterschied zählt, weil Anbieter auf demselben Backbone dieselben Artikel führen. Wird ein Artikel bei einem entfernt, ist er bei allen weg. Wurde ein Artikel vom Backbone nie eingespielt, hat ihn kein Reseller auf diesem Backbone. Unsere Seite zur Unabhängigkeit behandelt die wirtschaftlichen Folgen. Diese Seite behandelt die technischen.

Backbones zu verstehen beginnt damit zu verstehen, was mit einem Artikel vom Moment seiner Veröffentlichung bis zum Moment Ihres Downloads passiert.

Schritt 1: Veröffentlichung

Ein Nutzer verfasst einen Artikel (Textbeitrag oder kodierte Binärdatei) in seinem Newsreader und drückt auf „Posten". Der Newsreader verbindet sich über NNTP mit dem Anbieter des Nutzers und sendet den Artikel mit dem POST- oder IHAVE-Befehl. Der Front-End-Server des Anbieters empfängt ihn, vergibt eine Message-ID, falls keine angegeben war, und speichert ihn lokal.

Schritt 2: Einspielung und Indizierung

Das Einspielsystem des Backbones nimmt den neuen Artikel und schreibt ihn in den Spool-Speicher. Der Artikel wird nach Message-ID, Newsgroup(s), Datum und Headern indiziert. Dieser Index ermöglicht es Ihrem Newsreader, Artikel später zu suchen und abzurufen. Geschwindigkeit und Qualität dieses Indizierungssystems sind einer der Punkte, die einen guten Backbone von einem mittelmäßigen unterscheiden.

Schritt 3: Peering (Weiterverbreitung)

Der Backbone bietet den neuen Artikel seinen Peering-Partnern an. Jeder Partner prüft in seinem Index, ob er bereits einen Artikel mit dieser Message-ID hat. Falls nicht, nimmt er den Artikel an und speichert ihn auf seinem eigenen Spool. Falls doch, lehnt er das Angebot ab. Dieser Austausch läuft ständig, tausende Male pro Sekunde, zwischen jedem Paar von Peering-Backbones im Netzwerk. Unser Peering-Deep-Dive erklärt die technischen Details dieser Aushandlung auf Protokollebene.

Schritt 4: Abruf

Wenn Sie nach einem Artikel suchen oder ihn herunterladen, sendet Ihr Newsreader eine Anfrage an den Front-End-Server Ihres Anbieters. Das Front-End sucht den Artikel im Index, lokalisiert ihn auf dem Spool-Speicher und liefert ihn über Ihre NNTP-Verbindung zurück. Wenn SSL aktiviert ist (und das sollte es sein), ist dieser gesamte Austausch verschlüsselt.

Schritt 5: Verfall

Irgendwann altert ein Artikel über das Vorhaltezeit-Fenster des Backbones hinaus. Die Spool-Software markiert ihn zum Verfall und gibt schließlich den Speicher frei. Bei NewsDemon liegt dieses Fenster derzeit bei 5.695+ Tagen und wächst täglich um eins. Unser KI-gestütztes Filtersystem entfernt außerdem Müll, Spam und Sporge, bevor er überhaupt auf den Spool gelangt, und hält so das Archiv sauber und den Speicher effizient.

Ein Usenet-Backbone ist keine einzelne Maschine. Er ist ein verteiltes System mit klar getrennten Schichten, die jeweils unterschiedliche Teile der Arbeit erledigen.

Front-End-Server (Transit- und Reader-Server)

Das sind die Server, mit denen sich Ihr Newsreader verbindet. Sie übernehmen die NNTP-Authentifizierung (Ihren Benutzernamen und Ihr Passwort), verwalten Ihre Verbindungen, verarbeiten Such- und Download-Anfragen und streamen Artikel zurück. Front-End-Server sind auf gleichzeitige Verbindungen und Durchsatz optimiert. Ein stark frequentierter Backbone hat unter einer einzigen DNS-Adresse wie news.newsdemon.com möglicherweise Dutzende Front-End-Server im Load-Balancing.

NewsDemon betreibt Front-End-Server in drei geografischen Regionen: US East (Virginia), US West (Kalifornien) und EU (Niederlande). Das gibt Ihnen, egal wo Sie sind, einen nahegelegenen Einstiegspunkt, was Latenz reduziert und Download-Geschwindigkeit verbessert.

Back-End-Server (Spool-Speicher)

Hier liegen die eigentlichen Artikeldaten. Der Spool ist der Ort, an dem die Petabytes wohnen. Moderne Backbones nutzen gestuften Speicher: schnelle NVMe-Laufwerke für die aktuellsten und am häufigsten angefragten Artikel (die „Hot"-Schicht) und hochdichte Festplatten für ältere Inhalte (die „Cold"-Schicht). Manche Betreiber nutzen außerdem Bandarchive für sehr alten Inhalt. NewsDemon verwendet NVMe-Spool-Sets, die auf heißen Inhalten eine Artikel-Latenz unter 3 ms liefern.

Die Spool-Software ist das Gehirn des Ganzen. Sie entscheidet, wo neue Artikel abgelegt werden, wie sie für schnellen Abruf indiziert werden, wann Artikel von der heißen auf die kalte Speicherebene verschoben werden und wann sie verfallen. Verschiedene Backbone-Betreiber setzen unterschiedliche Spool-Software ein. Manche verwenden Open-Source-Lösungen wie Diablo oder Cyclone. Andere betreiben proprietäre Systeme, die sie selbst gebaut haben. Die Spool-Software ist der größte einzelne Unterschied in der Backbone-Leistung und ist das, was Sie als Endnutzer nie zu sehen bekommen.

Feeder-Server (Peering)

Eine separate Schicht übernimmt den Austausch von Artikeln mit Peering-Partnern. Feeder-Server halten dauerhafte Verbindungen zu anderen Backbones und handeln den ständigen Fluss neuer Artikel in beide Richtungen aus. Ein stark frequentierter Feeder-Server kann Millionen von Artikelangeboten pro Stunde verarbeiten. Wir behandeln das im Detail auf der Peering-Seite.

Der Spool ist der Kern jedes Backbones. Er ist das physische Speichersystem, das jeden Artikel hält, den der Backbone eingespielt hat und der noch nicht verfallen ist. Bei der Größenordnung eines modernen Usenet-Backbones, der ~500 TB neuer Inhalte pro Tag verarbeitet, ist Spool-Engineering nicht trivial.

Größenordnung

Ein Backbone mit 5.000+ Tagen Vorhaltezeit speichert eine gewaltige Datenmenge. Die genaue Zahl hängt davon ab, wie viel vom eingehenden Feed der Betreiber aufbewahrt (manche filtern aggressiv, andere speichern fast alles) und wie die Deduplizierung behandelt wird. NewsDemon nutzt KI-gestütztes Filtern, um Müll und Duplikate herauszunehmen, bevor Artikel auf den Spool gelangen, was unseren Speicher sauberer und effizienter hält als ein „Alles speichern"-Ansatz.

Gestufter Speicher

Nicht alle Artikel brauchen dieselbe Zugriffsgeschwindigkeit. Ein Beitrag von gestern wird tausende Male angefragt. Ein Beitrag von 2015 wird einmal im Monat angefragt. Backbone-Betreiber nutzen das, indem sie den Speicher stufen. Aktuelle und beliebte Artikel landen auf schnellen NVMe- oder SSD-Laufwerken. Ältere Artikel wandern auf hochdichte Festplatten, die auf sequentielles Lesen optimiert sind. Den Übergang zwischen den Stufen verwaltet die Spool-Software anhand von Zugriffsmustern und Alter.

Die NVMe-Spool-Sets von NewsDemon liefern auf heißen Artikeln eine Abruf-Latenz unter 3 ms. Kalte Artikel auf rotierenden Festplatten sind langsamer, aber für Downloads immer noch absolut funktional. Die Nutzererfahrung ist, dass Neues mit voller Geschwindigkeit lädt und Altes etwas langsamer, aber alles ist da.

Spool-Software

Die Software, die den Spool verwaltet, ist wohl das wichtigste Element im Technologie-Stack eines Backbones. Sie übernimmt Artikel-Schreibvorgänge (aus der Einspielung), Lesezugriffe (aus Nutzeranfragen), Indizierung (nach Message-ID, Newsgroup, Datum), Stufung (Verschieben von Artikeln zwischen Speicherebenen) und Verfall (Entfernen von Artikeln jenseits des Vorhaltezeit-Fensters). Beliebte Open-Source-Optionen sind Diablo (älter, bewährt) und Cyclone (neuer, schneller auf moderner Hardware). Manche Backbone-Betreiber, einschließlich einiger der größten, setzen vollständig proprietäre Spool-Systeme ein, die auf ihre spezifische Hardware und ihre Workloads abgestimmt sind.

Kein einzelner Backbone sieht jeden im Usenet veröffentlichten Artikel. Artikel verbreiten sich zwischen Backbones durch Peering, ein System bilateraler Austauschvereinbarungen zwischen Betreibern.

Der Prozess läuft ungefähr so: Backbone A erhält einen neuen Artikel (entweder durch direkte Veröffentlichung eines Nutzers oder von einem anderen Peering-Partner). Backbone A prüft, ob Backbone B diesen Artikel bereits hat, indem er eine Charge von Message-IDs sendet. Backbone B antwortet mit denen, die er haben will. Backbone A sendet die angeforderten Artikel. Backbone B macht dasselbe in die andere Richtung. Das passiert dauerhaft über Dutzende Peering-Beziehungen gleichzeitig.

Peering-Vereinbarungen variieren. Manche sind Full-Feed (beide Seiten tauschen alles aus). Manche sind teilweise (nur bestimmte Newsgroup-Hierarchien). Manche sind einseitig. Qualität und Breite der Peering-Beziehungen eines Backbones beeinflussen direkt seinen Artikelbestand. Ein Backbone mit starkem Peering über viele Partner hat einen vollständigeren Artikelpool als einer mit begrenztem Peering.

Das ist auch der Grund, warum unabhängige Backbones unterschiedliche Artikel führen. Selbst bei gutem Peering haben keine zwei Backbones identische Inhalte. Artikel werden an einen Backbone geschickt und breiten sich aus Gründen wie Timing, Filtern oder selektivem Peering möglicherweise nicht zu einem anderen aus. Dieser Unterschied macht das Kombinieren von Anbietern auf unterschiedlichen Backbones sinnvoll. Die vollständige technische Aufschlüsselung finden Sie in unserem Peering-Deep-Dive.

Ein Backbone-Betreiber (Tier-1-Anbieter) betreibt seine eigene Infrastruktur: Front-End-Server, Spool-Speicher, Feeder-Server, Peering-Verbindungen. Er kontrolliert jeden Teil des Artikel-Lebenszyklus.

Ein Reseller besitzt keine Backbone-Infrastruktur. Er kauft Zugang zu den Servern eines Tier-1-Betreibers, meist über eine Großhandelsvereinbarung, und verkauft diesen Zugang unter eigener Marke. Der Reseller kümmert sich um Marketing, Abrechnung und Support, aber die Artikel kommen vom Spool eines anderen.

Aus Sicht eines Nutzers kann die Erfahrung mit einem Reseller durchaus in Ordnung sein. Geschwindigkeit, Vorhaltezeit und Completion, die Sie sehen, sind die des Backbones, ausgeliefert über das Branding des Resellers. Das Problem entsteht, wenn Sie Anbieter vergleichen und nicht merken, dass zwei (oder fünf oder zehn) davon denselben Backend weiterverkaufen. Sie haben unterschiedliche Preise und unterschiedliche Websites, aber identische Artikelpools.

Die Frage „auf welchem Backbone läuft dieser Anbieter?" ist nützlicher als „wie viele Tage Vorhaltezeit behauptet dieser Anbieter zu haben?". Unsere Seite zur Unabhängigkeit behandelt die Eigentumsperspektive, und unser Leitfaden zur Anbieterwahl erklärt den vollständigen Entscheidungsrahmen.

Wir betreiben unseren eigenen Backbone über drei Serverregionen. Der Aufbau ist geradlinig, aber in Aufbau und Wartung teuer.

Front-End-Server in US East (Virginia), US West (Kalifornien) und EU (Niederlande), per Load-Balancing hinter news.newsdemon.com. Jede Verbindung ist mit 256-Bit-SSL verschlüsselt. 50 gleichzeitige Verbindungen pro Konto.

NVMe-Spool-Speicher für heiße Artikel (Abruf unter 3 ms). Hochdichte Festplatten für Cold Storage. KI-gestütztes Filtern entfernt Spam, Müll und Sporge, bevor Artikel auf den Spool gelangen. Artikel-Deduplizierung hält das Archiv sauber.

Peering-Verbindungen mit mehreren Upstream-Feeds. Wir haben außerdem eine große Sammlung von Artikeln aus Magnetband-Archiven wiederhergestellt, die über 20 Jahre zurückreichen. Diese Artikel wurden von anderen Betreibern nie migriert und sind exklusiv auf unserem Spool.

Unabhängig im Besitz. K&L Technologies, Inc. Keine Muttergesellschaft, kein gemeinsames Eigentum mit anderen Usenet-Marken, keine externe Instanz, die über Inhalte oder Preise entscheidet.