Si vous souhaitez analyser les données d’un site Web, vous devez d’abord savoir d’où proviennent les données du site Web.
Lorsque les utilisateurs accèdent à Internet, ils envoient des demandes de service au serveur. La demande envoyée est enregistrée par le serveur dans le journal du serveur dans un enregistrement séparé. Il s'agit du journal de données du site Web le plus original.
Regardez d'abord le journal Apache
10.1.1.95 - utilisateur [18/mars/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 (compatible ; MSIE 6.0 ; Windows NT 5.1 ; Maxthon)"
Ce qui précède est un journal standard d’Apache.
Cette ligne de contenu est composée de 9 éléments. Dans l'exemple ci-dessus, deux éléments sont vides, mais la ligne de contenu entière est toujours divisée en 9 éléments.
· La première information est l'adresse de l'hôte distant. C'est-à-dire l'adresse IP de la machine du visiteur. Le serveur envoie des informations de réponse au visiteur en fonction de cette adresse IP.
· Le deuxième élément est vide, remplacé par un espace réservé "-". En fait, c’est vrai la plupart du temps. Cet emplacement est utilisé pour enregistrer l'identification du visiteur, qui n'est pas seulement le nom de connexion du visiteur, mais l'adresse e-mail du visiteur ou un autre identifiant unique. Ces informations sont renvoyées par identd, ou directement par le navigateur. Au début, cet endroit enregistrait souvent l’adresse e-mail du téléspectateur. Cependant, cela n'a pas duré longtemps car certaines personnes l'utilisaient pour collecter des adresses e-mail et envoyer du spam, et presque tous les navigateurs du marché ont supprimé cette fonctionnalité depuis longtemps. Ainsi, à partir d’aujourd’hui, les chances que nous voyions une adresse e-mail dans la deuxième entrée du journal sont minces, voire nulles.
· Le troisième élément est également l'utilisateur. Cet emplacement permet d'enregistrer le nom fourni par le visiteur lors de son authentification. Bien entendu, si certains contenus du site Internet nécessitent une authentification de l’utilisateur, ces informations ne seront pas vides. Cependant, pour la plupart des sites Web qui ne nécessitent pas de vérification de connexion, cette entrée sera toujours vide dans la plupart des enregistrements du fichier journal.
· Le quatrième élément enregistré dans le journal est l'heure de la demande. Ce message est placé entre crochets et se présente dans ce que l'on appelle « format de journal commun » ou « format anglais standard ». Par conséquent, l'enregistrement du journal dans l'exemple ci-dessus indique que l'heure de la demande était le 18 mars 2005, 12:21:42. Le "+0800" à la fin de l'information horaire indique que le fuseau horaire du serveur est en retard de 8 heures sur UTC. En fait, l'heure des serveurs nationaux est de +8000.
· La cinquième information de l'enregistrement du journal est peut-être l'information la plus utile de l'ensemble de l'enregistrement du journal. Elle nous indique le type de demande reçue par le serveur. Le format typique de ces informations est « Protocole de ressources de méthode ».
Dans l'exemple ci-dessus, la méthode est GET. D'autres méthodes qui peuvent apparaître fréquemment sont POST et HEAD. Il existe de nombreuses méthodes juridiques possibles, mais voici les trois principales.
Une ressource fait référence à un document, ou URL, qu'un navigateur demande au serveur. Dans cet exemple, le navigateur a demandé « /stats/awstats.pl?config=user ».
Le protocole est généralement HTTP, suivi d'un numéro de version.
· La sixième information enregistrée est le code d'état. Il nous indique si la demande a abouti ou quelle erreur a été rencontrée. La plupart du temps, cette valeur est de 200, ce qui signifie que le serveur a répondu avec succès à la requête du navigateur et que tout est normal. De manière générale, un code d'état commençant par 2 signifie un succès, un code d'état commençant par 3 signifie que la demande de l'utilisateur a été redirigée vers un autre emplacement pour diverses raisons, un code d'état commençant par 4 signifie qu'il y a une sorte d'erreur du côté client, et un code d'état commençant par 4 signifie qu'il y a une sorte d'erreur du côté client. Les codes d'état commençant par 5 indiquent que le serveur a rencontré une erreur.
· La septième entrée de l'enregistrement du journal représente le nombre total d'octets envoyés au client. Il nous indique si le transfert a été interrompu (c'est-à-dire si la valeur est la même que la taille du fichier). L'addition de ces valeurs dans les enregistrements du journal vous indique la quantité de données envoyées par le serveur au cours d'une journée, d'une semaine ou d'un mois.
· Le huitième élément de l'enregistrement du journal enregistre le répertoire ou l'URL où se trouvait le client au moment de faire la demande. Cette fois, il s'agit de "http://10.1.1.1/pv/", qui est la page d'accueil sous le répertoire pv de 10.1.1.1. Dans la plupart des cas, la page d'accueil sera un fichier Web du type et du nom spécifiés après la directive DocumentRoot dans httpd.conf.
· Le neuvième élément de l'enregistrement du journal représente les informations détaillées du client.
Ce qui précède est une explication des enregistrements du journal Apache.
Passez ensuite au journal IIS, les enregistrements sont similaires, sauf que l'authentification de connexion renvoyée par identd, car elle a toujours été vide, est devenue le contenu du cookie envoyé ou reçu, et il existe des contenus de sous-état supplémentaires du protocole.
Comme vous pouvez le voir ci-dessus, la plupart des données que nous avons analysées peuvent être obtenues, mais certains problèmes subsistent. Lorsque l'utilisateur clique sur les boutons avant et arrière du navigateur, le navigateur du client lit d'abord le cache et ne le trouve que. dans le cache. Sinon, il redemandera au serveur. Par conséquent, la capacité du serveur à se souvenir de la page après que l'utilisateur a cliqué en arrière ou en avant dépend entièrement de la façon dont la page est écrite et de l'état de la machine.
Lors de l'utilisation des journaux d'origine pour l'analyse, certains petits ifram et d'autres pages seront demandés séparément, ce qui fera que le nombre de demandes d'ouverture d'une page ne sera pas nécessairement de 1. C'est également l'un des inconvénients des journaux d'origine.
Dans le même temps, ces enregistrements servent principalement à suivre l'état et la sécurité du serveur, et certaines données ne sont pas enregistrées.
· La relation entre les pages n'est pas enregistrée et il n'y a aucune relation entre la page à partir de laquelle l'utilisateur a accédé.
· Il est impossible de distinguer une certaine visite d'un utilisateur, en particulier pour les sites Web qui ne sont pas tenus d'être accessibles.
· Les opérations de page ne peuvent pas être enregistrées, en particulier les opérations de clic.
Certains sites Web ont donc développé leurs propres méthodes d'enregistrement, utilisant généralement JS ou une demande d'image d'un pixel pour enregistrer ces informations.
De cette manière, plusieurs informations sont enregistrées, dont le référent de la page source visitée, le numéro de session, le numéro de cookie et les données générées par le clic. Et ces données peuvent être enregistrées directement dans la base de données.
L’utilisation de cette méthode réduit certes la difficulté de l’analyse et augmente les informations pouvant être analysées, mais elle sacrifie un certain degré de précision. On peut dire qu’il y a des gains et des pertes.
· Le premier concerne les données enregistrables. Puisqu'elles sont générées sur le client, si une erreur du serveur se produit, 100 % des données seront perdues. Le serveur ne répond pas du tout, alors comment les données peuvent-elles être sorties ? De plus, comme js doit être démarré pour transmettre des données, toutes les données seront perdues dans une certaine mesure. Généralement, lorsque l'état du serveur n'est pas mauvais, un taux de précision de 98 % est acceptable.
· Les données de la page source seront toujours perdues. En raison de la relation entre les sauts de page et les protocoles, une certaine partie de la page source sera perdue. Ce qui est plus gênant, c'est que les pages https sont transmises à l'aide d'un protocole crypté, quel que soit le protocole. Quelle que soit la méthode utilisée, elle sera perdue sur la page http.
· Cela dépend grandement de la langue et du protocole de la page. Les appels sur la page, Ajax, js, etc. peuvent affecter l'exactitude de l'enregistrement.
· Enfin, toutes les pages doivent être ajoutées avec du code. Ne sous-estimez pas cela s'il y a beaucoup de pages, c'est vraiment un problème si cette page est oubliée, cela affectera les données globales.
· L'adresse IP de la machine est introuvable. Il existe certaines différences entre l'adresse IP à ce stade et l'adresse IP indiquée dans le journal. Dans certains cas, lorsque plusieurs machines partagent une adresse IP, ce qui est enregistré n'est pas l'adresse IP de la machine finale de l'utilisateur, mais. l'IP sur la voie d'accès à Internet.
Pour résumer ce qui précède, comme pour l'analyse du site Web, étant donné que la relation entre la méthode d'acquisition de données et la méthode de programmation du site Web est relativement compliquée, vous devez être plus prudent lors de l'analyse des données du site Web. Des pannes et des pièges dans les données peuvent survenir à tout moment. temps.
Source de l'article : Le carnet de Lance