Комментарии
31
По моему опыту, можно заниматься скрапингом современных веб-сайтов даже не пользуясь безголовыми браузерами.Я очень много и долго этим занимаюсь, поэтому могу ответить, почему headless так популярен.
Проблема в том, что современный веб основан на фреймоврках и зачастую реверс для скарпинга становится очень сложным — контент запрашивается по частям с бэкэнда, как-то модифицируется и лишь потом превращается в то, что необходимо вытащить.
Да, можно раскрутить все запросы, в том числе и JS-обработчик который все это собирает потом в то, что нужно. Но это долго + зачастую это еще и меняется со временем.
Отсюда и популярность headless — запросил и потом просто забрал готовое с веб-страницы.
Однако да, если это можно вытащить простыми запросами и объем большой — то проще и быстрее заюзать обычные запросы.
некоторые сайты имеют защиту от скрапинга, например если вы запрашиваете только данные но не картинки и html то вас заблокируют по ip
Скиньте пример сайта, который блокирует свою работу, если вы не загрузили картинки. Хотя на самом деле попахивает не установленным заголовком User-Agent
Алишечка, например. Если запрашивать с их CDN картинки и ничего другого то быстро наступает бан. ЕМНИП они шарят ваш IP и при отдаче проверяют проценты запросов от него на другие ресурсы. Там достаточно сложная эвристика, к тому-же они постоянно ее меняют. Может сейчас они все это убрали — не знаю, проверялось в июне прошлого года.
Бан наступает всегда, если квоту по запросам превысил. Здесь эвристики никакой и не нужно. Более 100 запросов в минуту — бан. Самое простое, что можно сделать со стороны сервера
Бан по частоте запросов и их количеству — это другое (но оно там тоже есть), тут фишка в том, что нужно в процессе запроса картинок время от времени запрашивать что-то еще, чтобы квота по запросам сбрасывалась. Грубо говоря, если вы запросили 50 картинок подряд и при этом ни одного запроса к апи/за html/стилями — бан, а если сделаете запрос — то можете следующие 50 грузить точно также. Это очень простое объяснение, там все сложнее. Они там вообще параноики, причем в ущерб удобства своих пользователям.
Да уж) Наверное эти расширения для «улучшения процесса покупок» их здорово бесят, раз они так загоняются
Вы очень странно рассуждаете. Нельзя сравнивать мелкий сайт с 1000 пользователями в месяц и мега площадку с сотнями миллионов пользователей в день. Первые конечно не будут придумывать как вам помешать скачать картинку с их сервера, это просто экономически не целесообразно, а вот вторые это совсем другая история. Представьте себе, каждый запрос от пользователя стоит реальных денег, тк использует реальные ресурсы (процессорное время, место на жёстком диске, амортизация сервера, электричество, работа персонала и даже уборщицы тёти Зины), компания за всё это платит и не понятно почему она вдруг должны отдавать вам (другой компании) эти ресурсы, за которые они заплатили, бесплатно. Вы думаете что вы один хотите бесплатно забрать картинки, описание, отзывы и прочую инфу? Таких как вы очень много. Компании на этом теряют деньги, хоть и косвенно. По этому вынуждены защищаться.
Публичный API. Вот решение для компаний, у которых есть каталогизированная информация. Борьба со скрапингом путём усложнения сайта, это путь в никуда. Вы тратите больше ресурсов для придумывания логик запросов и интерфейсов, и это никак не спасает вас, а только увеличивает финансовое сопровождение сайта. А ведь можно просто создать публичный АПИ, даже платный, установив на него такую цену, что-бы было проще купить АПИ, чем скрапить сайт. Так вы и свои сервера разгрузите и ещё денежку заработаете на трудах по каталогизированию.
Многие этого не понимаю и продолжают вливать деньги в борьбу со скрапингом, а могли как минимум экономить, как максимум зарабатывать.
Многие этого не понимаю и продолжают вливать деньги в борьбу со скрапингом, а могли как минимум экономить, как максимум зарабатывать.
Но вы же в статье не писали про получение данных из open api за деньги, а предлагаете скрапить их за даром, да ещё и из апи которое предназначено для сайта компании, для клиентов, а не для вас))) более того при наличии платного апи, большинство все равно выберет путь стыбрить за бесплатно...
Я увы ещё ни одной статьи на Хабре не написал)
Платное АПИ должно быть сбалансировано_платным (возможно бесплатным) относительно скрапинга веб версии. То есть лимиты к Веб версии должны быть такими, что-бы разделять реального пользователя и скрапера.
Платное АПИ должно быть сбалансировано_платным (возможно бесплатным) относительно скрапинга веб версии. То есть лимиты к Веб версии должны быть такими, что-бы разделять реального пользователя и скрапера.
а если это был кэширующий прокси?
Вот вам в копилку ещё один кейс copart.com У них данные можно скрапить через их API к серверу, подсмотрев запросы на фронтенде. Но стоит защита. Если пользователь раз 2 минуты не обновит кукиес с помощью обфусцированного JS скрипта на сайте, то бан по IP на полчаса. Паппитир Js библиотека хэдлесс браузера эту проблему и решает.
По моему опыту, можно заниматься скрапингом современных веб-сайтов даже не пользуясь безголовыми браузерами. Это очень простой, быстрый и хорошо масштабируемый процесс.Можете, пожалуйста, показать, как мне, например, получить номер телефона из объявления на авито или юле без использования headless-браузера? Там для получения номера надо, во-первых, авторизоваться (на юле ещё и код из смс ввести, для чего надо, например, писать скрипт для мобилки, который читает смс и отправляет код на на сервер),
во-вторых, для получения номера телефона там генерируется каждый раз специальный ключ на клиенте, и этот ключ передаётся как get-параметр при ajax-запросе номера. Js-код обфусцирован, поэтому найти алгоритм и научиться генерировать этот ключ самому непросто. А даже если получится, завтра они поменяют алгоритм генерации и спрячут его в другое место, и придется опять начинать сначала.
Можно ковырять код сайтов, ковырять их апи, искать способы обхода защиты от скраппинга… а можно просто поставить puppeteer и не париться.
P.S. Скраппинг номеров осуждаю.
в данном случае без headless-браузера не обойтись. В статье речь именно о простых случаях, когда достаточно сформировать правильно запросы и получить нужные данные, не занимаясь лишней работой — рендерингом, исполнением JS и выжирая память.
А кто-то для простого парсинга/скраппинга использует headless-браузеры? Зачем? Это же из пушки по воробьям. Могу ошибаться, но обычно про headless-браузеры начинают гуглить и интересоваться, когда обычным парсингом не получается решить задачу.
Я с вами согласен. В статье почему то этот подход преподносят как откровение.
Дело в том, что когда появился Селениум и ФантомЖС, в скрапинг нахлынуло много новых «пользователей», которые сам скрапинг узнали как раз как связка Selenium+Browser, оттуда пошли монструозные конструкции для скрапинга банального ответа GET'у. Так что в принципе польза от статьи есть, как раз для той категории, которые кроме как через браузер раньше не скрапили
Вторая стадия монструозности началась с момента, когда в браузерах реализовали собственные headless режимы (тогда PhantomJS закончился). Это развязало руки даже тем скрипткидди, которые раньше этого сторонились. Стало же так просто, открыл браузер, записал действия с помощью расширения Selenium'а, скопировал в скрипт, добавил headless и всё, можно в прод.
Вторая стадия монструозности началась с момента, когда в браузерах реализовали собственные headless режимы (тогда PhantomJS закончился). Это развязало руки даже тем скрипткидди, которые раньше этого сторонились. Стало же так просто, открыл браузер, записал действия с помощью расширения Selenium'а, скопировал в скрипт, добавил headless и всё, можно в прод.
Точно, только забывают убирать флаг navigator.webdriver
Можно ковырять код сайтов, ковырять их апи, искать способы обхода защиты от скраппинга… а можно просто поставить puppeteer и не париться.
Поддерживаю, к тому же вычислительные ресурсы стоят не так дорого (а иногда даже можно бесплатно, AWS Lambda дает бесплатно 400 000 ГБ‑секунд вычислений в месяц, 3 ГБ-секунд в среднем на одну страницу, а это ~133333 страниц бесплатно), да и vps никто не отменял, чем тратить рабочее время на обратный инжиниринг API, что может быть оправдано только при больших объемах данных и частой выгрузке.
P.S. Скраппинг номеров и каких либо перс. данных тоже осуждаю
Еще можно подключить aiohttp чтобы парсить много запросов асинхронно. Ускоряет солидно, если горлышко в ожидании запросов (а обычно оно там и есть).
Лучше перейти сразу на scrapy. Асинхронность там из коробки. Можно настроить максимальное количество запросов на домен, умеет фильтровать запросы дубли и многое другое. Плюс отличная масштабируемость — добавил spider, добавил pipeline — готово. Если надо лезть глубже менять логику обработки ответов или отправки запросов — пишешь свой middleware. Раньше писал свои велосипеды для парсинга, на scrapy уже год как и доволен как слон.
Ох вдсина, уже забанил несколько подсетей ваших за скрапинг. Что дальше, будете рекламировать как эффективно дудосить с ваших серверов?
Недавно в США скраперы выиграли дело против сайта, который их банил. Суд постановил, что скрапинг легален, а чинить ему препятствия незаконно
Я довольно долго работаю над срэпингом страниц и тоже некоторое время пытался съехать с Selenium на реверс инжиниринг запросов к бекэнду.
Но, несмотря на уверения автора далеко не многие сайты используют запросы для вытаскивания информации с бэка. Есть еще старый добрый JSP, JSF, PHP-генерация и тд.
Это первое. А второе — поддержка функционала становится головной болью. Каждый раз, когда что-то меняется в принимаемых/отдаваемых данных, надо начинать процесс заново. В то время, если меняется UI, то работоспособность скрэпера восстановить можно довольно быстро и несложно.
Но если надо что-то собрать быстро и много, то конечно через реверс-инжиниринг запросов это будет работать намного быстрее.
Но, несмотря на уверения автора далеко не многие сайты используют запросы для вытаскивания информации с бэка. Есть еще старый добрый JSP, JSF, PHP-генерация и тд.
Это первое. А второе — поддержка функционала становится головной болью. Каждый раз, когда что-то меняется в принимаемых/отдаваемых данных, надо начинать процесс заново. В то время, если меняется UI, то работоспособность скрэпера восстановить можно довольно быстро и несложно.
Но если надо что-то собрать быстро и много, то конечно через реверс-инжиниринг запросов это будет работать намного быстрее.
Подскажите неспециалисту в этой области. Во тут в статье и в комментариях пишут, что владельцы крупных сайтов всячески сопротивляются скрейпингу данных. Но ведь есть поисковые роботы, которые в автоматическом режиме обходят весь сайт и скачивают с него весь контент. Почему их не банят?
Чем вообще поисковые роботы отличаются от роботов-скрейперов? И где граница между добросовестным поисковиком и недобросовестным скачивателем чужих данных?
Чем вообще поисковые роботы отличаются от роботов-скрейперов? И где граница между добросовестным поисковиком и недобросовестным скачивателем чужих данных?
Почему их не банят?
1. IP-подсети поисковых ботов, с которых идет «благой» скрейпинг заранее известны и они могут добавляться в список разрешенных без ограничений на количество запросов.
2. Пункт 1. сочетается с полем User-Agent, в котором прописывается например Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)
3. Поисковыми ботами учитывается директива Crawl-delay, что так скажем «смягчает» нагрузку на целевой сайт и позволяет тем самым сделать так, чтобы боты не упирались в лимиты запросов.
Чем вообще поисковые роботы отличаются от роботов-скрейперов?
По своей сути, технически, практически ничем. Отличаются конечной целью использования данных. Например гуглу интересны данные с целью продажи рекламы, а производителям/продавцам например интересны площадки конкурентов, которые демпингуют цены на товары, тем самым вытесняют их с рынка и т.д.
И где граница между добросовестным поисковиком и недобросовестным скачивателем чужих данных?
ИМХО граница в нарушении интеллектуальных прав первоисточника. Т.к. ты например тратил свои деньги или время на написание статей, а какой-то ушлый скраперщик спарсил все твой статьи за 5 минут и опубликовал на своем сайте под видом своих, а из-за того, что у него например сайт выше в поиске и/или имеет хорошую поисковую оптимизацию, то твои статьи «выстрелили» на его сайте. Он получил прибыль за рекламу, а ты только разочарование. Поисковики не скрывают ссылки на источник информации, в отличие от недобросовестных скраперщиков.
1. IP-подсети поисковых ботов, с которых идет «благой» скрейпинг заранее известны и они могут добавляться в список разрешенных без ограничений на количество запросов.
То есть, если кто-то создаст новую поисковую систему, то у него будут проблемы с индексацией сайтов — его будут принимать за скрейпера и блокировать?
Поисковики кроме ссылок на найденный сайт показывают часть контента — кусок статьи, картинки. Есть какие-нибудь нормы, какую часть контента имеет право показывать поисковик на своей странице?
С виду просто, но есть нюансы: вроде поисковик это то кто легально показывает содержимое вашего сайта на своём сайте, не раскрывая полностью текст и заставляя переходить людей по ссылкам. А вот скрейпер это тот кто выдаёт ваш контент за свой, всячески скрывая источник.
Но что если скрейпер вообще не публикует ваш уникальный контент, но собирает базу для анализа конкурентов? Ведь Гугл тоже продаёт информацию о сканированных страницах. Я уже не говорю про Яндекс Турбо или Google AMP где вообще весь контент показывается с серверов поисковика, тем самым отбирая посетителей у вас. С юридической точки зрения любая автоматизация сбора информации это скрейпинг. Следовательно разделить добросовестность их использования можно только по конечному результату. Поисковики приводят к вам посетителей, это плюс, продают информацию о вас — это минус. От скреперов только минусы.
Добросовестный поисковик приносит пользу сайту, приводя ему трафик. Недобросовестный скрапер никакой пользы сайту не приносит
я делаю high-performance скрапинг с одной биржи и там только через реверс-инжиниринг бекенда.
пишу скрапер для одного потока, потом просто создаю 20-30-100 потоков и выжимаю все из I/O и их бекенда.
проблема это отслеживать их многие фишечки а-ля CSRF токены и кукисы, которые следят что это пользователь в броузере, а не бот — с опытом приходит понимание всех их защит и их становится легко победить.
Также хотелось бы узнать кто как делает ip masquerading? это если вы скрапите в 100 потоков, чтобы запросы шли через 100 разных прокси по всему миру
пишу скрапер для одного потока, потом просто создаю 20-30-100 потоков и выжимаю все из I/O и их бекенда.
проблема это отслеживать их многие фишечки а-ля CSRF токены и кукисы, которые следят что это пользователь в броузере, а не бот — с опытом приходит понимание всех их защит и их становится легко победить.
Также хотелось бы узнать кто как делает ip masquerading? это если вы скрапите в 100 потоков, чтобы запросы шли через 100 разных прокси по всему миру
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Скрапинг современных веб-сайтов без headless-браузеров