Как остановить повторяющиеся хиты от того же хоста до того же URL?

Если Вы не будете иметь дело со схемой точка-точка или соединением MPLS между Вашими филиалами, просто добавляя QoS к Вашему SonicWall, или другая VPN/межсетевое устройство не будет достаточно. Если Ваши SonicWall будут использовать общедоступные интернет-соединения, то они не будут иметь никакого контроля над входящими данными, полученными для WAN, и исходящий QoS будет неизолированным, после того как он поражает маршрутизатор Вашего ISP.

На самом деле добавленный любые политики QoS к входящему трафику могут вызвать больше сети conjestion. Рассмотрите пакет SMB, который пересек, Ваша пропускная способность ограничила ссылку на загрузку и достигает SonicWall. SonicWall видит, что это - совместный доступ к файлам Windows, который является низким приоритетом, и отбрасывает или задерживает пакет из-за более высокого приоритетного VoIP, который также получается. Ну, передающий клиент получает повторную передачу TCP и должен отправить тот пакет SMB снова, который увеличивает полное использование пропускной способности на Вашей ссылке, чем если бы пакет был позволен во-первых.

Я предполагаю, что мое предложение для увеличения высокого качества VoIP:

  1. Используйте MPLS для соединения с филиалами, которые будут соблюдать политики QoS.
  2. При использовании общедоступного Интернета для VPN используйте ссылки, которые выделены трафику VPN только (поэтому, когда Войдут в учет загрузок 100 МБ фотографий семейства с Flickr, это не будет влиять на трафик VPN).
  3. Если Вы комбинируете интернет-трафик, и трафик VPN на одном соединении не устанавливают QoS на входящем / входном трафике.

3
задан 6 October 2009 в 16:04
3 ответа

Из Вашего собственного описания я предложил бы, чтобы Вы запустили путем удаления того счетчика и видели, имеет ли это действительно значение. Это так легко тестируется, что я удивлен, что Вы уже не сделали так.

5
ответ дан 3 December 2019 в 05:09
  • 1
    Я знаю. Однако мы преобладаем над 5 миллионами uniques в месяц и всего несколькими людьми дневной триггер эта проблема, таким образом, it' s, к сожалению, не настолько легкий для меня, чтобы вытянуть счетчик и ожидать, чтобы видеть, происходит ли это снова как я can' t принимают решение в вакууме. –   6 October 2009 в 13:17
  • 2
    Извините, я don' t понимают. Почему can' t Вы удаляют тот счетчик? Объем трафика не важен и если у Вас есть проблема, достаточно значительная, что Вы обращаетесь за помощью к I' d говорят it' s далекий от принятия решения в вакууме. Вместо того, чтобы делать очевидный первый шаг, Вы хотите, чтобы мы взяли произвольные предположения в том, какова проблема могла быть, даже при том, что доказательство Вы обеспечиваете точки только в одной вещи. –  John Gardeniers 6 October 2009 в 13:26
  • 3
    о, don' t неправильно понимают меня, that' s логическая вещь попробовать, но если Ваш ' отказ rate' так сказать тот низко (that' s, где трафик входит), и there' s никакая воспроизводимость, затем я can' t обходят отключение, что другие в моей организации рассмотрели бы важными функциями. Я задал вопрос, здесь надеясь, что у кого-то еще была подобная проблема - я вижу разбрызгивание отчетов онлайн о просто этом шаблоне доступов, которые не являются DoS' s, и нет никакой однородности в тех людях, имеющих счетчики на их сайте. Тем не менее, спасибо, и я действительно соглашаюсь с Вашей точкой зрения. –   6 October 2009 в 13:42
  • 4
    Если вопрос стоит спросить it' s стоящий исследования. Если счетчик так важен, почему бы не использовать другой, чтобы сделать то же самое? Ключ здесь должен устранить тот, который Вы в настоящее время используете, чтобы видеть, изменяет ли это вещи. –  John Gardeniers 6 October 2009 в 13:50

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

3
ответ дан 3 December 2019 в 05:09
  • 1
    Попытайтесь воспроизвести ситуацию в своей разработке или любой другой изолированной среде, затем исправьте ошибку JavaScript. –  Karsten 6 October 2009 в 12:40

Проблема с memcached решением состоит в том, что Вы все еще получаете хиты, но Вы - планирование предотвращения любой интенсивной работы для обслуживания его путем проверки memcached и создания определения, если это - плохой запрос. Это - работа сам по себе, хотя уверенный, она может сохранять Ваш веб-сервер или сервер базы данных некоторый CPU.

Другой подход к использованию memcached для этого должен вычислить ответ для того, что URI, и если это уникально для IP затем, хранит ответ, включенный IP+URI в memcached, если бы не только включают его URI с какими-либо другими уникальными параметрами запроса, которые варьировались бы ответ. Затем ответьте на все запросы с любым кэшируемым ответом, который составляет меньше чем X старых секунд. Теперь Вы все еще повторно вычисляете каждые X секунды, но это - меньше, чем много связей секунда. Я верю кэш-памяти, которую осведомленный или веб-сервер прокси смог бы быть настроенным, чтобы сделать это, не пишущий ничему дополнительному, сказать MemProxy или Nginx соответственно.

Достигание основной причины плохого поведения было бы предпочтительно. Если это - связанный JavaScript, это мог бы быть JavaScript, связанный с конкретной рекламой на Ваших страницах. У Вас должен быть механизм в разработке для перезагрузки страницы с каждой возможной рекламой. Если у Вас нет этого, Вы не можете закончить тем, что ловили рекламу, которая дает пару пользовательских проблем.

0
ответ дан 3 December 2019 в 05:09

Теги

Похожие вопросы