Solução de problemas com grande número de retransmissões TCP / dup ack / segmento perdido

Question

Eu tenho um problema com o RDC diminuindo para um rastreamento ou desconectando totalmente. O cliente é o XP SP3 com RDC 6, o servidor é o Win 2k8 R2. Ambos foram examinados completamente e estão livres de vírus.

Eu baixei e instalei o Wireshark no computador cliente e executei uma captura de pacotes durante uma sessão RDC. O log mostrou pelo menos 10-20 retransmissões / dup ack / perdas de segmento por minuto durante o uso normal. Então, quando tive uma desconexão, disparou para dezenas dessas por segundo.

FYI, eu sei muito pouco sobre a ferramenta Wireshark ou como fazer uma análise completa desse problema.

** EDITAR **

Um pouco sobre minha arquitetura de rede:

Cliente -

• 12 Mb para baixo, 1 Mb para cima
• 1 laptop conectado diretamente ao modem - ou - (tentei desta forma sem alterações) conectado por meio de uma caixa de telefone Linksys DSL
• Localizado em Israel. Os serviços de telecomunicações são divididos em infra-estrutura e ISP, a infraestrutura é fornecida pelo HOT, o ISP é fornecido pelo Netvision.

Servidor -

• 5 Mb para baixo, 5 Mb para cima
• Média rede de hospedagem web / dados / aplicativos, roteada com a Allied Telesyn AR410
• Localizado em CA (EUA). O ISP é chamado América.

Outros clientes remotos não têm problemas para se conectar aos servidores (velocidade ou desconexões). Vários outros laptops foram usados no local do cliente para verificar se não é um problema de hardware. O modem a cabo também foi substituído.

    

Answer 1

Provavelmente não há informações suficientes, mas aqui estão algumas orientações gerais:

Se outros clientes remotos estiverem bem e não tiverem o sintoma, o problema provavelmente não está no servidor. Pode ser a conexão para esse cliente.

Uma retransmissão normalmente significa que um pacote não foi reconhecido, portanto geralmente não haverá "erros" em uma captura de pacotes. Isso significa que uma extremidade estava enviando os pacotes e a outra não foi confirmada. Você pode querer realizar a captura de ambas as extremidades, para determinar se a retransmissão é unidirecional ou ambas as maneiras.

Se você fizer ping no host do cliente, qual é o tempo de resposta? Se for mais de 150 ms, você poderá ter uma conexão abaixo do ideal.

A configuração do adaptador de rede do servidor para Large Send Offload deve ser desativada. O Windows deve ser inteligente o suficiente para saber que não pode enviar pacotes grandes para máquinas em sub-redes diferentes, mas infelizmente nem sempre é esse o caso. Se o seu servidor for um convidado hyper-v, isso é quase certamente o problema.

MTU. De um modo geral, acessando um servidor remotamente quando você não está na mesma sub-rede, a MTU deve ser sempre a menor MTU entre os dois pontos de extremidade. E isso geralmente significa o cliente. Para clientes remotos que se conectam através de VPN, não é incomum ter um MTU de 1400 ou até menor. Pode ser vantajoso definir o MTU do servidor para corresponder ao que seria o MTU mais baixo, para evitar problemas em que o MTU não possa ser descoberto corretamente (às vezes chamado de roteadores de buraco negro). Para encontrar o MTU para sua conexão, você pode inserir o seguinte comando do seu cliente:

ping -f -l xxxx <server ip>

Onde xxxx é o tamanho da MTU. Comece com 1400. Se funcionar, aumente até exibir a mensagem "O pacote precisa ser fragmentado, mas o DF setado". Se 1400 não funcionar, diminua até que isso aconteça. O maior número que funciona é o seu tamanho de carga útil. Adicione 28 ao tamanho da carga útil e essa é a sua MTU.

Você pode definir a MTU do servidor no seguinte local do registro:

HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{guid of the network adapter}  

FYI - Os pacotes RDP são sempre enviados com o conjunto de bits "Não fragmentar".

    

Answer 2

Esteja ciente de que o Monitor de Rede geralmente sinaliza erroneamente os pacotes como 'Segmento Perdido' no início de uma captura para qualquer conversa TCP iniciada antes da captura.

Isso porque o Netmanager verá Agradecimentos (Números de Sequência) para pacotes que ocorreram antes do início da captura. Como ele vê o ACK sem ver o pacote correspondente, ele assume que o pacote está perdido e sinaliza com 'Segment Lost'. Tenha cuidado para não confundir este início do segmento de perda de captura com as sequências perdidas reais. Se você classificar uma conversa por fluxo de IP individual, deverá classificar para o topo.

Como alternativa, você pode salvar a captura em um arquivo e recarregá-lo no Netmanager. Percebi que ele não sinaliza mais o início dos reconhecimentos de captura como "Segmento perdido" após o recarregamento.

    

Answer 3

Você está recebendo os seguintes pacotes:

1. TCP retransmite
2. ACK duplicado
3. Segmento perdido

Se você receber uma retransmissão TCP, isso ocorre porque o ACK que você enviou não foi recebido pelo servidor. O servidor não sabia que o pacote TCP foi recebido, acha que foi perdido e o enviará novamente.

O ACK duplicado é normalmente recebido no remetente no seguinte cenário:

• Receptor recebe o pacote 1
• O receptor envia o ACK para o pacote 1
• Receptor recebe o pacote 3
• O receptor envia o ACK para o pacote 1 (número de seqüência máximo do pacote recebido). Este é um ACK duplicado para o remetente.
• Receptor recebe o pacote 4
• O receptor envia o ACK para o pacote 1 (número de seqüência máximo do pacote recebido). Este é um ACK duplicado para o remetente.

O terceiro erro (segmento perdido) é exatamente esse cenário, mas no lado do receptor. Indica que o pacote 3 foi recebido antes do pacote 2.

Todos esses erros indicam congestionamento: em algum lugar ao longo do caminho, os pacotes são descartados. Isso pode ter muitas causas, por isso precisamos realmente de uma boa indicação de sua arquitetura de rede para poder lhe dizer qual é a causa.

Normalmente, o congestionamento não é uma coisa ruim. O TCP é feito para se ajustar automaticamente a esse cenário, aumentando a taxa de transferência até que o descarte / redução de pacotes comece a ocorrer. O fato de que o congestionamento apresenta problemas aqui pode ter várias causas diferentes:

1. Sua rede está tão congestionada que não consegue lidar com a taxa de transferência mínima necessária para o RDP. Este seria o caso de uma conexão de telefone celular 2G.
2. Os algoritmos no servidor ou no cliente estão mal configurados. Alguns programas "otimizadores" do ADSL podem causar isso, mexendo nos parâmetros do algoritmo TCP do Vegas no Windows.
3. Existe algum outro erro (carga muito alta no servidor ou no cliente, firmware / driver inválido para a placa de rede, ...)