The Cable GuyAuto-ajuste da janela de recepção TCP

Joseph Davies

Bem-vindo à primeira edição de The Cable Guy na TechNet Magazine. Os fãs da coluna no site da TechNet já sabem que cobrimos todo o tipo de questões de sistemas de redes e que continuaremos essa tradição aqui, todo mês. Se você for novo por aqui e estiver procurando um arquivo com as colunas anteriores, dirija-se ao site The Cable Guy.

Agora, vamos começar com nosso primeiro tópico aqui: a janela de recepção TCP.

A taxa de transferência sobre conexões TCP pode se limitar ao envio e recebimento de aplicativos e implementações de TCP e ao caminho de transmissão entre os itens TCP de mesmo nível. Nesta coluna, descreverei a janela de recepção TCP e seu impacto sobre a taxa de transferência de TCP, o uso de dimensionamento de janela de TCP e o novo recurso Auto-ajuste da janela de recepção do Windows Vista que otimiza a taxa de transferência de TCP quanto a dados recebidos.

Janela de recepção TCP

As conexões TCP possuem uma série de características importantes. Primeiro, são um circuito lógico ponto a ponto entre dois protocolos de Camada de Aplicativo. O TCP não fornece um serviço de entrega de um-para-muitos, mas apenas de um-para-um.

Segundo, as conexões TCP são orientadas por conexão. Antes de os dados serem transferidos, dois processos de Camada de Aplicativo devem negociar formalmente uma conexão TCP, usando o processo de estabelecimento de conexão TCP. Similarmente, as conexões TCP são formalmente fechadas após a negociação, usando o processo de término de conexão TCP.

Terceiro, os dados confiáveis enviados em uma conexão TCP são seqüenciados e espera-se uma confirmação positiva do destinatário. Caso não seja recebida uma confirmação positiva, o segmento é retransmitido. No destinatário, segmentos duplicados são descartados e segmentos que chegam fora de seqüência são recolocados na ordem certa.

Quarto, as conexões TCP são full duplex. Para cada item TCP de mesmo nível, a conexão TCP consiste em dois pipes lógicos: um pipe de saída e outro de entrada. O cabeçalho de TCP contém tanto o número de seqüência dos dados de saída, quanto uma ACK (confirmação) dos dados de entrada.

Além disso, o TCP exibe os dados enviados pelos pipes lógicos de entrada e saída como um fluxo contínuo de bytes. O número de seqüência e o número de confirmação em cada cabeçalho de TCP são definidos por limites de byte. O TCP não reconhece os limites de registro ou mensagens dentro do fluxo de bytes. O protocolo de Camada de Aplicativo deve fornecer a análise adequada do fluxo de bytes de entrada.

Para limitar a quantidade de dados que pode ser enviada por vez, a qualquer tempo, e para proporcionar controle de fluxo do destinatário, os itens TCP de mesmo nível utilizam uma janela. A janela representa a distribuição dos dados no fluxo de bytes que o destinatário permite que o remetente envie. O remetente pode enviar somente os bytes do fluxo que se encontram dentro da janela. A janela desliza ao longo do fluxo de bytes de saída do remetente e do fluxo de bytes de entrada do destinatário.

Para um dado pipe lógico (uma direção da conexão TCP full duplex), o remetente mantém uma janela de envio e o destinatário, uma janela de recepção. Quando não há segmentos de dados ou de ACK em trânsito, as janelas de envio e recepção do pipe lógico tornam-se coincidentes. Em outras palavras, a distribuição dos dados no fluxo de bytes de saída que o remetente tem permissão de enviar coincide com a distribuição dos dados no fluxo de bytes de entrada que o destinatário consegue receber. A Figura 1 ilustra essa relação de envio e recebimento.

Figura 1** Coincidindo as janelas de envio e recepção **(Clique na imagem para aumentar a exibição)

Para indicar o tamanho da janela de recepção, o cabeçalho de TCP contém um campo Window de 16 bits. Quando o destinatário recebe os dados, ele envia ACKs de volta ao remetente, indicando os bytes recebidos com êxito. Em cada ACK, o campo Window anota o número de bytes restantes na janela de recepção. Quando os dados são enviados, confirmados e recuperados pelo aplicativo, ambas as janelas, de envio e recepção, deslizam para a direita. A janela de recepção é a que controla quantos dados de confirmação podem estar em trânsito do remetente para o destinatário.

