+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Изменить маршрут через определенное время.

Изменить маршрут через определенное время., RouterOS

Giepie

Guest

09.05.2007 00:09:00

Привет всем! Хочу реализовать вот что. Если у кого есть идеи, помогите, пожалуйста! Из-за стоимости трафика и того, что нельзя отделить веб-трафик с 80 порта от скачивания трафика с 80 порта (например, загрузка сайта или скачивание 2ГБ файла с сайта), я хочу сделать это, изменяя шлюз определенного потока скачивания, скажем, через 60 секунд. Хочу использовать качественный трафик для всех веб-сайтов, но когда кто-то скачивает с определенного IP-адреса, скажем, в течение 60 секунд, я хочу, чтобы только этот поток был направлен через более дешевый, менее отзывчивый трафик. Хороший качественный трафик очень дорогой, но отзывчивый, а дешевый – достаточно быстрый, но с очень высокой задержкой. Какие есть идеи? Re, G

Equis Guest	#2 0 09.05.2007 05:47:00 Я думаю, это сломает скачивание. Я не знаю, как это сделать.

Diganet Guest	#3 0 09.05.2007 08:22:00 Ты бы оборвал TCP-соединение, и пользователю пришлось бы возобновить скачивание… /Henrik

Giepie

Guest

12.05.2007 16:28:00

Привет, Equis! Спасибо за ответ. Да, я думал, что это может нарушить скачивание, но моя идея заключалась в том, чтобы переводить на другой шлюз только большие файлы, вроде 100 МБ и больше. Думаю, большинство людей, которые скачивают такие большие файлы, используют менеджеры загрузки. Я думал в терминах списков IP-адресов. Напиши скрипт, который помечает определенные IP-адреса как «IP с большими файлами» и сохраняет эту метку. Так первый пользователь, скачивающий с определенного IP, может сломать соединение, но не последующие пользователи. Спасибо, G.

savage

Guest

13.05.2007 18:58:00

Изменение маршрута во время активного соединения убьет любое соединение (не только загрузку), подключенное к целевому IP-адресу. Создание 'ACL' для 'больших загрузок' тоже не сработает как следует, потому что http://www.mysite.com с обычным маленьким веб-сайтом вполне может быть на том же IP, что и http://www.bigsite.com с 1GB загрузками. Ну, если MT сможет иметь какую-то форму контроля времени (сброс соединения, если оно установлено дольше x минут), что возможно, тогда можно и говорить… -grin- Это не решит проблему с первой загрузкой, но настройте Squid правильно и отпустите его в кэш. Нет причин, почему 100МБ файл не может быть обслужен на 100% из кэша (Это здорово для Патчей / Service Packs / и т.д., например)… т.е. refresh_pattern \.exe$ 10080 90% 43200
maximum_object_size 1024 MB Должно дать довольно хороший результат. Жаль, что Mikrotik нельзя настроить так же тонко.

Giepie Guest	#6 0 13.05.2007 19:14:00 Привет, Savage! Спасибо за ответ. Сейчас я использую маршрут через веб-прокси, кэширую файлы размером до 18 МБ (можно подкорректировать, но у меня в CACHE MT пока только 512 МБ оперативной памяти). Я просто экспериментирую с разными идеями, чтобы предоставить наилучший сервис незлоупотребляющим клиентам и тем, кто скачивает большие файлы, при этом не сильно увеличивая расходы провайдера. Я согласен с твоим замечанием о подключении, основанном на времени — это было бы отлично. Я сейчас понимаю, что размещение определенных IP-адресов в списках адресов проблему не решит, так как в любом случае лучше закешировать файл. У меня “есть” опыт работы с SQUID-прокси, но для моего скромного опыта работы с Linux, MT Web Proxy вполне достаточен для моих нужд и довольно прост в настройке. Думаю, самая большая проблема в том, что я пытаюсь сделать, заключается в том, что невозможно определить, скачивает ли пользователь несколько маленьких изображений с сайта или действительно 1 ГБ файлов. Если бы скачивания работали на другом порту, отличном от тех файлов, которые отображаются на сайте. Но в конце концов, пользователь платит за каждый ГБ, поэтому он заслуживает лучшего, хотя мы все в этом деле ради денег, так что если можно сэкономить “немного” денег, почему бы и нет? Спасибо всем за помощь. Думаю, мы, возможно, дали MT-разработчикам что-то, о чем стоит подумать. Они и раньше творили чудеса, посмотрим, что они придумают в MT V4!! С уважением, Giepie

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры