Como posso detectar conexões de vida longa e marcá-las para modelar

Question

Eu gostaria de detectar conexões TCP que foram abertas por mais de um minuto (ou por mais de N bytes, ou pacotes M), então eu posso classificá-las como tráfego em massa ("downloads") e des-priorizá-las .

Posso detectar transmissões de longa duração com iptables / netfilter / conntrack e marcá-las para modelagem por tc?

Eu pensei que eu poderia usar o "número de seqüência" do TCP como uma medida do comprimento de um fluxo, mas infelizmente ele não começa em zero! Talvez o rastreamento de conexão com o netfilter / conntrack possa determinar o número de seqüência correto ou o número total de bytes e a duração da conexão, e escolha se deseja marcar o pacote.

(Eu também poderia mencionar que estou fazendo isso em ingresso usando uma interface virtual ifb0. Atualmente estou usando filas tbf (com sfq) para limitar dados de baixa prioridade. Independentemente, qualquer solução poderia também ser aplicado a egresso , por exemplo, para um servidor web em uma conexão limitada que deseja des-priorizar downloads para acelerar pequenos pedidos.

Atualização: Usando o conntrackd, consigo ver uma lista de conexões e há quanto tempo cada uma delas foi iniciada. Eu comecei a usar essa lista para detectar pares IP / porta que eu quero limitar (após 60 segundos). No entanto, há vários problemas:

• conntrack (d) não parece limpar as conexões da lista imediatamente quando elas fecharam! Então acabo marcando todas as conexões para limitar, mesmo aquelas que terminaram.
• A configuração de marcas no conntrack não parece definir marcas nos pacotes (até onde tc pode ver). (Isto não é apenas porque conntrack vê os pacotes depois de ifb0: também não consigo ver nenhuma marca nos pacotes de saída.) Então, acabo de adicionar novos filtros a tc para limitação, o que está longe de ser ideal a longo prazo.
• conntrack (d) não me diz quanta largura de banda cada conexão usou. Portanto, não consigo distinguir sessões intermitentes (por exemplo, iosocket) de downloads pesados. (De qualquer forma, esse é um problema difícil: se já temos 5 downloads e um novo download começa, como podemos dizer que ele está tentando inundar? Ele não chegará nem perto da taxa máxima.)

Qualquer sugestão acima será apreciada.

(No lado positivo, mesmo que não consiga classificar os downloads corretamente, simplesmente usar o tfb para limitar os dados recebidos a 80% do meu downrate máximo evitou o transbordamento da conexão e permitiu que novas conexões se estabelecessem muito mais facilmente do que antes .)

    

Answer 1

A expectativa de vida e longevidade real de uma conexão tem relação ZERO sobre se uma conexão deve ser moldada especialmente ou não.

Alguns exemplos:

SSH, possivelmente de longa duração, minutos, horas, dias, semanas, até meses. Ainda precisando de alta prioridade para responder à interação do usuário.

Bittorrent (ou protocolos semelhantes), vividos aleatoriamente, alguns por segundos, em seguida, desconectados, outros por minutos ou horas e, em seguida, desconectados. Poucos duram mais de um dia de cada vez.

Resumo: O comprimento de uma conexão não tem nada a ver se a conexão é "em massa" ou não, e se a conexão deve ou não ser tratada como em massa.

Não necessariamente diretamente relacionado, mas útil:

Usando a modelagem de tráfego, está limitando o tráfego de downloads ou prejudicial?