Como pode haver dados na janela de recepção que não tenham sido recuperados pelo aplicativo, bem como dados recebidos, mas não confirmados, a janela de recepção TCP possui estrutura adicional, como mostra a Figura 2.

Figura 2** Tipos de dados na Janela de recepção TCP **(Clique na imagem para aumentar a exibição)

Note a diferença entre as janelas de recepção máxima e atual. A janela de recepção máxima é de tamanho fixo. A janela de recepção atual é de tamanho variável e coincide com a quantidade de dados restante que o destinatário permite que o remetente envie. O tamanho da janela de recepção atual é o valor do campo Window anunciado nas ACKs enviadas de volta ao remetente, e é a diferença entre o tamanho máximo da janela de recepção e a quantidade de dados recebidos e confirmados, mas não recuperados pelo aplicativo.

Janela de recepção TCP e a taxa de transferência de TCP

Para otimizar a taxa de transferência de TCP (supondo um caminho de transmissão razoavelmente livre de erros), o remetente deve enviar pacotes suficientes para preencher o pipe lógico entre ele e o destinatário. A capacidade do pipe lógico pode ser calculada pela seguinte fórmula:

Capacity in bits = path bandwidth in bits per second * round-trip time (RTT) in seconds

A capacidade é conhecida como BDP (produto de atraso da largura de banda). O pipe pode ser gordo (alta largura de banda) ou magro (baixa largura de banda) e curto (baixo RTT) ou longo (alto RTT). Pipes gordos e longos têm o maior BDP. Exemplos de caminhos de transmissão de BDP alto são aqueles por satélite ou redes remotas (WANs) empresariais que contêm links intercontinentais de fibra ótica.

Aumentando o desempenho do remetente em transmissão de BDP alto

O novo recurso Auto-ajuste da janela de recepção proporciona um desempenho aprimorado para receber dados por links de BDP alto; mas, e o desempenho do remetente?

Os algoritmos existentes que impedem um item TCP de mesmo nível do remetente de sobrecarregar a rede são conhecidos como partida lenta e evitação de congestionamento. Esses algoritmos aumentam a janela de envio (o número de segmentos que o remetente pode enviar) ao enviar dados inicialmente na conexão e ao recuperar a partir de um segmento perdido.

A partida lenta aumenta a janela de envio de um segmento TCP inteiro para cada segmento de confirmação recebido (TCP em Windows XP e Windows Server 2003) ou para cada segmento confirmado (TCP em Windows Vista e Windows Server "Longhorn"). A evitação de congestionamento aumenta a janela de envio de um segmento TCP inteiro para cada janela de dados inteira que é confirmada.

Esses algoritmos funcionam bem para BDPs pequenos e tamanhos menores de janela de recepção. Entretanto, quando há uma conexão TCP com uma janela de recepção de tamanho grande e um BDP grande, como a replicação de dados entre dois servidores localizados por meio de um link WAN de alta velocidade, com tempo de viagem de ida e volta de 100 ms, esses algoritmos não aumentam a velocidade da janela de envio o bastante para utilizar totalmente a largura de banda da conexão.

Para utilizar melhor a largura de banda de conexões TCP nessas situações, a pilha TCP/IP de última geração contém CTCP (TCP Composto). O CTCP aumenta mais agressivamente a janela de envio para conexões com tamanhos grandes de janela de recepção e BDPs. O CTCP tenta maximizar a taxa de transferência nesses tipos de conexão, monitorando as variações de demora e as perdas. Além disso, o CTCP garante que seu comportamento não afete negativamente outras conexões TCP.

Em testes executados internamente na Microsoft, tempos de backup de arquivos grandes foram reduzidos quase pela metade em uma conexão de 1 Gbps com RTT de 50 ms. Conexões com BDP maior podem ter um desempenho ainda melhor. O CTCP e o Auto-ajuste da janela de recepção trabalham juntos para aumentar a utilização do link e podem resultar em ganhos substanciais de desempenho em conexões com BDPs grandes.

O CTCP encontra-se habilitado por padrão em computadores que executam o Windows Server "Longhorn" e desabilitados por padrão em computadores que executam o Windows Vista. É possível habilitar o CTCP com o comando "netsh interface tcp set global congestionprovider=ctcp". É possível desabilitar o CTCP com o comando "netsh interface tcp set global congestionprovider=none".

