Em termos de TCP / IP, como funciona um limitador de velocidade de download em um escritório?

Suponha que um escritório de pessoas deseje limitar os downloads HTTP a um máximo de 40% da largura de banda de sua velocidade de conexão com a Internet, para que não bloqueie outro tráfego.

Dizemos "ele não é suportado no seu firewall" e eles dizem que a linha inevitável "costumávamos fazer isso com o nosso Netgear / DLink / DrayTek".

Pensando nisso, um download é assim:

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

A velocidade é determinada pela rapidez com que o servidor envia dados para você e pela rapidez com que você os reconhece.

Portanto, para limitar a velocidade do download, você tem duas opções:

1) Instrua o servidor a enviar dados para você mais lentamente - e acho que não há nenhum recurso de protocolo para solicitar isso em TCP ou HTTP.

2) Reconheça os pacotes mais lentamente, limitando sua velocidade de upload e também arruinando sua velocidade de upload.

Como os dispositivos limitam isso? Existe uma maneira padrão?

O próprio TCP implementa o controle de congestionamento.

Esses limitadores de taxa simplesmente jogam pacotes fora do limite. O TCP lida com isso, garantindo que todos os pacotes cheguem e cheguem em ordem; o cliente não aceita os pacotes descartados e é reenviado pelo servidor.

A pilha TCP do servidor reenviará os pacotes e também reduzirá um pouco a taxa de envio, pois indica que há congestionamento entre ele e o cliente. Ele acelerará até que o limitador de taxa solte pacotes novamente e assim por diante.

A melhor descrição que eu já ouvi que fez sentido do método de limitação inerente do TCP foi um podcast recente do Security Now . Para citar Steve Gibson:

Portanto, por acordo universal, o TCP sendo esse protocolo muito inteligente, faz algo chamado "início lento". Geralmente, é dada permissão para enviar um certo número de pacotes sem reconhecimento. Então, a ideia é, vamos colocar as coisas em movimento aqui. E normalmente esse número é dois. E assim, quando o TCP é iniciado, ele pode enviar dois pacotes, um após o outro. Sem que o primeiro seja reconhecido, ele enviará o segundo. Mas então espera. E a regra para a limitação é permitir que o número de pacotes não reconhecidos aumente em um para cada reconhecimento que recebermos.

Então, vamos pensar sobre isso. Permitimos que o número de pacotes não reconhecidos seja aumentado em um para cada reconhecimento que recebermos. Então, primeiro enviamos dois pacotes conforme o início acordado. Eles são reconhecidos. Portanto, temos nosso primeiro reconhecimento. Estávamos nos permitindo enviar dois. Agora, com o recebimento dessa primeira confirmação, aumentamos isso de um para três. Agora, podemos enviar mais três pacotes sem nenhum reconhecimento adicional. Quando um reconhecimento volta por tudo o que enviamos antes, aumentamos para quatro. Isso é conhecido como "janela de congestionamento". Não é uma janela que é enviada na linha, ou seja, não é como a janela de recebimento, que é 16 bits do cabeçalho TCP que nos diz quantos dados podemos enviar adiante. Este é - é uma janela. Isto'

Se continuarmos aumentando o número de pacotes não reconhecidos, podemos enviar um a cada vez que recebermos uma confirmação, em algum momento atingiremos um limite. E a beleza desse sistema é que, quando começarmos a tentar enviar pacotes mais rapidamente do que o link mais fraco, literalmente, entre roteadores, em algum momento, encontraremos o ponto em que o link mais fraco será quebrado. Ele descarta os pacotes que estamos tentando enviar porque estamos tentando enviá-los muito rápido. Portanto, os reconhecimentos do outro lado param porque os dados não estão mais chegando.

E o que o TCP faz é, se ele não recebeu - e isso varia de estratégia. Com o tempo, a estratégia e a estratégia real de prevenção de congestionamentos variaram bastante. Existem nomes como Tahoe e Reno, e muitos outros que você verá se pesquisar no Google e na Wikipedia, que especificam exatamente qual é o comportamento. Mas a ideia é que, quando o remetente percebe que seus dados não estão mais sendo recebidos porque faltam reconhecimentos, reduz sua taxa de envio rapidamente. Normalmente, ele divide ao meio. Então, ele aumenta drasticamente e volta a aumentá-lo.

