Explication détaillée du cas de session PHP

Cette fois, je vais vous apporter une explication détaillée du cas de la session PHP. Quelles sont les précautions lors de l'utilisation de la session PHP. Voici un cas pratique, jetons un coup d'oeil.

Cookie et session sont deux concepts qui sont facilement confondus par les débutants en développement Web. Clarifier les deux aidera à mieux comprendre l'interaction Web. Personnellement, je pense que les principales différences entre session et cookie sont les suivantes :

cookie

Les informations sont enregistrées sur le client

Le client est responsable de la mise en œuvre spécifique

La taille et la quantité des données sont généralement limitées

Les données sont facilement volées et falsifiées

session

Les données sont enregistrées sur le serveur

Le serveur est responsable de la mise en œuvre spécifique

En principe, il n'y a pas de limite sur la taille et la quantité des données

Sécurité plus élevée et forte crédibilité

Au sens étroit, la session fait référence à l'ID de session et aux données associées dans la session Web. Au sens large, la session fait référence à la session interactive entre les parties communicantes. Par exemple, connexion utilisateur est une interaction de session, retirer de l'argent à un guichet automatique est une interaction de session, etc.

Détails de la session

La fonction principale de la session est d'identifier une session et d'enregistrer des données pendant la session. Voici quelques détails de la séance.

Accès

PHP obtient et stocke toutes les données de la session via $_SESSIONsuper variable globale. $_SESSION est un tableau qui peut être facilement attribué et lu, par exemple :

$name = $_SESSION['NAME'];  // 读取session中的name值
$_SESSION['NAME'] = 'new name';   // 赋新值
unset($_SESSION['NAME']);     // 移除session中的值

Heure d'expiration

Les données de la session par défaut peuvent expirer dans le La session est supprimée plus tard, selon que PHP exécute ou non le garbage collection à temps. Puisque le coefficient de PHP exécutant le garbage collection est le nombre de requêtes, les conséquences sont les suivantes : 1. Les données de session des sites à faible trafic ne sont pas supprimées pendant une longue période après l'expiration du délai d'attente. 2. Les sites à fort trafic effectuent fréquemment un garbage collection de session ; 3. Exécution de garbage Les utilisateurs qui rencontrent un garbage collection en cours d'exécution peuvent rencontrer un délai système avant que la collection n'exécute la demande de l'utilisateur. Une meilleure solution consiste à désactiver le garbage collection par défaut de PHP et à exécuter régulièrement la fonction session_gc avec une tâche cron. Cela garantit non seulement la rapidité de la session, mais améliore également les performances et l'expérience utilisateur.

Pour supprimer manuellement des données dans la session, vous pouvez utiliser unset pour supprimer un seul élément de données, ou la fonction session_destroy pour supprimer violemment toutes les données.

Supports de stockage et sérialisation

Les données de la session sont enregistrées sur le disque sous forme de fichier par défaut à l'ouverture de la session, . lisez le fichier et le contenu est inversé. Sérialisez puis remplissez le tableau $_SESSION. Dans les sites à fort trafic, le répertoire dans lequel les fichiers de session sont stockés contiendra un grand nombre de petits fichiers, ce qui entraînera une lourde charge d'E/S sur le système de fichiers .

Le gestionnaire du module de session peut spécifier la méthode de stockage des données, comme les stocker dans une base de données, redis/memcache et d'autres supports. Les gestionnaires intégrés de PHP incluent les fichiers (par défaut), Redis et Memcache. Les utilisateurs peuvent enregistrer leur propre gestionnaire via session_set_save_handler. Les données stockées dans la

session peuvent être des types de base tels que string, ou des types complexes tels que des tableaux et des objets. Le serialize_handler dans les paramètres de session est utilisé pour définir le gestionnaire pour la sérialisation et la désérialisation. Une fois que le gestionnaire a sérialisé les données, celles-ci sont transmises au save_handler pour être enregistrées. La sérialisation montre que des types tels que les ressources ne peuvent pas et ne doivent pas être enregistrés dans la session. L'idée de sauvegarder un handle de connexion DB dans la session, puis de le retirer pour l'utiliser 10 minutes plus tard doit être abandonnée dès que possible.

nom du paramètre de session

Étant donné que http est un protocole sans état, le client doit porter l'identifiant de session lors de la demande afin que le serveur puisse distinguer la session. Le nom par défaut qui identifie l'identifiant de session est PHPSESSID. Vous pouvez utiliser session_name pour définir d'autres noms. Par exemple, afin d'empêcher les attaquants de deviner que le backend est un système de langage PHP, vous pouvez définir le nom de l'identifiant de session sur JSESSIONID pour confondre les attaquants.

La session s'ouvre automatiquement

La version actuelle de PHP grand public n'ouvre pas automatiquement la session par défaut. Par exemple, un visiteur regarde simplement la page puis quitte la page. Si la session est automatiquement ouverte, l'identifiant de session sera envoyé au client après une série d'opérations d'initialisation afin que l'utilisateur puisse être identifié lors de sa prochaine visite. Pour les visiteurs ponctuels ou les utilisateurs non connectés au système, ces opérations n’entraîneront qu’une surcharge supplémentaire.

L'inconvénient de ne pas ouvrir automatiquement la session est qu'avant d'utiliser la session, assurez-vous que la session est ouverte, sinon vous risquez d'obtenir des données vides. Si le nom de session par défaut est renommé, session_name doit être appelé avant session_start pour indiquer le nom de session actuellement utilisé.

Session distribuée

Pour les sites à fort trafic, il existe souvent plus d'un serveur PHP fournissant des services sur le back-end. Si les multiples requêtes de l'utilisateur n'arrivent pas sur le même serveur et que les données de session du serveur ne sont pas partagées, l'utilisateur peut être amené à se connecter à plusieurs reprises. La solution à ce problème peut être apportée par la distribution des requêtes sur le front-end ou par la mise en place d'une session partagée distribuée sur le back-end.

Dans les systèmes qui enregistrent les données de session sous forme de fichiers, vous pouvez spécifier un répertoire comme répertoire partagé, et toutes les sessions du serveur sont enregistrées dans ce répertoire ; dans les systèmes qui stockent les sessions dans redis/memcache/db, etc., le partage de session peut être réalisé en configurant les connexions au même serveur de session. Dans un système construit avec le partage de session, l'équilibreur de charge frontal peut distribuer les requêtes à n'importe quel serveur à volonté.

Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !

Lecture recommandée :

Explication détaillée du cas d'obtention de données d'actualité à l'aide de PHP+ajax

traitement par lots php curl pour obtenir une concurrence contrôlable Explication détaillée des cas d'opération asynchrone

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!