Географически длинный туннель HTTP

[dignity]

Друзья, нетиповая задача, может кто сталкивался.

 

Все мы знаем, что TCP очень сильно деградирует от задержки + потерь.

Есть задача прокинуть как-то HTTP из США в Сибирь, чтобы обеспечить хорошую скорость доступа к ресурсам без недостатков TCP.

Смотрю на SCTP, но что-то не могу найти поддержку в Nginx, хотя в Apache есть. Если кто-то сталкивался, есть идеи, буду рад услышать.

Edited June 19, 2013 by dignity

[MMM]

думаю, что нужно простейшие tcp2sctp и sctp2tcp на другом конце, а там уже добавлять по вкусу nginx и т.п.

[dignity]

то что можно инкапсуляцию сделать, понятно. Я пока ищу готовое решение какого-либо туннеля. Инкапсулятор писать лениво... Его же поддерживать придется)) Кроме того, надо будет делать либо на уровня ядра с поддержкой маршрутизации и какого-то tun интерфейса, либо держать несколько туннелей, для каждого порта, условно.

[shafiev]

Друзья, нетиповая задача, может кто сталкивался.

 

Все мы знаем, что TCP очень сильно деградирует от задержки + потерь.

Есть задача прокинуть как-то HTTP из США в Сибирь, чтобы обеспечить хорошую скорость доступа к ресурсам без недостатков TCP.

Смотрю на SCTP, но что-то не могу найти поддержку в Nginx, хотя в Apache есть. Если кто-то сталкивался, есть идеи, буду рад услышать.

 

 

Не думаю, что sctp или же что-то анологичное сильно поможет , все таки большой джиттер и потери фундаментальная проблема.

[dignity]

Пробовать надо. Мне кажется, что заранее сложно сказать.

[snark]

Туннель между США и Сибирью не поможет?

Расстояние, разумеется, не сократится, но "путь" для ТСР будет "ближе" хотя бы из-за меньшего кол-ва хопов.

[Saab95]

Еще можно включить упаковку пакетов, очень ускорит доставку пачки подтверждений о доставке.

[agr]

наверное только кеширование контента поможет.

[Minkevich]

А рассматривается только такой вариант?

Почему бы не использовать протокол SSTP?

[dignity]

SSTP suffers from the same performance limitations as any other IP-over-TCP tunnel. In general, performance will be acceptable only as long as there is sufficient excess bandwidth on the un-tunneled network link to guarantee that the tunneled TCP timers do not expire. If this becomes untrue, performance falls off dramatically. This is known as the "TCP meltdown problem"[5][6]

 

Это из википедии. Сам не сталкивался.

 

Похоже, вы не очень поняли что мне надо)) мне надо разогнать tcp на длинном канале.

 

Кэширование не подходит. Трафик некэшируемый.

[-Pave1-]

Не совсем понял, при чем тут всякие SSTP, если честно.... От них delay что ли уменьшится? :)

 

Для разгона TCP знаю только 2 средства:

1. Wan оптимизаторы, как Cisco Waas, Riverbed и т.д. Дорого.

2. Использование tcp window scaling, т.е. расширенное TCP window >> 65k. Все современные ОС по сути это должны уметь. А если не хотят в конкретном случае использовать - надо копать почему, и принуждать к этому. Например в WinXP/2003 надо в реестре включать - правда работает все равно хуже последних.

Edited June 20, 2013 by -Pave1-

[MMM]

то что можно инкапсуляцию сделать, понятно. Я пока ищу готовое решение какого-либо туннеля. Инкапсулятор писать лениво... Его же поддерживать придется)) Кроме того, надо будет делать либо на уровня ядра с поддержкой маршрутизации и какого-то tun интерфейса, либо держать несколько туннелей, для каждого порта, условно.

 

Можно придумать что-то вроде

withsctp netcat | netcat

[dignity]

2. Использование tcp window scaling, т.е. расширенное TCP window >> 65k. Все современные ОС по сути это должны уметь. А если не хотят в конкретном случае использовать - надо копать почему, и принуждать к этому. Например в WinXP/2003 надо в реестре включать - правда работает все равно хуже последних.

Не, не подходит)) представьте что клиент - обычный домашний хомяк из США, зачем его принуждать.

[-Pave1-]

Не, не подходит)) представьте что клиент - обычный домашний хомяк из США, зачем его принуждать.

Ну тогда только коммерческий WAN оптимизатор, находящийся "рядом" с этим самым хомячком - и никак иначе...

Никаких других путей нет - что ни городи. Т.к. если delay > 10ms и ширина окна 65k - то время проведенное в ожидании подтверждения о приеме данных будет много больше времени непосредственно передачи данных... Тут как бы врожденное ограничение TCP:

http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/

Edited June 20, 2013 by -Pave1-

[Ivan_83]

htcp через sysctl задействовать в качестве tcp.cc, дальше читать маны как его ещё можно выкрутить.

[Ilya Evseev]

spdy не поможет?

[dignity]

Spdy поможет, наверное), просто параллельно пытаюсь не прикладной протокол найти, а транспортный. Похоже, кроме congestion алгоритмов tcp без вариантов. Буду пробовать с yeah.