En termes TCP / IP, comment fonctionne un limiteur de vitesse de téléchargement dans un bureau?

Supposons qu'un bureau de personnes, ils veulent limiter les téléchargements HTTP à un maximum de 40% de bande passante de leur vitesse de connexion Internet afin qu'il ne bloque pas le reste du trafic.

Nous disons "ce n'est pas pris en charge dans votre pare-feu", et ils disent que la ligne inévitable "nous pouvions le faire avec notre Netgear / DLink / DrayTek".

En y réfléchissant, un téléchargement est comme ceci:

HTTP GET request
Server sends file data as TCP packets
Client acknowledges receipt of TCP packets
Repeat until download finished.

La vitesse est déterminée par la vitesse à laquelle le serveur vous envoie des données et la vitesse à laquelle vous les reconnaissez.

Donc, pour limiter la vitesse de téléchargement, vous avez deux choix:

1) Demandez au serveur de vous envoyer des données plus lentement - et je ne pense pas qu'il existe de fonctionnalité de protocole pour demander cela en TCP ou HTTP.

2) Reconnaissez les paquets plus lentement en limitant votre vitesse de téléchargement, et ruinez également votre vitesse de téléchargement.

Comment les appareils font-ils cette limitation? Existe-t-il une méthode standard?

TCP lui-même implémente le contrôle de congestion.

Ces limiteurs de débit jetteront simplement les paquets au-delà de la limite. TCP gère cela, garantissant que tous les paquets arrivent et arrivent tous dans l'ordre; le client n'ACK pas pour les paquets abandonnés, et ils sont renvoyés par le serveur.

La pile TCP du serveur renverra les paquets, et il rappellera également un peu son débit d'envoi, car il suppose qu'il y a une congestion entre lui et le client. Cela accélérera jusqu'à ce que le limiteur de débit supprime à nouveau les paquets, etc.

La meilleure description que j'ai jamais entendue qui donnait un sens à la méthode de limitation inhérente de TCP était hors d'un podcast Security Now récent . Pour citer Steve Gibson:

Donc, par accord universel, TCP étant ce protocole très intelligent, il fait ce qu'on appelle un «démarrage lent». Il est généralement autorisé à envoyer un certain nombre de paquets sans accusé de réception. Donc, l'idée étant, faisons bouger les choses ici. Et généralement, ce nombre est deux. Et donc quand TCP démarre, il peut envoyer deux paquets, l'un après l'autre. Sans que le premier soit reconnu, il enverra le second. Mais alors ça attend. Et puis la règle de limitation est que nous permettons au nombre de paquets non acquittés d'augmenter d'une unité pour chaque accusé de réception que nous recevons.

Alors réfléchissons à ça. Nous permettons d'augmenter le nombre de paquets non acquittés de un pour chaque accusé de réception que nous recevons. Nous envoyons donc d'abord deux paquets comme point de départ convenu. Ils sont reconnus. Nous avons donc notre première reconnaissance. Nous nous permettions d'en envoyer deux. Maintenant, avec la réception de ce premier accusé de réception, nous l'augmentons d'un à trois. Nous pouvons donc maintenant envoyer trois paquets supplémentaires sans autre accusé de réception. Lorsqu'un accusé de réception revient pour tout ce que nous avons envoyé auparavant, nous passons à quatre. C'est ce qu'on appelle la «fenêtre de congestion». Ce n'est pas une fenêtre qui est jamais envoyée sur la ligne, c'est-à-dire que ce n'est pas comme la fenêtre de réception, qui est 16 bits de l'en-tête TCP qui nous dit combien de données nous pouvons envoyer à l'avance. Celui-ci est - c'est une fenêtre. Il'

Si nous continuons d'augmenter le nombre de paquets non acquittés que nous sommes autorisés à envoyer d'un par chaque fois que nous recevons un accusé de réception, à un moment donné, nous allons atteindre une limite. Et la beauté de ce système est qu'il va, alors que nous commençons à envoyer des paquets plus rapidement que le lien le plus faible, littéralement le lien, entre les routeurs, à un moment donné, nous trouvons le point où le lien le plus faible se rompt. Il supprime les paquets que nous essayons d'envoyer parce que nous essayons de les envoyer trop rapidement. Les accusés de réception de l'autre extrémité s'arrêtent donc parce que les données ne passent plus.

Et ce que fait TCP, c'est s'il n'a pas reçu - et cela varie selon les stratégies. Au fil du temps, la stratégie, la stratégie réelle d'évitement de la congestion a beaucoup varié. Il y a des noms comme Tahoe et Reno, et tout un tas d'autres que vous verrez si vous faites des recherches sur Google et Wikipedia, qui précisent exactement quel est le comportement. Mais l'idée est que, lorsque l'expéditeur se rend compte que ses données ne passent plus parce qu'il manque des accusés de réception, il réduit rapidement son taux d'envoi. En règle générale, il le divise en deux. Ainsi, il la redimensionne considérablement, puis recommence à l'augmenter.

