Frage Wie kann ich langlebige Verbindungen erkennen und für die Gestaltung markieren?


Ich möchte TCP-Verbindungen erkennen, die seit mehr als einer Minute geöffnet sind (oder für mehr als N Bytes oder M-Pakete), so dass ich sie als Massenverkehr ("Downloads") klassifizieren und sie priorisieren kann.

Kann ich langlaufende Streams mit iptables / netfilter / conntrack erkennen und sie für das Shaping durch tc markieren?

Ich dachte, ich könnte die TCP-Sequenznummer als Maß für die Länge eines Streams verwenden, aber leider fängt es nicht bei Null an! Vielleicht könnte die Verbindungsverfolgung mit netfilter / conntrack die korrekte Sequenznummer oder die Gesamtanzahl von Bytes und die Dauer der Verbindung bestimmen und auswählen, ob das Paket markiert werden soll.

(Ich könnte auch erwähnen, dass ich das mache Eintritt Verwenden 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 Austrittzum Beispiel für einen Webserver auf einer begrenzten Verbindung, der Downloads herunterstufen möchte, um kleine Anfragen zu beschleunigen.)


Update: Mit conntrackd kann ich eine Liste von Verbindungen sehen, und wie lange jedes einzelne 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 sind! Also markiere ich alle Verbindungen zur Begrenzung, sogar die, die fertig sind.
  • Das Setzen von Marken in Conntrack scheint keine Markierungen in den Paketen zu setzen (soweit tc dies sehen kann). (Das liegt nicht nur daran, dass conntrack die Pakete nach ifb0 sieht: Ich kann auch keine Markierungen auf den Ausgangspaketen sehen.) Also habe ich gerade neue Filter zur Begrenzung hinzugefügt, was auf lange Sicht alles andere als ideal ist.
  • conntrack (d) sagt mir nicht, wie viel Bandbreite jede Verbindung benutzt hat. So kann ich nicht intermittierende (z. B. iOS-Socket-) Sitzungen von starken Downloads unterscheiden. (In jedem Fall ist das ein schwieriges Problem: Wenn wir bereits 5 Downloads haben und ein neuer Download beginnt, wie können wir dann sagen, dass er versucht zu fluten? Er wird nicht annähernd die maximale Rate erreichen.)

Irgendwelche Vorschläge mit dem oben genannten würden geschätzt.

(Auf der anderen Seite, selbst wenn ich die Downloads nicht korrekt klassifizieren kann, hat die Verwendung von tfb, um eingehende Daten auf 80% meiner maximalen Downrate zu beschränken, das Überfließen der Verbindung verhindert und neue Verbindungen viel einfacher eingerichtet als zuvor.)


1
2018-06-07 17:48


Ursprung


Ok, ich habe eine Reihe von Tools gefunden, die detaillierte Informationen zum Netzwerkverkehr anzeigen können (z. B. zeigt jnettop einige Informationen, die conntrackd nicht enthält). debianhelp.de/networktools2.htm  Ich kann vielleicht meinen Klassifikationsdämon mit einem von ihnen verbessern. - joeytwiddle


Antworten:


Die Lebenserwartung und tatsächliche Langlebigkeit einer Verbindung hat eine NULL-Beziehung, ob eine Verbindung speziell geformt werden soll oder nicht.

Einige Beispiele:

SSH, möglicherweise langlebig, Minuten, Stunden, Tage, Wochen, sogar Monate. Immer noch hohe Priorität, um auf Benutzerinteraktion reagieren zu können.

Bittorrent (oder ähnliche Protokolle), nach dem Zufallsprinzip gelebt, einige für Sekunden, dann getrennt, andere für Minuten oder Stunden, dann getrennt. Wenige mehr als einen Tag zu einer Zeit.

Zusammenfassung: Die Länge einer Verbindung hat NICHTS damit zu tun, ob die Verbindung "bulk" ist oder nicht, und ob die Verbindung als Bulk behandelt werden soll oder nicht.

Nicht unbedingt direkt verwandt, aber nützlich:

Wenn Traffic Shaping verwendet wird, ist der Download-Verkehr hilfreich oder schädlich?


2
2018-04-17 00:30



Ich wünschte, ich könnte dir zustimmen, aber wenn ich kombinieren die Langlebigkeit mit der Gesamtzahl der Bytes, die über diese Verbindung übertragen werden, dann kenne ich die Rate und kann langlebige Downloads von kurzlebigen HTTP-Anfragen und langlebigen SSH-Sitzungen unterscheiden. Meine endgültige Lösung verwendet eine modifizierte Version von jnettop und hat in den letzten 9 Monaten gut genug für mich gearbeitet, aber ich befürchte, dass ich es noch nicht geschafft habe, es zu veröffentlichen! - joeytwiddle