Zusammenfassung

  • RFC 2398 ordnete zwölf TCP-Testwerkzeuge nach Zweck, Funktionsweise, Automatisierung, Verfügbarkeit und benötigter Umgebung, statt „Testen“ als austauschbare Einzelhandlung zu behandeln.
  • Aktive Störung, Messung eines laufenden Stacks, Paketmitschnitt, nachträgliche Analyse und grafische Darstellung lieferten verschiedene Belege; weder eine Kurve noch ein Durchsatzwert bewiesen allein Korrektheit, Sicherheit oder Anwendungserfolg.

Das TCP-Labor des Jahres 1998 bestand nicht aus einem einzigen Messgerät. Dbs koordinierte mehrere Übertragungen und schrieb ASCII-Protokolle. Dummynet brachte Warteschlangen, Bandbreitengrenzen und Verzögerung in einen tatsächlich laufenden Stack ein. NIST Net machte aus einem Linux-System einen „selektiv schlechten“ Router. Andere Werkzeuge injizierten Fehler, konstruierten Pakete, untersuchten Mitschnitte oder trugen Sequenznummern über der Zeit auf. RFC 2398 stellte zwölf davon zusammen, ohne ihre Rollen gleichzusetzen.

Schon das Schema des Katalogs war eine Beweisdisziplin. Jeder Eintrag musste Name, Kategorie, Beschreibung, Automatisierungsgrad, Verfügbarkeit, erforderliche Umgebung und Referenzen nennen. Ein Werkzeugname konnte damit nicht mehr die Methode ersetzen. Derselbe Graph blieb mehrdeutig, wenn nicht feststand, wie der Verkehr erzeugt wurde, welcher Stack lief, wo gemessen wurde und welche Annahmen die Analyse prägten.

Die drei Kategorien hießen funktionale Korrektheit, Leistung und Belastung. Sie hingen zusammen, waren aber nicht austauschbar. Ein Stack konnte Daten schnell übertragen und dennoch eine vorgeschriebene Reaktion verfehlen. Er konnte einen einfachen Austausch bestehen und unter Last versagen. Ein Belastungsergebnis zeigte möglicherweise eine Schwäche, ohne schon zu klären, ob sie in der Implementierung, im Messpfad oder im Versuchsaufbau lag.

Dummynet, NIST Net und Orchestra griffen früh in die Kette ein. Dummynet simulierte endliche Warteschlangen, Bandbreite und Verzögerung zwischen Schichten eines realen Stacks. NIST Net verzögerte, verwarf, duplizierte oder begrenzte Pakete und konnte feste oder verteilte Verzögerungen sowie gleichmäßigen oder überlastungsabhängigen Verlust erzeugen. Orchestra fügte eine skriptbare Fehlerschicht ein, die Nachrichten verwerfen, verzögern, umordnen, vervielfachen, verändern oder neu einführen konnte. Ob das Verhalten richtig war, musste der Mensch weiterhin aus der Spur ableiten.

Tcpanaly setzte später an. Es prüfte tcpdump-Spuren mit kodiertem Wissen über viele Implementierungen, versuchte den Grund jedes gesendeten Pakets zu erklären und eine Verhaltensabweichung von einem wahrscheinlichen Messfehler zu unterscheiden. RFC 2398 räumte ein, dass das Werkzeug schwer einzuordnen war: Es profilierte Verhalten, statt einen festen Test auszuführen. Tcptrace berechnete Neuübertragungen, Umlaufzeiten, Fenster und Durchsatz; Tracelook und Xplot machten erfasste Variablen sichtbar. Sie halfen, ein Ereignis zu sehen, erzeugten es aber nicht.

Netperf, TReno und Ttcp markierten eine weitere Grenze. Ein Leistungswert hing davon ab, was den Verkehr erzeugte und wessen TCP-Verhalten darin steckte. TReno taktete UDP- oder ICMP-Pakete so, wie es ein konformes staukontrolliertes TCP mit SACK tun könnte, um den Pfad unabhängig vom TCP der Endsysteme zu messen. Damit beantwortete es eine andere Frage, nicht jede Frage besser.

Der Katalog blieb hinsichtlich seiner Autorität bescheiden. Die Werkzeuge waren der TCP Implementer’s Working Group gemeldet worden; die Liste war nicht vollständig. Die Autoren prüften die damalige Verfügbarkeit. Sie versprachen weder dauerhafte Pflege noch heutige Kompatibilität oder allgemeine Eignung.

Der Sicherheitsabschnitt zog eine noch härtere Grenze. Manche Werkzeuge konnten schädliche Pakete oder Denial-of-Service-Situationen erzeugen. Manche verlangten fremden Kernelcode oder Root-Rechte. Paketmitschnitte konnten fremde Post und Dateien offenlegen. Trotzdem bewertete keines der Werkzeuge Sicherheit „in irgendeiner Weise oder Form“. Ein Netz stören zu können bedeutete nicht, seine Sicherheit beurteilen zu können.

Der Graph war deshalb nicht der Test. Er war eine Darstellung nahe dem Ende einer längeren Beweiskette: gewähltes Werkzeug, Umgebung, gesetzte oder beobachtete Bedingung, Implementierungsstand, Verkehr, Mitschnitt, Berechnung, Visualisierung und menschliche Deutung. Fehlt ein Glied, wird eine saubere Linie zur überzeugenden Anekdote. Bleiben alle erhalten, kann das Ergebnis genau sagen, was geschah, ohne mehr zu behaupten, als der Versuch wissen konnte.

Quellen