Você está sempre obcecado por tentar encontrar o provedor de Internet “melhor e mais rápido”? Passei recentemente pelo turbilhão de marketing de comparação de vários planos diferentes e me lembrei de um fato simples: a métrica principal (largura de banda) utilizada pela indústria é realmente super enganosa. Acontece que, para a maioria dos casos de uso de navegação na web, uma conexão de Internet de vários Mbps oferece uma melhora pequena no desempenho.

Um dos principais culpados é o TCP início-lento, e sim, ele é um recurso, não um bug. Para entender o porquê, temos que olhar dentro da própria pilha TCP e, ao fazer isso, podemos também aprender algumas dicas interessantes sobre  como construir serviços web mais rápido em geral.

TCP início-lento 

O TCP oferece um monte de recursos built-in diferentes, mas os dois que nos interessam são controle de congestionamento e prevenção de congestionamento. TCP início-lento é, especificamente, uma implementação do controle de congestionamento dentro da camada TCP:

Ele é usado em conjunto com outros algoritmos para evitar o envio de mais dados do que a rede é capaz de transmitir, ou seja, para evitar congestionamento da rede.

O fluxo de alto nível é simples: o cliente envia um pacote SYN que anuncia seu tamanho máximo de buffer (rwnd – receive window/janela de recepção),o remetente responde, enviando vários pacotes de volta (cwnd – congestion window/janela de congestionamento) e depois, cada vez que recebe um ACK do cliente, ele dobra o número de pacotes que podem estar “na conexão”, enquanto não reconhecida.

Essa fase também é conhecida como a fase do “crescimento exponencial” da conexão TCP. Então, por que devemos nos preocupar? Bem, não importa o tamanho do seu tubo, cada conexão TCP passa por essa fase, o que também significa que mais frequentemente do que não, a largura de banda utilizada é efetivamente limitada pelas configurações de tamanho de buffer do remetente e do receptor.

HTTP e TCP início-lento

É claro, uma conexão de largura de banda maior vai ser útil quando você estiver transmitindo um arquivo grande, ou executando um teste de velocidade fútil. O problema é que o tráfego HTTP tende a fazer uso de conexões curtas e arrojadas – nesses casos, muitas vezes nunca sequer atingem a capacidade plena de nossos tubos! Uma pesquisa feita no Google mostra que um aumento de 5 Mbps a 10 Mbps resulta em uma melhoria decepcionante de 5% nos tempos de carregamento da página.

Ou, dito de maneira um pouco diferente, uma conexão de 10 Mbps, em média, utiliza apenas 16% da sua capacidade. Como se vê, se quisermos uma Internet mais rápida, devemos nos concentrar em reduzir o tempo de ida e volta entre o cliente e o servidor, não necessariamente apenas investir em tubos maiores.

A história de CWND

Se o TCP início-lento é lento assim, então não poderíamos só torná-lo mais rápido? Acontece que, até muito recentemente, a própria pilha TCP do Linux foi codificada para começar com a janela de congestionamento (cwnd) de apenas 3 ou 4 pacotes, o que equivale a cerca de 4kb (~ 1360 bytes por pacote). Combine isso com o caso, infelizmente frequente, patológico de buscar um único recurso por conexão, e você conseguiu limitar seriamente seu desempenho.

A partir da versão 2.6.33 do kernel, depois de uma discussão prolongada e uma série de recomendações IETF, o valor inicial de cwnd foi redefinido para 10 pacotes, que em si é um enorme passo à frente. Apenas um problema, adivinhe quais versões do kernel que a maioria dos servidores roda hoje? Sim, talvez seja a hora de atualizar seus servidores. Como dica prática, se você estiver pensando sobre como ativar o SPDY para o seu serviço web, então execute em qualquer coisa, mas alguns dos kernels mais recentes não vão realmente te fornecer quaisquer melhorias de desempenho! Uma pequena mudança na pilha TCP, mas uma grande diferença no geral.

Então, o que eu posso fazer sobre isso?

TCP início lento (TCP Slow-Start) é uma característica, não um bug, e ele traz algumas implicações interessantes e importantes. Como desenvolvedores, nós ignoramos muitas vezes o tempo de ida e volta do cliente para o servidor, mas se estamos realmente interessados ​​na construção de uma web mais rápida, então este é um bom momento para investigar suas opções: reutilizar suas conexões TCP quando se fala de serviços web, construir serviços web que suportam HTTP keep-alive e pipelining, e pensar de cabo a rabo sobre latência. Ah, e não desperdice seu dinheiro naquele tubo de mais de 10Mbps! Você provavelmente não vai precisar dele.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.igvita.com/2011/10/20/faster-web-vs-tcp-slow-start/