Bandwidth é realmente irrelevante?

O tema pode até parecer um pouco antigo, mas é sempre bom reforçar alguns conceitos que parecem um pouco esquecidos.

Você acabou de contratar um link de alta velocidade entre dois DataCenters para uma determinada necessidade. Instalou os equipamentos, configurou os serviços e as rotas, mas na hora de transferir os dados você percebe que a transferência de dados é lenta. Antes de sair acionando meio mundo para fazer um troubleshooting, vamos fazer algumas contas para saber se houve um erro de configuração ou apenas de expectativa.

Quando usamos o protocolo TCP para transferir dados, os dois fatores mais importantes são o “TCP window size” e o “Round Trip Time“, e não necessariamente o tamanho do link (bandwidth) contratado. De posse destes dois podemos calcular o throughput máximo deste link, independentemente do tamanho contratado.

Antes de brincarmos com as fórmulas, vamos fazer um pequeno glossário dos termos envolvidos:

• Bandwidth (Largura de Banda) é um limite teórico/nominal de transferência de dados através de um canal de comunicação, medido em bits/s. Ex.: um cabo CAT5 tem uma bandwidth estimada de 100 Mbps;
• Throughput (taxa de transferência) é a taxa de transferência efetiva (real) através de um canal de comunicação. Ex. uma transferência de arquivo de 10 KB através de um cabo CAT5;
• Round Trip Time (RTT ou Latência) é o tempo (em segundos) que um pacote leva para ir e voltar entre dois pontos;
• TCP window size é a quantidade de informação que um cliente pode receber de um servidor de uma única vez, que é negociada entre os dois no início de cada comunicação. O tamanho padrão é de 64 KB.

Fórmula para calcular o throughput TCP

Apesar de simples, poucos tem a exata noção de como funciona o cálculo de throughput TCP. Mas a fórmula é a seguinte:

TCP Window size / Round Trip Time = Throughput em bps

Vamos a um exemplo prático: você contratou um link de 1 Gbps de bandwidth entre São Paulo e Rio de Janeiro, que tem uma latência média de 30 ms. Se tentar transferir um arquivo grande (imagine uma replicação de banco de dados ou até um simples FTP), qual será o throughput (taxa de transferência)?

Para começar, vamos converter o “TCP window size” de bytes para bits, sendo que o tamanho padrão de uma máquina windows é 64 KB (65.536 bytes). Então:

65.536 bytes * 8 = 524.288 bits

Agora, vamos dividir este “TCP window size” pelo “Round Trip Time” (sendo que 30 ms = 0,030 s):

524.288 bits / 0,030 s= 17.476.266 bps de throughput  (ou seja, temos um throughput máximo de 17,4 Mbits/s, o que dá pouco mais de 2 MBytes/s!!)

Então, apesar de termos contratado um link nominal de 1Gbps entre os DataCenters, não teremos mais de 17,4Mbps reais de taxa de transferência, dadas estas condições.

Então o que podemos fazer para melhorar essa situação? Não muito: reduzir a latência ou melhorar o “TCP window size”.

Para reduzir a latência não é uma tarefa tão simples: seria necessário fazer São Paulo e Rio de Janeiro ficarem mais próximos. Já para melhorar o “TCP window size“, basta fazer ajustes individualmente em todos os equipamentos envolvidos na comunicação para aumentar esta “janela” de transferência. É complicado e trabalhoso, mas é mais factível do que a primeira opção.

Mas esta alternativa nos leva a outra questão: qual o tamanho adequado do “TCP window size“?

Formula para calcular o “TCP window size“

A fórmula é a mesma do cálculo de throughput, apenas alterando a ordem dos fatores

Throughput em bits/s * Round Trip Time = TCP Window size

Então no nosso caso, com um link de 1 Gbps ficamos assim:

1.000.000.000 bps * 0,030 s = 30.000.000 bits (que é igual a 3.750.000 Bytes)

Então se configurarmos os equipamentos para um “TCP Window size” igual a 3.750 KB conseguiríamos usar todo o link de 1 Gbps. Mas o principal problema de fazer isso é que os equipamentos consomem muito mais memória para buffer. Ironicamente, outro problema grave é a perda de pacotes, pois qualquer pacote perdido numa janela fará com que a janela inteira seja retransmitida, a não ser que a pilha TCP esteja configurada com uma melhoria chamada “selective acknowledgements”, que a maioria não tem.

Outra opção seria usar um acelerador de WAN que ficam constantemente manipulando os parâmetros de “TCP window size“, aplicando “selective acknowledgements” e que possuem outras otimizações até em camada 7 (aplicação) para reduzir os famigerados “Round Trip Times“.

Reduzir Latência? Como isso é possível?

A não ser que você descubra como ultrapassar a barreira da velocidade da luz, não há como reduzir a latência real entre duas localidades. Uma opção é, de novo, usar uma solução para aceleração WAN que permita responder os acknowledgements localmente para os servidores, ao invés de aguardar esses acknowledgements vindo da outra ponta. Assim, os servidores são “enganados” e acabam enviando mais pacotes TCP em menos tempo. E entre os aceleradores WAN, o “TCP Window size” é alterado dinamicamente para transferir mais dados pelo mesmo link, sem a necessidade de ficar manipulando esse parâmetro em cada um dos servidores.

Junto com essas otimizações, existem diversas outras como remover dados duplicados do fluxo TCP, que resultam em melhores níveis de compressão, e cache local desses conteúdos, fazendo com que dados repetidos não sejam retransmitidos a cada solicitação (imagine uma mesma página web, um mesmo anexo de um e-mail ou uma assinatura de segurança sendo solicitada por diversos usuários pelo mesmo link).

O resultado dessas otimizações será uma melhor utilização do link WAN com uma consequente redução no tempo necessário para os dois DataCenters se conversarem.

Source: http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/