Donc, essentiellement, cela signifie que la perte de paquets est la fonction de signalisation pour «Nous ne pouvons pas envoyer les données plus rapidement» et que les expéditeurs TCP à chaque extrémité d'une connexion, partout sur Internet, sont toujours en quelque sorte - ils » essaie d'aller plus vite que la vitesse maximale disponible entre les deux points de terminaison, c'est-à-dire le lien le plus faible, où qu'il se trouve, et ils le poussent toujours à la limite. Donc, étant donné qu'il y a un point quelque part qui est plus faible que leur capacité à envoyer des paquets, ils vont le trouver parce qu'ils vont pomper les paquets. Tant qu'il y a des données à envoyer et qu'ils ont une connexion à large bande passante, l'expéditeur augmentera le taux d'envoi, c'est-à-dire le nombre de paquets en attente, les paquets autorisés à être présents à la volée en guise de remerciements. reviens, maintient agressivement ce nombre vers le haut jusqu'à ce qu'il le pousse trop loin. Ensuite, il recule beaucoup, puis recommence.

C'est donc ce qui se passe réellement entre les connexions TCP qui sont, comme, probablement, je ne sais pas quel pourcentage, mais le plus gros pourcentage du trafic sur Internet passe par des connexions TCP. Tous nos systèmes d'exploitation dans le noyau, dans la soi-disant pile TCP, ont ces compteurs. Et lorsque nous envoyons un fichier, lorsque nous téléchargeons un gros fichier ou que nous recevons une page Web, le serveur à l'autre bout fait la même chose. Il pousse, sur une base de connexion individuelle, autant de paquets qui n'ont pas encore été reconnus comme il peut, augmentant le taux de paquets jusqu'à ce qu'il atteigne le point où il commence à échouer ou à bégayer. Ensuite, il recule, pour permettre aux choses de récupérer, puis recommence à fonctionner.

Et donc cela finit par être une sorte de système d'auto-étranglement qui, compte tenu des contraintes, je veux dire, il semble vraiment un peu génial et grossier. "

Donc, pour limiter la vitesse de téléchargement, vous avez deux choix:

1) Demandez au serveur de vous envoyer des données plus lentement - et je ne pense pas qu'il existe de fonctionnalité de protocole pour demander cela en TCP ou HTTP.

2) Reconnaissez les paquets plus lentement en limitant votre vitesse de téléchargement, et ruinez également votre vitesse de téléchargement.

3) Votre routeur / pare-feu place les données entrantes dans un compartiment QoS et ne vide ce compartiment qu'au taux que vous avez demandé. Les données entrantes s'adapteront à cette vitesse car les ordinateurs à l'intérieur ne verront que l'accusé de réception à cette vitesse. En outre, le paquet abandonné occasionnellement (délibérément) fonctionne très bien pour ralentir une connexion.

Lorsque vous essayez de trouver un périphérique qui gère cela, recherchez QoS (Quality of Service) dans la configuration / documentation. Les boîtes Linux (ou BSD) sont également pratiques pour cela.

Vous utilisez un pare-feu ou un périphérique prenant en charge la limitation de la qualité de service (QoS).

Vous pouvez créer un système Linux pour servir de passerelle de bureau et lui faire utiliser la mise en forme du trafic pour y parvenir. Il suffit d'installer plusieurs cartes réseau et chaque machine pointe vers est une passerelle.

En prime, vous pouvez également configurer un serveur proxy pour faciliter le trafic. Quelque chose comme Squid. Il peut également y avoir des distributions d'appliance de routage clé en main.

Le protocole HTTP ne fournit pas de fonctionnalités pour limiter la bande passante utilisée, et même si c'était le cas, ce serait un paramètre côté client, sur lequel les administrateurs réseau ne pourraient avoir aucun contrôle.

La limitation de la bande passante (également appelée «qualité de service») est généralement gérée sur des routeurs / pare-feu, qui gèrent tout le trafic entrant et sortant vers / depuis un réseau; ceux qui le prennent en charge vous permettent généralement de configurer des stratégies telles que «laissez n'importe quel ordinateur client utiliser au maximum 10% de toute la bande passante disponible» ou «donnez la priorité SMTP au FTP afin que les e-mails puissent circuler même lorsque quelqu'un effectue un téléchargement lourd ".

La manière exacte dont cela est accompli dépend du routeur / pare-feu utilisé, mais le moyen le plus simple consiste à simplement jeter les paquets qui dépassent les limites configurées; TCP veillera à ce qu'ils soient retransmis et pourra éventuellement passer à travers le goulot d'étranglement.