Existe uma solução de túnel HTTP que não usa CONNECT, HTTPS ou codificação em partes? [fechadas]

Question

Estou procurando uma maneira de obter uma conexão rápida do OpenVPN através de um firewall restritivo (isso não é um local de trabalho e não estou quebrando nenhum código de conduta).

Atualmente estou usando a porta 443 diretamente para o servidor openvpn, já que o firewall permite TCP arbitrário nesta porta. Nenhuma porta além de 80 e 443 está aberta (somente TCP) e o DNS é interno. No entanto, a porta 443 tem um limite de velocidade de 15mbit / s aplicado e é extremamente não confiável (o link openvpn falhará completamente a cada poucos minutos).

Eu testei completamente e cheguei à conclusão de que a porta 80 permitirá somente solicitações HTTP tradicionais - qualquer coisa envolvendo CONNECT ou Transfer-Encoding: Chunked será descartada silenciosamente.

O ping é baixo o suficiente (5-10ms) e velocidade alta o suficiente (70mbit para baixo, 15mbit para cima) que eu estou realmente pronto para considerar um túnel de polling HTTP (ou alguma magia que define um comprimento de conteúdo enorme e dispara cargas de dados fictícios), mas o problema é que não consigo encontrar um. Alguma solução para isto já existe?

Já experimentei o link recomendado, mas não tenho nenhuma alegria, pois requer codificação em partes.

Editar: Encontrou uma semi-solução - link . Funciona, mas infelizmente muito lento em termos de latência para realmente fazer muito com. Curiosamente, antes de colocá-lo atrás do nginx, abrindo suas URLs internas, pude ver a página padrão do proxy transparente que estou por trás (wampserver apache, aparentemente).

    

Answer 1

Você está tendo o problema mencionado neste artigo de Olaf Titz?

link

Citando (desde que eu não poderia dizer mais claro). Observe que a camada superior e a camada inferior do TCP possuem timers diferentes. Quando uma conexão de camada superior é iniciada rapidamente, seus temporizadores também são rápidos. Agora, pode acontecer que a conexão inferior tenha temporizadores mais lentos, talvez como uma sobra de um período com uma conexão de base lenta ou não confiável.

Imagine o que acontece quando, nessa situação, a conexão básica começa a perder pacotes. A camada inferior TCP coloca em fila uma retransmissão e aumenta seus tempos limite. Como a conexão é bloqueada durante esse período, a camada superior (ou seja, payload) TCP não recebe um ACK oportuno e também enfileira a retransmissão. Como o tempo limite ainda é menor do que o tempo limite da camada inferior, a camada superior fará fila para mais retransmissões mais rapidamente do que a camada inferior poderá processá-las. Isso faz com que a conexão da camada superior pare muito rapidamente e cada retransmissão apenas aumenta o problema - um efeito interno de fusão.

As provisões de confiabilidade dos TCPs saem pela culatra aqui. As retransmissões da camada superior são completamente desnecessárias, uma vez que a operadora garante a entrega - mas a camada superior do TCP não pode saber disso, porque o TCP sempre assume uma portadora não confiável. "

Talvez essa seja a discussão neste tópico ( link ) para obter algumas dicas que ajudarão.