Gostaria de detectar conexões TCP que estão abertas há mais de um minuto (ou para mais de N bytes ou M pacotes), para poder classificá-las como tráfego em massa ("downloads") e despriorizá-las.
Posso detectar streams de longa duração com iptables/netfilter/conntrack e marcá-los para modelagem por tc?
Achei que poderia usar o "número de sequência" do TCP como uma medida do comprimento de um fluxo, mas infelizmente ele não começa do zero! Talvez o rastreamento de conexão com netfilter/conntrack possa determinar o número de sequência correto, ou o número total de bytes, e a duração da conexão, e escolher se deseja marcar o pacote.
(Eu também poderia mencionar que estou fazendo isso ementradausando uma interface virtual ifb0. Atualmente estou usando filas tbf (com sfq) para limitar dados de baixa prioridade. Independentemente disso, qualquer solução também poderia ser aplicada asaída, por exemplo, para um servidor web com uma conexão limitada que deseja despriorizar downloads para acelerar pequenas solicitações.)
Atualização: Usando o conntrackd consigo ver uma lista de conexões e há quanto tempo cada uma foi iniciada. Comecei a usar esta lista para detectar pares de IP/porta que desejo limitar (após 60 segundos). No entanto, existem vários problemas:
- conntrack(d) não parece limpar as conexões da lista imediatamente quando elas são fechadas! Então acabo marcando todas as conexões para limitação, mesmo as que já terminaram.
- Definir marcas no conntrack não parece definir marcas nos pacotes (até onde tc pode ver). (Isso não ocorre apenas porque conntrack vê os pacotes após ifb0: também não consigo ver nenhuma marca nos pacotes de saída.) Então, acabei de adicionar novos filtros ao tc para limitação, o que está longe de ser ideal no 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, este é um problema difícil: se já tivermos 5 downloads e um novo download for iniciado, como podemos saber que ele está tentando inundar? Ele não chegará nem perto da taxa máxima.)
Qualquer sugestão com o acima será apreciada.
(Pelo lado positivo, mesmo que eu não consiga classificar os downloads corretamente, simplesmente usar tfb para limitar os dados recebidos a 80% da minha taxa de downrate máxima evitou sobrecarregar a conexão e permitiu que novas conexões fossem estabelecidas com muito mais facilidade do que antes.)
Responder1
A expectativa de vida e a longevidade real de uma conexão têm relação ZERO sobre se uma conexão deve ser moldada de maneira especial ou não.
Alguns exemplos:
SSH, possivelmente de longa duração, minutos, horas, dias, semanas e até meses. Ainda precisa de alta prioridade para responder à interação do usuário.
Bittorrent (ou protocolos semelhantes), vividos aleatoriamente, alguns por segundos e depois desconectados, outros por minutos ou horas e depois desconectados. Poucos duram mais de um dia de cada vez.
Resumo: O comprimento de uma conexão NADA tem a ver com o fato de a conexão ser "em massa" ou não e se a conexão deve ou não ser tratada como em massa.
Não necessariamente relacionado diretamente, mas útil:
Usando modelagem de tráfego, limitar o tráfego de download é útil ou prejudicial?