Предложение по улучшению: оптимизация TCP.

Не мог бы ты показать это на видео на YouTube или чём-то подобном, потому что пока всё немного загадочно. Было бы круто, если бы это действительно выполняло то, что обещает — просто необходимо для VSAT-систем и настроек 3G.

TPROXY очень интересная штука. Я тестировал её на Debian, и она оказалась очень хороша. Сохраняет исходный IP-адрес, поэтому не выглядит как NAT, а скорее как обычный роутер. Впрочем, сомневаюсь, что у роутеров найдется достаточно вычислительной мощности для создания действительно крутой TPROXY-настройки для провайдера. Думаю, нужен quad Xeon с 8 ГБ и полгига SSD. Есть несколько вещей, которые можно сделать с TPROXY и Squid, что действительно было бы полезно для WISP, прозрачный кэширующий прокси без NAT. Может быть, польза будет ограничена в мире динамичного контента, плохо поддающегося кэшированию, но при правильной настройке можно сэкономить примерно 20% трафика. Внутристрочная HTTP-компрессия в формате gz. Я запускал TPROXY на Debian в этой конфигурации (в лабораторной/тестовой настройке) и это удивительно эффективно. Можно сжимать HTTP-данные в формате gz, что может уменьшить размер текстовых потоков на 80%. Если учитывать графический контент (который нельзя сжать), можно сэкономить 20-40% пропускной способности при доставке веб-страниц клиентам. Также можно сжимать входящие запросы к хостингам. Все современные браузеры поддерживают контент, сжатый в формате gz. Фильтрация контента по клиентам. С помощью правил брандмауэра можно направлять трафик для списка «фильтруемых» клиентов через TPROXY и нечто вроде DansGuardian и при этом сохранять исходный IP-адрес. Опять же, избегая того, чтобы устройство NAT отображалось как исходный адрес на стороне провайдера.

Как давно ты используешь Thundercache? Насколько он эффективен для кэширования YouTube и видеохостингов? Действительно ли он незаметен?