Melhorias de desempenho da Next Generation TCP/IP Stack

Por The Cable Guy

Este artigo descreve as melhorias de desempenho da Next Generation TCP/IP Stack, entre elas o ajuste automático da janela de recebimento, melhoria do tráfego sem fio e melhorias na detecção e recuperação do caminho de roteamento.

Nesta página

Introdução
Ajuste automático da janela de recebimento
Melhorias do tráfego sem fio
Melhorias na detecção e recuperação do caminho de roteamento
Detecção de inacessibilidade com vizinhos do IPv4
Suporte a failback para alterações do gateway padrão
Para obter mais informações

Introdução

A pilha TCP/IP no Microsoft Windows 2000 apresentou um conjunto de melhorias de desempenho, entre elas o dimensionamento da janela de recebimento do TCP, confirmações seletivas e melhor estimativa da viagem de ida e volta (RTT). Nos anos posteriores ao lançamento do Windows 2000, houve muitas mudanças na largura de banda da rede, incluindo o maior predomínio do uso de links com grande largura de banda e sem fio. A Next Generation TCP/IP Stack do Windows Vista (atualmente na fase de testes beta) e do Windows Server "Longhorn" (também na fase de testes beta) inclui um novo conjunto de melhorias de desempenho para aumentar a taxa de transmissão em ambientes de rede com grande largura de banda, alta latência e alta perda de dados.

Este artigo descreve as seguintes melhorias de desempenho:

• Ajuste automático da janela de recebimento

• Melhoria do tráfego sem fio

• Melhorias na detecção e recuperação do caminho de roteamento

Ajuste automático da janela de recebimento

O tamanho da janela de recebimento do TCP é a quantidade de bytes em um buffer de memória de um host receptor usado para armazenar os dados de entrada por meio de uma conexão TCP. Após o estabelecimento da conexão, o tamanho da janela de recebimento é divulgado em cada segmento TCP. A divulgação do espaço restante no buffer da memória de recebimento é um mecanismo de controle de fluxo no lado do destinatário que evita que o remetente envie dados que o destinatário não será capaz de armazenar. Um host remetente pode enviar apenas a quantidade máxima de dados divulgada pelo destinatário antes de aguardar a confirmação e uma atualização do tamanho da janela de recebimento.

Janelas de recebimento no Windows Server 2003 e no Windows XP

Para a pilha TCP/IP do Windows Server 2003 e do Windows XP, o tamanho máximo da janela de recebimento:

• Tem um valor padrão de acordo com a velocidade do link da interface de envio O valor real se ajusta automaticamente a incrementos iguais ao tamanho máximo de segmento (MSS) negociado durante o estabelecimento da conexão TCP.

• Pode ser configurado manualmente Os valores de registro HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize e HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\TCPWindowSize podem ser configurados com no máximo 65.535 bytes (sem dimensionamento de janela) ou 1.073.741.823 (com dimensionamento de janela). Sem o dimensionamento da janela, é possível obter apenas uma taxa de transmissão de aproximadamente 5 megabits por segundo (Mbps) em um caminho cujo RTT é de 100 milissegundos, independentemente da largura de banda do caminho.

• Pode ser dimensionado até 1 gigabyte (GB) com o dimensionamento da janela O dimensionamento da janela, definida em RFC 1323, permite que o TCP negocie um fator de dimensionamento do tamanho da janela durante o estabelecimento da conexão. Você pode habilitar o dimensionamento da janela definindo o valor de registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts em 1 ou 3. Por padrão, o dimensionamento da janela é usado em uma conexão apenas se o segmento de sincronização (SYN) recebido contiver a opção Dimensionamento da Janela.

• Pode ser especificado por um aplicativo Um aplicativo pode especificar o tamanho máximo da janela de recebimento de uma conexão, usando a opção SO_RCVBUF do Windows Sockets quando uma conexão for iniciada. Para o dimensionamento da janela, o aplicativo deve especificar um tamanho de janela superior a 65.535 bytes.

