Como o anycast funciona com o tcp?

Question

O TCP, sendo stateful, deve exigir que os pacotes subseqüentes atinjam o mesmo servidor. O HTTP (Stateless) é executado sobre TCP e os CDNs podem usar anycast.

Então, como o TCP funciona com o anycast? E se o syn e o ack forem para servidores diferentes? Acho que ouvi falar que o Google tem alguma solução para isso, mas não tenho certeza.

Por favor, responda tanto para IPv4 quanto para IPv6, se houver alguma diferença.

    

Answer 1

Esse é um desses muitos desafios, que podem ser abordados de muitas maneiras diferentes. A abordagem mais simples é ignorá-lo e esperar pelo melhor. Enquanto o roteamento não mudar no meio da conexão, tudo ficará bem. Mas quando o roteamento muda, ele irá quebrar todas as conexões afetadas pela mudança de roteamento. As outras respostas já se aprofundam com essa abordagem.

Outra abordagem é rastrear para onde as conexões são roteadas. Se um pacote for roteado para o POP errado, o CDN pode encapsular o pacote para o POP correto para processamento adicional. Isso introduz uma sobrecarga adicional, o cliente experimentará um aumento de latência quando isso acontecer. Essa latência aumentada persistirá durante a vida útil da conexão. Mas é provável que seja melhor para a experiência do usuário do que uma conexão quebrada.

Em termos de consumo de largura de banda, a sobrecarga não é muito significativa, porque afeta apenas os pacotes em uma direção, e essa tende a ser a direção com o menor uso de largura de banda.

O rastreamento pode ser feito no nível da conexão ou rastreando qual é o POP preferido para servir cada endereço IP de cliente individual. A estrutura de dados mais óbvia para rastrear as conexões seria uma tabela de hash distribuída.

Se o cliente suportar MPTCP, existe outra solução que pode ser usada. Assim que a conexão for estabelecida, o servidor abrirá outro subfluxo usando um endereço IP unicast. Se esse subfluxo for estabelecido com sucesso, a conexão poderá sobreviver à mudança do roteamento do endereço anycast, simplesmente usando o endereço unicast para a vida útil restante da conexão.

Em princípio, todas as abordagens acima seriam as mesmas para IPv4 e IPv6. Mas, na prática, algumas soluções podem não funcionar tão bem no IPv4 devido à falta de endereços IP.

Por exemplo, a abordagem MPTCP exige que cada servidor tenha um endereço IP público para funcionar bem. Uma grande configuração de balanceamento de carga pode ter muitos servidores para atribuir um endereço IP público a cada um. Além disso, estabelecer o novo subfluxo não pode ser iniciado pelo servidor, se o cliente estiver por trás de um NAT, o que geralmente é o caso do IPv4. Isso significa que o servidor teria que enviar o endereço IP unicast como uma opção sobre o subfluxo inicial e permitir que o cliente inicie o subfluxo extra.

Eu não sei qual das abordagens acima foi usada por CDNs.

    

Answer 2

Funciona melhor do que o esperado, especialmente para sessões TCP que geralmente têm vida curta, como aquelas geradas por clientes HTTP.

O Anycast assume que a topologia da rede não vai mudar durante a duração da sessão e, se mudar, não é provável que outro ponto de extremidade esteja subitamente mais próximo do que aquele que negociou a sessão. O protocolo do aplicativo deve lidar com esse tipo de atividade de desconexão / reconexão.

Os CDNs funcionam muito bem no Anycast, já que todo o seu modelo de negócios é de sessões TCP de curta duração, com transferência de rede significativamente unidirecional fora de sua rede. Se o fluxo ACK acabar indo para algum lugar diferente do ponto de extremidade para o qual foi originalmente negociado, a conexão será interrompida para esse ativo.

    

Answer 3

Anycast é melhor descrito como um esquema de roteamento "de um para mais próximo" e normalmente funciona com o BGP (Border Gateway Protocol) anunciando IPs de destino de várias origens, resultando em roteamento dos pacotes para os IPs de destino mais próximos listado.

Então, no sentido amplo, anycast é usado apenas para descobrir qual servidor se conectar e não há nada sobre isso que o torne inadequado ao TCP ou à rede com estado.

O principal caso de uso para anycast é em CDNs (Content Delivery Networks), que geralmente têm conexões de curta duração e / ou sem informações de estado - como seria de esperar ao fornecer lotes de conteúdo de página da Web pequeno e estático. Nesse caso de uso, a suposição de anycast de que a topologia da rede permanecerá a mesma pelo menos durante a sessão é uma suposição bastante segura, dada a curta duração da sessão típica, e as consequências mínimas dessa suposição se tornam falsas - na pior das hipóteses , a sessão falha no meio e o usuário recarrega a página da Web.

A desvantagem de usar anycast para sessões mais longas ou para usos que são intolerantes a interrupções é que a topologia de rede tem maior probabilidade de mudar durante um período de tempo mais longo, e a conexão será interrompida silenciosamente se isso acontecer. Como você alude na sua pergunta, o Google (e outros) estão trabalhando em métodos proprietários para resolver este problema, mas por enquanto, é tudo proprietário e secreto.

Então, a resposta para sua pergunta sobre como o anycast funciona com o TCP é que ele funciona muito bem, a menos que a topologia da rede mude ... se a topologia mudar, ela [potencialmente] quebra.

Há uma interessante apresentação aqui (aviso, pdf) com dados do mundo real sobre o uso de anycast, incluindo algumas sessões de longa duração, e parece que no mundo real, "comutação pop" (onde a topologia de rede muda no meio de uma sessão e quebra uma conexão) é uma experiência muito rara - em um conjunto de dados, com 683.204 sessões e 23.795 sessões com duração superior a 10 minutos, apenas 4 sessões foram alteradas.