Tráfego de entrada com limitação de taxa

Question

Eu nunca entendi muito bem se é possível limitar o tráfego de entrada . Percebo que não existe um método direct que controle a taxa de envio de pacotes do servidor remoto (a menos que você esteja no controle de ambos os endpoints), mas levando em conta essa limitação, como exatamente os gerenciadores de downloads permitem me para definir com sucesso limites de velocidade de download?

Existe algum link entre o TCP slow-start e o tráfego de entrada que limita a taxa? É possível usar os métodos descritos pelo slow-start para limitar artificialmente a taxa de envio de pacotes do remetente?

Como consideração adicional, deve ser observado que o servidor no qual gostaria de implementar a modelagem de tráfego estabelece a própria conexão PPPoE e atua como um roteador para o restante da rede.

Atualização: As respostas até agora deram uma visão geral das perguntas que fiz, mas ainda não sei como os gerenciadores de downloads conseguem limitar o tráfego de entrada e mais especificamente, se é possível implementar uma estratégia semelhante em uma caixa de gateway Linux.

    

Answer 1

Os gerentes de download provavelmente trabalham conforme explicado no artigo em bloco .

A process utilizing BSD sockets may perform its own rate limiting. For upstream limiting, the application can do this by simply limiting the rate of data that is written to a socket. Similarly, for downstream limiting, an application may limit the rate of data it reads from a socket. However, the reason why this works is not immediately obvious. When the application neglects to read some data from a socket, its socket receive buffers fill up. This in turn will cause the receiving TCP to advertise a smaller receiver window (rwnd), creating back pressure on the underlying TCP connection thus limiting its data flow. Eventually this “trickle-down” effect achieves end-to-end rate limiting. Depending on buffering in all layers of the network stack, this effect may take some time to propagate.

Se você ocasionalmente precisar limitar um único programa em um sistema UNIX, uma solução simples é trickle . A modelagem real do tráfego, como você executaria em um gateway, pode ser feita com tc . Isso está documentado em Capítulo 9. Disciplinas de enfileiramento para gerenciamento de largura de banda do roteamento avançado Linux & HOWTO de Controle de Tráfego.

    

Answer 2

No caso de um modem de 56k versus uma linha de DSl de 4 Mbps, não há (normalmente) nenhuma forma de fazer a diferença de velocidade, é apenas uma diferença na velocidade do link.

A razão pela qual é difícil moldar no tráfego de entrada é que não há buffer no meio de transmissão. Você aceita os bits recebidos ou eles estão perdidos. Para o tráfego que está prestes a sair de uma interface, você pode armazenar e reordenar os pacotes o quanto quiser (ou, pelo menos, até a memória buffer disponível no dispositivo).

Para protocolos que possuem uma camada sobre TCP (não sei se esse é o caso de torrents), seria uma questão simples de solicitação de dados adicionais. Caso contrário, o aplicativo precisaria se comunicar com o sistema operacional para atrasar o ACK dos pacotes. A maioria dos protocolos baseados em UDP necessitará, por necessidade, de ACK / reenviar a lógica no protocolo específico do aplicativo, então, nesse ponto, é trivial rodá-los.

Uma rota possível seria moldar o tráfego da Internet no lado da LAN do seu roteador DSL, pois, nesse momento, você estaria configurando uma porta de saída.

    

Answer 3

Não consigo responder por que você não encontrou nenhuma solução que permita moldar os dados de entrada (e não conheço nenhum que esteja no topo da minha cabeça), mas sobre como o remetente sabe com que rapidez o receptor pode receber dados :

O design básico do TCP / IP é que, para cada pacote que a fonte enviar ao destino, ele deve aguardar o destino responder (com um ACK pacote) dizendo que recebeu o pacote.

Portanto, se você tiver um remetente de 4Mbps e um receptor de 56Kbps, o remetente deverá aguardar entre o envio de pacotes para o receptor responder a cada pacote (há alguns detalhes técnicos para reduzir essa sobrecarga, mas a premissa ainda é válida) em um nível abstrato).

Então, o que acontece se o remetente já estiver enviando 56 Kbps de dados e, em seguida, tentar enviar um pouco mais?

O pacote se perde. (Bem, potencialmente enfileirado no buffer de um switch, mas quando isso é preenchido, o pacote é perdido). Como o pacote foi perdido, o receptor nunca o recebe e, portanto, nunca envia um pacote ACK . Como o remetente nunca recebe este ACK pacote (porque nunca foi enviado, mas também pode ser perdido, ou pode haver uma interrupção na rede), o remetente é obrigado a reenviar o pacote extra. Ele se senta e tenta reenviar o pacote até que ele passe e a resposta ACK retorne a ele.

Então, para recapitular, uma vez que o remetente tenha excedido a largura de banda do receptor, ele terá que parar e reenviar o próximo pacote repetidamente até que haja largura de banda disponível suficiente para ele passar. Isso reduz efetivamente a velocidade de envio ao máximo que o cliente pode receber. (E há métodos de otimização para reduzir o número de vezes que um pacote tem que ser reenviado nesse caso, onde basicamente o remetente diminui cada vez que ele precisa reenviar um pacote, mas isso está além do escopo desta descrição simplificada.

    

Answer 4

Você pode fazer isso com uma interface ifb.

Com uma interface ifb, você pode rotear o fluxo de entrada de eth0 (ou qualquer outro) para a saída em ifb0 (por exemplo) e aplicar as regras de limite.

Verifique esta URL da Linux Foundation: link

E esses scripts limitam a incomming e outcomming bandwight: link

    

Answer 5

Confira o Wondershaper: link

Em relação ao tráfego de entrada:

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.

    

Answer 6

use UFW (parede de fogo não complicada) link

Este thread mostra um exemplo simples que o padrão para IPs com 6 ocorrências dentro de 30 segundos é negado:

sudo ufw limit ssh/tcp

Além disso, um comando mais 'avançado' com valores especificados para tempo e contagem de ocorrências

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