Muitas vezes, é difícil determinar o valor correto da janela de recebimento. Para preencher a capacidade da rede entre o remetente e o destinatário, o tamanho da janela deve ser configurado de acordo com o produto do atraso da largura de banda da conexão, que é a largura de banda multiplicada pelo tempo da viagem de ida e volta. Mesmo que você determine corretamente o produto do atraso da largura de banda, não saberá a velocidade com que o aplicativo receptor recuperará os dados do buffer de entrada de dados (a taxa de recuperação do aplicativo).

Apesar de permitir o dimensionamento de janelas, o tamanho máximo da janela de recebimento no Windows Server 2003 e no Windows XP pode, mesmo assim, limitar a taxa de transmissão porque se trata de um tamanho máximo fixo para todas as conexões TCP (a menos que o aplicativo especifique em contrário), o que pode aumentar a taxa de transmissão em algumas conexões e diminuir em outras. Além disso, o tamanho máximo fixado da janela de recebimento em uma conexão TCP não varia com a alteração das condições da rede.

Janela de recebimento na Next Generation TCP/IP Stack

Para solucionar o problema de determinar corretamente o valor do tamanho máximo da janela de recebimento de uma conexão com base nas condições de momento da rede, a Next Generation TCP/IP Stack permite o ajuste automático da janela de recebimento. O ajuste automático da janela de recebimento determina continuamente o tamanho ideal da janela de recebimento, medindo o produto do atraso da largura de banda e a taxa de recuperação do aplicativo, ajustando o tamanho máximo da janela de recebimento de acordo com a mudança nas condições da rede.

O ajuste automático da janela de recebimento permite o dimensionamento da janela de TCP por padrão, permitindo que o tamanho da janela chegue a até 16 MB. À medida que os dados atravessam a conexão, a Next Generation TCP/IP Stack monitora a conexão, mede o produto do atraso da largura de banda do momento na conexão e a taxa de recuperação do aplicativo, e ajusta o tamanho da janela de recebimento para otimizar a taxa de transmissão. A Next Generation TCP/IP Stack não usa mais os valores de registro TCPWindowSize.

Com uma taxa de transmissão maior entre os pontos TCP, o uso da largura de banda da rede aumenta durante a transferência de dados. Se todos os aplicativos forem otimizados para receber dados de TCP, o uso geral da rede pode aumentar consideravelmente, tornando mais importante o uso da QoS (Qualidade de Serviço) nas redes que operam na sua capacidade máxima ou perto dela.

Melhorias do tráfego sem fio

As redes sem fio — como as que utilizam o IEEE 802.11, o GPRS (Serviço Geral de Rádio por Pacotes), ou o UMTS (Sistema Universal de Telecomunicações Móveis) — proporcionam mobilidade e conectividade em todos os lugares para dispositivos portáteis de computação. Entretanto, as redes sem fio também podem sofrer grandes perdas de pacotes, dependendo das condições da rede, da atenuação do sinal, de interferências eletromagnéticas e da mudança de local do computador móvel. Em ambientes de rede com grande perda, as freqüentes desconexões por tempo e retransmissões de TCP podem reduzir radicalmente a taxa de transmissão.

A Next Generation TCP/IP Stack permite o uso dos seguintes RFCs para otimizar a taxa de transmissão em ambientes de grande perda:

• RFC 2582: A modificação do NewReno para o algoritmo de recuperação rápida de TCP
  O algoritmo de recuperação rápida, definido no RFC 2001, baseia-se no algoritmo 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 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 da opção SACK (Confirmação Seletiva) para TCP
  A SACK, definida no RFC 2018, permite que um receptor indique até quatro blocos não-contíguos de dados recebidos. O RFC 2883 define um uso adicional dos campos na opção SACK TCP para confirmar pacotes duplicados. Isso permite que o remetente de um segmento TCP que contenha a opção SACK determine quando retransmitiu um segmento desnecessariamente e ajuste o seu comportamento para evitar futuras retransmissões. Quanto menos retransmissões forem enviadas, melhor será a taxa de transferência total.

