Limitazione del traffico in entrata

Non ho mai capito bene se è possibile limitare il traffico in entrata o meno . Mi rendo conto che non esiste un metodo diretto per controllare la velocità di invio dei pacchetti del server remoto (a meno che tu non abbia il controllo di entrambi gli endpoint), ma tenendo conto di questa limitazione, come esattamente i gestori dei download mi consentono di impostare con successo i limiti di velocità di download ?

Esiste un collegamento tra il traffico in entrata TCP ad avvio lento e il limite di velocità? È possibile utilizzare i metodi descritti da slow-start per limitare artificialmente la velocità di invio dei pacchetti da parte del mittente?

Come ulteriore considerazione, va notato che il server su cui vorrei implementare il traffic shaping stabilisce la connessione PPPoE stessa e funge da router per il resto della rete.

Aggiornamento: le risposte finora hanno fornito una giusta panoramica delle domande che ho posto, ma ancora non so come i gestori di download siano in grado di limitare il traffico in entrata e, più specificamente, se sia possibile implementare una strategia simile su un Scatola gateway Linux.

Molto probabilmente i gestori dei download funzionano come spiegato nel documento di approfondimento .

Un processo che utilizza socket BSD può eseguire il proprio limite di velocità. Per la limitazione a monte, l'applicazione può farlo semplicemente limitando la velocità dei dati scritti su un socket. Allo stesso modo, per la limitazione a valle, un'applicazione può limitare la velocità di dati che legge da un socket. Tuttavia, il motivo per cui funziona non è immediatamente ovvio. Quando l'applicazione trascura di leggere alcuni dati da un socket, i suoi buffer di ricezione socket si riempiono. Questo a sua volta farà sì che il TCP ricevente pubblicizzi una finestra ricevente più piccola (rwnd), creando una contropressione sulla connessione TCP sottostante limitando così il suo flusso di dati. Alla fine questo effetto "gocciolante" raggiunge la limitazione della frequenza end-to-end. A seconda del buffering in tutti i livelli dello stack di rete, questo effetto potrebbe richiedere del tempo per propagarsi.

Se di tanto in tanto bisogno di tasso-limite di un unico programma su un sistema UNIX, una soluzione semplice è rivolo . La modellazione del traffico reale, come si farebbe su un gateway, può essere eseguita con tc. Questo è documentato nel Capitolo 9. Discipline di accodamento per la gestione della larghezza di banda del Linux Advanced Routing & Traffic Control HOWTO.

Nel caso di un modem a 56k rispetto a una linea DSl a 4 Mbps, non c'è (di solito) alcuna modellatura che fa la differenza di velocità, è solo una differenza nella velocità del collegamento.

Il motivo per cui è difficile modellare il traffico in entrata è che non esiste buffer nel supporto di trasmissione. Accettate i bit in arrivo o vengono persi. Poiché il traffico sta per lasciare un'interfaccia, è possibile bufferizzare e riordinare i pacchetti quanto si desidera (o, almeno fino alla memoria buffer disponibile nel dispositivo).

Per i protocolli che hanno uno strato sopra TCP (non so se sia il caso dei torrent), sarebbe una semplice questione di stimolare le richieste per ulteriori dati. Altrimenti, l'applicazione dovrebbe comunicare con il sistema operativo, per ritardare l'ACK dei pacchetti. La maggior parte dei protocolli basati su UDP avrà, per necessità, la logica ACK / rinvio nel protocollo specifico dell'app, quindi a quel punto è al limite del banale per stimolarli.

Un possibile percorso sarebbe quello di modellare il traffico da Internet sul lato LAN del router DSL, poiché a quel punto, ti saresti modellato su una porta di uscita.

Non posso rispondere al motivo per cui non hai trovato soluzioni che consentano di modellare i dati in arrivo (e non ne conosco nessuno in cima alla mia testa), ma quanto a come il mittente sa quanto velocemente il destinatario può ricevere i dati:

Il design di base di TCP / IP è che per ogni pacchetto che l'origine invia alla destinazione, deve attendere che la destinazione risponda (con un ACKpacchetto) dicendo che ha ricevuto il pacchetto.

Quindi, se hai un mittente da 4 Mbps e un ricevitore da 56 Kbps, il mittente deve sedersi e attendere tra l'invio dei pacchetti affinché il destinatario risponda a ciascun pacchetto (ci sono alcuni dettagli tecnici per ridurre questo sovraccarico, ma la premessa si mantiene comunque su un abstract livello).

Quindi cosa succede se il mittente sta già inviando 56Kbps di dati e quindi prova a inviarne un po 'di più?

Il pacchetto si perde. (Bene, potenzialmente in coda nel buffer di uno switch, ma quando si riempie, il pacchetto si perde). Poiché il pacchetto si è perso, il destinatario non lo riceve mai e quindi non invia mai un ACKpacchetto. Poiché il mittente non riceve mai questo ACKpacchetto (perché non è mai stato inviato, ma potrebbe anche essere perso o potrebbe esserci un'interruzione della rete), il mittente è tenuto a inviare nuovamente il pacchetto aggiuntivo. Si siede e tenta di rinviare il pacchetto fino a quando non viene superato e la ACKrisposta torna a esso.

Quindi, per ricapitolare, una volta che il mittente ha esaurito la larghezza di banda del destinatario, deve fermarsi e rinviare il pacchetto successivo più e più volte fino a quando non c'è abbastanza larghezza di banda disponibile per farla passare. Ciò riduce efficacemente la velocità di invio al massimo che il client può ricevere. (E ci sono metodi di ottimizzazione per ridurre il numero di volte in cui un pacchetto deve essere reinviato in questo caso, in cui sostanzialmente il mittente rallenta ogni volta che deve rinviare un pacchetto, ma questo va oltre lo scopo di questa descrizione semplificata.

Puoi farlo con un'interfaccia ifb.

Con un'interfaccia ifb, puoi instradare il flusso di ingresso di eth0 (o qualunque altra cosa) all'uscita in ifb0 (per esempio), e applicare lì le regole del limite.

Controlla questo URL della Linux Foundation: http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

E questi script che limitano l'arrivo e l'outcoming del bandwight: https://github.com/rfrail3/misc/blob/master/tc/traffic-control.sh

Dai un'occhiata a Wondershaper: http://lartc.org/wondershaper/

Per quanto riguarda il traffico in entrata:

This is slightly trickier as we can't really influence how fast the internet
ships us data. We can however drop packets that are coming in too fast,
which causes TCP/IP to slow down to just the rate we want. Because we don't
want to drop traffic unnecessarily, we configure a 'burst' size we allow at
higher speed.

Now, once we have done this, we have eliminated the downstream queue totally
(except for short bursts), and gain the ability to manage the upstream queue
with all the power Linux offers.

usa UFW (Muro di fuoco semplice) http://ubuntuforums.org/showthread.php?t=1260812

Questo thread mostra un semplice esempio che vengono negati i valori predefiniti su IP con 6 hit entro 30 secondi:

sudo ufw limit ssh/tcp

Anche un comando più "avanzato" con valori specificati per il tempo e il conteggio dei colpi

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP