целесообразность proxy?

[dsedsedse]

Всем доброго дня.

 

Вопрос в следующем: есть ли целесообразность установки proxy сервера на сегодняшний день?

Появились мысли завернуть безлимитчиков с урезанным каналом (от 256 до 1мбит на пользователя, в зависимости от тарифов) через прозрачный прокси (squid)

Предположим есть внешние каналы 20...40Mbit и около 400 безлимитчиков, которые ходят через NAT.

(В этом же канале работают и другие пользователи на лимитных тарифах)

 

0. Целесообразно ли ставить прокси?

1. Разгрузит ли proxy внешний канал, и какой объем scsi массива нужен для оптимальной разгрузки?

2. Примерная конфигурация сервера (cpu, ram, hdd)

3. Есть ли проблемы при прозрачном кэшировании трафика при работе с интернет?

 

Заранее спасибо, с Уважением, dsedsedse :)

[zcat]

3. Есть ли проблемы при прозрачном кэшировании трафика при работе с интернет?

Проблемы точно есть. Клиент заливает .html файл на удаленный сервер, затем скачивает его и файл попадает в кеш proxy. Через 5 минут заливается обновленная копия, а вот кеш может отдавать свою копию вместо копии с сервера еще достаточно долгое время. Причем особо малограмотным клиентам приходится объяснять это достаточно долго, пока до них дойдет.

[GateKeeper]

Если говорить об apache, то при отдаче статики он отдаёт и заголовок вида Not-Modified-Since. А сквид даже в порядком подпорченной конфигурации прежде, чем отдать контент на сервере справляется посредством HEAD, при котором все те же самые заголовки и передаются. Далее простое

if (stored_mtime != checked_mtime) refetch();

примерно так.

[dsedsedse]

Мне казалось proxy сначала будет сравнивать содержимое на сервере, с данными в кэше и по результату отдавать более свежую копию?

[dsedsedse]

И все-же? Кто использует у себя прокси, а кто не использует, и почему?

[zcat]

Если говорить об apache, то при отдаче статики он отдаёт и заголовок вида Not-Modified-Since.

GateKeeper, заголовка 'Not-Modified-Since' в природе не существует.

 

Apache, как и любой другой нормальный веб-сервер, отдает заголовок Last-Modified. В случае статического контента (а именно с ним и возникает проблема описанная при использовании проксей), дата модификации выдается в соответствии с атрибутами файла на диске веб-сервера.

При повторных визитах веб-броузеры посылают для такого типа контента (то есть для контента у которого небыло заголовков Cache-Control: no-cache и т.п.) запросы If-Modified-Since, на которые веб-сервер может ответить 304 Not Modified вместо отдачи файла.

 

Кроме того, есть еще такой заголовок "Expires" (в апаче для его выдачи надо подключить mod_expires). Так вот, если Expires выдавался, то на сервер никаких заголовков вообще отправляться не будет пока время expires не закончится. Правда можно нажать Ctrl+R и броузер таки попытается обновить страницу.

 

Так вот, а при работе через проксю, ситуация несколько иная и очень часто вытащить из прокси обновление статики бывает проблематично, особенно если прокся настроена из принципа экономии трафика своему владельцу.

 

В случае использования Transparent Proxy у провайдера, без уведомления об этом клиентов, провайдеру придется периодически объяснять какого х... он эту transparent proxy вообще воткнул.

[zcat]

Да, кстати, еще не стоит забывать что например SQUID посылает запросы на веб-серверы в HTTP/1.0, правда с заголовком Host, разумеется.

В то время как все современные броузеры посылают запросы в HTTP/1.1

[builder]

Выходит, не целесообразно? Т.к. клиента надо поставить в известность, тем паче дать выбор "с прокси - за такие бабки, без прокси - за такие бабки". Большинству клиентов это не объяснишь, и согласия не получишь, а сквид экономит полосу когда клиентов много и трафик большой.

[zcat]

builder, ну вобщем где-то так

[builder]

Собственно озабочен такими же вопросами, что и товарисч dsedsedse.

Хочется в растущей сети

а) эфективней использовать канал, прозрачно проксируя http и ftp

б) кэшировать DNS-ответы, т.к. наблюдается растущая задержка от вышестоящих, да и не безопасно это как тут подсказали

в) приоритезировать некоторые протоколы

с) пошейпить всех (в разумных пределах)

И соответственно изучая и этот форум, наталкиваешься на весьма противоположные взгляды. Где же правда! :)

[BETEPAH]

может опрос сделать на тему "я использую (неиспользую) в своей сети прокси", тоже стал задумываться, так как сеть растёт понемногу

[builder]

Тут пока лазил по форуму, видел ветку, где парни такую железяку под это дело залудили :) 150 гигов в пятом рейде - пол рунета кэшируют :). Зря наверно так не заморачивались бы.

