Trafic entrant à limitation de débit

Je n'ai jamais vraiment compris s'il était possible ou non de limiter le trafic entrant . Je me rends compte qu'il n'y a pas de méthode directe permettant de contrôler le taux d'envoi de paquets du serveur distant (sauf si vous contrôlez les deux points de terminaison), mais en tenant compte de cette limitation, comment les gestionnaires de téléchargement me permettent-ils de définir avec succès les limites de vitesse de téléchargement ?

Existe-t-il un lien entre le démarrage lent du protocole TCP et le trafic entrant à limitation de débit? Est-il possible d'utiliser les méthodes décrites par slow-start pour limiter artificiellement le taux d'envoi de paquets par l'expéditeur?

Comme considération supplémentaire, il convient de noter que le serveur sur lequel j'aimerais implémenter la mise en forme du trafic établit la connexion PPPoE elle-même et agit comme un routeur pour le reste du réseau.

Mise à jour: les réponses ont jusqu'à présent donné une bonne vue d'ensemble des questions que j'ai posées, mais je ne sais toujours pas comment les gestionnaires de téléchargement sont en mesure de limiter le trafic entrant, et plus précisément, s'il est possible de mettre en œuvre une stratégie similaire sur un Boîte de passerelle Linux.

Les gestionnaires de téléchargement fonctionnent très probablement comme expliqué dans le papier d'entretien .

Un processus utilisant des sockets BSD peut effectuer sa propre limitation de débit. Pour la limitation en amont, l'application peut le faire en limitant simplement le taux de données qui sont écrites sur un socket. De même, pour la limitation en aval, une application peut limiter le débit de données qu'elle lit à partir d'un socket. Cependant, la raison pour laquelle cela fonctionne n'est pas immédiatement évidente. Lorsque l'application néglige de lire certaines données d'un socket, ses tampons de réception de socket se remplissent. Cela entraînera à son tour le TCP récepteur à annoncer une fenêtre de réception plus petite (rwnd), créant une contre-pression sur la connexion TCP sous-jacente, limitant ainsi son flux de données. Finalement, cet effet «goutte à goutte» permet de limiter le débit de bout en bout. Selon la mise en mémoire tampon dans toutes les couches de la pile réseau, cet effet peut prendre un certain temps à se propager.

Si vous avez parfois besoin de limiter le débit d'un seul programme sur un système UNIX, une solution simple est délicate . La mise en forme du trafic réel, comme vous le feriez sur une passerelle, peut être effectuée avec tc. Ceci est documenté au Chapitre 9. Disciplines de mise en file d'attente pour la gestion de la bande passante du HOWTO Linux Advanced Routing & Traffic Control.

Dans le cas d'un modem 56k contre une ligne DSl à 4 Mbps, il n'y a (généralement) aucune mise en forme qui fait la différence de vitesse, c'est juste une différence dans la vitesse de la liaison.

La raison pour laquelle il est difficile de façonner le trafic entrant est qu'il n'y a pas de tampon dans le support de transmission. Soit vous acceptez les bits entrants, soit ils sont perdus. Pour le trafic qui est sur le point de quitter une interface, vous pouvez mettre en mémoire tampon et réorganiser les paquets autant que vous le souhaitez (ou, au moins jusqu'à la mémoire tampon disponible dans le périphérique).

Pour les protocoles qui ont une couche au-dessus de TCP (je ne sais pas si c'est le cas pour les torrents), ce serait une simple question de stimulation des demandes de données supplémentaires. Sinon, l'application devrait communiquer avec le système d'exploitation, pour retarder l'acquittement des paquets. La plupart des protocoles basés sur UDP auront, par nécessité, une logique ACK / resend dans le protocole spécifique à l'application, donc à ce stade, il est trivial de les rythmer.

Une voie possible serait de façonner le trafic Internet du côté LAN de votre routeur DSL, car à ce moment-là, vous façonneriez un port de sortie.

Je ne peux pas expliquer pourquoi vous n'avez trouvé aucune solution qui permette de façonner les données entrantes (et je n'en connais pas du haut de ma tête), mais quant à la façon dont l'expéditeur sait à quelle vitesse le récepteur peut recevoir des données:

La conception de base de TCP / IP est que pour chaque paquet que la source envoie à la destination, elle doit attendre que la destination réponde (avec un ACKpaquet) en disant qu'elle a reçu le paquet.

Donc, si vous avez un expéditeur à 4 Mbit / s et un récepteur à 56 Kbit / s, l'expéditeur doit alors s'asseoir et attendre entre les envois de paquets pour que le récepteur réponde à chaque paquet (il y a quelques détails techniques pour réduire cette surcharge, mais la prémisse tient toujours sur un résumé niveau).

Alors, que se passe-t-il si l'expéditeur envoie déjà 56 Kbps de données et essaie ensuite d'en envoyer un peu plus?

Le paquet est perdu. (Eh bien, potentiellement en file d'attente dans le tampon d'un commutateur, mais lorsque cela se remplit, le paquet est perdu). Depuis que le paquet s'est perdu, le récepteur ne le reçoit jamais, et donc n'envoie jamais de ACKpaquet. Étant donné que l'expéditeur ne reçoit jamais ce ACKpaquet (car il n'a jamais été envoyé, mais il peut également être perdu ou il peut y avoir une interruption du réseau), l'expéditeur doit renvoyer le paquet supplémentaire. Il s'assoit et essaie de renvoyer le paquet jusqu'à ce qu'il passe et que la ACKréponse lui revienne.

Donc, pour récapituler, une fois que l'expéditeur a maximisé la bande passante du récepteur, il doit s'arrêter et renvoyer le paquet suivant encore et encore jusqu'à ce qu'il y ait suffisamment de bande passante disponible pour qu'il puisse passer. Cela réduit efficacement la vitesse d'envoi au maximum auquel le client peut recevoir. (Et il existe des méthodes d'optimisation pour réduire le nombre de fois où un paquet doit être renvoyé dans ce cas, où l'expéditeur ralentit chaque fois qu'il doit renvoyer un paquet, mais cela dépasse le cadre de cette description simplifiée.

Vous pouvez le faire avec une interface ifb.

Avec une interface ifb, vous pouvez router le flux d'entrée de eth0 (ou autre) vers la sortie dans ifb0 (par exemple), et y appliquer les règles de limite.

Vérifiez cette URL de la Linux Foundation: http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

Et ces scripts qui limitent la bande passante entrante et sortante: https://github.com/rfrail3/misc/blob/master/tc/traffic-control.sh

Découvrez Wondershaper: http://lartc.org/wondershaper/

Concernant le trafic entrant:

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.

utiliser UFW (Uncomplicated Fire Wall) http://ubuntuforums.org/showthread.php?t=1260812

Ce fil montre un exemple simple que les IP par défaut avec 6 hits dans les 30 secondes sont refusés:

sudo ufw limit ssh/tcp

Également une commande plus «avancée» avec des valeurs spécifiées pour le temps et le nombre de hits

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