Verstopfen zu viele Anwendungen die eigene Internetleitung, stellt sich schnell der Wunsch ein, den Netzwerkverkehr besser zu steuern. Dem steht oft die komplizierte Konfiguration entgegen. Trickle ermöglicht einfaches Traffic Shaping ohne Netzwerk-Diplom.

Dass die um eine Leitung konkurrierenden Applikationen aufeinander keine Rücksicht nehmen, haben die anderen Artikel in diesem Schwerpunkt schon erläutert. Was der Administrator dagegen tun kann, auch: Er muss eine feine Steuerung aus- und eingehender Pakete organisieren. Dafür bietet Linux ein ausgefeiltes System, das Traffic Shaping in allen Varianten mit unterschiedlichsten Algorithmen ermöglicht. Wem das alles zu groß, zu aufwändig und zu systemnah ist, der greift zu Trickle (träufeln).

Shaping im Userspace

Trickle [1] verspricht die Traffic-Probleme im Userspace zu lösen. Nicht mal Administratorrechte sind dazu nötig, zum Kompilieren allerdings die Libevent [2]. Im Gegensatz zu anderen Ansätzen braucht Trickle keine Kernelmodule und muss nicht aufwändig konfiguriert werden, einige Parameter genügen.

Trickle bedient sich eines bekannten Mechanismus, um sich zwischen Applikationen und den Netzwerk-Stack zu schieben: »LD_PRELOAD«, eine Umgebungsvariable, die den dynamischen Linker dazu anweist, eine bestimmte Bibliothek zu laden, bevor er auf die Glibc zurückgreift. Damit lassen sich gezielt einzelne Funktionen der Standardlibraries durch eigene überschreiben.

Im Normalfall stellt die Glibc die Netzwerkfunktionen und damit die Schnittstelle zur entsprechenden Kernelfunktionalität bereit. Trickle aber lädt beim Start über »LD_ PRELOAD« eine eigene dynamische Bibliothek, die entsprechende Netzwerkfunktionen enthält, jedoch nur TCP-Funktionen wie »socket()«, (Abbildung 1). Statt auf Funktionen der Glibc greifen Anwendungen nun erst auf die Trickle-Versionen zu, die schließlich die Bandbreitenanpassung vornehmen. Die Trickle-Funktionen ihrerseits rufen die Glibc-Verwandten auf, wenn sie ihre Buchführung erledigt haben. Um an die Originalfunktionen zu kommen, verwendet Trickle die Bibliotheksfunktion »dlopen()«.

Abbildung 1: Die Trickle-Bibliothek ersetzt über »LD_PRELOAD« einige Netzwerkfunktionen der Glibc durch eigene Versionen, die den Datendurchsatz überwachen und regeln.

Weil der beschriebene Mechanismus dynamische Bibliotheken nutzt, funktioniert Trickle nicht mit statischen Binaries. Genauso versagt Trickle bei SUID-Programmen, denn bei denen ist aus Sicherheitsgründen der »LD_PRELOAD«-Mechanismus ausgeschaltet.

Natürlich können auch die restlichen Anwendungen – in der Regel wohl Clients – selbst diesen Mechanismus nicht ohne weiteres benutzen. Deshalb ist es nötig, sie mit dem Programm »trickle« aufzurufen, das das Preloading übernimmt. Ein Limit nur für die Download-Rate des gestarteten Programms anzugeben ist Aufgabe des Trickle-Schalters »-d«:

trickle -d 50 ftp ftp.host.domain

Damit überwacht Trickle, dass die mit »ftp« aufgebaute FTP-Verbindung in Download-Richtung im Durchschnitt unter 50 KBytes/s bleibt. Für den Upload kennt Trickle die Option »-u«. Abbildung 2 zeigt den Verlauf eines Web-Downloads unter Trickles Kontrolle.

Abbildung 2: Trickle reguliert einen Web-Download auf eine durchschnittliche Rate von 50 KBytes/s. Zu Beginn ist die Abweichung vom eingestellten Wert am größten, da sich das System erst einschwingen muss.

Daemon steuert zentral

Andere, gleichzeitig laufende FTP-Programme bleiben von Trickles Eingriffen unberührt. Um den Netzwerkverkehr umfassend zu regulieren, müssen also alle relevanten Programme unter Trickles Kontrolle gestellt werden. Der Daemon »trickled« führt über alle Trickle-Verbindungen Buch und regelt so die Gesamtbandbreite. Auch der Daemon kennt die Parameter »-d« und »-u«:

trickled -d 50 -u 5 -f -N 5