Então, basicamente, o que isso significa é que a perda de pacotes é a função de sinalização para "Não podemos enviar os dados com mais rapidez" e que os remetentes TCP em cada extremidade de uma conexão, em toda a Internet, são sempre meio que - eles ' estão tentando ir mais rápido que a velocidade máxima disponível entre os dois pontos de extremidade, ou seja, o link mais fraco, onde quer que esteja, e eles estão sempre empurrando-o para o limite. Portanto, dado que há um ponto em algum lugar mais fraco do que a capacidade deles de enviar pacotes, eles o encontrarão porque bombearão os pacotes. Enquanto houver dados a serem enviados e eles tiverem uma conexão de largura de banda alta, o remetente aumentará a taxa de envio, ou seja, o número de pacotes pendentes, os pacotes que podem estar disponíveis em tempo real como agradecimentos volte, agressivamente continua movendo esse número para cima até empurrá-lo muito longe. Depois recua muito e depois avança novamente.

Portanto, é isso que realmente está acontecendo entre as conexões TCP que, provavelmente, não sei qual porcentagem, mas a maior porcentagem de tráfego na Internet é através de conexões TCP. Todos os nossos sistemas operacionais no kernel, na chamada pilha TCP, possuem esses contadores. E quando estamos enviando um arquivo, quando estamos carregando um arquivo grande ou recebendo uma página da web, o servidor do outro lado está fazendo a mesma coisa. Ele está empurrando, em uma base de conexão individual, o maior número de pacotes que ainda não foram reconhecidos, aumentando a taxa de pacotes até atingir o ponto em que começa a falhar ou gaguejar. Depois, ele recua, para permitir que as coisas se recuperem e, em seguida, começa a trabalhar novamente.

E isso acaba sendo uma espécie de sistema de auto-estrangulamento que, dadas as restrições, quero dizer, realmente parece meio desagradável e grosseiro ".

Portanto, para limitar a velocidade do download, você tem duas opções:

1) Instrua o servidor a enviar dados para você mais lentamente - e acho que não há nenhum recurso de protocolo para solicitar isso em TCP ou HTTP.

2) Reconheça os pacotes mais lentamente, limitando sua velocidade de upload e também arruinando sua velocidade de upload.

3) Seu dispositivo roteador / firewall coloca os dados recebidos em um depósito de QoS e esvazia esse depósito apenas na taxa solicitada. Os dados recebidos se adaptarão a essa velocidade, pois os computadores internos verão apenas o recebimento de confirmação nessa velocidade. Além disso, o pacote descartado ocasional (propositalmente) funciona muito bem para diminuir a velocidade da conexão.

Ao tentar encontrar um dispositivo que lide com isso, procure QoS (Qualidade de Serviço) na configuração / documentação. As caixas Linux (ou BSD) também são úteis para isso.

Você usa um firewall ou dispositivo que suporte a limitação de QoS (qualidade de serviço).

Você pode criar um sistema Linux para atuar como o gateway do escritório e usar a modelagem de tráfego para conseguir isso. Só precisa de várias NICs instaladas e, em seguida, todas as máquinas apontadas são como um gateway.

Como bônus, você também pode configurar um servidor proxy para facilitar o tráfego. Algo como Lula. Pode haver distribuições de dispositivo de roteamento turnkey que também podem fazer isso.

O protocolo HTTP não fornece recursos para limitar a largura de banda usada, e mesmo que isso acontecesse, seria uma configuração do lado do cliente, na qual os administradores de rede não poderiam ter nenhum controle.

A limitação de largura de banda (também conhecida como "Qualidade de Serviço") geralmente é gerenciada em roteadores / firewalls, que controlam todo o tráfego de entrada e saída de / para uma rede; os que oferecem suporte a isso geralmente permitem configurar políticas como "permitir que qualquer computador cliente use no máximo 10% de toda a largura de banda disponível" ou "dar prioridade ao SMTP sobre o FTP para que os emails possam fluir mesmo quando alguém estiver fazendo um download pesado" "

Como exatamente isso é feito depende do roteador / firewall usado, mas a maneira mais básica é simplesmente jogar fora os pacotes que excedem os limites configurados; O TCP garantirá que eles sejam retransmitidos e eventualmente passará pelo gargalo.