что такое скрапинг веб сайтов
Web Scraping – что это такое и зачем он нужен
Каталог товаров, спортивная статистика, цены на офферы… Что-то знакомое, правда? Эти и другие вещи собирают с помощью специальных софтов или вручную в документы. Там информация структурирована; нет необходимости разбираться что и где.
Если вас заинтересовал такой метод, подумайте о веб-скрейпинге.
Что такое веб-скрейпинг?
Web scraping – процесс сбора данных с помощью программы, то есть в автоматическом режиме. В русскоязычном пространстве этот процесс называют парсингом. А программу – парсером. Точно так же как за бугром говорят to scrape web page, у нас – парсить страницу. Так что если изучаете материал на английском, не переводите как “скрабить”, “скрабы” и так далее 🙂
Как работает веб-скрейпинг?
Запускаете программу и загружаете в нее адреса страниц. А еще наполняете софт ключевыми словами и фразами, блоками и числами, которые нужно собрать. Эта программка заходит на указанные сайты и копирует в файл все, что найдет. Это может быть файл CSV-формата или Excel-таблица.
Когда программа закончит работу, вы получите файл, в котором вся информация будет структурирована.
Для чего он нужен?
С помощью веб-скрейпинга собирают нужные данные. Например, у вас новостное агентство и вы хотите проанализировать тексты своих конкурентов на конкретную тематику. Какую лексику они используют? Как подают информацию? Конечно, найти такие статьи можно вручную, но проще настроить программу и поручить эту задачу ей.
Или так: вы любитель литературы и сейчас страшно хотите найти информацию о болгарских поэтах. На болгарском. В болгарском интернете информации о болгарской литературе в принципе мало, и поэтому штудировать каждый сайт – долго. В таком случае есть смысл обратиться к парсеру. Загоняете в программу ключевые слова и фразы, по которым она будет искать материал о поэтах, – и ждете, пока софт завершит работу.
То есть парсить информацию могут все, кто захочет. В основном этим занимаются те, кому нужно проанализировать контент конкурентов.
Зачем нужны прокси для веб-скрейпинга?
В web data scraping вы не обойдетесь без прокси. Есть две причины использовать промежуточные серверы.
Если обновляете страницу определенное количество раз, на ней срабатывает антифрод-система. Сайт начинает воспринимать ваши действия как DDoS-атаку. Итог – доступ к странице закрывается, вы не можете зайти на нее.
Парсер делает огромное количество запросов на сайт. Поэтому в любой момент его работу может остановить антифрод-система. Чтобы успешно собрать информацию, используйте даже несколько IP-адресов. Все зависит от того, какое количество запросов необходимо сделать.
Некоторые сайты защищаются от веб-скрейпинга как могут. А прокси помогают эту защиту обойти. Например, вы парсите информацию из буржевых сайтов, а у них стоит защита. Когда программа захочет скопировать содержимое страниц в таблицу, она сможет это сделать, но ресурс отдаст вам информацию на русском – не на английском.
Чтобы обойти такую антифрод-систему, используют прокси того же сервера, на котором расположен сайт. Например, парсить инфу с американского веб-ресурса нужно с американским IP.
Какие прокси использовать?
Покупайте платные прокси. Благодаря ним вы обойдете антифрод-системы сайтов. Бесплатные не дадут вам этого сделать: веб-ресурсы уже давно занесли бесплатные айпи в блэклисты. И если сделаете огромное количество запросов с публичного адреса, в какой-то момент произойдет следующее:
Во втором случае вы сможете спокойно скрайпить и дальше, но нужно будет при каждом новом обращении к странице вводить капчу.
Иногда достаточно одного запроса, чтобы сайт закрыл доступ или попросил ввести капчу. Так что вывод один: только платные промежуточные серверы.
Купить недорогие прокси для веб-скрейпинга вы можете на нашем сайте. Если не будет получаться настроить его или возникнут другие вопросы – пишите. Саппорт онлайн 24/7. Отвечает в течение 5 минут.
А сколько их должно быть?
Точно сказать, сколько использовать прокси для веб-скрейпинга, нельзя. У каждого сайта свои требования, а у каждого парсера в зависимости от задачи будет свое количество запросов.
300-600 запросов в час с одного айпи-адреса – вот примерные лимиты сайтов. Будет хорошо, если отыщете ограничение для ресурсов с помощью тестов. Если у вас нет такой возможности – берите среднее арифметическое: 450 запросов в час с одного IP.
К каким программам обратиться?
Инструментов для парсинга много. Они написаны на разных языках программирования: Ruby, PHP, Python. Есть программы с открытым кодом, где пользователи вносят изменения в алгоритм, если нужно.
Для вас – самые популярные программы для веб-скрейпинга:
Найдите подходящий софт для себя. А еще лучше – попробуйте несколько и выберите из них лучший.
А это законно?
Если боитесь собирать данные с сайтов, не стоит. Парсинг – это законно. Все, что находится в открытом доступе, можно собирать.
Например, вы можете спокойно спарсить электронные почты и номера телефонов. Это личная информация, но если пользователь сам публикует ее, претензий уже не может быть.
Заключение
Благодаря веб-скрапингу пользователи собирают каталоги товаров, цены на эти товары, спортивную статистику, даже целые тексты. Парсинг без блокировки – это реально: достаточно просто закупиться IP-адресами и менять их.
Парсинг данных: лучшие сервисы для веб-скрапинга
Часто у вебмастера, маркетолога или SEO-специалиста возникает необходимость извлечь данные со страниц сайтов и отобразить их в удобном виде для дальнейшей обработки. В этой статье мы разберемся, что такое скрапинг данных, и расскажем про семь сервисов для веб-скрапинга, которые не требуют знания кода.
Что такое скрапинг данных?
Веб-скрапинг (Web Scraping) — это способ извлечения данных с сайта или приложения (в понятном человеку виде) и сохранение их в таблицу или файл.
К категории полезных данных могут относиться:
Это легальная техника, но иногда способы использования этих данных могут быть незаконными. Например, в октябре 2020 года Facebook подал жалобу в федеральный суд США против двух компаний, обвиняемых в использовании двух вредоносных расширений для браузера Chrome. Эти расширения позволяют выполнять скрапинг данных без авторизации в Facebook, Instagram, Twitter, LinkedIn, YouTube и Amazon.
Оба расширения собирали публичные и непубличные данные пользователей. Компании же продавали эти данные, которые после использовались для маркетинговой разведки — это нелегально.
Как используют полученные данные
У веб-скрапинга/парсинга очень широкий спектр применений. Например:
1. Отслеживание цен
Собирая информацию о товарах и их ценах, например, на Amazon или других платформах, вы сможете корректировать цены, чтобы опередить конкурентов.
2. Рыночная и конкурентная разведка
Если вы хотите поработать на новом рынке, то сначала нужно оценить свои шансы, а принять взвешенное решение поможет как раз сбор и анализ данных.
3. Модернизация сайтов
Когда компании переносят устаревшие сайты на современные платформы, они используют скрапинг сайта для быстрой и легкой выгрузки данных.
4. Мониторинг новостей
Скрапинг новостных сайтов и блогов позволяет отслеживать интересующие темы и экономит ваше время.
5. Анализ эффективности контента
Блогеры и контентмейкеры используют скрапинг для извлечения статистики о своих постах, видео, твитах в таблицу. Например, в этом видео автор статьи получает данные из его профиля на сайте Medium, используя веб-скрапер:
Данные в таком формате:
Сервисы для веб-скрапинга
Скрапинг требует правильного парсинга исходного кода страницы, рендеринга JavaScript, преобразования данных в читаемый вид и, по необходимости, фильтрации… Звучит суперсложно, правда? Но не волнуйтесь — есть множество готовых решений и сервисов, которые упрощают процесс скрапинга.
Вот 7 лучших инструментов для парсинга сайтов, которые хорошо справляются с этой задачей.
1. Octoparse
Octoparse — это простой в использовании скрапер для программистов и не только.
Особенности:
2. ScrapingBee
Сервис ScrapingBee Api использует «безлоговый браузер» и смену прокси. Также имеет API для скрапинга результатов поиска Google.
Безлоговый браузер (headless-браузер) — это инструмент разработчика, с помощью которого можно тестировать код, проверять качество и соответствие верстке.
Особенности:
3. ScrapingBot
ScrapingBot предоставляет несколько API: API для сырого HTML, API для сайтов розничной торговли, API для скрапинга сайтов недвижимости.
Особенности:
4. Scrapestack
Scrapestack — это REST API для скрапинга веб-сайтов в реальном времени. Он позволяет собирать данные с сайтов за миллисекунды, используя миллионы прокси и обходя капчу.
Особенности:
5. Scraper API
Scraper API работает с прокси, браузерами и капчей. Его легко интегрировать — нужно только отправить GET запрос к API с вашим API ключом и URL.
Особенности:
6. ParseHub
ParseHub — ещё один сервис для веб-скрапинга, не требующий навыков программирования.
Особенности:
7. Xtract.io
Xtract.io — это гибкая платформа, использующая технологии AI, ML и NLP.
Её можно настроить для скрапинга и структурирования данных сайтов, постов в соцсетях, PDF-файлов, текстовых документов и электронной почты.
Цена: есть демо-версия
Особенности:
Независимо от того, чем вы занимаетесь, парсинг веб-страниц может помочь вашему бизнесу. Например, собирать информацию о своих клиентах, конкурентах и прорабатывать маркетинговую стратегию.
Веб скрапинг для веб разработчиков: краткое резюме
Знание только одного подхода к веб скрапингу решает проблему в краткосрочной перспективе, но все методы имеют свои сильные и слабые стороны. Осознание этого экономит время и помогает решать задачу эффективнее.
Многочисленные ресурсы рассказывают об единственно верном методе извлечения данных с веб-страницы. Но реальность такова, что для этого можно использовать несколько решений и инструментов.
Если нет, советую углубиться в теорию, а потом вернуться к статье.
Статический контент
Начнем с простейшего подхода.
Если вы планируете скрапить веб-страницы, это первое с чего нужно начать. Потребуется незначительная компьютерная мощность и минимум времени.
Однако это работает только в том случае, если исходный HTML код содержит данные, на которые вы ориентируетесь. Чтобы проверить это в Chrome, щелкните правой кнопкой мыши страницу и выберите «Просмотр кода страницы». Теперь вы должны увидеть исходный код HTML.
Как только найдете данные, напишите CSS селектор, принадлежащий wrapping элементу, чтобы позже у вас была ссылка.
Для реализации вы можете отправить HTTP-запрос GET на URL-адрес страницы и получить обратно исходный HTML код.
В Node можно использовать инструмент CheerioJS, чтобы парсить необработанный HTML и извлекать данные с помощью селектора. Код будет выглядеть так:
Динамический контент
Во многих случаях вы не можете получить доступ к информации из необработанного HTML-кода, потому что DOM управлялся JavaScript, выполняемым в фоновом режиме. Типичным примером этого является SPA (одностраничное приложение), где HTML-документ содержит минимальный объем информации, а JavaScript заполняет его во время выполнения.
В этой ситуации решение состоит в том, чтобы создать DOM и выполнить сценарии, расположенные в исходном коде HTML, как это делает браузер. После этого данные могут быть извлечены из этого объекта с помощью селекторов.
Headless браузеры
Headless браузер это то же самое, что и обычный браузер, только без пользовательского интерфейса. Он работает в фоновом режиме, и вы можете управлять им программно вместо того, чтобы щелкать мышью и печатать с клавиатуры.
Puppeteer один из самых популярных headless браузеров. Это простая в использовании библиотека Node, которая предоставляет API высокого уровня для управления Chrome в автономном режиме. Он может быть настроен для запуска без заголовка, что очень удобно при разработке. Следующий код делает то же самое, что и раньше, но он будет работать и с динамическими страницами:
Конечно, можно делать более интересные вещи с Puppeteer, поэтому стоит посмотреть документацию. Вот фрагмент кода, который перемещается по URL, делает снимок экрана и сохраняет его:
Для работы браузера требуется гораздо больше вычислительной мощности, чем для отправки простого запроса GET и анализа ответа. Поэтому выполнение относительно медленное. Не только это, но и добавление браузера в качестве зависимости делает пакет массивным.
С другой стороны, этот метод очень гибкий. Вы можете использовать его для навигации по страницам, имитации щелчков, движений мыши и использования клавиатуры, заполнения форм, создания скриншотов или создания PDF-страниц, выполнения команд в консоли, выбора элементов для извлечения текстового содержимого. В принципе, все, что может быть сделано вручную в браузере.
Вы подумаете, что излишне моделировать целый браузер только для создания DOM. На самом деле это так, по крайней мере, при определенных обстоятельствах.
Jsdom — библиотека Node, которая анализирует передаваемый HTML, как это делает браузер. Однако это не браузер, а инструмент для построения DOM из заданного исходного HTML кода, а также для выполнения кода JavaScript в этом HTML.
Благодаря этой абстракции Jsdom может работать быстрее, чем headless браузер. Если это быстрее, почему бы не использовать его вместо headless браузеров все время?
Цитата из документации:
У людей часто возникают проблемы с асинхронной загрузкой скриптов при использовании jsdom. Многие страницы загружают скрипты асинхронно, но невозможно определить, когда это произошло, и, следовательно, когда надо запустить код и проверить полученную структуру DOM. Это фундаментальное ограничение.
Это решение показано в примере. Каждые 100 мс проверяется, появился ли элемент или произошел тайм-аут (через 2 секунды).
Он также часто выдает сообщения об ошибках, когда Jsdom не реализует некоторые функции браузера на странице, такие как: “Error: Not implemented: window.alert…”или “Error: Not implemented: window.scrollTo…”. Эта проблема также может быть решена с помощью некоторых обходных путей (виртуальных консолей).
Как правило, это API более низкого уровня, чем Puppeteer, поэтому нужно реализовать некоторые вещи самостоятельно.
Это немного усложняет использование, как видно из примера. Jsdom для этой же работы предлагает быстрое решение.
Давайте посмотрим на тот же пример, но с использованием Jsdom:
Jsdom — это быстрое и легкое решение, но можно всё сделать еще проще.
Нужно ли нам моделировать DOM?
Веб-страница, которую вы хотите скрапить, состоит из тех же HTML и JavaScript, тех же технологий, которые вы уже знаете. Таким образом, если вы найдете фрагмент кода, из которого были получены целевые данные, можно повторить ту же операцию, чтобы получить тот же результат.
Если всё упростить, данные, которые вы ищете, могут быть:
Найдя ресурс, содержащий данные, вы можете отправить аналогичный сетевой запрос на тот же сервер, что и исходная страница. В результате вы получите ответ, содержащий целевые данные, которые можно легко извлечь с помощью регулярных выражений, строковых методов, JSON.parse и т. д.
Простыми словами, вы можете взять ресурс, на котором расположены данные, вместо того, чтобы обрабатывать и загружать весь материал. Таким образом, проблема, показанная в предыдущих примерах, может быть решена с помощью одного HTTP-запроса вместо управления браузером или сложным объектом JavaScript.
Это решение кажется простым в теории, но в большинстве случаев оно может быть трудоемким и требует опыта работы с веб-страницами и серверами.
Начните с наблюдения за сетевым трафиком. Отличный инструмент для этого — вкладка Network в Chrome DevTools. Вы увидите все исходящие запросы с ответами (включая статические файлы, AJAX-запросы и т. д.), чтобы выполнять их итерацию и искать данные.
Если ответ будет изменен каким-либо кодом перед отображением на экране, процесс будет медленнее. В этом случае вы должны найти эту часть кода и понять, что происходит.
Как видите, такой способ может потребовать гораздо больше работы, чем методы, описанные выше. С другой стороны, это обеспечивает наилучшую производительность.
Диаграмма показывает требуемое время выполнения и размер пакета по сравнению с Jsdom и Puppeteer:
Результаты не основаны на точных измерениях и могут варьироваться, но хорошо показывают приблизительную разницу между этими методами.
Интеграция облачных сервисов
Допустим, вы реализовали одно из перечисленных решений. Один из способов выполнить скрипт — включить компьютер, открыть терминал и запустить его вручную.
Но это станет раздражать и будет неэффективно, поэтому лучше, если бы вы могли просто загрузить скрипт на сервер, и он выполнял код регулярно в зависимости от настроек.
Это можно сделать, запустив фактический сервер и настроив правила, когда выполнять скрипт. В других случаях, облачная функция более простой способ.
Облачные функции — это хранилища, предназначенные для выполнения загруженного кода при возникновении события. Это означает, что вам не нужно управлять серверами, это делается автоматически выбранным вами облачным провайдером.
Триггером может быть расписание, сетевой запрос и множество других событий. Вы можете сохранить собранные данные в базе данных, записать их в Google sheet или отправить по электронной почте. Все зависит от вашей фантазии.
Если вы используете Puppeteer, облачные функции Google — самое простое решение. Размер пакета в формате Headless Chrome (
130 МБ) превышает максимально допустимый размер архива в AWS Lambda (50 МБ). Есть несколько методов, чтобы заставить его работать с Lambda, но функции GCP по умолчанию поддерживают Chrome без заголовка, вам просто нужно включить Puppeteer в качестве зависимости в package.json.
Если вы хотите узнать больше об облачных функциях в целом, изучите информацию по архитектуре без серверов. На эту тему уже написано много хороших руководств, и большинство провайдеров имеют легкую для понимания документацию.
Web scraping вашего сайта: непрошеные гости и как их встречают
На первом в истории полностью виртуальном мероприятии РИТ++, прошедшем в конце мая, инженер Qrator Labs — Георгий Тарасов, рассказал публике про веб-скрейпинг, он же парсинг, популярным языком. Мы решили предоставить вашему вниманию транскрипцию выступления. Видео в конце публикации.
Всем привет! Наша компания достаточно давно занимается проблематикой защиты от DDoS-атак, и в процессе этой работы мне удалось достаточно подробно познакомиться со смежными сферами — изучить принципы создания ботов и способы их применения. В частности — web scraping, то есть массовый сбор публичных данных с веб-ресурсов с использованием ботов.
В какой-то момент эта тема меня необычайно увлекла многообразием прикладных задач, в которых скрейпинг с успехом используется. Здесь надо отметить, что наибольший интерес для меня представляет «темная сторона» веб-скрейпинга, то есть вредные и плохие сценарии его использования и негативные эффекты, которые он может оказать на веб-ресурсы и бизнес, с ними связанный.
При этом в силу специфики нашей работы чаще всего именно в такие (плохие) кейсы приходилось подробно погружаться, изучая интересные детали. И результатом этих погружений стало то, что мой энтузиазм передался коллегам — мы реализовали свое решение по отлову нежелательных ботов, ну а у меня накопилось достаточно историй и наблюдений, которые составят интересный, надеюсь, для вас материал.
Я буду рассказывать о следующем:
Поэтому, по совету старших товарищей, вы расчехляете питоновскую командную строку и пишете простой скрипт, который принимает на вход URL’ы, ходит туда, загружает страницу, парсит контент, находит в нем интересующие ключевые слова, блоки или цифры, складывает их в файлик или в табличку и идет дальше.
Заряжаете в этот скрипт необходимое количество вам адресов научных публикаций, онлайн-изданий, новостных ресурсов — он быстро все перебирает, складывая результаты. Вам же остается только по ним нарисовать графики и диаграммы, таблицы — а на следующее утро с видом победителя получаете свой заслуженный балл.
Давайте подумаем — сделали ли вы кому-нибудь в процессе плохо? Ну, если только вы не парсили HTML регулярным выражением, то скорее всего никому плохо вы не сделали, а тем более сайтам, на которые вы таким образом сходили. Это однократная деятельность, ее можно назвать скромной и незаметной, и вряд ли кто-то пострадал от того, что вы пришли, быстро и незаметно схватили необходимый вам кусочек данных.
С другой стороны — будете ли делать это снова, если все получилось в первый раз? Давайте признаемся — скорее всего, будете, потому что вы только что сэкономили кучу времени и ресурсов, получив, скорее всего, даже больше данных, чем изначально рассчитывали. И это не ограничивается только научными, академическими или общеобразовательными изысканиями.
Потому что информация стоит денег, а вовремя собранная информация стоит еще больших денег. Именно поэтому скрейпинг является серьезной статьей заработка для большого количества людей. Это популярная тема на фрилансе: зайдите и увидите кучу заказов с просьбой собрать те или иные данные или написать скрейпинговый софт. Также есть коммерческие организации, занимающиеся скрейпингом на заказ или предоставляющие платформы для этой активности, так называемый scraping as a service. Такое многообразие и распространение возможно, в том числе и потому, что скрейпинг сам по себе чем-то нелегальным, предосудительным, не является. С правовой точки зрения к нему очень трудно придраться — особенно на текущий момент, мы скоро узнаем почему.
Для меня особый интерес представляет еще и то, что в техническом плане бороться со скрейпингом вам никто не может запретить — это создает интересную ситуацию, в которой участники процесса по обе стороны баррикад имеют возможность в публичном пространстве обсуждать техническую и организационную сторону этого дела. Двигать вперед, в некоторой степени, инженерную мысль и вовлекать в этот процесс все больше людей.
С точки зрения правовых аспектов, ситуация, которую мы сейчас рассматриваем — с дозволенностью скрейпинга, не всегда была такой ранее. Если мы немного посмотрим на хронологию достаточно хорошо известных судебных исков, связанных со скрейпингом, то увидим, что еще на его заре первым иском была претензия компании eBay к скрейперу, который собирал данные с аукционов, и суд запретил ему заниматься этой деятельностью. Дальнейшие 15 лет статус-кво более-менее сохранялся — крупные компании выигрывали суды против скрейперов, когда обнаруживали их воздействие. Facebook и Craigslist, а также некоторые другие компании отметились исками, закончившимися в их пользу.
Однако год назад все внезапно изменилось. Суд счел, что претензия LinkedIn к компании, собиравшей публичные профили пользователей и резюме, является необоснованной, оставил без внимания письма и угрозы с требованием остановить активность. Суд постановил, что сбор публичных данных, вне зависимости от того, делает его бот или человек, не может быть основанием для претензии со стороны компании, демонстрирующей эти публичные данные. Такой мощный юридический прецедент сместил баланс в пользу скрейперов и позволил большему количеству людей проявлять, демонстрировать и пробовать собственный интерес в данной области.
Однако, глядя на все эти в целом безобидные вещи, не стоит забывать, что у скрейпинга много и негативных применений — когда данные собираются не просто для дальнейшего использования, но в процессе реализуется идея нанесения какого либо ущерба сайту, или бизнесу который за ним стоит, либо попытки обогатиться каким-то образом за счет пользователей целевого ресурса.
Посмотрим на несколько знаковых примеров.
Первым из которых является скрейпинг и копирование чужих объявлений с сайтов, которые предоставляют доступ к таким объявлениям: автомобили, недвижимость, личные вещи. Я в качестве примера выбрал замечательный гараж в Калифорнии. Представьте, что мы натравливаем туда бота, собираем картинку, собираем описание, забираем все контактные данные, и через 5 минут это же объявление у нас висит на другом сайте похожей направленности и, вполне возможно, что выгодная сделка произойдет уже через него.
Если мы немножечко здесь включим воображение и подумаем в соседнюю сторону — что если этим занимается не наш конкурент, а злоумышленник? Такая копия сайта может хорошо пригодиться чтобы, для примера, затребовать с посетителя предоплату, или просто предложить ввести данные платежной карты. Дальнейшее развитие событий вы можете представить самостоятельно.
Другой интересный случай скрейпинга это скупка товаров ограниченной доступности. Производители спортивной обуви, такие, как Nike, Puma и Reebok, периодически запускают кроссовки лимитированных и т.н. сигнатурных серий — за ними охотятся коллекционеры, они находятся в продаже ограниченное время. Впереди покупателей на сайты обувных магазинов прибегают боты и сгребают весь тираж, после чего эти кроссовки всплывают на сером рынке с совершенно другим ценником. В свое время это взбесило вендоров и ритейл, который их распространяет. Уже 7 лет они борются со скрейперами и т.н. сникер-ботами с переменным успехом, как техническими, так и административными методами.
И ещё один похожий случай — это исчерпание инвентаря в онлайн-магазинах. Он похож на предыдущий, но в нем никаких покупок на деле не производится. Есть онлайн-магазин, и определенные позиции товаров, которые приходящие боты сгребают в корзину в том количестве, которое отображается как доступное на складе. В итоге легитимный пользователь, пытающийся купить товар, получает сообщение о том, что данного артикула нет в наличии, огорченно чешет затылок и уходит в другой магазин. Сами же боты после этого сбрасывают набранные корзины, товар возвращается в пул — а тот, кому он был нужен, приходит и заказывает. Или не приходит и не заказывает, если это сценарий мелких пакостей и хулиганства. Отсюда видно, что даже если прямого финансового ущерба онлайн-бизнесу такая деятельность не наносит, то она как минимум может серьезно покорежить бизнес метрики, на которые будут ориентироваться аналитики. Такие параметры, как конверсия, посещаемость, востребованность товара, средний чек корзины — все они будут сильно испачканы действиями ботов по отношению к этим товарным позициям. И перед тем, как эти метрики брать в работу, их придется старательно и кропотливо очищать от воздействия скрейперов.
Помимо такой бизнес направленности, есть и вполне заметные технические эффекты, возникающие от работы скрейперов — чаще всего, когда скрейпинг делается активно и интенсивно.
Один из примеров из нашей практики у одного из клиентов. Скрейпер пришел на локацию с параметризованным поиском, который является одной из самых тяжелых операций в бэкенде рассматриваемой структуры. Скрейперу понадобилось перебрать достаточно много поисковых запросов, и он из 200 RPS к этой локации сделал почти 700. Это серьезно нагрузило часть инфраструктуры, из-за чего пошла деградация качества сервиса для остальных легитимных пользователей, взлетело время ответа, посыпались 502-е и 503-и ошибки. В общем, скрейпера это ничуть не волновало и он сидел и делал свое дело, пока все остальные судорожно обновляли страничку браузера.
Отсюда видно, что такая активность может вполне классифицироваться как прикладная DDoS-атака — и зачастую так оно и бывает. Особенно если онлайн-магазин не такой большой, не имеет многократно зарезервированной по производительности и расположению инфраструктуры. Такая активность вполне может если не положить ресурс полностью — скрейперу это не очень выгодно, так как он в данном случае не получит свои данные — то заставить всех остальных пользователей серьезно огорчиться.
Но, помимо DDoSа, у скрейпинга есть еще интересные соседи из сферы киберпреступности. Например, перебор логинов-паролей использует похожую техническую базу, то есть с помощью тех же самых скриптов это можно делать с упором на скорость и производительность. Для credential stuffing используют наскрейпленные откуда-то пользовательские данные, которые засовываются в поля форм. Ну и тот пример с копированием контента и выкладыванием его на похожих сайтах — это серьезная подготовительная работа для того, чтобы подсовывать фишинговые ссылки и заманивать ничего не подозревающих покупателей.
Для того чтобы понять как разные варианты скрейпинга могут с технической точки зрения повлиять на ресурс попробуем посчитать вклад отдельных факторов в эту задачу. Займемся некоторой арифметикой.
Представим, что у нас справа куча данных, которые нам нужно собрать. У нас есть задача или заказ выгрести 10 000 000 строчек товарных позиций, ценники например или котировки. И в левой части у нас есть бюджет времени, так как завтра или через неделю эти данные заказчику будут уже не нужны — они устареют, придется собирать их снова. Поэтому нужно уложиться в некоторый таймфрейм и, используя собственные ресурсы, сделать это оптимальным образом. У нас есть некоторое количество серверов — машин и айпи-адресов, за которыми они находятся, с которых мы будем ходить на интересующий нас ресурс. У нас есть некоторое количество инстансов пользователей, которыми мы прикидываемся — есть задача убедить онлайн-магазин или некоторую публичную базу в том, что это разные люди или разные компьютеры ходят за какими-то данными, чтобы у тех, кто будет анализировать логи, не возникало подозрений. И у нас есть некоторая производительность, интенсивность запросов, с одного такого инстанса.
Понятно, что в простом кейсе — одна хост-машина, студент с ноутбуком, перебирающий Washington Post, будет сделано большое количество запросов с одними и теми же признаками и параметрами. Это будет очень хорошо заметно в логах, если таких запросов будет достаточно много — а значит найти и забанить, в данном случае по айпи адресу, легко.
По мере усложнения скрейпинговой инфраструктуры появляется большее количество айпи адресов, начинают использоваться прокси, в том числе домовые прокси — о них чуть попозже. И мы начинаем мультиинстансить на каждой машине — подменять параметры запросов, признаки которые нас характеризуют, с той целью, чтобы в логах все это дело размазалось и было не столь бросающимся в глаза.
Если мы продолжаем в эту же сторону, то у нас появляется возможность в рамках этого же уравнения уменьшать интенсивность запросов с каждого такого инстанса — делая их более редкими, более эффективно их ротируя, чтобы запросы от одних и тех же пользователей не попадали рядом в логи, не вызывая подозрений и будучи похожими на конечных (легитимных) пользователей.
Ну и есть граничный случай — у нас в практике один раз был такой кейс, когда к заказчику пришел скрейпер с большого количества IP-адресов с совершенно разными признаками пользователей за этими адресами, и каждый такой инстанс сделал ровно по одному запросу за контентом. Сделал GET на нужную страничку товара, спарсил ее и ушел — и больше ни разу не появлялся. Такие кейсы довольно редки, так как для них нужно задействовать бóльшие ресурсы (которые стоят денег) за то же самое время. Но при этом отследить их и понять, что кто-то вообще приходил сюда и скрейпил, становится намного сложнее. Такие инструменты для исследования трафика, как поведенческий анализ — построение паттерна поведения конкретного пользователя, сильно усложняются. Ведь как можно делать поведенческий анализ, если нет никакого поведения? Нет истории действий пользователя, он ранее никогда не появлялся и, что интересно, больше с тех пор тоже ни разу не пришел. В таких условиях, если мы не пытаемся на первом же запросе что-то сделать, то он получит свои данные и уйдет, а мы останемся ни с чем — задачу по противодействию скрейпингу мы здесь не решили. Поэтому единственная возможность — это по первому же запросу догадаться, что пришел не тот, кого мы хотим видеть на сайте, и отдать ему ошибку или другим способом сделать так, чтобы он свои данные не получил.
Для того чтобы понять, как можно двигаться по этой шкале усложнения в построении скрейпера, посмотрим на арсенал, которым обладают создатели ботов, который чаще всего применяется — и на какие категории его можно разделить.
Первичная, самая простая категория, с которой большинство читателей знакомы — это скриптовый скрейпинг, использование достаточно простых скриптов для того, чтобы решать относительно сложные задачи.
И данная категория является, пожалуй, самой популярной и подробно задокументированной. Даже сложно порекомендовать, что конкретно читать, потому что, реально, материала море. Куча книжек написана по этому методу, есть масса статей и публикаций — в принципе достаточно потратить 5 / 4 / 3 / 2 минуты (в зависимости от нахальства автора материала), чтобы спарсить свой первый сайт. Это логичный первый шаг для многих, кто начинает в веб-скрейпинге. “Starter pack” такой деятельности это чаще всего Python, плюс библиотека, которая умеет делать запросы гибко и менять их параметры, типа requests или urllib2. И какой-нибудь HTML-парсер, чаще всего это Beautiful Soup. Также есть вариант использовать либы, которые созданы специально для скрейпинга, такие, как scrapy, которая включает в себя все эти функциональности с удобным интерфейсом.
С помощью нехитрых трюков можно прикидываться разными девайсами, разными пользователями, даже не имея возможности как-то масштабировать свою деятельность по машинам, по айпи адресам и по разным аппаратным платформам.
Для того чтобы сбить нюх у того, кто инспектирует логи на стороне сервера, с которого собираются данные, достаточно подменять интересующие параметры — и делать это нетрудно и недолго. Посмотрим на пример кастомного лог-формата для nginx — мы записываем айпишник, TLS-информацию, интересующие нас хедеры. Здесь, конечно, не все, что обычно собирается, но данное ограничение необходимо нам для примера — посмотреть на подмножество, просто потому что все остальное еще проще «подкинуть».
Для того, чтобы нас не банили по адресам, мы будем использовать residential proxy, как их называют за рубежом — то есть, прокси с арендованных (или взломанных) машин в домовых сетях провайдеров. Понятно, что забанив такой айпи адрес, есть шанс забанить какое-то количество пользователей, которые в этих домах живут — а там вполне могут оказаться посетители вашего сайта, так что иногда делать такое себе дороже.
TLS-информацию также не сложно подменить — взять наборы шифров популярных браузеров и выбрать тот, который понравится — наиболее распространенный, или ротировать их периодически, для того чтобы представляться разными устройствами.
Что касается заголовков — referer с помощью небольшого изучения можно выставлять такой, какой понравится скрейпленному сайту, а юзерагент мы берем от Chrome, или Firefox, чтобы он ничем не отличался от десятков тысяч других юзеров.
Дальше, жонглируя этими параметрами, можно представляться разными устройствами и продолжать скрейпить, не боясь как-то отметиться для невооруженного взгляда, ходящего по логам. Для вооруженного взгляда это все-таки несколько труднее, потому что такие простые уловки нейтрализуются такими же, достаточно простыми, контрмерами.
Сравнение параметров запроса, заголовков, айпи адреса друг с другом и с публично известными позволяет отлавливать самых наглых скрейперов. Простой пример — к нам пришел поисковой бот, но только IP у него почему-то не из сети поисковика, а из какого-нибудь облачного провайдера. Даже сам Гугл на странице, описывающей Googlebot, рекомендует делать reverse lookup DNS-записи для того, чтобы убедиться, что данный бот реально пришел с google.com или других валидных ресурсов Гугла.
Таких проверок бывает много, чаще всего они рассчитаны на тех скрейперов, которые не заморачиваются фаззингом, какой-то подменой. Для более сложных кейсов есть более надежные и более тяжеловесные методы, например подсунуть этому боту Javascript. Понятно, что в таких условиях борьба уже неравная — ваш питоновский скриптик не сможет выполнить и интерпретировать JS-код. Но это может сделать автор скрипта — если у автора бота есть достаточно времени, желания, ресурсов и навыка, чтобы пойти посмотреть в браузере, что делает ваш Javascript.
Суть проверок в том, что вы интегрируете скрипт в вашу страницу, и вам важно не только то, чтобы он выполнился — а еще чтобы он продемонстрировал какой-то результат, который обычно POST’ом отправляется обратно на сервер перед тем, как на клиента высыпется контент, и сама страничка загрузится. Поэтому, если автор бота решил вашу загадку и захардкодит правильные ответы в свой питоновский скрипт, либо, к примеру, поймет, где ему нужно парсить сами строки скрипта в поисках нужных параметров и вызываемых методов, и будет вычислять ответ у себя — он сможет обвести вас вокруг пальца. Вот, в качестве примера.
Я думаю, что некоторые слушатели узнают этот кусочек javascript’a — это проверка, которая раньше была у одного из самых крупных облачных провайдеров в мире перед доступом к запрашиваемой странице, компактная и очень простая, и в то же время без ее изучения так просто на сайт не пробиться. При этом, применив чуть-чуть усилий, мы можем попросить страницу в поисках интересующих нас JS-методов, которые будут вызываться, от них, отсчитав, найти интересующие нас значения, которые должны быть вычислены, и всунуть себе в код вычисления. После не забыть несколько секунд поспать из-за задержки, и вуаля.
Мы попали на страницу и дальше можем парсить то, что нам нужно, потратив не больше ресурсов, чем на создание самого нашего скрейпера. То есть с точки зрения использования ресурсов нам ничего дополнительного для решения таких задач не нужно. Понятно, что гонка вооружений в этом ключе — написание JS-челленджей и их парсинг и обход сторонними средствами — ограничивается только временем, желанием и навыками автора ботов и автора проверок. Эта гонка может длиться довольно долго, но в какой-то момент большинству скрейперов это становится неинтересно, ведь есть более интересные варианты с этим справиться. Зачем сидеть и парсить JS-код у себя в Python, если можно просто взять и запустить браузер?
Да, я говорю в первую очередь о headless-браузерах, потому что этот инструмент, изначально создававшийся для тестирования и Q&A, оказался идеально подходящим для задач веб-скрейпинга на текущий момент.
Не будем вдаваться в подробности по headless-браузерам, я думаю, что большинство слушателей о них и так знает. Оркестраторы, которые автоматизируют работу headless-браузеров, претерпели довольно бодрую эволюцию за последние 10 лет. Сначала, в момент возникновения PhantomJS и первых версий Selenium 2.0 и Selenium WebDriver, работающий под автоматом headless-браузер было совсем не трудно отличить от живого пользователя. Но, с течением времени и появлением таких инструментов, как Puppeteer для headless Chrome и, сейчас, творение господ из Microsoft — Playwright, которое делает то же, что и Puppeteer но не только для Хрома, а для всех версий популярных браузеров, они все больше и больше приближают «безголовые» браузеры к настоящим с точки зрения того, насколько их можно сделать с помощью оркестрации похожими по поведению и по разным признакам и свойствам на браузер здорового человека.
Для того чтобы заниматься распознаванием headless’ов на фоне обычных браузеров, за которыми сидят люди, как правило, используются те же самые javascript’овые проверки, но более глубокие, подробные, собирающие тучу параметров. Результат этого сбора отправляют обратно либо в средство защиты, либо на сайт, с которого скрейпер хотел забрать данные. Эту технологию называют fingerprinting, потому что собирается настоящий цифровой отпечаток браузера и девайса, на котором он запущен.
Вещей, на которые смотрят JS-проверки при фингерпринтинге, довольно много — их можно разделить на некоторые условные блоки, в каждом из которых копание может продолжаться до плюс бесконечности. Свойств действительно очень много, какие-то из них легко спрятать, какие-то менее легко. И здесь, как и в предыдущем примере, очень многое зависит от того, насколько дотошно скрейпер подошел к задаче сокрытия торчащих «хвостов» безголовости. Есть свойства объектов в браузере, которые подменяет по умолчанию оркестратор, есть та самая property (navigator.webdriver), которая выставляется в headless’ах, но при этом ее нет в обычных браузерах. Ее можно спрятать, попытку спрятать можно задетектировать, проверив определенные методы — то что проверяет эти проверки, тоже можно спрятать и подсовывать фальшивый output функциям, которые распечатывают методы, например, и до бесконечности это может длиться.
Другой блок проверок, как правило, отвечает за изучение параметров окна и экрана, которых у headless-браузеров по определению нет: проверка координат, проверка размеров, какой размер у битой картинки, которая не отрисовалась. Есть масса нюансов, которые человек, хорошо знающий устройство браузеров, может предусмотреть и на каждый из них подсунуть правдоподобный (но ненастоящий) вывод, который улетит в проверки fingerprint’а на сервер, который будет его анализировать. Например, в случае отрисовки средствами WebGL и Canvas каких-то картинок, 2D и 3D, можно полностью весь вывод взять готовый, подделать, выдать в методе и заставить кого-то поверить в то, что что-то действительно нарисовалось.
Есть более хитрые проверки, которые происходят не одномоментно, а допустим, JS-код покрутится какое-то количество секунд на странице, или будет вообще постоянно висеть и передавать какую-то информацию на сервер с браузера. К примеру, отслеживание положения и скорости движения курсора — если бот «кликает» только в нужные ему места и переходит по ссылкам со скоростью света, то это можно отследить по движению курсора, если автор бота не додумается в оркестраторе прописать какое-то человекоподобное, плавное, смещение.
И есть совсем дебри — это version-specific параметры и свойства объектной модели, которые специфичны от браузера к браузера, от версии к версии. И для того, чтобы эти проверки корректно работали и не фолсили, например, на живых юзерах с какими-нибудь старыми браузерами, нужно учитывать кучу вещей. Во-первых, нужно успевать за выходом новых версий, видоизменять свои проверки, чтобы они учитывали положение вещей на фронтах. Нужно держать обратную совместимость, чтобы на сайт, защищенный такими проверками смог приходить кто-то на нетиповом браузере и при этом не ловиться как бот, и множество другого.
Это кропотливая, достаточно сложная работа — такими вещами обычно занимаются компании, которые предоставляют bot detection как услугу, и заниматься таким самостоятельно на своем ресурсе — это не очень выгодное вложение времени и средств.
Но, что поделать — нам очень нужно поскрейпить сайт, обвешанный тучей таких проверок на безголовость и вычисляющий наш какой-нибудь headless-chrome с puppeteer’ом несмотря на все, как бы сильно мы ни старались.
Маленькое лирическое отступление — кому интересно поподробнее почитать про историю и эволюцию проверок, например на безголовость Chrome, есть забавная эпистолярная дуэль двух авторов. Про одного автора я знаю не очень много, а второго зовут Antoine Vastel — это молодой человек из Франции, который ведет свой блог о ботах и об их обнаружении, об обфускации проверок и многих других занятных вещах. И вот они со своим визави на протяжении двух лет спорили о том, можно ли задетектить headless Chrome.
А мы двинемся дальше и поймем, что же делать, если не получается headless’ом пробиться через проверки.
Значит, мы не будем использовать headless, а будем использовать большие настоящие браузеры, которые рисуют нам окошки и всякие визуальные элементы. Инструменты, такие как Puppeteer и Playwright позволяют вместо headless’а запускать браузеры с отрисованным экраном, считывать user input оттуда, снимать скриншоты и делать многое другое, что недоступно браузерам без визуальной составляющей.
Помимо обхода проверок на безголовость в этом случае также можно справится со следующей проблемой — когда у нас какие-то элементы хитрые сайтоделы, прячут из текста в картинки, делают невидимыми без совершения дополнительных кликов или каких-то других действий и движений. Прячут какие-то элементы, которые должны быть hidden, и на которые попадаются headless’ы: они-то не знают, что этот элемент сейчас не должен отображаться на экране, и попадаются на этом. Мы можем просто отрисовать в браузере эту картинку, скормить скриншот OCR’у, получить на выходе текст и использовать его. Да, это сложнее, дороже с точки зрения разработки дольше и ест больше ресурсов. Но есть скрейперы, которые работают именно так, и в ущерб скорости и производительности собирают данные таким образом.
«А как же CAPTCHA?» — спросите вы. Ведь OCR’ом (продвинутую) капчу не решишь без каких-то более сложных вещей. На это есть простой ответ — если у нас не получается решать капчу автоматом, почему бы не задействовать человеческий труд? Зачем разделять бота и человека, если можно комбинировать их труд для достижения цели?
Есть сервисы, которые позволяют отправлять им капчу, где она решается руками людей сидящих перед экранами, и через API можно получить ответ на свою капчу, подставить в запрос куку, например, которая будет при этом выдана, и дальше уже автоматизированно обрабатывать информацию с этого сайта. Каждый раз, когда всплывает капча, мы дергаем апишку, получаем ответ на капчу — подсовываем его в следующем вопросе и идем дальше.
Понятно, что это тоже стоит копеечку — решение капчи закупается оптом. Но если наши данные стоят дороже, чем составят затраты на все эти ухищрения, то, в конце концов, почему бы и нет?
Теперь, когда мы посмотрели на эволюцию в сторону сложности всех этих инструментов, давайте подумаем: как поступить, если скрейпинг произошел на нашем онлайн ресурсе — онлайн-магазине, публичной базе знаний, да на чем угодно.
В первую очередь скрейпер нужно обнаружить. Я вам так скажу: далеко не все кейсы публичного сбора вообще приносят негативные эффекты, как мы уже успели рассмотреть в начале доклада. Как правило, более примитивные методы, те же самые скрипты без рейт-лимитирования, без ограничения скорости запроса, могут нанести гораздо больше вред (если их не предотвращать средствами защиты), чем какой-нибудь сложный, изощренный, скрейпинг headful-браузерами с одним запросом в час, который сначала еще нужно как-то найти в логах.
Поэтому сначала нужно понять, что нас скрейпят — посмотреть на те значения, которые обычно аффектятся при этой деятельности. Мы говорим сейчас про технические параметры и про бизнес-метрики. Те вещи, которые можно увидеть у себя в Grafana, на протяжении времени отсматривая нагрузку и трафик, всякого рода всплески и аномалии. Это можно делать и вручную, если вы не используете средство защиты, но это более надежно делают те, кто умеет фильтровать трафик, обнаруживать разного рода инциденты и матчить их с какими-то событиями. Потому что помимо анализа логов постфактум и помимо анализа каждого отдельного запроса здесь может работать и использование какой-то накопленной средством защиты базы знаний, которая уже видела действия скрейперов на этом ресурсе или на похожих ресурсах, и можно как-то сравнить одно с другим — речь о корреляционном анализе.
Что касается бизнес-метрик — мы уже вспоминали на примере скриптов, которые наносят прямой или косвенный финансовый ущерб. Если есть возможность быстро отслеживать динамику по этим параметрам, то опять же скрейпинг можно заметить — а дальше уже, если вы решаете эту задачу самостоятельно, добро пожаловать в логи вашего бэкенда.
Что касается средств защиты, которые применяются против агрессивного скрейпинга, то большинство методов мы уже рассмотрели, говоря про разные категории ботов. Анализ трафика нам поможет от самых простых кейсов, поведенческий анализ поможет отследить такие вещи, как фаззинг (подмена identity) и мультиинстансинг на скриптах. Против более сложных вещей мы будем собирать цифровые отпечатки. И, конечно же, у нас есть CAPTCHA как последний довод королей — если мы не смогли хитрого бота как-то поймать на предыдущих вопросах, то, наверное, он споткнется на капче, не правда ли?
Ну, здесь все немножко сложнее. Дело в том, что по мере увеличения сложности и хитрости проверок они становятся все дороже в основном для клиентской стороны. Если анализ трафика и последующее сравнение параметров с какими-то историческими значениями можно делать абсолютно неинвазивно, без влияния на время загрузки страницы и на скорость работы онлайн ресурса в принципе, то fingerprinting, если он достаточно массивный и делает сотни разных проверок на стороне браузера, может серьезно повлиять на скорость загрузки. А странички с проверками тоже мало кто любит наблюдать в процессе перехода по ссылкам.
Что касается CAPTCHA — это самый грубый и самый инвазивный метод. Это штука, которая реально может отпугнуть пользователей или покупателей от ресурса. Капчу никто не любит, и к ней не от хорошей жизни обращаются — к ней прибегают тогда, когда все остальные варианты не сработали. Здесь есть и еще один забавный парадокс, некоторая проблема с таким применением этих методов. Дело в том, что большинство средств защиты в той или иной суперпозиции применяют все эти возможности в зависимости от того, с насколько сложным сценарием бот активности они столкнулись. Если у нас пользователь сумел пройти анализаторы трафика, если его поведение не отличается от поведения пользователей, если отпечаток его похож на валидный браузер, он преодолел все эти проверки, и тут в конце мы показываем ему капчу — и это оказывается человек… это бывает очень грустно. В итоге капча начинает показываться не злобным ботам, которых мы хотим отсечь, а довольно серьезной доле пользователей — людей, которые могут на это разозлиться и могут в следующий раз не прийти, не купить что-то на ресурсе, не поучаствовать в его дальнейшем развитии.
Учитывая все эти факторы — что же нам в итоге делать, если скрейпинг пришел к нам, мы на него посмотрели и смогли как-то оценить его влияние на наши бизнес- и технические показатели? С одной стороны, бороться со скрейпингом по определению как со сбором публичных данных, машинами или людьми смысла не имеет — вы сами согласились с тем, что эти данные доступны любому пользователю пришедшему из интернета. И решать задачу по ограничению скрейпинга «из принципа» — то есть из-за того что к вам приходят продвинутые и талантливые ботоводы, вы стараетесь их всех забанить — значит потратить очень много ресурсов на защиту, либо собственных, либо использовать дорогостоящее и очень сложное решение, self-hosted или облачное в «режиме максимальной защищенности» и в погоне за каждым отдельным ботом рисковать отпугнуть долю валидных пользователей такими вещами, как тяжелые javascript-проверки, как капча, которая выскакивает на каждом третьем переходе. Все это может ваш сайт до неузнаваемости изменить не в пользу ваших посетителей.
Если вы хотите использовать средство защиты, то нужно искать такие, которые позволят вам менять и как-то находить баланс между той долей скрейперов (от простых до сложных), которую вы будете пытаться отсечь от использования своего ресурса и, собственно, скоростью работы вашего веб-ресурса. Потому что, как мы уже посмотрели, какие-то проверки делаются просто и быстро, а какие-то проверки делаются сложно и долго — и при этом очень заметны для самих посетителей. Поэтому решения, которые умеют применять и варьировать эти контрмеры в рамках общей платформы, позволят вам достичь этого баланса быстрее и качественнее.
Ну и еще очень важно использовать то, что называется «правильный mindset» в изучении всей этой проблематики на своих или чужих примерах. Нужно помнить, что в защите нуждаются не сами публичные данные — их все равно рано или поздно увидят все люди, которые этого хотят. В защите нуждается пользовательский опыт: UX ваших клиентов, покупателей и пользователей, которые, в отличие от скрейперов, приносят вам доход. Вы сможете его сохранить и повысить, если будете лучше разбираться в этой очень интересной сфере.