Существует ли решение HTTP-туннеля, которое не использует CONNECT, HTTPS или кодирование по фрагментам? [закрыто]
Я ищу способ получить быстрое соединение OpenVPN через ограничительный брандмауэр (это не рабочее место, и я не нарушаю никаких правил поведения).
В настоящее время я использую порт 443 напрямую для сервера openvpn, поскольку брандмауэр разрешает произвольный TCP на этом порту. Нет открытых портов, кроме 80 и 443 (только TCP), а DNS является внутренним. Однако порт 443 имеет ограничение скорости 15 Мбит / с и крайне ненадежен (ссылка openvpn полностью отключается каждые несколько минут).
Я тщательно протестировал и пришел к выводу, что порт 80 разрешает только традиционные HTTP-запросы - все, что связано с CONNECT или Transfer-Encoding: Chunked, будет автоматически отброшено.
Пинг достаточно низкий (5-10 мс) и скорость достаточно высока (70 Мбит вниз, 15 Мбит вверх), поэтому я действительно готов рассмотреть туннель опроса HTTP (или какое-то волшебство, которое устанавливает огромную длину контента и запускает множество фиктивных данных), но проблема в том, что я не могу их найти. Существует ли уже какое-либо решение для этого?
Я пробовал обычно рекомендуемый http://sourceforge.net/projects/http-tunnel/ , но без радости, поскольку он требует кодирования фрагментов.
Редактировать: Найдено полурешение - http://www.targeted.org/htthost/ .Работает, но, к сожалению, слишком медленно с точки зрения задержки, чтобы с ней можно было что-то делать. Интересно, что до того, как я поместил его в nginx, открыв его внутренние URL-адреса, я смог увидеть страницу по умолчанию прозрачного прокси, за которым я использую (очевидно, wampserver apache).
У вас возникла проблема, упомянутая в этой статье Олафа Титца?
http://sites.inka.de/bigred/devel/tcp-tcp.html
Цитирование ( так как я не мог сказать это яснее). Обратите внимание, что TCP верхнего и нижнего уровней имеет разные таймеры. Когда соединение верхнего уровня запускается быстро, его таймеры тоже работают быстро. Теперь может случиться так, что нижнее соединение имеет более медленные таймеры, возможно, как остаток периода с медленным или ненадежным базовым соединением.
Представьте, что происходит, когда в этой ситуации базовое соединение начинает терять пакеты. TCP нижнего уровня ставит в очередь повторную передачу и увеличивает время ожидания. Поскольку соединение заблокировано на этот период времени, TCP верхнего уровня (т. Е. Полезной нагрузки) не получит своевременного ACK и также поставит в очередь повторную передачу. Поскольку тайм-аут по-прежнему меньше тайм-аута нижнего уровня, верхний уровень будет ставить в очередь больше повторных передач быстрее, чем нижний уровень может их обработать. Это приводит к очень быстрой остановке соединения верхнего уровня, и каждая повторная передача только усугубляет проблему - эффект внутреннего сбоя.
Обеспечение надежности TCP дает здесь обратный эффект. Повторные передачи верхнего уровня совершенно не нужны, так как оператор связи гарантирует доставку, но TCP верхнего уровня не может этого знать, потому что TCP всегда предполагает ненадежный носитель ».
Возможно, это обсуждение в этой ветке ( http://news.ycombinator.com/item?id=2409090) даст вам несколько полезных указателей.
Это приводит к очень быстрой остановке соединения верхнего уровня, и каждая повторная передача только усугубляет проблему - эффект внутреннего срыва.Обеспечение надежности TCP дает здесь обратный эффект. Повторные передачи верхнего уровня совершенно не нужны, так как оператор связи гарантирует доставку, но TCP верхнего уровня не может этого знать, потому что TCP всегда предполагает ненадежный носитель ».
Возможно, это обсуждение в этой ветке ( http://news.ycombinator.com/item?id=2409090) даст вам несколько полезных указателей.
Это приводит к очень быстрой остановке соединения верхнего уровня, и каждая повторная передача только усугубляет проблему - эффект внутреннего срыва.Обеспечение надежности TCP дает здесь обратный эффект. Повторные передачи верхнего уровня совершенно не нужны, так как поставщик услуг гарантирует доставку, но TCP верхнего уровня не может этого знать, потому что TCP всегда предполагает ненадежный носитель. "
Возможно, это обсуждение в этой ветке ( http://news.ycombinator.com/item?id=2409090) даст вам несколько полезных указателей.