[umike]

еще прокся может неприятно подпортить пользователю сидение в веб-чатах, после чего он подпортит настроение поддержке :)

[builder]

может опрос сделать на тему "я использую (неиспользую) в своей сети прокси", тоже стал задумываться, так как сеть растёт понемногу

Видите, как все молчат, а Вы говорите опрос. Москвичи, с их толстыми каналами не в счет, а остальные проксируют всё и вся, тока

--еще прокся может неприятно подпортить пользователю сидение в веб-чатах, после чего он подпортит настроение поддержке :)

--В случае использования Transparent Proxy у провайдера, без уведомления об этом клиентов, провайдеру придется периодически объяснять какого х... он эту transparent proxy вообще воткнул.

набили шишек себе и теперь делиться не хотят :))) как я их понимаю.

З.Ы. Москвичи тож всё кэшируют наверняка :))

[zcat]

Хех, а вот ftp кешировать вообще не стоит, парни. Это очень плохо. Во-первых, с active/passive mode напаритесь, а во-вторых, когда кешируется ftp, у тех кто по ftp не только скачивает, но и закачивает наружу, такие глюки бывают ...

Когда к нам (хостинг-провайдер) звонят с подобными глюками и все указывает на наличие transparent proxy, мы всегда рекомендуем людям либо обратиться за разъясениями к тем кто настраивал интернет, либо менять провайдера интернет.

[builder]

Хех, а вот ftp кешировать вообще не стоит, парни. Это очень плохо

Это очевидно, zcat.

Думаю, что первый вариант резюме по топику может звучать так - прозрачное и тем паче не прозрачное проксирование - это решение для энд-юзеровских сеток, никак не выше.

[umike]

Видите, как все молчат, а Вы говорите опрос. Москвичи, с их толстыми каналами не в счет, а остальные проксируют всё и вся

не москвичи, не прокисруем, не кэшируем ;)

[Egor]

имхо прокси оператору делать не следует, а если и делать, то честно сказав, да еще по возможности и дополнительно продав. А для потребителя это экономия примерно 10% трафика и/или полосы.

DNS при нагрузке лучше распараллеливать, а не кэшировать, хотя тут это может сойти, а для отсутствия туннелирования, считать трафик от DNS внешним. простому юзеру несколько сотен килобайт в месяц что слону дробина, а туннели теряют смысл.

[builder]

Вот у меня у клиентов DNS-сервера прописаны честные (апстримовских операторов), причём прописаны руками без DHCP. А можно bind (кэширующий) настроить так, чтобы на него перенаправлялись (iptables) все запросы? Т.е. не будет ли это криво? Не хочется менять у клиентов настройки.

[Bushi]

Проксируев весь http. Экономия трафика ~7% (от общего трафика). Используем transparent proxy (wccp2 + oops). Клиенты знают. По желанию клиента отключаем проксирование.

[GateKeeper]

А можно bind (кэширующий) настроить так, чтобы на него перенаправлялись (iptables) все запросы? Т.е. не будет ли это криво? Не хочется менять у клиентов настройки.

Ну, криво не будет, разве только клиенту опять придётся сказать, ибо, вычисляется очень легко (nslookup прямо говорит, что за птица ответила на запрос).

[dsedsedse]

Делаем промежуточные выводы - экономия трафика не более 10%, а проблем, связанных с http и ftp кэшированием значительно больше.

 

Роль прокси, как дополнительного сервиса (в качестве продажи) - тоже неясна...

 

Хотя можно, наверно, сделать пользоватею выбор (пусть он имеет возможность включить-выключить самостоятельно проксирование, через свой личный кабинет), но уже не видно явной рентабельности от этого проекта (стоимость сервера+дополнительная нагрузка на ИБП+время на настройку/сопровождение системы...)

[builder]

Ну, криво не будет, разве только клиенту опять придётся сказать, ибо, вычисляется очень легко (nslookup прямо говорит, что за птица ответила на запрос).

Ну а пользователю хуже то не будет - или он ответ получает через 200мс или через 2мс из кэша. Или есть сервисы которым надо на прямую с честным DNS работать?

[Shiva]

А можно поставить антивирь и банерорезку, так же фильтрацию для детей по просьбе пап/мам и продавать этот сервис, за доп деньги :)

[GateKeeper]

Ну а пользователю хуже то не будет - или он ответ получает через 200мс или через 2мс из кэша. Или есть сервисы которым надо на прямую с честным DNS работать?

Проблемы те же, что и со сквидом: Хуже будет, если я, администратор зоны, не могу проверить результат своей работы, ибо следующее обновление кеша бинда будет минут через Ндцать, а отчитаться надо сейчас? Ну и прочие аналогичные проблемы вида: зона ТАМ обновилась, а зона ТУТ все еще пуляет нас на УЖЕ левые адреса...