Limitazione della larghezza di banda sulla porta Ethernet

Question

Sto scrivendo un'applicazione per l'esecuzione su un server in cui devo essere in grado di impostare la larghezza di banda massima per ciascuna porta Ethernet (ci saranno fino a 6 porte).

Ovviamente posso limitare la larghezza di banda utilizzata dall'applicazione, ma non ho ancora trovato alcuna informazione sulla limitazione della larghezza di banda effettiva della porta Ethernet sul computer.

Questo dovrebbe essere fatto creando un driver per monitorare tutte le porte? Qualcuno potrebbe indicarmi la giusta direzione?

Answer 1

Penso che la cosa più semplice sarebbe quella di creare un dispositivo di output che si possa comporre con il proprio mittente reale che limiterebbe l'output stesso piuttosto che fare casino con la porta ethernet.

Answer 2

Se si ha accesso a una macchina Linux, è facile fare una cosa del genere. In effetti è possibile aggiungere tutti i tipi di problemi di rete per renderlo interessante.

Basta installare due schede di rete e configurare netem per il traffico intermedio. (es. un blip netem nel cavo, aggiungendo menomazioni come ritardo, jitter, larghezza di banda ecc.)

Ecco lo script che uso per testare le prestazioni delle mie app di streaming audio Android passando il traffico di Android attraverso Linux box (con un AP wifi collegato a una delle interfacce).

Aggiunto: Testando le prestazioni del mio App, voglio dire come sarebbe si comportano App su una rete 4G durante la guida (vale a dire un sacco di Jitter). Oppure un caso d'uso in casa con Wi-Fi; cosa succede se tutti in casa decidono di trasmettere video HD in streaming contemporaneamente (ad esempio contesa sull'ampiezza di banda, con molto di perdita di pacchetti).

#!/bin/bash 

ORIGINAL_PATH=$PATH 

#echo $ORIGINAL_PATH 

export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/game" 

#echo $PATH 
CTOSINTERFACE=eth1 # EGRESS interface on Bridge, facing the SERVER 
STOCINTERFACE=eth0 # EGGRES interface on Bridge, facing the CLIENT 

# Client To Server 
CDELAY=$1 
CJITTER=$2 
CLOSS=$3 
CDUPLICATE=$4 
CCORRUPT=$5 
CREORDER=$6 

# Server to Client 
SDELAY=$7 
SJITTER=$8 
SLOSS=$9 
SDUPLICATE=$10 
SCORRUPT=$11 
SREORDER=$12 

# Clear Latency/Loss/Jitter 
/sbin/tc qdisc del root dev $CTOSINTERFACE 2>/dev/null 
/sbin/tc qdisc del root dev $STOCINTERFACE 2>/dev/null 


# Client to Server Impairments (on Bridge) 
qdisc add dev $CTOSINTERFACE root netem delay ${CDELAY}ms ${CJITTER}ms loss $CLOSS% duplicate ${CDUPLICATE}% corrupt ${CCORRUPT} reorder ${CREORDER}% limit 10000000 2>&1 >/dev/null 
qdisc add dev $STOCINTERFACE root netem delay ${SDELAY}ms ${SJITTER}ms loss $SLOSS% duplicate ${SDUPLICATE}% corrupt ${SCORRUPT} reorder ${SREORDER}% limit 10000000 2>&1 >/dev/null 

#$PATH=$ORIGINAL_PATH 
export PATH=$ORIGINAL_PATH 
#echo $PATH 

e chiamare lo script come

#sudo impare_network.sh 100 20 30 0 0 0 0 0 0 0 0 0 0 

questo sarebbe - sul up-link (da client a server) - aggiungere un ritardo di 100 ms, un jitter del 20% (con distribuzione normale) , Perdita di pacchetti del 30%.

Answer 3

In Windows non è generalmente possibile farlo a livello di SO senza software aggiuntivo - il caso d'uso è semplicemente visto come non molto importante, e seriamente: questo è abbastanza corretto. Se ho bisogno di limiti di rete, posso applicarli nel passaggio.

L'eccezione è solo in Hyper-V, dove la versione newwest (nel 2012 R2) può limitare la larghezza di banda in uscita.

In genere, è necessario un software di terze parti su Windows, ma il caso d'uso è DAVVERO spigoloso, perché in genere è un posto molto migliore per mettere quel limite in essere nel prossimo switch superiore.