Практикум: как “оформить” бота
В контексте проекта мониторинга CMS в Рунете часто спрашивают, как сопровождать робота, собирающего статистику по сайтам. Отмечу, что при большом числе запросов (а робот, опрашивающий CMS-ки, генерирует этих запросов десятки миллионов), важна каждая мелочь. Кратко поделюсь некоторым нашим опытом.
CMS определяются по сигнатурам. Конкретная сигнатура для веб-сервера строится на основании анализа его ответов на специальный набор запросов. Естественно, сама методика опроса серверов должна быть оптимизирована в плане нагрузки. Например, там где только возможно, используются не GET-запросы, а HEAD. Также ограничен разумной величиной поток запросов на конкретный веб-сервер.
Робот корректно представляется в User-Agent. В нашем случае вот так: “Web-Monitoring/1.0; +http://monoid.nic.ru/”. Здесь присутствует адрес в корпоративном домене, под которым находится веб-страница с максимально подробным описанием того, что это за “зверь” забежал на ваш сайт. Почитайте: monoid.nic.ru. Практика подтверждает, что такая страница – необходимый элемент: она снижает обеспокоенность веб-мастеров.
Для IP-адреса, с которого ходит робот, обязательно нужна заполненная обратная зона, с говорящим именем, расположенная в том же узнаваемом корпоративном домене. В нашем случае это monoid-srv.nic.ru. Корректная обратная зона приветствуется не веб-мастерами, но админами и инженерами NOC-ов. (Да, возможно, с точки зрения внешнего наблюдателя, идеально было бы держать веб-сервер с информационной страницей на том же IP, с которого ходит робот, но технологически добротная реализация этого варианта слишком уж затратна.)
Правильно обозначенный робот – это очень хорошо. Прежде всего потому, что излишне осторожные веб-мастеры, обнаружившие следы запросов в логах, получают возможность во многом разобраться самостоятельно.
(А подробное описание методики с оценкой точности, подготовленное Артемием Ломовым, тоже опубликовано на stat.nic.ru.)
Адрес записки: https://dxdt.ru/2013/05/30/5861/
Похожие записки:
- Десятилетие DNSSEC в российских доменах
- Говорилки в google-поиске
- Пресертификаты в Certificate Transparency
- "Блокирующие" источники случайности в операционных системах
- Статья о Certificate Transparency
- DNS как транспорт для сигналов и данных
- Удостоверяющий центр TLS ТЦИ
- Ретроспектива заметок: ключ по фотографии
- Сервис для просмотра логов Certificate Transparency
- Сорок лет Интернету
- Про цепочки, RSA и ECDSA
1 комментарий от читателей
1. 31st May 2013, 16:48 // Читатель jno написал:
излишне озабочены или нет, а неопознанных ботов надо давить – факт.
если CMS не своя, то уверенности в отсутствии дыр быть не может.
да и со своей – тоже :)