Como o balanceador de carga gerencia conexões TCP?

5

Tenho dúvidas sobre como lidar com conexões TCP por meio do balanceador de carga.

Tenho três servidores atrás do meu balanceador de carga e, às vezes, devido a algumas tarefas de processamento, não há dados sendo enviados entre servidores e clientes. Após cinco minutos, as conexões ociosas serão descartadas porque o servidor enviou sinalizador RST. redefinido pelo par). Eu queria saber balanceador de carga poderia ser responsável por isso, então eu usei WireShark para capturar pacotes TCP com RST FLAG, e capturou esses pacotes.

A minha pergunta é, se o balanceador de carga for responsável por redefinir a conexão, não verei os pacotes RST no lado do servidor, pois ele foi enviado pela LB com IP de origem alterado? Ou talvez eu esteja errado, e ainda é possível capturá-lo no lado do servidor, mesmo que o LB esteja enviando pacotes RST?

EDIT 1

Eu gostaria de restringir (ou talvez melhorar) a minha pergunta. Se alguma coisa entre o cliente e o servidor envia um pacote com o RST, ele deve estar visível no cliente e no servidor ou apenas em um desses (cliente, por exemplo)?

EDIT 2

Eu capturei pacotes com sinalizador RST no lado do cliente e do servidor, e o que é estranho é que no lado do cliente parece que o servidor LB enviou, e no lado do servidor parece que o cliente enviou (por fonte / IP de destino)

    
por whd 17.02.2017 / 09:08

1 resposta

11

Tanto quanto eu posso ver, este é o seu equívoco sobre tópicos de redes, incluindo Camadas OSI e métodos de comunicação.

Para responder brevemente à sua pergunta principal, devo dizer que a maneira como o seu LoadBalancer está tratando completamente depende da sua configuração e de como você definiu / quis que ela estivesse sendo tratada. Mas para mostrar como o LoadBalancing realmente funciona nas Camadas 4 e 7 do Modelo OSI, leia as seguintes informações:

Primeiro de tudo, sobre pacotes RST você deve notar que o que você mencionou é totalmente comum porque o RST é usado para redefinir a conexão e pode ocorrer em ambos os lados, dependendo do que não pode ser concluído e quando não há mais conversa acontecendo entre servidor e cliente enquanto a conexão ainda não terminou. Trecho de uma resposta em Quora , um pacote RST é enviado no meio do handshake de 3 vias quando o servidor rejeita a conexão ou não está disponível OU no meio da transferência de dados quando o servidor ou o cliente se torna indisponível ou rejeita comunicação adicional sem o processo formal de encerramento da conexão TCP de 4 vias .

O protocolo de controle de transmissão (TCP) opera na camada transporte (camada 4 no modelo OSI). O TCP fornece entrega confiável, ordenada e verificada por erros de um fluxo de octetos e cria uma conexão virtual entre aplicativos executados em hosts que se comunicam por uma rede IP. Em outras palavras, ele fornece um serviço de comunicação em um nível intermediário entre um programa aplicativo e o Internet Protocol, e como os pacotes IP podem - podem - ser perdidos, corrompidos ou chegar fora de ordem, o TCP possui mecanismos para corrigir esses erros, transformando o fluxo de pacotes IP em um canal de comunicação confiável. Cada aplicativo recebe um número de porta TCP exclusivo para permitir a entrega para o aplicativo correto em hosts nos quais muitos aplicativos estão em execução. Por exemplo, a porta TCP padrão 22 foi atribuída para contatar os servidores SSH - as portas padrão podem ser alteradas nos arquivos de configuração, se necessário.

No endereço IP do balanceador de carga da camada 4, o balanceamento de carga é anunciado aos clientes de um site ou serviço. Assim, como poderia ter sido adivinhado, o endereço de destino registrado nos pedidos dos clientes seria o endereço do LoadBalancer. Quando o balanceador de carga da Camada 4 recebe uma solicitação e toma a decisão de balanceamento de carga, ela também realiza a conversão de endereços de rede (NAT) no pacote de solicitação, alterando o endereço IP de destino registrado do próprio para o do servidor de conteúdo escolhido na rede interna. Por exemplo, em seu cenário, seu LoadBalancer mudará seu próprio endereço para o que é necessário para servir o serviço solicitado ao cliente, para ser mais explícito, vamos considerar um de seus três servidores por trás do LoadBalancer sendo servido como seu servidor de armazenamento e o cliente está disposto a ler um PDF ou qualquer conteúdo em seu site. O endereço de destino do cliente é definido para o endereço IP público que é atribuído ao seu LoadBalancer e quando o LoadBalancer recebe a solicitação ele decidirá qual servidor - na própria rede interna - ele deve mapear a solicitação dependendo das regras que você tiver configurado e configurado no seu LoadBalancer. Da mesma forma, antes de encaminhar as respostas do servidor aos clientes, o balanceador de carga altera o endereço de origem registrado no cabeçalho do pacote do endereço IP do servidor interno - seu armazenamento, por exemplo - para o seu próprio. (Os números de porta TCP de destino e origem gravados nos pacotes às vezes também são alterados de maneira semelhante.) Em seguida, ele toma suas decisões de roteamento com base nas informações de endereço extraídas dos primeiros pacotes no fluxo TCP e não inspeciona o conteúdo do pacote.

E para responder "se o balanceador de carga for responsável por redefinir as conexões, não verei os pacotes RST no lado do servidor, pois ele está sendo enviado pelo LB com o ip de origem alterado?", devo dizer que você só verá pacotes RST em outro servidores se a conexão deles precisar ser redefinida com o LoadBalancer, não a conexão do cliente com o LoadBalancer.

BTW, eu recomendo que você use o tcpdump em seus servidores internos para ver se você pode receber solicitações do LoadBalancer ou não, assim você pode ver o que está errado e você vai descobrir como corrigir seus problemas. Não se preocupe usando o WireShark, é uma ferramenta brilhante, mas você deve estar familiarizado o suficiente para entender o que está mostrando.

    
por 20.02.2017 / 07:43