• RFC 3517: Um algoritmo conservador de recuperação de perdas com base em SACK (Confirmação Seletiva) para TCP
  A atual implementação de TCP/IP no Windows Server 2003 e no Windows XP utiliza informações de SACK apenas para determinar quais segmentos TCP não chegaram ao seu destino. O RFC 3517 define um método de uso de informações de SACK para recuperar perdas quando forem recebidas confirmações duplicadas, substituindo o algoritmo de recuperação rápida quando a SACK estiver habilitada em uma conexão. A Next Generation TCP/IP Stack mantém o controle das informações de SACK antes da conexão e monitora o recebimento de confirmações e de confirmações duplicadas, permitindo uma recuperação mais rápida quando vários segmentos não forem recebidos no destino.

• RFC 4138: F-RTO (Recuperação por Forward RTO): Um algoritmo para detecção de desconexões falsas de retransmissões por tempo com o TCP e o SCTP (Protocolo de Transmissão de Controle de Fluxo)
  Retransmissões falsas de segmentos TCP podem ocorrer quando houver um aumento repentino e temporário do RTT. Quando esse aumento ocorre, as RTOs (desconexões de retransmissões por tempo) de segmentos anteriormente enviados começam a vencer e o TCP começa 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 TCP através do seguinte comportamento:

  Quando o RTO de vários segmentos expirar, o TCP retransmite apenas o primeiro segmento. Quando a primeira confirmação for reconhecida, o TCP começa a enviar novos segmentos (se isso for permitido pelo tamanho divulgado da janela). Se a confirmação seguinte confirmar os outros segmentos que foram desconectados por tempo, mas que não foram retransmitidos, o TCP conclui que a desconexão por tempo foi falsa e não retransmite os outros segmentos desconectados por tempo.

  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 AP sem fio para outro), o F-RTO impede a retransmissão desnecessária de segmentos e volta mais rapidamente à sua velocidade normal de envio. O uso da recuperação de perdas por SACK e do F-RTO é mais adequado para conexões que utilizam links GPRS.

Melhorias na detecção e recuperação do caminho de roteamento

Para tentar automaticamente um novo caminho de roteamento de tráfego remoto quando as conexões TCP começam a retransmitir segmentos, a pilha TCP/IP do Windows Server 2003 e do Windows XP permitem a detecção de gateway inativos. A detecção de gateways inativos é um mecanismo de failover que muda automaticamente o gateway padrão de um computador para o gateway padrão configurado seguinte (quando um computador estiver configurado com vários gateways padrão em uma interface). Entretanto, a detecção de gateways inativos no Windows Server 2003 e no Windows XP não faz o seguinte:

• Distinguir se o gateway padrão local falhou ou se um gateway remoto (roteador) falhou.

• Oferecer um método de failback para fazer o gateway padrão voltar a ser o gateway padrão principal quando o caminho de roteamento principal for restaurado.

A Next Generation TCP/IP Stack soluciona esses problemas por meio da detecção de inacessibilidade com vizinhos do IPv4 e da possibilidade de failback no caso de mudança automática de configuração do gateway padrão.

Detecção de inacessibilidade com vizinhos do IPv4

Detecção de inacessibilidade de vizinhos é um recurso do IPv6 que permite que um nó verifique a possibilidade de comunicação com um nó vizinho. A comunicação com um nó vizinho é possível se houve uma confirmação recente de que pacotes IPv6 enviados ao nó vizinho foram recebidos e processados por esse nó. O IPv6 verifica a possibilidade de acesso por meio da troca de mensagens unicast de solicitação ao vizinho e divulgação do vizinho, ou utilizando protocolos de camada superior tais como o TCP para indicar se uma conexão está enviando e recebendo dados. Com a detecção de inacessibilidade de vizinhos, um nó IPv6 pode determinar quando a comunicação com um nó vizinho deixou de ser acessível e transmitir a condição de erro a outros componentes e aplicativos.

