Хитрый способ сбора качественной пробиваемой базы для XRUMER. Расширение профиля пользователя
Хитрый способ сбора качественной пробиваемой базы для XRUMER
Всем привет! Ни для кого не секрет, что каким бы замечательным не был софт для массовой регистрации/рассылки, без надлежащего качества баз он почти не имеет ценности. Базы можно добыть различными способами – спарсить самому /купить /найти в паблике/etc. Каждый вариант хорош по – своему и у каждого из них есть свои плюсы и минусы.
Паблик базы. Основной плюс это бесплатность. Часто в паблик сливаются и покупные базы, так что найти стоящие все-таки можно, другое дело что по этим базам будет работать сразу большое количество вебмастеров(как с лиц, так и с ломаным хрумом) и они быстро превратятся в помойку, а как известно, 1 трастовая ссылка зачастую лучше чем 1000 с гавносайтов.
Покупка базы. В основном это лотерея. Селлеров сейчас достаточное количество, но еще больше барыг, которые покупают и перепродают базы, выдавая за свои свежеспарсенные.Данный метод получения базы хорош в том случае если вы дорожите своим временем и покупаете базу у проверенного временем человека.
Самостоятельный парсинг. Самый лучший, но в тоже время затратный вариант. Для успешного парсинга нужно обладать словарем по тематике, признаками для парсинга + свежими прокси/соксами, если вы соберетесь парсить google, к примеру. Разумеется нужен и сам парсер, для хрумоводом все проще, так как с хрумером идет Hrefer, но все же я рекомендовал еще купить что-нибудь дополнительно. Лично я использую webparser, хотя многие хвалят a-parser, в общем кто на что горазд и у кого какие потребности.
База собранная собственноручно дает небольшое временное преимущество над другими вебмастерами, но не стоит думать, что собрав скажем базу форумов по хорошим признакам вы не обнаружите на доброй половине из них спам от «собратьев по оружию», но в любом случае свежеспаршенные (сырые) базы будут лучше паблик и зачастую лучше покупных, но как говорится этот вариант для тех у кого хорошие аппаратные мощности + есть время.
Есть конечно же еще варианты – утащить с чужого сервера, пропарсить интернет по примерно такому запросу
Пример лота в телдери:
_http://www.telderi.ru/ru/viewsite/67448
Как видим: “также прогонялся по профилям, прогон по профилям и каталогам был осуществлен 30 дней назад”, значит это “наш клиент”. Копируем урл сайта к себе в текстовый файл.
Таким нехитрым способом мы собираем БАЗУ сайтов, которые когда-либо прогонялись хрумером или ручками по трастовым сайтам. Отмечу тот факт, что большинство прогонщиков работают с дефолтным хрумером без измененного файла xas_AI.txt, что опять же нам на руку.
Буквально за час, можно собрать около 200 урлов сайтов, которые были «запачканы» прямым прогоном хрумером. Далее мы идем пополнять коллекцию на SEO форумы, там мы ищем темы с прогонами и смотрим на отзывы, форумов полно, для примера :
_http://www.maultalk.com/forum38.html
Далее идем по популярным веткам прогонщиков и смотрим в темах тех, кто оставлял отзывы об услуге. В 85% случаев, если у них заполнено поле сайт в профиле и подпись, то там находится их сайт, по которому они заказывали прогон, причем зачастую не один.
Работа по сбору таких урлов немного нудная, но зато эффект будет достойным(пока поверьте на слово).
После 2-3 часов работы, которую можно сбагрить на аутсорс толковому школьнику за 100-150 рублей с , мы получаем приличный список сайтов, теперь дело за малым – вытащить обратные ссылки.
Для начала идем в _ http://ahrefs.com и (можно воспользоватся другим софтом/сервисами) и извлекаем ВСЕ обратные ссылки
.
Данную нудную работу тоже лучше поручить кому-то.
Вторым этапом будет подготовка урлов для парсинга, и тут опять следует небольшая хитрость.
Нужно составить запросы для ПАРСИНГА примерно такого вида, приведу пример для сайт
«Просмотр профиля» http://сайт/
«Профиль» http://сайт/
«Профиль пользователя» http://сайт/
«Пользователь» http://сайт/
«Сайт» http://сайт/
«Домашняя страница» http://сайт/
«user» http://сайт/
«member» http://сайт/
«profile» http://сайт/
Просто ввести название домена в кавычках «http://сайт»
Просто погуляйте по форумам и посмотрите как выглядят там профили.
Сделать список таких признаков и урлов вам поможет EXCEL и оператор &
В одной колонке у вас урлы, в другой наши простенькие “признаки”:
Наглядный пример:
>>>>
1) в составе VS Premium и выше
2) зависит от редакции
3) для open source проектов бесплатен
4) ограничение на 10 одновременно загружаемых dll, за $ с меньшими ограничениями
Теперь рассмотрим замеченные мной достоинства и недостатки каждого профайлера в отдельности, не указанные в сравнительной таблице.
VS Profiler встроен в VS (правда, в premium и ultimate)взаимодействие с ADO.NET
капризный, иногда профайлинг не запускается без объяснения причин
секция appSettings должна быть в web.config, а не вынесена в отдельный файл, т.к. туда пишутся какие-то служебные настройки, а разработчики видимо не предусмотрели расположение данной секции во внешнем файле
на большом проекте и не очень мощной машине заметно подтормаживаетANTS Profiler самая подробная информация по вызовам методов, куча счетчиков производительности
в режиме профайла SQL думает, что кроме./SQLEXPRESS серверов больше не существует:)
нет сравнения двух результатов замеровdotTrace больше всех понравилась документация
в режиме просмотра дерева какая-то каша из цифр, названий методов, сборок
не запустился в режиме IIS Application, хотя всё делал по хорошей документации.EQATEC маленький и быстрый, подходит, если не нужно смотреть производительность построчно и не нужны исходники
данный минус - следствие плюса: меньше, чем у других конкурентов, возможностей.
Итак, сделаю, возможно, субъективный вывод. Мой выбор - EQATEC Profiler, для многих задач оценки производительности его более чем достаточно. Если у вас есть возможность использования VS Premium или Ultimate, встроенный профайлер достаточно неплохой продукт. В этом случае необходимость в покупке других профайлеров отпадёт. Из оставшихся двух профайлеров своей мощью поражает ANTS профайлер, хотя, конечно, почему нет сравнения результатов - непонятно. У dotTrace обилие вариантов приобретения с большим количеством возможностей самого профайлера.
Спасибо, что дочитали этот обзор! Надеюсь, он поможет вам сделать выбор.
P.S. Предложения по подробному обзору каждого профайлера принимаются.
В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures » Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.
Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.
В англоязычной литературе процесс обработки запроса в IIS называется «request processing pipeline» - что-то вроде «конвейера обработки запроса». В общих чертах он представлен на рисунке ниже для http-запроса.
Рис. 1. HTTP request processing pipeline (IIS 7.x).
Таким образом, http-запрос проходит по «сборочной ленте конвейера» через следующее:
1.
Браузер обращается к веб-серверу по определённому URL, на стороне сервера запрос перехватывает драйвер HTTP.SYS
.
2.
HTTP.SYS
стучится к WAS
для получения информации из хранилища конфигурации.
3.
Служба WAS
запрашивает конфигурацию из хранилища - из файла в папке IIS (applicationHost.config).
4.
Поскольку данный запрос получен по протоколу HTTP конфигурационную информацию получает служба W3SVC
(она же WWW Service на картинке), эта информация содержит в себе данные о пуле приложений (application pool) и прочих параметрах сайта.
5.
Служба W3SVC
использует эту информацию для кофигурации HTTP.SYS
.
6.
Служба WAS
запускает процесс W3WP.exe
для пула приложений, если он ещё не был запущен.
7.
В процессе W3WP.exe
работает приложение веб-сайта, которое, собственно, формирует и возвращает ответ драйверу HTTP.SYS
.
8.
HTTP.SYS
отправляет ответ браузеру.
В принципе уже этой схемы достаточно для прохождения интервью в большинстве компаний и получения общего представления об архитектуре IIS. Но если вы не для галочки сюда зашли, то прошу следовать далее.
2. Крупный план Теперь остановимся чуть поподробнее на каждом из упомянутых компонентов.2.1. HTTP.SYS На транспортном уровне IIS использует прослушивателей протоколов (protocol listeners), которые располагаются поверх стека TCP/IP. Наиболее интересный нам такой компонент – это системный драйвер HTTP.sys, который встроен в ядро ОС и работает с протоколами HTTP и HTTPS, регистрирующийся самостоятельно на прослушку всех портов, на которые будут приходить запросы к сайтам в IIS.Встроенный в ядро HTTP.sys стал нововведением в IIS 6, заместив собой Windows Socket API – компонент перехвата HTTP- и HTTPS-запросов на пользовательском уровне в IIS более ранних версий. Вероятно, интеграция драйвера в ядро является той самой причиной, по которой версия IIS жёстко привязана к версии Windows.
Драйвер принимает все входящие запросы и перенаправляет их в нужный пул приложений. Если по какой-то причине рабочий процесс, в коем хостится требуемый пул, остановлен (сбой, таймаут простоя, смена конфигурации и т.п.) или ещё запускается, то HTTP.sys сохраняет входящие запросы в специально отведённой для каждого пула очереди. Таким образом, запросы пользователей никуда не пропадают, и они вообще не замечают каких-то перебоев в работе сайтов под управлением IIS.
Ещё HTTP.sys умеет кешировать ответы (более подробно - Instances in which HTTP.sys does not cache content), поэтому некоторые запросы обрабатываются без передачи на уровень приложения, а также проводит первичный разбор URI запроса и его валидацию в соответствии с RFC 2396 (кое-что можно почерпнуть отсюда - Use of special characters like "%" ‘.’ and ‘:’ in an IIS URL) и журналирование запросов/ответов.
Некоторые настройки HTTP.sys вынесены в системный реестр Windows (более подробно - Http.sys registry settings for Windows). Кстати, там же – в реестре – можно подсмотреть обычное место прописки нашего гражданина: %SystemRoot%\system32\drivers\http.sys.
- Администрирование драйвера HTTP.sys.
- Управление рабочими процессами.
- Мониторинг показателей производительности веб-сайтов.
В IIS 7.x функция управления процессами была вынесена в отдельную службу – WAS (см. п.2.3) в целях универсализации архитектуры. Теперь WWW-служба стала по своей сути одним из адаптеров, специализируясь на протоколах HTTP/HTTPS – работа поверх драйвера HTTP.sys. Однако WWW-служба остаётся краеугольным компонентом IIS, поэтому её настройка отличается от настройки адаптеров к другим протоколам (чуть подобнее здесь); она функционирует в том же рабочем процессе, что и WAS, и реализована в той же самой библиотеке (рис. 2).
Рис.2.
Рабочий процесс со службами W3SVC и WAS.
Раз уж зашла речь об адаптерах к прослушивателям протоколов (protocol listener adpater), то давайте чуть задержимся и посмотрим, какие они бывают. В принципе IIS 7.x можно настроить для обработки запросов по любым протоколам помимо типовых HTTP и FTP, например, POP3, SMTP, Gopher. Вы даже вольны придумать свой протокол для своей веб- или WCF-службы и реализовать для него все нужные компоненты, если не жалко своего времени. Скорее всего, адаптеры и прослушиватели для наиболее распространённых протоколов доступны для свободного и коммерческого скачивания – этого я не проверял. Но прежде всего стоить обратить внимание на стандартные службы (рис. 3), поставляемые с.NET Framework и интегрированные с IIS:
- NetTcpActivator для протокола TCP;
- NetPipeActivator для Named Pipes;
- NetMsmqActivator для Message Queuing (ака MSMQ).
Рис. 3.
Перечень стандартных не-HTTP-адаптеров в оснастке Служб Windows.
Но всё-таки наиболее важным для нас адаптером является именно WWW-служба, т.ч. остановимся чуть подробнее на двух оставшихся от IIS 6 функциях.
Администрирование и конфигурирование HTTP(S). В момент обновления конфигурации веб-сайтов, служба WAS передаёт эту информацию WWW-службе, а та уже, в свою очередь, настраивает HTTP.sys на прослушку конкретных портов, разбор IP и заголовка запрашиваемого сайта и, возможно, других параметров драйвера. В обратную сторону W3SVC обращается к WAS, когда в очередь запросов в HTTP.sys поступает новый, – для получения рабочего процесса-обработчика данного запроса.
Отслеживание показателей производительности. WWW-служба ведёт счётчики производительности, используя для этого драйвер HTTP.sys, и предоставляет их показатели веб-сайтами и кэшу IIS. Более подробной информации по этому вопросу мне найти не удалось.
2.3. Windows Process Activation Service (WAS) Итак, WWW-служба в IIS 7.x, как и в IIS 6, продолжает выполнять задачи по администрированию HTTP.sys и управлению показателями производительности веб-сайтов. А вот задача управления рабочими процессами вынесена в отдельную службу – WAS. Она запускается системой в единственном экземпляре, считывает конфигурацию из файла %SystemRoot%\System32\inetsrv\Config\ApplicationHost.config и настраивает через соответствующие адаптеры прослушивателей протоколов в соответствии с указанной в нём информации. Напомним, что для протоколов HTTP/HTTPS адаптером является служба W3SVC, а прослушивателем – драйвер HTTP.sys. При перехвате прослушивателем запроса он через свой адаптер обращается к службе WAS для получения рабочего процесса приложения, которому будет передан запрос для обработки и формирования ответа клиенту.При активации нужного для обработки пользовательского запроса приложения задействуются следующие компоненты:
- Адаптеры прослушивателей (Listener adapters) – специальные службы Windows, работающие с конкретным протоколом и взаимодействующие с WAS для направления запросов к правильному рабочему процессу.
- Собственно WAS. Она ответственна за создание рабочих процессов и управление их временем жизни.
- Исполняемый файл w3wp.exe – шаблон рабочего процесса.
- Менеджер приложений управляет созданием и утилизацией доменов приложений (application domains), которые хостятся внутри рабочего процесса.
- Обработчики протоколов – протоколозависимые компоненты внутри рабочего процесса, ответственные за обмен данными между конкретным адаптером и рабочим процессом. Есть 2 типа обработчиков протоколов: у процесса (process protocol handler - PPH) и у домена приложения (AppDomain protocol handlers - ADPH).
Рис. 4.
Компоненты w3wp.exe для взаимодействия с внешними компонентами.
Как отмечалось выше, .NET Framework несёт в себе реализацию компонент для протоколов HTTP/HTTPS (наш любимый ASP.NET), net.tcp, net.pipe и MSMQ. Стеки протоколов HTTP/HTTPS и FTP всё-таки более тесно интегрированы в IIS и ОС, поэтому настройку для нового протокола лучше продемонстрировать на примере менее популярных дотнетовских протоколов. Итак, после установки фреймворка в файле конфигурации IIS ApplicationHost.config появляется записи:
А соответствующие компоненты PPH и ADPH настраиваются в дотнетовском machine.config:
Загрузка...
