Come posso rilevare connessioni di lunga durata e contrassegnarle per la modellatura


1

Vorrei rilevare le connessioni TCP aperte da più di un minuto (o per più di N byte o pacchetti M), in modo da poterle classificare come traffico di massa ("download") e deselezionarle.

Posso rilevare flussi di lunga durata con iptables / netfilter / conntrack e contrassegnarli per la modellazione mediante TC?

Ho pensato di poter usare il "numero sequenza" TCP come misura della lunghezza di un flusso, ma sfortunatamente non inizia da zero! Forse il tracciamento della connessione con netfilter / conntrack potrebbe determinare il numero di sequenza corretto o il numero totale di byte e la durata della connessione e scegliere se contrassegnare il pacchetto.

(Potrei anche menzionare che lo sto facendo su ingress usando un'interfaccia virtuale ifb0. Attualmente sto usando code tbf (con sfq) per limitare i dati a bassa priorità. Indipendentemente da ciò, qualsiasi soluzione potrebbe essere applicata anche a egress , ad esempio per un server web su una connessione limitata che desidera deselezionare le priorità dei download per accelerare le piccole richieste.)


Aggiornamento: Usando conntrackd sono in grado di vedere un elenco di connessioni e da quanto tempo è iniziata ciascuna. Ho iniziato a utilizzare questo elenco per rilevare coppie IP / porte che voglio limitare (dopo 60 secondi). Tuttavia ci sono numerosi problemi:

  • conntrack (d) non sembra cancellare prontamente le connessioni dalla lista quando hanno chiuso! Quindi finisco per contrassegnare tutte le connessioni per limitare, anche quelle che hanno terminato.
  • L'impostazione dei segni in conntrack non sembra impostare segni nei pacchetti (per quanto tc può vedere). (Questo non è solo perché conntrack vede i pacchetti dopo ifb0: Non riesco nemmeno a vedere alcun segno sui pacchetti di uscita.) Quindi ho appena aggiunto nuovi filtri a tc per la limitazione, che a lungo termine è tutt'altro che ideale.
  • conntrack (d) non mi dice quanta larghezza di banda ha usato ogni connessione. Quindi non riesco a distinguere sessioni intermittenti (ad es. Iosocket) da download pesanti. (In ogni caso, questo è un problema difficile: se abbiamo già 5 download e inizia un nuovo download, come possiamo dire che sta cercando di inondare? Non raggiungerà da nessuna parte vicino alla velocità massima.)

Eventuali suggerimenti con quanto sopra sarebbero apprezzati.

(Il lato positivo, anche se non riesco a classificare correttamente i download, semplicemente usando tfb per limitare i dati in entrata all'80% del mio downrate massimo ha impedito il sovraccarico della connessione e ha permesso alle nuove connessioni di stabilire molto più facilmente di prima.)


Ok, ho trovato un sacco di strumenti in grado di visualizzare informazioni dettagliate sul traffico di rete (ad es. Jnettop mostra alcune informazioni che Conntrackd non ha). debianhelp.co.uk/networktools2.htm Potrei essere in grado di migliorare il mio demone classificatore usando uno di essi.
Joeytwiddle,

Risposte:


2

L'aspettativa di vita e l'effettiva longevità di una connessione hanno una relazione ZERO sull'opportunità o meno di stabilire una connessione in modo speciale.

Qualche esempio:

SSH, possibilmente di lunga durata, minuti, ore, giorni, settimane, persino mesi. Ancora bisogno di alta priorità per rispondere all'interazione dell'utente.

Bittorrent (o protocolli simili), vissuto casualmente, alcuni per secondi poi disconnesso, altri per minuti o ore, quindi disconnesso. Pochi che durano più di un giorno alla volta.

Riepilogo: la lunghezza di una connessione non ha NIENTE a che fare con se la connessione è "bulk" o meno e se la connessione deve essere trattata o meno come bulk.

Non necessariamente direttamente correlato, ma utile:

Utilizzando il traffic shaping, limitare il traffico di download è utile o dannoso?


Vorrei poter essere d'accordo con te, ma se combino la longevità con il numero totale di byte trasferiti su quella connessione, allora conosco la velocità e posso distinguere i download di lunga durata da richieste HTTP di breve durata e sessioni SSH di lunga durata . La mia soluzione finale utilizza una versione modificata di jnettop e ha funzionato abbastanza bene per me negli ultimi 9 mesi, ma temo di non essere ancora riuscita a pubblicarla!
joeytwiddle,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.