A Next Generation TCP/IP Stack também permite a detecção de inacessibilidade com vizinhos para tráfego de IPv4, verificando as condições de acesso de vizinhos IPv4 na cache de roteamento do IPv4. A detecção de inacessibilidade de vizinhos do IPv4 verifica a possibilidade de acesso por meio de troca de mensagens unicast de solicitação do protocolo ARP e de resposta ARP, ou utilizando protocolos de camada superior tais como o TCP. Com a detecção de inacessibilidade de vizinhos do IPv4, as comunicações por IPv4 se beneficiam do fato de saber quando os nós vizinhos, inclusive roteadores, ficam inacessíveis e passam a transmitir essa condição.

Com a Next Generation TCP/IP Stack, caso as conexões TCP comecem a retransmitir segmentos, a pilha tenta determinar se ainda é possível a comunicação com o gateway padrão atual, enviando uma mensagem unicast de Solicitação ARP. Se o roteador padrão não responder, a Next Generation TCP/IP Stack altera o gateway padrão para o gateway seguinte da lista. Caso o roteador padrão responda, a detecção do gateway inativo pode alterar o gateway padrão para o gateway seguinte da lista.

Suporte a failback para alterações do gateway padrão

No TCP/IP para Windows Server 2003 e Windows XP, quando a detecção do gateway inativo altera o gateway padrão, o novo gateway padrão permanece sendo o gateway principal para o tráfego de roteamento padrão até que a detecção de gateways inativos alterne para o gateway seguinte da lista (passando por toda a lista de gateways padrão) ou até que o computador seja reiniciado. Portanto, a detecção de gateways inativos no TCP/IP do Windows Server 2003 e do Windows XP realiza uma função de failover, mas não de failback.

A falta de failback para gateways padrão pode causar problemas com a velocidade de transferência em uma sub-rede que contém dois roteadores: um roteador principal de alta capacidade e um roteador de reserva de baixa capacidade. Se houver uma falha temporária com o roteador de alta capacidade, a detecção de gateways inativos pode fazer os hosts da sub-rede alternarem para o roteador reserva. Quando o roteador de alta capacidade voltar a ficar disponível, nenhum dos hosts da rede o utilizará, porque passaram a usar o roteador de reserva.

A Next Generation TCP/IP Stack permite o failback de gateways inativos, tentando periodicamente enviar tráfego de TCP por meio do gateway inativo. Se o tráfego de TCP enviado através do gateway inativo for bem-sucedido, a Next Generation TCP/IP Stack alterna o gateway padrão para o gateway inativo determinado anteriormente.

No nosso exemplo com o roteador de alta capacidade e o roteador de reserva de baixa capacidade, caso o roteador de alta capacidade fique indisponível, os hosts da sub-rede alternam os seus gateways padrão para o roteador de reserva e tentam periodicamente enviar tráfego de TCP através do roteador de alta capacidade. Quando o roteador de alta capacidade voltar a ficar disponível e os hosts constatarem que o tráfego de TCP enviado através do roteador de alta capacidade foi recebido com êxito, os hosts da sub-rede alternem o seu gateway padrão de volta para o roteador de alta capacidade.

O suporte de failback para os gateways padrão principais pode aumentar a velocidade de transferência enviando o tráfego através do gateway padrão principal da sub-rede.

Para obter mais informações

Para obter mais informações sobre o TCP/IP no Windows, consulte os seguintes recursos:

• Next Generation TCP/IP Stack in Windows Vista and Windows Server "Longhorn" (em inglês)

• Microsoft Windows Server 2003 TCP/IP Implementation Details (em inglês)

Para enviar comentários sobre o conteúdo desta coluna, escreva para o Microsoft TechNet. Lembre-se de que este não é um alias de suporte e o recebimento de uma resposta não é garantido.

Para obter uma lista e mais informações sobre todas as colunas do The Cable Guy, clique aqui.