是否存在不使用CONNECT、HTTPS或分块编码的HTTP隧道解决方案？
我正在寻找一种方法，以获得一个快速的OpenVPN连接通过一个限制性防火墙(这不是一个工作场所，我没有违反任何行为守则)。
目前，我使用直接到openvpn服务器的端口443，因为防火墙允许此端口上的任意TCP。除了80和443之外，没有端口是开放的(仅TCP)，并且DNS是内部的。然而，端口443的速度限制为15 15mbit/s，而且非常不可靠(openvpn链接每隔几分钟就会完全失效)。
我已经进行了彻底的测试，并得出结论:端口80只允许传统的HTTP请求--任何涉及连接或传输的请求--编码:块将被静默丢弃。
ping足够低(5-10 is )和足够高的速度(70 70mbit，15 70mbit)，以至于我真的准备好考虑HTTP轮询隧道(或者某种设置大量内容长度并触发大量虚拟数据的魔法)，但问题是我找不到一个。这方面的解决方案已经存在吗？
我尝试过普遍推荐的http://sourceforge.net/projects/http-tunnel/，但没有喜悦，因为它需要分组编码。
编辑:找到一个半解决方案- http://www.targeted.org/htthost/。工作，但不幸的是，在延迟方面太慢，不能真正做很多事情。有趣的是，在我把它放在nginx后面之前，通过打开它的内部URL，我能够看到我所支持的透明代理的默认页面(很明显，wampserver)。
回答 1
Server Fault用户
发布于 2013-03-06 16:13:20
您是否有Olaf在这篇文章中提到的问题？
http://sites.inka.de/bigred/devel/tcp-tcp.html
引用(因为我不能说得更清楚)。注意，上层TCP和下层TCP有不同的计时器。当上层连接快速启动时，它的定时器也是快速的。现在，可能发生的情况是，较低的连接有较慢的计时器，可能是从具有缓慢或不可靠的基本连接的周期中遗留下来的。
想象一下，在这种情况下，当基本连接开始丢失数据包时会发生什么。下层TCP排队重新传输并增加超时。由于连接被阻塞了这么长时间，上层(即有效负载) TCP将无法获得及时的ACK，并且还将排队进行重新传输。由于超时仍然小于下层超时，所以上层将排起比下层处理更快的重传队列。这使得上层连接的失速非常快，每一次重传都会增加问题--内部熔毁效应。
TCPs可靠性规定在这里适得其反。上层重传是完全没有必要的，因为载波保证传送，但是上层TCP不能知道这一点，因为TCP总是假定一个不可靠的载波。“
也许，这个线程(http://news.ycombinator.com/item?id=2409090)中的讨论将为您提供一些有帮助的指针。
https://serverfault.com/questions/478905
复制相似问题
腾讯云开发者