O tamanho do campo Window no cabeçalho de TCP é de 16 bits, o que permite a um item TCP de mesmo nível anunciar um tamanho máximo de janela de recepção de 65.535 bytes. É possível calcular a taxa de transferência aproximada para um dado tamanho de janela TCP através da seguinte fórmula:

Throughput = TCP maximum receive windowsize / RTT

Por exemplo, com uma janela de recepção de 65.535 bytes, é possível obter apenas uma taxa de transferência aproximada de 5,24 megabits por segundo (Mbps) em um caminho com RTT de 100 ms, indiferentemente da largura de banda real do caminho de transmissão. Com os caminhos de transmissão de BDP alto de hoje, o tamanho de janela TCP criado originalmente, mesmo em seu valor máximo, provoca um gargalo no tráfego.

Dimensionamento da janela TCP

Para que tamanhos de janela maiores acomodem caminhos de transmissão de alta velocidade, o RFC 1323 (ietf.org/rfc/rfc1323.txt) define o dimensionamento de janela que permite ao destinatário anunciar um tamanho de janela maior do que 65.535 bytes. Uma opção de Dimensionamento de janela TCP contém um fator de dimensionamento de janela que, quando combinado com o campo Window de 16 bits no cabeçalho de TCP, pode aumentar o tamanho da janela de recepção a um máximo de, aproximadamente, 1 GB. A opção Dimensionamento de janela é enviada somente em segmentos SYN (sincronizados) durante o processo de estabelecimento da conexão. Ambos os itens TCP de mesmo nível podem indicar fatores de dimensionamento de janela diferentes para uso no tamanho de suas janelas de recepção. Ao permitir que um remetente envie mais dados em uma conexão, o dimensionamento de janela TCP permite que os nós TCP utilizem melhor alguns tipos de caminho de transmissão com BDPs altos.

Embora o tamanho da janela de recepção seja importante para a taxa de transferência de TCP, um outro fator importante para determinar a melhor taxa de transferência de TCP é a velocidade com que o aplicativo recupera os dados acumulados na janela de recepção (a taxa de recuperação do aplicativo). Se o aplicativo não recuperar os dados, a janela de recepção pode começar a ficar cheia, fazendo com que o destinatário anuncie um tamanho menor de janela atual. Em casos extremos, a janela de recepção máxima lota, fazendo com que o destinatário anuncie um tamanho de janela de 0 byte. Nesse caso, o remetente deve interromper o envio de dados até que a janela de recepção esvazie. Portanto, para otimizar a taxa de transferência de TCP, a janela de recepção TCP da conexão deve ser definida como um valor que reflita tanto o BDP do caminho de transmissão da conexão, quanto a taxa de recuperação do aplicativo.

Mesmo que você consiga determinar corretamente o BDP e a taxa de recuperação do aplicativo, eles podem mudar no decorrer do tempo. A taxa de BDP pode variar segundo o congestionamento no caminho de transmissão e a taxa de recuperação do aplicativo, com base no número de conexões das quais o aplicativo está recebendo dados.

Janela de recepção no Windows XP

Para a pilha TCP/IP do Windows XP (e Windows Server® 2003), o tamanho máximo da janela de recepção possui uma série de atributos significativos. Primeiro, o valor padrão se baseia na velocidade do link da interface do remetente. O valor real se ajusta automaticamente a incrementos idênticos de MSS (tamanho máximo de segmento) negociados durante o estabelecimento da conexão TCP.

Segundo, o tamanho máximo da janela de recepção pode ser configurado manualmente. Os valores do Registro HKLM\System \CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize e HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize podem ser configurados como um máximo de 65.535 bytes (sem dimensionamento de janela) ou 1.073.741.823 (com dimensionamento de janela).

Terceiro, o tamanho máximo da janela de recepção pode usar dimensionamento de janela. É possível habilitar o dimensionamento de janela definindo o valor do Registro HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts como 1 ou 3. Por padrão, o dimensionamento de janela é usado em uma conexão apenas se o segmento SYN recebido contiver a opção Dimensionamento de janela.

Finalmente, o tamanho máximo da janela de recepção pode ser especificado por um aplicativo, por meio da opção SO_RCVBUF do Windows Sockets, quando uma conexão é iniciada. Para o dimensionamento da janela, o aplicativo deve especificar um tamanho de janela superior a 65.535 bytes.

