O que é TCP sobre TCP e como o OpenVPN no modo TCP evita o problema?

Question

Esseartigoexplica por que TCP sobre TCP pode ser um desastre de desempenho.

Meu entendimento sobre o problema é que a conexão TCP 'externa' lida com a perda de pacotes e o congestionamento da rede e age de acordo, aumentando os tempos limite (e, assim, reduzindo a taxa de transferência). Entretanto, a conexão TCP 'interna' não vê essas condições de rede porque elas são 'fixadas' pelo TCP externo. E, portanto, o TCP 'interno' continua enviando pacotes na velocidade anterior e, assim, explode o buffer de envio interno da conexão TCP 'externa'.

Minhas perguntas são:

1. Meu entendimento está correto?
2. Parece que o colapso do TCP sobre TCP é apenas interno (ou seja, afeta apenas os buffers locais), mas também afeta a rede? Causa mais congestionamentos na rede e degrada outras conexões na mesma rede?
3. Como as VPNs baseadas em TCP resolvem esse problema? OpenVPN tem umartigosobre isso, mas não diz por que não é um problema na prática (ou é?)

Muito obrigado por qualquer resposta!

Answer 1

No meu entendimento, o problema do "colapso do TCP" não é difícil de resolver: você só precisa definir um grande tempo limite de retransmissão para a conexão TCP interna.

Ao aumentar bastante o tempo limite mínimo de retransmissão da conexão TCP interna, desabilitamos efetivamente o mecanismo de retransmissão de tempo limite do TCP interno. Portanto, o problema do colapso do TCP é evitado.

Por exemplo, no Linux, você pode usar ip route replace 192.168.168.1/24 via 192.168.168.2 rto_min 12spara aumentar o tempo limite mínimo de retransmissão de todas as conexões internas estabelecidas através do OpenVPN de 0,2 segundos para 12 segundos (presume-se que 192.168.168.1/24 seja o seu segmento de rede OpenVPN).

Você pode definir o comando acima como retorno de chamada do evento up do OpenVPN. Desta forma, evitamos o problema do colapso do TCP de uma forma simples.

Usamos este método para otimizar o link tcp-over-tcp. Mesmo na linha com alta latência (centenas de milissegundos) e alta perda de pacotes, não encontramos nenhum efeito adverso.

PS: Em uma linha com alta latência, alta perda de pacotes e alta largura de banda, é óbvio que você precisa preparar uma grande janela para que as conexões TCP internas ocupem toda a largura de banda.

ATUALIZAR:

A questão aqui é por que o TCP sobre TCP não tem um efeito perceptível na VPN baseada em TCP?

Porque em uma linha de alta qualidade que raramente perde pacotes, o fenômeno do colapso do TCP não é proeminente.

Answer 2

Eu diria que isso tem mais a ver com a forma comoTCPfunciona, e não com o OpenVPN em si. Aí vem um longo discurso e meus poucos centavos:

Meu entendimento está correto?

Aproximadamente sim, mas a conexão TCP interna não está "protegida". Se o externo descartar um pacote e a taxa de transferência diminuir ou a latência aumentar, a conexão interna também será limitada por isso, observe que ela não pode usar o desempenho total e começará a recuar.

Parece que o colapso do TCP sobre TCP é apenas interno (ou seja, afeta apenas os buffers locais), mas também afeta a rede?

Você terá apenas uma conexão TCP com o servidor, portanto isso afetará apenas essa conexão específica e tudo o que estiver nela. O que o colapso se refere é o que descrevi na resposta anterior.

Causa mais congestionamentos na rede e degrada outras conexões na mesma rede?

Não, mas eu precisaria definir "rede" aqui. Se você tiver uma conexão ruim com a Internet, sim, tudo sofrerá com quedas de pacotes ou outros problemas de transmissão. Se você quer dizer que há apenas um problema com a conexão do cliente <=> servidor, então suas conexões não VPN não serão afetadas.

Como as VPNs baseadas em TCP resolvem esse problema?

Ao usar uma única conexão com o servidor, envie o tráfego dentro dessa conexão e espere pelo melhor.

O OpenVPN tem um artigo sobre isso, mas não diz por que não é um problema na prática, é um problema na prática.

Sim. O TCP tem uma sobrecarga muito maior em termos de tamanho de pacote do que o UDP, então você está sempre pagando uma penalidade de tamanho por ter dois cabeçalhos TCP (interno e externo) em sua conexão. Reenvios e aumento de TCP também afetarão seu desempenho. Se você tiver uma boa conexão, ou seja, sem quedas, baixa latência e alta largura de banda, você não verá muito aumento/retirada/reenvio e, portanto, não perceberá isso. Se você tiver uma conexão ruim, então a primeira resposta entra em ação, as conexões externas podem diminuir, isso afetará o tráfego interno que diminuirá, os pacotes podem ficar fora de ordem e serem reenviados e assim por diante, o que definitivamente irá afetar o desempenho do túnel.

A resposta longa é longa. Espero que isso tenha feito algum sentido para alguém mais do que para mim.