In diesem Fall stehen die Parameter aber für die Gesamtbandbreite der beteiligten Programme. Der obige Befehl setzt also die gesamte Download-Rate auf 50 und die Upload-Rate auf 5 KByte/s fest. Der Parameter »-f« sorgt dafür, dass der Daemon im Vordergrund läuft, »-N 5« lässt ihn alle fünf Sekunden eine Statistik ausgeben. Ohne den Parameter »-d« setzt Trickle Upload- und Downloadrate auf 10 KByte/s. Für dauerhafte Einstellungen liest der Daemon die Konfigurationsdatei »/etc/trickled.conf« (Default) oder die hinter »-c« angegebene.

Läuft der Daemon, nehmen die »trickle«-Instanzen bei ihrem Start mit ihm Kontakt auf (normalerweise über den Unix-Socket »/tmp/.trickled.sock«) und regeln nach seinen Vorgaben ihre jeweiligen Clientprogramme. Bricht die Verbindung zum Server ab, arbeitet »trickle« weiter, vergisst aber die ursprünglichen Vorgaben. Läuft der Server zum Beispiel mit einem Download-Limit von 10 KByte/s, hält ein anschließend gestartetes »trickle wget http://www.server.domain/datei« diese Vorgabe ein. Bricht der Benutzer den Server während des Downloads ab, geht die Rate nach oben.

Dauerhafte Einstellungen in einer Datei

In der Konfigurationsdatei »/etc/trickled.conf« legt der Benutzer auch Prioritäten für einzelne Dienste fest. Dabei stehen niedrige Werte für eine hohe Priorität. Intern ordnet Trickle die Datenpakete in eigenen Warteschlange entsprechend um. Damit bleibt zum Beispiel trotz großer Downloadrate (im Test um die 90 KByte/s) eine interaktive Sitzung mit »ssh« noch gut nutzbar. Eine einfache Variante der Konfigurationsdatei sieht zum Beispiel so aus:

[ssh]
Priority = 1
[www]
Priority = 8

Die Dokumentation sieht für eine ähnliche Konstellation noch die Parameter Time-Smoothing und Length-Smoothing vor, die große Schwankungen der Raten verhindern sollen. Im Gegensatz zu den ihnen entsprechenden Kommandozeilenoption »-d« und »-l« lassen sich die Parameter der Konfigurationsdatei für jeden einzelnen Internetdienst (etwa SSH, FTP, WWW) einstellen:

[ssh]
Priority = 1
Time-Smoothing = 0.1
Length-Smoothing = 2
[www]
Priority = 8
Time-Smoothing = 5
Length-Smoothing = 20

Die Werte geben an, über welchen Zeit- raum (in Sekunden) respektive über wie viele Bytes hinweg Trickle die Anwendungen ungehindert Daten verschicken und empfangen lässt. Zur Übertragung großer Datenmengen sollte man eher größere Werte einstellen, für interaktive Anwendungen kleine. Große Unterschiede bewirkten diese beiden Werte im Test aber nicht. Hier bietet sich also ein weites Feld für eigene Experimente.

Parameter zur Feineinstellung

Prinzipiell kann ein solches System nur bis zu einem gewissen Grad wirksam sein. Ob im Kernel- oder im Userspace: Die Vielzahl der Puffer, die immer schon einige Pakete enthalten, und die dynamische Natur der Netzwerke sind eine natürliche Grenze für Traffic Shaping.

So berechnet Trickle die jeweiligen Raten über ein bestimmtes Zeitintervall. Da die Rate zu Beginn immer klein ist und dann steigt, ist eine Überreaktion in die andere Richtung erst einmal die Folge. Sie steigt weit über den angestrebten Wert (siehe Abbildung 2).

Der Benutzer legt mit »-w« die Breite eines Fensters in Bytes fest, in dem Trickle solche Traffic-Spitzen findet. Allerdings zeigte auch dies im Test wenig Wirkung: Die Unterschiede zur Default-Einstellung (512 Bytes) waren kaum messbar. Auch ohne Feintuning arbeitete Trickle mit den Voreinstellungen recht gut.

Gut für den Heimgebrauch

Trickle erlaubt einzelnen Benutzern die Traffic-Kontrolle eigener Anwendungen. Mit einigen Tricks – Wrapper-Skripte um relevante Programme – wäre auch Mehrbenutzerbetrieb denkbar. Ohne solche Vorkehrungen funktioniert Trickle nur in einem kooperativen Umfeld: Der Benutzer muss jedes Programm extra mit dem Binary »trickle« starten.

Trickle beherrscht nur TCP-Stream-Verbindungen, was aber auf die meisten Traffic-intensiven Dienste zutrifft – dass DNS zum Beispiel nicht unter Trickle-Kontrolle steht, lässt sich verkraften. Wer ohne großen Konfigurationsaufwand auch während des Übertragens großer Datenmengen noch interaktiv arbeiten möchte, findet in Trickle eine passende Lösung.

Auch Webentwickler finden in Trickle einen neuen Helfer. Wer seinen Webbrowser unter Trickles Kontrolle startet, simuliert damit die Bandbreite schmaler Modemleitungen – ideal zum Testen und Optimieren von Websites.