Apesar de permitir o dimensionamento de janelas, o tamanho máximo da janela de recepção no Windows XP pode, mesmo assim, limitar a taxa de transferência, pois se trata de um tamanho máximo fixo para todas as conexões TCP (a menos que seja especificada pelo aplicativo), o que pode aumentar a taxa de transferência em algumas conexões e diminuir em outras. Além disso, o tamanho fixo máximo da janela de recepção em uma conexão TCP não varia com alterações na taxa de recuperação do aplicativo ou o congestionamento no caminho de transmissão.

Auto-ajuste da janela de recepção no Windows Vista

Para otimizar a taxa de transferência de TCP, especialmente em caminhos de transmissão com BDP alto, a pilha TCP/IP de próxima geração, no Windows Vista (e na próxima versão do Windows Server, de codinome "Longhorn"), dá suporte ao Auto-ajuste da janela de recepção. Este recurso determina o melhor tamanho de janela de recepção, medindo o BDP e a taxa de recuperação do aplicativo e adaptando o tamanho de janela para as condições momentâneas de caminho de transmissão e aplicativo.

O auto-ajuste da janela de recepção permite o dimensionamento de janela TCP por padrão, permitindo um tamanho máximo de janela de recepção de até 16 MB. À medida que os dados atravessam a conexão, a pilha TCP/IP de próxima geração monitora a conexão, mede seu BDP atual e a taxa de recuperação do aplicativo e ajusta o tamanho da janela de recepção de modo a otimizar a taxa de transferência. A pilha TCP/IP de próxima geração não usa mais o valor TCPWindowSize do Registro.

O auto-ajuste da janela de recepção traz uma série de benefícios. Ele determina, automaticamente, o melhor tamanho de janela de recepção a cada conexão. No Windows XP, o valor TCPWindowSize do Registro se aplica a todas as conexões. Os aplicativos já não precisam especificar tamanhos de janela TCP por meio das opções do Windows Sockets. E os administradores de TI não precisam mais configurar manualmente um tamanho de janela de recepção TCP para computadores específicos.

Com o auto-ajuste da janela de recepção, um item TCP de mesmo nível com base em Windows Vista anunciará, normalmente, tamanhos muito maiores de janela de recepção do que um item TCP de mesmo nível baseado em Windows XP. Isso permite ao outro item TCP de mesmo nível preencher o pipe para o item TCP baseado em Windows Vista, enviando mais segmentos de dados de TCP sem ter que esperar por uma ACK (sujeita ao controle de congestionamento de TCP). No caso de tráfego típico de sistemas de rede baseados em cliente, como páginas da Web ou email, o servidor Web ou de email poderá enviar mais dados TCP mais rapidamente para o computador cliente, resultando em um aumento global no desempenho da rede. Quanto maior o BDP e a taxa de recuperação do aplicativo na conexão, maior o aumento de desempenho.

O impacto na rede é que um fluxo de pacotes de dados TCP, que normalmente seria enviado a um ritmo menor e mais comedido, é enviado muito mais rapidamente, o que resulta em um maior pico de utilização da rede durante a transferência dos dados. No caso de computadores baseados em Windows XP e Windows Vista realizando a mesma transferência de dados por um mesmo pipe longo e gordo, é transferida a mesma quantidade de dados. No entanto, a transferência de dados do computador cliente baseado em Windows Vista é mais veloz, devido ao tamanho maior de janela de recepção e da capacidade do servidor de preencher o pipe do servidor para o cliente.

Uma vez que o auto-ajuste da janela de recepção aumentará a utilização da rede de caminhos de transmissão com BDP alto, o uso de QoS (Qualidade de Serviço) ou a limitação da taxa de envio do aplicativo pode se tornar importante para caminhos de transmissão operando próximos ou já na capacidade total. Para cuidar dessa possível necessidade, o Windows Vista dá suporte a configurações de QoS baseadas em Diretiva de Grupo, que lhe permitem definir taxas de limitação para envio de tráfego por endereço IP ou porta TCP. Para obter mais informações, consulte recursos de QoS baseadas em diretivas. 

Aumentando a taxa de transferência de TCP em redes com grandes perdas

