Страница 1 из 2

Ограничение скорости передачи HTTP

Добавлено: 18 май 2014, 00:40
tizerenko
Доброго времени суток.

Помогите пожалуйста, в каком файле задаётся ограничение скорости, в настройках по-умолчанию 40 кб максимальный размер отдачи, а мне нужно сделать 100кб, чтобы во время досса не могли забить мой канал.
Заранее благодарю.

Добавлено: 18 май 2014, 03:28
Максим
Медленная отдача это лишь грубый эмулятор медленной загрузки сайтов, не нужно использовать его для защиты от DDOS. Ограничение устанавливается не на сервер и не на IP, а всего лишь на каждое подключение, так что создав несколько соединений можно легко забить ваш канал. Более того, DDOS в 99% случаев генерируется огромным потоком запросов на сервер, и именно ими забивается канал, т.е. боты даже не получают ответ от сервера, ответ им не нужен. Данная настройка в борьбе с DDOS абсолютно бесполезна. Ограничение установлено в самой программе и изменить его никак нельзя.

Добавлено: 18 май 2014, 08:27
tizerenko
Сильную атаку не отбить этим, но тут дело обстоит в другом, что на моём домашнем сервере стоит 20 мбит скорость, и когда кто-нибудь начинает скачивать со своим каналом в 100 мбит, для остальных не только еле грузятся файлы, а ещё вдобавок медленней открываются страницы, в итоге так не составит труда положить мой сервак простому школьнику со своего домашнего ПК, тут я нашёл решение в ограничении скорости на скачивание, кол-во потоков на загрузку файлов я нашёл решение, здесь нашлось решение использование модуля apache mod_bw, только весь мануал на английском и примеры для линукса, поэтому я ищу помощь.

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

Добавлено: 18 май 2014, 11:13
Максим
ok сделаю любую скорость.

Добавлено: 18 май 2014, 13:43
Dragon_Knight
Совершенно неправильный подход.
Если хотите ограничить скорость скачивания файлов, то именно это и делайте, зачем резать всё?
Вот Вам готовый пример http://habrahabr.ru/post/51442/

Добавлено: 18 май 2014, 14:33
tizerenko
Dragon_Knight писал(а):было выставить, это будет новое
Я знаю что на php можно резать скорость, но правильней её отбивать ещё на более низком уровне, что позволяет делать mod_bw, с него бы примеров.

Да дело в том, что при 100 кб мои шаблоны быстро грузятся, у кого сайт с картинками высокого разрешения тем конечно нужно больше где-то 250 кб, вполне рациональное использование да и тем более при помощи php придётся вносить правки в движок, а он может быть и закодирован, куда более рационально выделить каждому по равной скорости на низком уровне, php это уже решение высокого уровня да и будет работать немного медленней.

Потом все ссылки придётся менять на
loadfile ("/files/moifilm.avi", 10240); // Скорость указываем в байтах
а это уже проблематично учитывая что посты где расположены ссылки в html, и теги <? будут расцениваться как обычный текст, то есть нужно их ещё будет все изменить чтобы они вели на скрипт обработчик и реальные ссылки передавались get запросом, в общем очередные танцы с бубном.

Добавлено: 18 май 2014, 14:56
Dragon_Knight
Если хотите резать на низком уровне, то Вам к аппаратным фаерволам как-бы...
tizerenko писал(а):Потом все ссылки придётся менять на ....
htaccess и mod_rewrite? нее, не слышал...

Во общем-то дело Ваше, как хотите делать так и делайте, разве что когда вы осознаете, что этот вариант Вам не подходит, - вы придёте в эту ветку форума :D

Добавлено: 18 май 2014, 18:31
tizerenko
Если хотите резать на низком уровне, то Вам к аппаратным фаерволам как-бы..
Согласен, но это уже аппартный уровень, и тут деньги нужны.
htaccess и mod_rewrite? нее, не слышал...
Да знаю я, можно и яваскриптом заменить ссылки, но вот только это всё равно медленней и менее практично, а у программистов ценится практичность, тут как-бы дело квалификации, но кому хочется тот может и пыхой резать, подходов несколько имеется.

Добавлено: 18 май 2014, 19:53
Dragon_Knight
Как раз более практично это именно htaccess и mod_rewrite.
Пользователь видит прямую ссылку на файл, программы тоже видят прямую ссылку на файл, а по факту файл отдаёт php. Это целых 3 плюса имеет:
1) Никаких проблем со скачкой файлов, ибо со стороны клиента это прямая ссылка на файл.
2) Никаких проблем с ботами, они тоже видят ссылку на конкретный файл и спокойно индексируют этот файт.
3) Можно вести учёт скачки и запросов файлов, делать разграничения на скачку и так далее, в рамках возможностей PHP.
Минус тока один, и то не существенный: На 0.0...1% возрастёт нагрузка на сервер.

Ява вообще не практично и отчасти нецелесообразно, ибо не у всех включена она, а так-же JS и боты не совместимы.

Добавлено: 18 май 2014, 20:29
tizerenko
Ява вообще не практично и отчасти нецелесообразно, ибо не у всех включена она, а так-же JS и боты не совместимы.
Бот тогда получит стандартную ссылку в html, и пользователь у которого нету JS (хотя таких сейчас нету, это когда-то давно когда ещё не было jQuery и браузеры были плохо защищены (допустим на ie 6-8 при дополнительной настройке в браузере через js можно обращаться к своему винту, видеть, читать, создавать и удалять любые файлы включая системные, за исключением некоторых на которых нету прав администратора), сейчас js только у ботов нету и то не у всех, у современных таких как поисковые всё есть, вот гугл даже индексирует текст на картинки используя свои алгоритмы чтения изображения по пикселям.


По 3-му пункту не оспоримый плюс только делать разграничения для разных групп пользователей, тут только так, но для моих нужд не нужно, т.к статус пользователя у меня только "зарегистрированный" который видит ссылки и "гость" не видит ссылки.

А что касается делать учёт скачек, тут уже есть своё более рациональное применение, есть модуль который ведёт логи каждого обращения, потом по этим логам можно смотреть и сортировать критерии по расширениям файлов, по браузерам, по ip, странам итп ( ну в общем то тот же liveinternet может выдать кол-во скачек или гугл analytic тут просто не нужно разрабатывать велосипед дважды, когда и так профессионалы уже всё сделали)

Добавлено спустя 11 минут 2 секунды:
В целом не один из высказанных вариантов не будет являться однозначным, т.к всё имеет свои плюсы и недостатки, тут выбор лежит в основе практичности (допустим профессиональные разработчики CMS не берут в основу своего движка какой-нибудь фреймворк, когда от него будет задействовано 5-10 процентов всего функционала), и здесь в моей ситуации практичней решить задачу низкоуровневым способом нежели через php