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