Ich möchte TCP-Verbindungen erkennen, die länger als eine Minute (oder länger als N Bytes oder M Pakete) offen waren, damit ich sie als Massenverkehr („Downloads“) klassifizieren und herabstufen kann.
Kann ich mit iptables/netfilter/conntrack lang laufende Streams erkennen und sie zur Formung durch tc markieren?
Ich dachte, ich könnte die TCP-Sequenznummer als Maß für die Länge eines Datenstroms verwenden, aber leider beginnt sie nicht bei Null! Vielleicht könnte die Verbindungsverfolgung mit Netfilter/Conntrack die richtige Sequenznummer oder die Gesamtzahl der Bytes und die Dauer der Verbindung ermitteln und entscheiden, ob das Paket markiert werden soll.
(Ich könnte auch erwähnen, dass ich dies mache aufEintrittmit einer virtuellen ifb0-Schnittstelle. Ich verwende derzeit TBF-Warteschlangen (mit SFQ), um Daten mit niedriger Priorität zu begrenzen. Unabhängig davon könnte jede Lösung auch angewendet werden aufAusgang, beispielsweise für einen Webserver mit eingeschränkter Verbindung, der Downloads herabstufen möchte, um kleine Anfragen zu beschleunigen.)
Update: Mit conntrackd kann ich eine Liste der Verbindungen sehen und wie lange es her ist, dass jede einzelne Verbindung initiiert wurde. Ich habe begonnen, diese Liste zu verwenden, um IP/Port-Paare zu erkennen, die ich begrenzen möchte (nach 60 Sekunden). Es gibt jedoch eine Reihe von Problemen:
- conntrack(d) scheint Verbindungen nicht sofort aus der Liste zu löschen, wenn sie geschlossen wurden! Daher markiere ich am Ende alle Verbindungen zur Begrenzung, auch diejenigen, die beendet wurden.
- Das Setzen von Markierungen in Conntrack scheint keine Markierungen in den Paketen zu setzen (soweit tc das sehen kann). (Das liegt nicht nur daran, dass Conntrack die Pakete nach ifb0 sieht: Ich kann auch keine Markierungen in ausgehenden Paketen sehen.) Ich habe also gerade neue Filter zu tc hinzugefügt, um dies zu begrenzen, was auf lange Sicht alles andere als ideal ist.
- conntrack(d) sagt mir nicht, wie viel Bandbreite jede Verbindung verbraucht hat. Ich kann also nicht zwischen zeitweiligen (z. B. iOSocket-)Sitzungen und umfangreichen Downloads unterscheiden. (Das ist auf jeden Fall ein schwieriges Problem: Wenn wir bereits 5 Downloads haben und ein neuer Download beginnt, wie können wir dann erkennen, dass er versucht, zu fluten? Er wird nicht einmal annähernd die maximale Rate erreichen.)
Alle Vorschläge zu den oben genannten Punkten sind willkommen.
(Die gute Nachricht ist: Auch wenn ich die Downloads nicht richtig klassifizieren kann, kann ich durch die einfache Verwendung von tfb zur Begrenzung eingehender Daten auf 80 % meiner maximalen Downloadrate eine Überlastung der Verbindung verhindern und neue Verbindungen viel einfacher als zuvor herstellen.)
Antwort1
Die Lebenserwartung und tatsächliche Lebensdauer einer Verbindung hat NICHTS damit zu tun, ob eine Verbindung speziell geformt werden sollte oder nicht.
Einige Beispiele:
SSH, möglicherweise langlebig, Minuten, Stunden, Tage, Wochen, sogar Monate. Benötigt immer noch hohe Priorität, um auf Benutzerinteraktionen reagieren zu können.
Bittorrent (oder ähnliche Protokolle) waren zufällig aktiv, manche für Sekunden, dann wurde die Verbindung getrennt, andere für Minuten oder Stunden, dann wurde die Verbindung getrennt. Nur wenige hielten länger als einen Tag am Stück.
Zusammenfassung: Die Länge einer Verbindung hat NICHTS damit zu tun, ob es sich bei der Verbindung um eine „Bulk“-Verbindung handelt oder nicht und ob die Verbindung als Bulk-Verbindung behandelt werden soll oder nicht.
Nicht unbedingt direkt verwandt, aber nützlich:
Ist die Begrenzung des Downloadverkehrs durch Traffic Shaping hilfreich oder schädlich?