Redes com grandes perdas podem diminuir expressivamente a taxa de transferência, devido a expirações de tempo limite de conexão e retransmissões freqüentes. São exemplos de rede com grandes perdas redes sem fio – como aquelas baseadas em IEEE 802.11, GPRS (General Packet Radio Service) ou UMTS (Universal Mobile Telecommunications System) – que podem ter muitas perdas de pacotes dependendo das condições de rede, da atenuação de sinal, de interferências eletromagnéticas e da mudança de local do computador.

A pilha TCP/IP de próxima geração dá suporte aos quatro RFCs a seguir para otimizar a taxa de transferência em ambientes de grandes perdas.

RFC 2582: a modificação de NewReno para o Algoritmo de Recuperação Rápida do TCP

O algoritmo de Recuperação Rápida, definido no RFC 2001, baseia-se no algoritmo de Reno, que aumenta a quantidade de dados que um remetente pode enviar quando um segmento é retransmitido devido a um evento de retransmissão rápida. Embora o algoritmo de Reno funcione bem para segmentos únicos perdidos, ele não funciona tão bem quando há mais de um segmento perdido. O algoritmo NewReno permite uma taxa de transferência maior, alterando a forma pela qual o remetente pode aumentar a sua velocidade de envio durante a recuperação rápida quando vários segmentos de uma janela de dados são perdidos e o remetente recebe uma confirmação parcial (uma confirmação de que somente uma parte dos dados foram recebidos com êxito).

RFC 2883: uma extensão à opção SACK (confirmação seletiva) para TCP

O SACK, definido no RFC 2018, permite que um destinatário indique até quatro blocos não contíguos de dados recebidos para usar a opção SACK de TCP. O RFC 2883 define um uso adicional dos campos na opção SACK TCP para confirmar pacotes duplicados. Isso permite que o remetente perceba quando retransmitir desnecessariamente um segmento e ajuste o seu comportamento para evitar futuras retransmissões desnecessárias. Quanto menos retransmissões forem enviadas, melhor será a taxa de transferência global.

RFC 3517: um algoritmo conservador de recuperação de perdas baseado em SACK (confirmação seletiva) para TCP

A implementação atual de TCP/IP no Windows Server 2003 e no Windows XP usa informações de SACK apenas para determinar quais segmentos TCP não chegaram ao destino. O RFC 3517 define um método de uso das informações de SACK para executar a recuperação de perdas quando confirmações duplicadas forem recebidas, substituindo o algoritmo de recuperação rápida mais antigo quando o SACK estiver habilitado em uma conexão. A pilha TCP/IP de próxima geração controla as informações de SACK por conexão e monitora as confirmações de entrada e duplicadas para uma recuperação mais rápida quando vários segmentos não forem recebidos no destino.

RFC 4138: F-RTO (Forward RTO-Recovery): um algoritmo para a detecção de tempos limite falsos de retransmissão com os protocolos TCP e SCTP.

Podem ocorrer falsas retransmissões de segmento de TCP com um aumento repentino de RTT, fazendo com que os RTOs (tempos limite de retransmissão) dos segmentos enviados anteriormente comecem a expirar e o TCP passe a retransmiti-los. Se ocorrer um aumento pouco antes do envio de uma janela completa de dados, o remetente pode retransmitir toda a janela de dados. O algoritmo F-RTO evita a retransmissão falsa de segmentos de TCP, por meio do comportamento a seguir.

Quando o RTO de vários segmentos expira, o TCP retransmite apenas o primeiro segmento. Quando a primeira confirmação é recebida, o TCP começa a enviar novos segmentos (se permitido pelo tamanho de janela anunciado). Se a confirmação seguinte confirmar os outros segmentos cujo tempo limite expirou, mas não foram retransmitidos, o TCP determinará que a expiração de tempo limite era falsa e não retransmitirá os outros segmentos nessa situação.

O resultado desse comportamento é que, em ambientes que passam por aumentos repentinos e temporários de RTT (como ocorre quando um cliente sem fio passa de um ponto de acesso para outro), o F-RTO impede a retransmissão desnecessária de segmentos e volta mais rapidamente à sua taxa de envio normal. O uso da recuperação de perdas por SACK e do F-RTO é mais adequado para conexões que utilizam links GPRS.

Joseph Davies é redator técnico da Microsoft, e vem ensinando e escrevendo sobre tópicos de sistema de redes Windows desde 1992. Escreveu cinco livros para a Microsoft Press e é autor da coluna mensal The Cable Guy da Technet (em inglês).

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..