↑ Retornar para Problemas do mundo real

Throughput vs TCP Window Size vs Link Size – AJUDA – RESOLVIDO

Home Fórum Problemas do mundo real Throughput vs TCP Window Size vs Link Size – AJUDA – RESOLVIDO

Este tópico contém 26 respostas, possui 9 vozes e foi atualizado pela última vez por  rgentil 5 anos, 10 meses atrás.

Visualizando 25 posts - 1 até 25 (de 27 do total)
  • Autor
    Posts
  • #48641

    RenatoR
    Participante

    Pessoal, bom dia!

    Acompanho o blog/forum há algum tempo, mas nunca fui de postar aqui…
    Agora estou com um problema, não tão grave em termos operacionais, mas que me deixou bem curioso.

    Em resumo, o que acontece é que uma transferência via SFTP através de 2 servidores UNIX não passa de 1375kbps (cravados).
    Quando o cliente estabelece 2 sessoes dessa trasnferência, as 2 cravam em 1375kbps – o que mostra que a rede não é o gargalo.

    A topologia é a seguinte:

    Server_A -> router_A + link de 34M -> cloud MPLS -> router_B + stm1 -> Server_B

    O cliente já tentou transferir em horários alternativos (a noite, quase sem tráfego nos links) e mesmo assim, nada feito, sempre os mesmos 1375kbps.
    Eu (e tb o cliente) estamos convencidos de que é um problema no aplicativo/servidor, mas ainda sim fiquei curioso.

    Eu capturei alguns traces e notei que o TCP Window size está em 17655. Eu queria dar alguma pista para o cliente, baseado no que vi nos traces, mas não cheguei a nenhuma conclusão.

    Em termos de camada de transporte, o que define a taxa de transferência? O TCP window size está diretamente ligado a isso?
    Li bastante coisa na Internet a respeito, mas muita coisa MUITO teorica e não consegui chegar a nenhuma conclusão.

    Como disse, o problema não está tão critico, é mais curiosidade minha em aprender.

    Espero que tenha ficado claro… estou escrevendo com um pouco de pressa. Se alguem puder compartilhar algo, eu agradeco – e depois posso postar mais detalhes caso necessario.
    Espero que essa discussao tb ajude outros a entender/aprender algo novo.

    Abracos

    0

    0
    #114375

    zekkerj
    Participante

    @RenatoR: Em termos de camada de transporte, o que define a taxa de transferência?

    Essa é uma pergunta difícil de responder. A transferência TCP usa várias técnicas pra tentar aproveitar ao máximo a banda disponível. Eu entendo que a janela tcp não é um fator limitante, mas o resultado da aplicação das várias técnicas sobre o tráfego.

    Se vc observa sempre a mesma taxa de transferência, me parece que vc esteja sofrendo algum tipo de shaping.

    0

    0

    -----------------------------------------------------------------------------
    Receba Johrei e purifique seu Espírito.
    http://www.messianica.org.br/o-johrei.jsp

    #114376

    RenatoR
    Participante

    Zekkerj, obrigado pela resposta.

    Não descarto essa possibilidade, afinal, como já me disseram uma vez, “a gente nunca sabe, até saber” 🙂
    Mas o estranho é que quando eles abrem 2 sessoes (ou 3, ou mais) e cada uma delas chega aos exatos 1375kbps. É muito estranho. Olhando o Netflow, dá pra ver cada sessao exatamente ocupando a mesma banda.

    Não tem nenhum device na rede (packeshaper, WAAS, etc) que seria capaz de capar uma sessao apenas (se os 1375kbps se dividissem entre todas as conexoes, eu estaria mais preocupado).

    Outra coisa interessante, é que durante o dia os links desses 2 lugares chegam perto de 100% (o 34M chega em quase 28M e o STM1 em quase 120M).

    Obrigado novamente.

    PS.: Espero que não esteja parecendo que eu quero que a galera resolve o “meu” problema… queria mesmo era entender e me apronfundar no tema.

    0

    0
    #114377

    Fernando Avelino
    Participante

    Concordo com o zekkerj, não acho que o problema seja janelamento tcp, minha experiência com problemas assim sempre evidenciou gargalos na rede da operadora em 90% dos casos, ainda mais usando mpls

    0

    0
    #114378

    Leonardo Ortiz
    Participante

    Sobre o problema, veja no Unix se não tem alguma regra no firewall que esteja limitando, ou alguma outra coisa como tc ou cbq encima, ou o proprimo servidor FTP, no PROFtp por exemplo tem uma linha chamada “TransferRate” para limitar.

    0

    0
    #114379

    RenatoR
    Participante

    Na verdade é SFTP e não FTP. É via SSH, pela porta 22…

    E “eu” sou a operadora. Já verifiquei tudo, os CEs e os switches MPLS, não tem nada bloqueando ou limitando. E como eu disse, com 2 ou 3 sessoes abertas, cada uma delas flui a 1375kbps. Não sei nem se os roteadores teriam capacidade de fazer um shapping assim, “por sessao”.

    Dentro da nossa rede nao tem firewall e segundo o cliente na rede dele tb nao (mas nunca se sabe né…).

    Nesse exato momento, o tráfego dos links está bem alto, mais de 80% em cada um deles. E a sessao de SFTP está lá com seus 1375kbps.

    0

    0
    #114380

    jorge.ff
    Participante

    RenatoR

    Você consegue fazer um teste de transferencia usando ftp em vez de sftp ? Já tive um problema parecido e fazendo um teste transferindo via ftp a velocidade ia lá em cima , via sftp ficava lento . No meu caso tiramos a criptografia do S.O (tb linux) criando uma vpn entre os dois roteadores . Na epoca não fomos muito afundo pq era um projeto para ontem .

    Jorge

    0

    0
    #114381

    jorge.ff
    Participante

    https://www.eldos.com/security/articles/7122.php

    Dá uma olhada nesse link .

    Abs
    Jorge

    0

    0
    #114382

    chainsawman
    Participante

    Isso que o jorge.ff falou pode ser compravado em equipamentos baratos (routerboards), onde uma transferência SFTP geralmente deixa a CPU em 100%.

    0

    0
    #114383

    thiago.mello
    Participante

    Teste via FTP e veja se a lentidão continua. SFTP usa criptografia de dados e sinceramente não sei se existe alguma limitação para transferência de dados.
    Faça com o FTP e veja se a velocidade continua a mesma.
    Recentemente identifiquei uma lentidão na transferência de arquivos no meu trabalho, temos um link FastEthernet que estava sobrecarregado, veja a rede de ponta a ponta se possível.

    Abs

    0

    0
    #114384

    RenatoR
    Participante

    Obrigado pessoal… estou insistindo com o cliente para fazer um teste com FTP.
    Ele está relutante (teimosia pura), mas acho que vai ceder.

    Tem algo mais em um trace que eu consiga ver na transferencia de SFTP?
    Deixei o trace rodando por um bom tempo e segue um padrao, 2 pacotes de dados de envio, 1 ack, 2 de envio, 1 ack e assim vai.
    Se o link estivesse fazendo shapping, qual seria o comportamento? Veriamos retransmissions? Renegociacao de janela TCP? Alguem tem ideia?

    Vou bolar um lab aqui e simular com iperf no fim de semana pra ver o que rola.

    Muito agradecido!

    0

    0
    #114385

    zekkerj
    Participante

    Vc citou o lab de iperf, seria uma boa idéia fazer uma transferência entre os dois servidores usando as mesmas portas do serviço sftp, mas com o iperf mesmo. Assim vc poderia eliminar o fator criptografia do problema.

    0

    0

    -----------------------------------------------------------------------------
    Receba Johrei e purifique seu Espírito.
    http://www.messianica.org.br/o-johrei.jsp

    #114386

    RenatoR
    Participante

    Concordo contigo, seria um ótimo teste… mas o cliente está teimando para fazer uma simples transferência de FTP, quem dirá colocar iperf rodando nos 2 servidores (servidores de correio de produção). Pra ajudar, a empresa em questão é grande e tem gente em diferentes países da America Latina e alguns na India participando deste processo… a comunicação tb tem sido um problema (dentro do próprio cliente).

    0

    0
    #114387

    RenatoR
    Participante

    Fiz o seguinte “LAB” aqui:

    Iperf Server -> router -> Iperf Client

    Bem simples… o server tem IP 192.168.200.2 e o client 10.172.192.3.

    Rodei uma vez sem shapping e ficou perto de 5M. Configurei um shapping de 1M no router e rodei de novo e os valores ficaram de acordo (vejam a imagem).

    0

    0
    #114388

    RenatoR
    Participante

    Agora olhando a captura e vendo essa janela de “summary” do wireshark, ele próprio indica o avg transfer, mas nao consegui ver nenhuma indicacao nos pacotes mostrando que o router de fato estava fazendo shapping.

    0

    0
    #114389

    zekkerj
    Participante

    Usou as mesmas portas do serviço sftp, certo? A idéia é "enganar" um possível shaping, e fazê-lo atuar — se existir. Pq se não atuar, é pq não existe, e nesse caso a limitação é do protocolo (ou do aplicativo).

    0

    0

    -----------------------------------------------------------------------------
    Receba Johrei e purifique seu Espírito.
    http://www.messianica.org.br/o-johrei.jsp

    #114390

    RenatoR
    Participante

    isso foi em um home lab e nao no ambiente real.

    de toda forma, agora a noite o cliente testou via FTP e não ocorreu a limitação. o cliente (e eu tb) está convencido de que o problema é no servidor ou no cliente. ainda existiria a possibilidade de ser algo especifico com a porta 22, mas eu já revirei a config de todos os routers e switches envolvidos e não tem nada especifico por porta tcp.

    o que eu queria entender é: com os 2 traces que eu capturei, qual o indicio na captura que mostra que a “rede” está dizendo para o servidor “baixar” a velocidade?

    abraços e muito obrigado pelos comentarios!

    0

    0
    #114391

    zekkerj
    Participante

    @RenatoR: qual o indicio na captura que mostra que a "rede" está dizendo para o servidor "baixar" a velocidade?

    Retransmissões, segmentos com janela 0, mensagens icmp source quench (mais raras)

    0

    0

    -----------------------------------------------------------------------------
    Receba Johrei e purifique seu Espírito.
    http://www.messianica.org.br/o-johrei.jsp

    #114392

    RenatoR
    Participante

    Vou analisar os traces de novo e ver se encontro algo.

    Se alguém tiver curiosidade:

    https://www.dropbox.com/s/64huvpbvve2mx8o/shape1m1.pcapng – IPERF com shape de 1M no router
    https://www.dropbox.com/s/91b1n7utjq0emtv/no_shape1.pcapng – IPERF sem shape nenhum

    Lembrando, a topologia foi: server (onde foi realizada a caputura) router client
    Bem simples..

    Abs

    0

    0
    #114393

    RenatoR
    Participante

    E olha só, o cliente fez os seguinte testes:

    – Transferencia via FTP entre os 2 sites – mesma taxa de transferencia (1375kbps) – com 2 ou 3 sessoes ao mesmo tempo, cada uma chega a apenas 1375kbps.
    – Transferencia via FTP e SFTP entre 2 servidores locais (na LAN de um dos sites) – chegou a quase 50M.

    A mesa virou e agora a “culpa” tá voltando pra mim, hehehehe

    0

    0
    #114394

    RenatoR
    Participante

    FINALMENTE RESOLVIDO!!!!!!!!

    A solução está aqui:
    http://packetlife.net/blog/2010/aug/4/tcp-windows-and-window-scaling/

    Depois de muito comparar e muito ler na Internet, notei que o TCP Window Scaling estava vindo setado como “0” (no wireshark mostra “-2 scaling not in use”). Esses parametros sao negociados pelo server e client.

    O cliente mexeu em algo nos servers (UNIX) e habilitou a opção de TPC Scaling e também o tamanho max do window size – resultado – o TCP Window Size subiu e a transferência também!!!

    Basicamente, a premissa é a seguinte:

    Throughput = TCP Win Size / RTT

    Como a latência nesse link era de 104ms, com o TCP Window Size de 17655bytes (=141240bits) 141240bits/104ms = 1358,07bits/msec 1358kbits/s ou 1358kbps – justamente a velocidade que eu estava vendo na monitoração por SNMP e Netflow.

    Falow, abracos!

    0

    0
    #114395

    thiago.fiorini
    Participante

    Parabéns!!

    Qual a velocidade agora?

    0

    0
    #114396

    RenatoR
    Participante

    Perto de 2500KB/s ou 20Mbps

    A janela subiu para 262140 (65535×4).

    Abraços

    0

    0
    #114397

    rgentil
    Participante

    RenatoR

    Depois disso vc fez traces de novo para comparar a diferenca ??? Pode postar as duas para a galera ver a diferenca (eu tbm quero ver).

    valeu

    0

    0
    #114398

    RenatoR
    Participante

    Cara, eu ia postar, mas to vendo aqui que no trace veio os IPs dos servidores, user/pass e a porra toda (FTP é clean text).
    Vou ver se dou uma “limpada” neles e posto algo aqui.

    Basicamente a diferença foi no SYN, SYN-ACK, ACK onde a janela de TCP ficou maior e veio com “option” de scaling. Ai na transferência, a janela ficou maior e o scaling passou de “-1 no scaling used” para “multiplied by 4”.

    abs

    0

    0
Visualizando 25 posts - 1 até 25 (de 27 do total)

Você deve fazer login para responder a este tópico.