Как узнать процесс браузера
Конечно, современные браузеры развиваются. Программисты совершенствуют механизмы работы браузеров, но всё же полностью решить задачу порой бывает сложно. Например, когда «слабый» компьютер (4 ГБ или меньше оперативной памяти, недостаточная производительность процессора и/или устройств хранения информации и т.д.).
Так как узнать общий объём занятой памяти ( имеется ввиду оперативной памяти, скрытых процессов, файла подкачки ) браузером и понять действительно ли проблема из-за нехватки памяти или это проблема иного характера?
Windows
Самый простой способ - это открыть диспетчер задач (для ОС Windows на панели задач нажать правую кнопку мыши, из меню выбрать «Диспетчер задач») и посмотреть объём занимаемой памяти браузером.
Например, на скриншоте открыты два браузера Microsoft Edge и Mozilla Firefox с одинаковым количеством вкладок и одинаковыми сайтами. Firefox занимает в памяти 650 МБ, а Edge - 430 МБ. Но верно ли «Диспетчер задач» показывает занимаемый объём памяти?
В прошлой статье я рассказывал о программе Windows Terminal . Запустим Windows Terminal. По-умолчанию программа запускается с инструментом Windows PowerShell. Скопируйте текст ниже и вставьте в окно Windows Terminal.
Это команда покажет размер в байтах всех процессов браузера Microsoft Edge. Для Microsoft Edge процесс называется msedge. Для Mozilla Firefox - firefox, для Google Chrome - chrome, для Яндекс.Браузера - browser, для Opera - opera и т.д.
Для перевода в мегабайты разделим получившееся число на 1024 (килобайты) и ещё раз на 1024 (мегабайты) и получим 1178,19 МБ или примерно 1,1 ГБ с округлением в меньшую сторону.
Можно использовать такую команду для отображения сразу в мегабайтах.
Почему «Диспетчер задач» показывает 430 МБ, хотя формально браузер использует 1,1 ГБ памяти? Дело в том, что часть процессов браузеров скрыта системой.
Linux
Для пользователей операционных систем Linux я предлагаю (не претендуя на абсолютную правильность) использовать в терминале такую команду:
Как и для Windows необходимо перевести в мегабайты, например, так
и для вывода результата
Таким образом, можно понять достаточно ли вам ОЗУ, размера файла подкачки для работы браузера.
Инструкция о том, как понять, какая из вкладок браузера нагружает процессор и чрезмерно употребляет оперативную память, найдя её во встроенном диспетчере задач.
Случается иногда крайне противная ситуация, когда понимаешь, что система вдруг начинает тормозить. И ведь вроде бы ничего толком не запущено, кроме браузера, в котором, ах ты блин, открыто несколько десяток вкладок. Что делать? Как определить ту, что внезапно стала пожирать память и нагружать процессор, разгоняя кулер до немыслимых оборотов и тормозящую все прочие процессы?
При таком количестве открытых вкладок в браузере сложно прощёлкать все. Да и потом, как внешне определить, какая из них вдруг начала проказничать и пакостить?
Закрывать браузер или перезагружать ПК, а потом ждать, пока вся эта куча снова прогрузится, ужасно не хочется. Закрывать все - попрощаться с теми вкладками, которые только запланировал, но ещё не изучил.
Ведь про существование диспетчера задач Windows, который вызывается по сочетанию клавиш Ctrl+Alt+delete все знают?
Аналогичная штука существует и в большинстве современных браузеров, по крайней мере тех, что построены на движке Chromium. Ведь многие пользователи сегодня проводят свой день исключительно в сети, то есть в браузере.
Вызвать диспетчер процессов браузера можно по сочетанию клавиш Shift+Esc. Либо иначе:
- Меню-Дополнительные инструменты -Диспетчер задач (Chrome).
- Меню-Дополнительно-Дополнительные инструменты-Диспетчер задач (Яндекс.Браузер)
- Меню-Инструменты-Диспетчер задач (Vivaldi)
В нём можно увидеть список процессов внутри браузера: открытые вкладки, добавленные расширения, системные процессы браузера, которые можно отсортировать по количество употребляемой оперативной памяти или по нагрузке на процессор. Уже далее при необходимости можно завершить лишь то, что доставляет неудоство, не закрывая при этом браузер целиком или не трогая лишние табы.
Или закинуть денег на зарплату авторам.
Или хотя бы оставить довольный комментарий, чтобы мы знали, какие темы наиболее интересны читателям. Кроме того, нас это вдохновляет. Форма комментариев ниже.
Читайте о встроенном в Chrome Диспетчере задач. Как его открыть, посмотреть запущенные в браузере процессы, или завершить нежелательные . Как узнать какие процессы используют ресурс браузера, замедляют его работу и не являются ли они вредоносными.
Введение
Аналогично большинству операционных систем, обладающих встроенными приложениями «Диспетчер задач» или «Монитор ресурсов» , которые позволяют отслеживать все активные процессы и программы, запущенные на пользовательском компьютере, в веб-браузере «Google Chrome» также присутствует одноименная функция, ответственная за избавление от проблемных вкладок и расширений. И далее мы подробнее на ней остановимся.
Откройте «Диспетчер задач Google Chrome»
Доступ к искомой функции обозревателя «Google Chrome» , как и ко всем остальным настройкам браузера, возможен из панели управления. И чтобы осуществить переход к требуемой службе необходимо выполнить ряд последовательных действий.
Шаг 1. Откройте на компьютерном устройстве веб-браузер «Google Chrome» .
Шаг 2. В правом верхнем углу окна обозревателя, после адресной строки и кнопок управления установленными приложениями, нажмите на кнопку «Настройка и управления Google Chrome» , представленную в виде трех последовательно расположенных точек, образующих вертикальную линию, и откройте главное меню веб-браузера.
Шаг 3. Во всплывающей панели меню отыщите, в представленном перечне доступных системных действий, и выберите раздел «Дополнительные инструменты» , для отображения вложенного скрытого меню, в котором, из вариантов предложенных функций, выберите раздел «Диспетчер задач» .
Примечание. Для продвинутых пользователей обозреватель «Google Chrome» предоставляет возможность напрямую открыть окно «Диспетчер задач» без перехода в меню управления обозревателя. В качестве альтернативы, используйте комбинацию совместно нажатых клавиш «Shift + Esc» в программной платформе управления компьютерным устройством «Windows» , или клавиш «Search + Esc» в операционной системе «Chrome» .
Теперь, когда открыто окно «Диспетчер задач» веб-браузера «Google Chrome» , пользователи могут ознакомиться со списком всех сетевых вкладок, расширений и процессов, запущенных в данный момент в обозревателе и представленных в простой стандартной табличной форме.
Окончание любых хлопотных процессов
Ознакомившись с перечнем, представленных в окне «Диспетчер задач» , запущенных процессов, пользователи могут быстро завершить любой из них, непосредственно воспользовавшись возможностями данной службы. Такая операция может быть особенно полезна в случае, когда отдельная вкладка или исполняемая служба перестает реагировать на действия пользователей, замирает или не отвечает на соответствующее обращение браузера.
Чтобы принудительно прекратить исполнение проблемного процесса, необходимо отыскать его в окне «Диспетчер задач» веб-браузера «Google Chrome» , выделить, щелкнув левой кнопкой мыши, а затем нажать на кнопку «Завершить процесс» , ответственную за непосредственное исполнение команды.
При необходимости выбрать сразу несколько процессов, дальнейшее функционирование которых более не требуется, или активные задачи функционируют с ошибками, содержат отдельные неполадки, блокирующие исполнение установленных команд, имеют подтвержденный отказ работоспособности, то пользователи могут завершить исполнение всех процессов одновременно, отметив каждый необходимый элемент из списка, удерживая нажатой клавишу «Shift» или «Ctrl» (клавишу «Command» на устройствах «Mac» ), тем самым расширяя список выделения, а затем нажав на кнопку «Завершить процесс» для исполнения.
Ознакомьтесь с данными об используемых, запущенными задачами, ресурсах
Стандартная форма отображения функции «Диспетчер задач» содержит предустановленный, заданный по умолчанию, набор ресурсов, с которым пользователи могут ознакомиться сразу после запуска службы, и включает несколько важных источников данных. Однако представленным списком ресурсов возможности веб-браузера «Google Chrome» не ограничиваются. И пользователи могут ознакомиться со всеми ресурсами, используемыми каждой из активных задач. В обозревателе «Google Chrome» , на выбор пользователям, доступно более двадцати категорий статистических данных, которые могут быть мгновенно добавлены в основной список отображения функции «Диспетчер задач» в качестве новых дополнительных столбцов.
Для изменения количества отображаемых сведений пользователям необходимо щелкнуть правой кнопкой мыши по задаче, с дополнительными данными которой необходимо ознакомиться, и открыть всплывающее контекстное меню с полным списком доступных параметров статистики.
В представленном списке нажмите левой кнопкой мыши на любые дополнительные категории, чтобы добавить их в стандартное окно отображения сведений функции «Диспетчер задач» . Категории, отмеченные «галочкой» рядом с названиями, уже отображаются по умолчанию. Если необходимо убрать конкретный раздел статистических данных для уменьшения загруженности окна функции вариантами разнообразных сведений, то в контекстном меню нажмите на лишнюю категорию и убедитесь, что флажок рядом с ее именем был снят. И в главном окне функции столбец будет исключен из общей таблицы информационных данных, отображаемых в окне «Диспетчер задач» .
Полный список возможных категорий статистических сведений, доступных для отображения, представлен следующими разделами:
- «Задача»
- «Профиль»
- «Объем потребляемой памяти»
- «ЦПУ»
- «Процессорное время»
- «Время начала»
- «Сеть»
- «Идентификатор процесса»
- «GDI-дескрипторы»
- «USER-дескрипторы»
- «Кеш изображений»
- «Кеш скрипта»
- «Кеш CSS»
- «Память GPU»
- «Память SQLite»
- «Порт отладки NaCl»
- «Память JavaScript»
- «Переходы в активный режим»
- «Ошибки отсутствия страницы в памяти»
- «Приоритет процессов»
- «Количество соединений keepalive» .
Пользователи могут отсортировать данные в определенных столбцах, щелкнув левой кнопкой мыши по его заголовку. Например, если нажать на название столбца «Объем потребляемой памяти» , то процесс, использующий большую часть памяти, будет отображен первым, в отсортированном по убыванию результатов, списке.
Повторное нажатие на заголовок столбца «Объем потребляемой памяти» изменит способ представления статистических данных, и расположит готовые сведения в порядке возрастания, поместив в начало списка наименьший результат.
Совет для профессионалов: если дважды щелкнуть левой кнопкой мыши строку запущенной вкладки в окне функции «Диспетчер задач» , то веб-браузер «Google Chrome» мгновенно выполнит переход на выбранную вкладку. Если пользователи выбрали определенное расширение, обозреватель отобразит в новой вкладке соответствующую страницу настроек указанного расширения, предоставив доступ к связанным параметрам.
Заключение
Международная компьютерная сеть «Интернет» представляет собой самый обширный источник получения разнообразной информации, а также выступает главным связующим элементом для удаленной передачи данных и безопасного способа их хранения на сторонних закрытых серверах. И благодаря использованию специальных приложений, взаимодействие пользователей с сетью «Интернет» значительно упрощается.
Сетевые обозреватели позволяют обрабатывать поступающие данные и отображают информацию в доступном виде, а также облегчают их обработку, защиту, хранение, возможные варианты обмена и перемещения посредством внедрения разнообразных функциональных расширений и предустановленных служб.
В веб-браузере «Google Chrome» , одном из наиболее востребованном обозревателе среди пользователей в мире, доступна возможность дополнительной установки различных расширений множества разработчиков. За отслеживание информации и получение статистических данных о деятельности запущенных вкладок, расширений и исполняемых процессов, в «Google Chrome» отвечает функция «Диспетчер задач» , функционирующая по аналогии с одноименными службами операционных систем.
И пользователи, в случае возникновения непредвиденных ситуаций, связанных с отказом работоспособности отдельных вкладок, приложений или процессов, а также для ознакомления с нагрузкой и задействованием ресурсов обозревателя «Google Chrome» , могут воспользоваться статистическими результатами, отображаемыми в окне функции «Диспетчер задач» . Простой способ запуска функции позволит пользователям проанализировать состояние запущенных процессов обозревателя и в случае обнаружения неполадок мгновенно устранить проблему, принудительно завершив любой из процессов.
Это 2-я часть из 4-х, в которой рассматривается внутренняя работа Chrome. В предыдущей части мы рассмотрели, как различные процессы и потоки работают с разными частями браузера. В этом посте мы подробнее рассмотрим, как каждый процесс и поток взаимодействуют, чтобы отобразить веб-сайт.
- в ходе перевода, я старался вычленять из статьи ПОНЯТИЯ, т.е. текстовые единицы которые несут специальный (технический) смысл. В переводе эти понятия выделены по особенному — во первых понятия предваряются символом звёздочки, во-вторых в них вместо пробела используется тире. Например: *браузер-процесс, *сайто-изоляция. При переводе понятий, приоритет отдавался не красоте перевода, а желанию выделить, акцентировать, то что мы имеем дело с ПОНЯТИЕМ, а не с фигурой речи.
- также, некоторые слова переведены неверно с точки зрения русского языка, в жаргонном стиле, например пайплайн, продакшен. У "технарей" такой перевод не вызовет затруднений, у остальных читателей прошу прощения.
Рассмотрим простой пример использования веб-браузера: вы вводите URL в браузере, затем браузер извлекает данные из интернета и отображает страницу. В этой заметке мы остановимся на той части, где пользователь запрашивает сайт, а браузер готовится к отображению страницы — также известной как навигация.
Как мы описывали в первой части, все, что находится вне вкладки, обрабатывается *браузер-процессом. *Браузер-процесс имеет такие потоки, как *UI-поток (UI thread), который рисует кнопки и поля ввода браузера, *сетевой-поток (network thread), который имеет дело с сетевым стеком для получения данных из Интернета, *поток-хранения (storage thread), который контролирует доступ к файлам и многие другие. Когда вы вводите URL в адресную строку, ваш ввод обрабатывается *UI-потоком *браузер-процесса.
Рисунок 1: Интерфейс браузера вверху, схема *браузер-процесса с *UI-потоком, *сетевым-потоком и *потоком-хранения внутри внизу
= Шаг 1. Обработка ввода
Рисунок 1-bis: *UI-поток спрашивает, является ли входной запрос поисковым или URL-адресом
= Шаг 2. Старт навигации
Когда пользователь нажимает Enter, *UI-поток инициирует сетевой вызов для получения контента сайта. В углу вкладки отображается анимация загрузки, и *сетевой-поток проходит через соответствующие протоколы, такие как DNS поиск и создание TLS соединения для запроса.
= Шаг 3. Чтение ответа
Как только тело ответа (payload, полезная нагрузка) начинает поступать, *сетевой-поток при необходимости смотрит на первые несколько байт данных. В заголовке ответа 'Content-Type' должно быть указано, какой это тип данных, но так как он может отсутствовать или быть неправильным, то в данном случае выполняется прослушивание MIME-типа. Это "сложное дело", прокомментировано в исходном коде. Вы можете прочитать эти комментарии исходного кода, чтобы посмотреть, как разные браузеры обращаются с парами 'content-type/payload'
Рисунок 3: Заголовок ответа, содержащий Content-Type и полезную нагрузку, которая является фактическими данными
Если ответ является HTML-файлом, то следующим шагом будет передача данных в *рендер-процесс, но если это zip-файл или какой-либо другой файл, то это означает, что это запрос на загрузку, поэтому он будет передан в менеджер загрузок.
Рисунок 4: *Сетевой-поток спрашивает, являются ли данные ответа HTML данными с безопасного сайта
Здесь также выполняется проверка SafeBrowsing. Если домен и ответные данные, похоже совпадают с известным вредоносным сайтом, то *сетевой-поток предупреждает показом предупреждающей страницы. Кроме того, выполняется проверка Cross Origin Read Blocking (CORB), чтобы убедиться, что конфиденциальные межсайтовые данные не попадают в *рендер-процесс.
= Шаг 3. Поиск *рендер-процесса
После того, как все проверки завершены и *сетевой-поток уверен, что браузер может перейти к запрашиваемому сайту, *сетевой-поток сообщает *UI-потоку, что данные готовы. Затем *UI-поток ищет *рендер-процесс для продолжения рендеринга веб-страницы.
Рисунок 5: *Сетевой-поток, просящий *UI-поток предоставить *рендер-процесс
Поскольку сетевой запрос на получение обратного ответа может занять несколько сотен миллисекунд, применяется оптимизация для ускорения этого процесса. Когда *UI-поток посылает URL запрос в *сетевой-поток на шаге 2, он уже знает, к какому сайту он обращается. *UI-поток пытается проактивно найти или запустить *рендер-процесс параллельно с сетевым запросом. Таким образом, если все пойдет как ожидалось, *рендер-процесс уже будет находиться в режиме ожидания, к моменту когда *сетевой-поток получил данные. Этот резервный процесс может быть не использован, если навигация будет перенаправлена на другой сайт, в этом случае может потребоваться другой процесс.
= Шаг 4. Реализация перехода
Теперь, когда данные и *рендер-процесс готовы, выполняется IPC запрос из *браузер-процесса в *рендер-процесс для реализации перехода. Также передается стрим данных, для того чтобы *рендер-процесс мог продолжать получать HTML-данные. Как только *браузер-процесс получает подтверждение того, что в *рендер-процессе всё выполнено, навигация завершается и начинается фаза загрузки документа.
Рисунок 6: IPC между *браузер-процессом и *рендер-процессом, запрос на рендеринг страницы
= Дополнительный шаг. Завершение начальной загрузки
После реализации навигации *рендер-процесс продолжает загрузку ресурсов и рендеринг страницы. Подробнее о том, что происходит на этом этапе, мы расскажем в следующем посте. Как только *рендер-процесс "финиширует" рендеринг, он посылает IPC запрос обратно в *браузер-процесс (это происходит после того, как все события загрузки сработали на всех фреймах страницы и закончили своё выполнение). На этом этапе *UI-поток останавливает анимацию индикатора загрузки страницы.
Я пишу "финиширует" в кавычках, потому что JavaScript на стороне клиента все равно может загрузить дополнительные ресурсы и вывести новые представления после этого момента.
Рисунок 7: IPC-запрос от *рендер-процесса к *браузер-процессу для уведомления о том, что страница "загружена".
Простая навигация была завершена! Но что случится, если пользователь снова поместит другой URL в адресную строку? Что ж, процесс браузера пройдет те же самые этапы, что и при переходе на другой сайт. Но перед тем, как это сделать, ему нужно проверить для текущего отрисованного сайта, волнует ли его событие beforeunload.
beforeunload может создавать высплыавющее предупреждение "Покинуть этот сайт?" при попытке навигации наружу или закрытии вкладки. Все внутренние вкладки, включая ваш JavaScript код, обрабатывается *рендер-процессом, поэтому *браузер-процесс должен свериться с текущим *рендер-процессом, когда приходит новый навигационный запрос.
Внимание: Не добавляйте без необходмости обработчики beforeunload. Это создает дополнительные задержки, так как обработчик должен быть выполнен еще до того, как навигация может быть запущена. Этот обработчик событий должен добавляться только при необходимости, например, если необходимо предупредить пользователей о том, что они могут потерять данные, введенные на странице.
Рисунок 8: IPC-запрос от *браузер-процесса к *рендер-процессу, говорящий ему, что он собирается перейти на другой сайт
Если навигация была инициирована из *рендер-процесса (например, пользователь нажал на ссылку или JavaScript на стороне клиента запустил window.location = "https://newsite.com" ), то *рендер-процесс сначала проверяет обработчики beforeunload . Затем он проходит через тот же процесс, что и процесс запуска навигации. Единственное отличие состоит в том, что запрос на навигацию запускается от *рендер-процесса к *браузер-процессу.
Когда новая навигация осуществляется на сайт, отличный от текущего, вызывается отдельный *рендер-процесс для обработки новой навигации, в то время как текущий *рендер-процесс продолжается для обработки таких событий, как выгрузка. Для получения более подробной информации смотрите обзор состояния жизненного цикла страницы и то, как вы можете подключаться к событиям с помощью Page Lifecycle API.
Рисунок 9: 2 IPC-запроса от *браузер-процесса к новому *рендер-процессу, говорящему отрисовать страницу и говорящему старому *рендер-процессу выгрузить страницу
Одним из недавних изменений в процессе навигации является введение service worker. *Сервис-воркер — это способ написания сетевого прокси в коде вашего приложения; позволяющий веб-разработчикам иметь больше контроля над тем, что кэшировать локально а когда получать новые данные из сети. Если *сервис-воркер настроен на загрузку страницы из кэша, то нет необходимости запрашивать данные из сети.
Важно помнить, что *сервис-воркер — это JavaScript-код, который запускается в *рендер-процессе. Но когда приходит запрос на навигацию, как *браузер-процессу узнать что у сайта есть *сервис-воркер?
Рисунок 10: Сетевой-поток в процессе просмотра браузером скоупа \сервис-воркера
Рисунок 11: *UI-поток в *браузер-процессе запускает *рендер-процесс для работы с *сервис-воркерами; поток *сервис-воркера в *рендер-процессе затем запрашивает данные из сети
Рисунок 12: *UI-поток в *браузер-процессе, запускающий *рендер-процесс для обработки *сервис-воркера с параллельным запуском сетевого запроса
Всем известно, что находясь внутри браузера, нельзя извлечь достаточное количество информации о его пользователе с помощью простого JavaScript. Служебная информация, вроде имени браузерного движка, операционной системы и их версий хоть и дает общее представление о пользователе (и об аудитории в целом), но все же не является всеобъемлющей.
Для комплексного анализа пользователя используется User-ID в Universal Analytics, но с помощью независимых программных компонентов, запущенных и находящихся где-то в памяти компьютера рядом с браузером, тоже можно собирать данные о пользователе. Полученная непосредственно из памяти браузера информация позволит осуществить анализ как отдельного пользователя, так и всей аудитории. Здесь будет рассмотрено семейство браузеров на движке Webkit и на конкретном примере браузера Google Chrome.
Браузер как хранилище интересной информации
Ежедневно миллионы людей доверяют своему веб-браузеру самую сокровенную информацию: личные и банковские данные, списки избранных сайтов. Большая часть действительно «вкусной» информации (в первую очередь, для злоумышленников) скрывается как самим браузером (менеджеры паролей с шифрованием), так и веб-ресурсами, которыми люди пользуются с помощью браузера (безопасно написанный и отлаженный код, SMS-оповещения/подтверждения и т.д). Но помимо этого остаются открытыми и легкодоступными данные, вроде исходного кода страниц. Ведь именно там и находится большинство того материала, на основе которого и можно произвести комплексный анализ пользователей. И материал этот отнюдь не одного лишь технического характера.
Сами по себе браузеры (особенно на базе Chromium) построены таким образом, чтобы о пользователях «утекало» как можно меньше информации во внешний мир. Т.е разработчики всячески пытаются обезопасить людей от всевозможных, пусть даже и несущественных утечек. Google Chrome, к примеру, создает для каждой отдельной вкладки свою «песочницу» в виде отдельного процесса. О деталях можно узнать, перейдя по локальной ссылке: chrome://memory Логично предположить, что каждая такая отдельная вкладка-процесс хранит исходный код собственной страницы.
Как узнать то, что знает браузер?
Процесс браузера ничем не отличается от других процессов операционной системы, а потому и он точно так же хранит все свои данные в оперативной памяти и для него свойственны все те же принципы секторной памяти. Программные компоненты, будучи запущенными в пределах ОС, находятся на одном программном уровне с браузером. Это дает возможность прочитать память браузера, снять её дамп.
Теперь стоит понять, от чего же зависит качество сбора информации из исходных кодов открытых страниц браузера, располагающихся в памяти. Chromium — это OpenSource-проект, так что достаточно немного покопаться в его исходном коде, чтобы прояснить многие базовые аспекты.
Например, то, как устроена страница веб-документа. В классе Document, являющимся частью движка WebKit, есть вот такой код(С++):
Из этого кусочка можно судить, например, о том, что всю информацию о сущностях веб-страницы браузер хранит в объектах, являющихся иерархичными по своей структуре. В этом можно убедиться, заглянув и в каталог всех известных движку WebKit HTML-элементов.
Сочетая эту информацию со знаниями о том, как операционная система выделяет память для нового программного объекта, получается, что находиться в памяти HTML код страницы может в совершенно раздробленном виде.
Сканирование памяти и вычленение разведданных
Предположим, один из пользователей открыл у себя в браузере новую вкладку (вот такую). Что в этом простом случае, казалось бы, можно извлечь?
Например, то, что искал пользователь в поисковой системе, и что еще не было стерто браузером из памяти:
Можно узнать и некоторые персональные данные. Например, почтовый ящик конкретного пользователя:
С помощью анализатора дампа также удалось получить и исходный код страницы целиком. По всей видимости, где-то в программном коде браузера формируется строка, содержащая весь исходный код веб-страницы. Проанализировать его можно как вручную, так и с помощью всевозможных HTML-парсеров.
Часто полезную информацию получается извлечь благодаря механизму так называемого «межсайтового сопряжения». Например, когда определенные веб-ресурсы поддерживают авторизацию через аккаунт Google+, Facebook и т.д. В таком случае уже удастся получить наиболее приближённые к конкретному пользователю аналитические данные.
Предположим у целевого пользователя есть google-аккаунт и этот пользователь прокоментировал определенную сущность на сайте, который сопряжен с его аккаунтом Google. В таком случае бОльшая часть информации о google-пользователе будет инкапсулирована внутри исходного кода веб-страницы. Вот примерная часть дампа, которую можно будет вычленить из большинства страниц, интегрированных с Google:
Как минимум удалось получить ссылку на профиль пользователя, его имя и фамилию. На основе уже лишь этих данных можно развернуть широкомасштабный сбор информации о пользователе.
Что в итоге?
Часто бывает так, что крупные веб-проекты выпускают отдельные приложения для своих клиентов. Эти приложения, как правило, функционируют с браузером на одном уровне — на уровне операционной системы. Такой подход позволяет не только упрощать некоторые функции для пользователя, но и собирать о нем ценные аналитические данные, которые редко представляется возможным собрать в пределах самого браузера стандартными методами веб-аналитики. Некоторые производители клиентских приложений могут даже получать из памяти браузера глубоко личные данные, чтобы максимально «узнать» своего пользователя.
Внутри памяти браузера содержится огромное количество информации о пользователе. Вычленить базовые куски можно с помощью простого анализатора памяти процесса. Причем в этих кусках может содержаться информация широкого спектра. В конечном итоге именно эти базовые кусочки и могут лечь в основу комплексного анализа как отдельного пользователя, так и целой аудитории.
Читайте также: