Se quiser analisar os dados do site, primeiro você deve saber de onde vêm os dados do site.
Quando os usuários acessam a Internet, eles enviam solicitações de serviço ao servidor. A solicitação enviada é registrada pelo servidor no log do servidor em um registro separado. Este é o log de dados mais original do site.
Primeiro olhe o log do apache
10.1.1.95 - usuário [18/Mar/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 (compatível; MSIE 6.0; Windows NT 5.1; Maxthon)"
O acima é um log padrão do Apache.
Esta linha de conteúdo consiste em 9 itens. No exemplo acima, dois itens estão em branco, mas toda a linha de conteúdo ainda está dividida em 9 itens.
· A primeira informação é o endereço do host remoto. Ou seja, o IP da máquina do visitante. O servidor envia informações de resposta ao visitante com base neste IP.
· O segundo item fica em branco, substituído por um espaço reservado "-". Na verdade, isso é verdade na maioria das vezes. Este local é usado para registrar a identificação do visitante, que não é apenas o nome de login do visitante, mas o endereço de e-mail do visitante ou outro identificador exclusivo. Essas informações são retornadas pelo identd ou diretamente pelo navegador. No início, esse local geralmente registrava o endereço de e-mail do visualizador. No entanto, não durou muito porque algumas pessoas o usaram para coletar endereços de e-mail e enviar spam, e quase todos os navegadores do mercado removeram esse recurso há muito tempo. Portanto, a partir de hoje, as chances de vermos um endereço de e-mail na segunda entrada do log são quase nulas.
· O terceiro item também é usuário. Este local é usado para registrar o nome fornecido pelo visitante durante a autenticação. É claro que se algum conteúdo do site exigir autenticação do usuário, essa informação não ficará em branco. No entanto, para a maioria dos sites que não exigem verificação de login, essa entrada ainda estará em branco na maioria dos registros do arquivo de log.
· O quarto item registrado no log é o horário da solicitação. Esta mensagem está entre colchetes e está no que é chamado de "formato de log comum" ou "formato padrão em inglês". Portanto, o registro de log no exemplo acima indica que o horário da solicitação foi 18 de março de 2005, 12h21min42s. O “+0800” no final da informação de horário indica que o fuso horário do servidor está 8 horas atrás do UTC. Na verdade, o horário dos servidores domésticos é +8000.
· A quinta informação no registro de log é talvez a informação mais útil em todo o registro de log. Ela nos informa que tipo de solicitação o servidor recebeu. O formato típico desta informação é "Method Resource Protocol".
No exemplo acima, o método é GET. Outros métodos que podem aparecer com frequência são POST e HEAD. Existem muitos métodos legais possíveis, mas estes são os três principais.
Um recurso refere-se a um documento, ou URL, que um navegador solicita do servidor. Neste exemplo, o navegador solicitou "/stats/awstats.pl?config=user".
O protocolo geralmente é HTTP, seguido por um número de versão.
· A sexta informação registrada é o código de status. Ele nos informa se a solicitação foi bem-sucedida ou qual erro foi encontrado. Na maioria das vezes, esse valor é 200, o que significa que o servidor respondeu com sucesso à solicitação do navegador e está tudo normal. De modo geral, um código de status começando com 2 significa sucesso, um código de status começando com 3 significa que a solicitação do usuário foi redirecionada para outro local por vários motivos, um código de status começando com 4 significa que há algum tipo de erro no lado do cliente e um código de status começando com 4 significa que há algum tipo de erro no lado do cliente. Os códigos de status começando com 5 indicam que o servidor encontrou um erro.
· A sétima entrada no registro representa o número total de bytes enviados ao cliente. Diz-nos se a transferência foi interrompida (ou seja, se o valor é igual ao tamanho do arquivo). A soma desses valores nos registros de log informa quantos dados o servidor enviou em um dia, semana ou mês.
· O oitavo item do registro de log registra o diretório ou URL onde o cliente estava quando fez a solicitação. Desta vez é "http://10.1.1.1/pv/", que é a página inicial do diretório pv de 10.1.1.1. Na maioria dos casos, a página inicial será um arquivo da web do tipo e nome especificado após a diretiva DocumentRoot em httpd.conf.
· O nono item do registro representa as informações detalhadas do cliente.
O texto acima é uma explicação dos registros de log do Apache.
Em seguida, mude para o log do IIS, os registros são semelhantes, exceto que a autenticação de login retornada pelo identd, porque sempre esteve vazia, tornou-se o conteúdo do cookie enviado ou recebido, e há alguns conteúdos adicionais de subestado do protocolo.
Como você pode ver acima, a maioria dos dados que analisamos podem ser obtidos, mas ainda existem alguns problemas. Quando o usuário clica nos botões avançar e voltar do navegador, o navegador do cliente lê primeiro o cache e apenas o encontra. no cache. Caso contrário, ele solicitará novamente o servidor. Portanto, se o servidor consegue se lembrar da página depois que o usuário clica para voltar ou avançar depende inteiramente da maneira como a página é escrita e do status da máquina.
Ao usar logs originais para análise, alguns iframs pequenos e outras páginas serão solicitados separadamente, fazendo com que o número de solicitações para abrir uma página não seja necessariamente 1. Essa também é uma das desvantagens dos logs originais.
Ao mesmo tempo, esses registros servem principalmente para rastrear o status e a segurança do servidor, e alguns dados não são registrados.
· A relação entre as páginas não é registrada e não há relação entre qual página o usuário acessou.
· É impossível distinguir uma determinada visita de um utilizador, especialmente para websites que não necessitam de ser acessíveis.
· As operações de página não podem ser gravadas, especialmente operações de clique.
Portanto, alguns sites desenvolveram seus próprios métodos de gravação, geralmente usando JS ou uma solicitação de imagem de um pixel para registrar essas informações.
Desta forma, são registadas diversas informações, incluindo o referenciador da página de origem visitada, o número da sessão, o número do cookie e os dados gerados pelo clique. E esses dados podem ser registrados diretamente no banco de dados.
A utilização deste método reduz a dificuldade de análise e aumenta a informação que pode ser analisada, mas sacrifica um certo grau de precisão. Pode-se dizer que há ganhos e perdas.
· O primeiro são os dados graváveis. Como são gerados no cliente, se ocorrer um erro no servidor, 100% dos dados serão perdidos. O servidor não responde, então como os dados podem ser gerados? Além disso, como o js precisa ser iniciado para transmitir dados, todos os dados serão perdidos até certo ponto. Geralmente, quando o status do servidor não é ruim, uma taxa de precisão de 98% é aceitável.
· Os dados da página de origem ainda serão perdidos Devido à relação entre saltos de página e protocolos, uma certa quantidade da página de origem será perdida. O que é mais problemático é que as páginas https são transmitidas usando um protocolo criptografado. Não importa qual método seja usado, ele será perdido na página http.
· É muito afetado pelo idioma e protocolo da página. Chamadas na página, Ajax, js, etc. podem afetar a precisão do registro.
· Finalmente, todas as páginas devem ser adicionadas com código. Não subestime isso. Se houver muitas páginas, isso será realmente um problema. Se essa página for esquecida, isso afetará os dados gerais.
· O IP da máquina não pode ser encontrado. Existem algumas diferenças entre o IP neste ponto e o IP no log. Em alguns casos onde várias máquinas compartilham um IP, o que é registrado não é o IP da máquina final do usuário. o IP na rota de acesso à Internet.
Resumindo o que foi dito acima, no que diz respeito à análise do site, uma vez que a relação entre o método de aquisição de dados e o método de programação do próprio site é relativamente complicada, é necessário ser mais cauteloso ao analisar os dados do site. Falhas e armadilhas nos dados podem ocorrer a qualquer momento. tempo.
Fonte do artigo: caderno de Lance