Если вы хотите проанализировать данные веб-сайта, вы должны сначала узнать, откуда берутся данные веб-сайта.
Когда пользователи получают доступ к Интернету, они отправляют запросы на обслуживание на сервер. Отправленный запрос фиксируется сервером в журнале сервера отдельной записью. Это самый оригинальный журнал данных сайта.
Сначала посмотрите журнал Apache
10.1.1.95 - пользователь [18 марта 2005 г.: 12:21:42 +0800] «GET /stats/awstats.pl?config=user HTTP/1.1″ 200 899 «http://10.1.1.1/pv/» «Mozilla/4.0 (совместимый; MSIE 6.0; Windows NT 5.1; Maxthon)»
Выше приведен стандартный журнал Apache.
Эта строка содержимого состоит из 9 элементов. В приведенном выше примере два элемента пусты, но вся строка содержимого по-прежнему разделена на 9 элементов.
· Первая часть информации — это адрес удаленного хоста. То есть IP машины посетителя. Сервер отправляет посетителю ответную информацию на основе этого IP-адреса.
· Второй элемент пуст, заменен заполнителем «-». На самом деле, это правда в большинстве случаев. Это место используется для записи идентификационных данных посетителя, которые представляют собой не только имя пользователя, но и адрес электронной почты посетителя или другой уникальный идентификатор. Эту информацию возвращает identd или непосредственно браузер. Вначале в этом месте часто записывался адрес электронной почты зрителя. Однако это продлилось недолго, поскольку некоторые люди использовали его для сбора адресов электронной почты и рассылки спама, а почти все браузеры на рынке уже давно удалили эту функцию. Таким образом, на сегодняшний день вероятность того, что мы увидим адрес электронной почты во второй записи журнала, близка к нулю.
· Третий элемент также является пользовательским. Это место используется для записи имени, предоставленного посетителем при аутентификации. Конечно, если какой-либо контент на веб-сайте требует аутентификации пользователя, эта информация не будет пустой. Однако для большинства веб-сайтов, которые не требуют проверки входа, эта запись в большинстве записей файла журнала по-прежнему будет пустой.
· Четвертый элемент, записанный в журнале, — это время запроса. Это сообщение заключено в квадратные скобки и имеет так называемый «общий формат журнала» или «стандартный английский формат». Таким образом, запись журнала в приведенном выше примере указывает, что время запроса было 18 марта 2005 г., 12:21:42. «+0800» в конце информации о времени указывает на то, что часовой пояс сервера отстает от UTC на 8 часов. Фактически время на внутренних серверах составляет +8000.
· Пятая часть информации в записи журнала, пожалуй, самая полезная информация во всей записи журнала. Она сообщает нам, какой запрос получил сервер. Типичный формат этой информации — «Протокол ресурса метода».
В приведенном выше примере используется метод GET. Другие часто встречающиеся методы — POST и HEAD. Существует множество возможных законных способов, но это три основных.
Ресурс относится к документу или URL-адресу, который браузер запрашивает у сервера. В этом примере браузер запросил «/stats/awstats.pl?config=user».
Обычно используется протокол HTTP, за которым следует номер версии.
· Шестая часть регистрируемой информации — это код состояния. Он сообщает нам, был ли запрос успешным или какая ошибка произошла. В большинстве случаев это значение равно 200, что означает, что сервер успешно ответил на запрос браузера и все в порядке. Вообще говоря, код состояния, начинающийся с 2, означает успех, код состояния, начинающийся с 3, означает, что запрос пользователя был перенаправлен в другое место по разным причинам, код состояния, начинающийся с 4, означает, что на стороне клиента произошла какая-то ошибка, и код состояния, начинающийся с 4, означает, что на стороне клиента произошла какая-то ошибка. Коды состояния, начинающиеся с 5, указывают на то, что на сервере произошла ошибка.
· Седьмая запись в журнале представляет общее количество байтов, отправленных клиенту. Он сообщает нам, была ли передача прервана (т. е. совпадает ли значение с размером файла). Суммируя эти значения в записях журнала, вы узнаете, сколько данных сервер отправил за день, неделю или месяц.
· Восьмой элемент записи журнала записывает каталог или URL-адрес, по которому находился клиент во время отправки запроса. На этот раз это «http://10.1.1.1/pv/», то есть домашняя страница в каталоге pv 10.1.1.1. В большинстве случаев домашней страницей будет веб-файл, тип и имя которого указаны после директивы DocumentRoot в httpd.conf.
· Девятый элемент записи журнала представляет подробную информацию о клиенте.
Выше приведено объяснение записей журнала Apache.
Затем переключитесь на журнал IIS, записи аналогичны, за исключением того, что аутентификация входа в систему, возвращаемая identd, поскольку она всегда была пустой, стала содержимым отправленного или полученного файла cookie, а также есть некоторое дополнительное содержимое подсостояния протокол.
Как видно из вышеизложенного, большую часть проанализированных нами данных можно получить, но все же есть некоторые проблемы. Когда пользователь нажимает кнопки «Вперед» и «Назад» в браузере, браузер клиента сначала считывает кэш и только находит его. В противном случае он повторно запросит сервер. Таким образом, сможет ли сервер запомнить страницу после того, как пользователь нажмет кнопку «Назад» или «Вперед», полностью зависит от способа записи страницы и состояния машины.
При использовании исходных журналов для анализа некоторые небольшие iframe и другие страницы будут запрашиваться отдельно, в результате чего количество запросов на открытие страницы не обязательно будет равно 1. Это также один из недостатков исходных журналов.
При этом эти записи в основном предназначены для отслеживания состояния и безопасности сервера, а некоторые данные не записываются.
· Связь между страницами не записывается, и нет никакой связи между тем, с какой страницы пользователь перешел.
· Невозможно отличить определенное посещение от пользователя, особенно для веб-сайтов, доступ к которым не требуется.
· Операции со страницами не могут быть записаны, особенно операции с кликами.
Поэтому некоторые веб-сайты разработали свои собственные методы записи, обычно используя JS или запрос однопиксельного изображения для записи этой информации.
Таким образом, записывается несколько фрагментов информации, включая реферер посещенной исходной страницы, номер сеанса, номер файла cookie и данные, сгенерированные в результате клика. И эти данные можно записать прямо в базу данных.
Использование этого метода снижает сложность анализа и увеличивает объем информации, которую можно проанализировать, но при этом приходится жертвовать определенной степенью точности. Можно сказать, что есть приобретения и потери.
· Во-первых, это записываемые данные. Поскольку они генерируются на клиенте, в случае возникновения ошибки сервера 100% данных будут потеряны. Сервер вообще не отвечает, как же можно вывести данные? Более того, поскольку для передачи данных необходимо запустить js, все данные в определенной степени будут потеряны. Как правило, при неплохом состоянии сервера допустима точность 98%.
· Данные исходной страницы все равно будут потеряны. Из-за связи между переходами на страницы и протоколами определенная часть исходной страницы будет потеряна. Что еще более неприятно, так это то, что https-страницы передаются с использованием зашифрованного протокола, независимо от того. Независимо от того, какой метод используется, он будет потерян на http-странице.
· Сильно зависит от языка и протокола страницы. Вызовы на странице, Ajax, js и т. д. могут повлиять на точность записи.
· Наконец, все страницы должны быть добавлены с кодом. Не стоит этого недооценивать. Если страниц много, это действительно проблема. Если эту страницу забудут, это повлияет на общие данные.
· Невозможно найти IP-адрес машины. Между IP-адресом на данный момент и IP-адресом в журнале есть некоторые различия. В некоторых случаях, когда несколько компьютеров имеют общий IP-адрес, записывается не IP-адрес конечного компьютера пользователя. IP на маршруте доступа в Интернет.
Подводя итог вышесказанному, что касается анализа веб-сайта, поскольку связь между методом сбора данных и собственным методом программирования веб-сайта относительно сложна, вам необходимо быть более осторожными при анализе данных веб-сайта. Сбои и ловушки в данных могут возникнуть в любой момент. время.
Источник статьи: записная книжка Лэнса.