我正在寻找一种通过限制性防火墙建立快速 OpenVPN 连接的方法（这不是工作场所，我也没有违反任何行为准则）。
目前我使用端口 443 直接连接到 openvpn 服务器，因为防火墙允许此端口上的任意 TCP。除了 80 和 443 之外，没有端口开放（仅 TCP），DNS 是内部的。但是，端口 443 的速度限制为 15mbit/s，并且非常不可靠（openvpn 链接每隔几分钟就会完全失败）。
我已经彻底测试并得出结论，端口 80 只允许传统的 HTTP 请求 - 任何涉及 CONNECT 或 Transfer-Encoding: Chunked 的请求都会被悄悄丢弃。
ping 值足够低（5-10ms）且速度足够高（70mbit 下载，15mbit 下载），我真正准备考虑 HTTP 轮询隧道（或设置大量内容长度并发送大量虚拟数据的某种魔法），但问题是我找不到。是否已经存在任何解决方案？
我尝试过一般推荐的http://sourceforge.net/projects/http-tunnel/，但由于它需要分块编码，因此没有什么乐趣。
编辑：找到了一个半解决方案 -http://www.targeted.org/htthost/。可以工作，但不幸的是延迟太慢，无法真正发挥作用。有趣的是，在我将其放在 nginx 后面之前，通过打开其内部 URL，我能够看到我后面的透明代理的默认页面（显然是 wampserver apache）。
答案1
您是否遇到了 Olaf Titz 的这篇文章中提到的问题？
http://sites.inka.de/bigred/devel/tcp-tcp.html
引用（因为我无法说得更清楚）。请注意，上层和下层 TCP 具有不同的计时器。当上层连接启动速度快时，其计时器也很快。现在可能会发生下层连接的计时器较慢的情况，这可能是由于基础连接速度慢或不可靠而遗留下来的。
想象一下，在这种情况下，当基础连接开始丢失数据包时会发生什么。下层 TCP 将重新传输排队并增加其超时。由于连接被阻塞了这么长时间，上层（即有效负载）TCP 将无法及时获得 ACK，并且还会将重新传输排队。由于超时仍然小于下层超时，因此上层将排队更多重新传输，速度比下层处理它们的速度要快。这使得上层连接很快停滞，每次重新传输只会加剧问题 - 内部崩溃效应。
TCP 的可靠性规定在这里适得其反。上层重新传输完全没有必要，因为载体保证交付 - 但上层 TCP 无法知道这一点，因为 TCP 总是假设载体不可靠。
也许这是本主题中的讨论（http://news.ycombinator.com/item?id=2409090）将为您提供一些有用的指点。