Êtes-vous toujours confus au sujet des cookies, des sessions, des jetons et de JWT ?
coldplay.xixi
Libérer： 2020-08-19 13:44:21
avant
5748 Les gens l'ont consulté
Qu'est-ce que l'authentification
En termes simples, cela signifie vérifier l'identité de l'utilisateur actuel, prouver "vous êtes vous-même" (Par exemple : lorsque vous pointez chaque jour pour aller et revenir du travail, vous devez pointer avec votre empreinte digitale. Lorsque votre empreinte digitale correspond à l'empreinte digitale saisie dans le système, le pointage est réussi)
Authentification sur Internet :
Connectez-vous avec votre nom d'utilisateur et votre mot de passe
Envoyez le lien de connexion par e-mail
Recevez le code de vérification via le numéro de téléphone mobile
Tant que vous recevez l'e-mail/le code de vérification, vous êtes le propriétaire par défaut du compte
Qu'est-ce que l'autorisation
Un utilisateur accorde un tiers- autorisation de l'application du parti pour accéder à certaines ressources de l'utilisateur
Lorsque vous installez l'application mobile, l'APP vous demandera si vous devez accorder des autorisations (accès aux albums photo, localisation géographique, etc.)
Lorsque vous accédez au mini programme WeChat, lorsque vous vous connectez, le mini programme vous demandera si Autoriser l'octroi d'autorisations (obtention d'informations personnelles telles que surnom, avatar, région, sexe, etc.)
Les moyens de mettre en œuvre l'autorisation sont : cookie, session, jeton, OAuth
Que sont les informations d'identification
La condition préalable pour obtenir l'authentification et l'autorisation est-ce qu'un média (certificat) est nécessaire pour marquer l'identité du visiteur
Pendant la période des Royaumes combattants, Shang Yang a mené sa réforme et a inventé le poste de prise de photo. L'autocollant photo est délivré par le gouvernement et est une planche de bambou lisse et finement polie sur laquelle est gravée la photo de profil du titulaire et son lieu de naissance. Les Chinois doivent l'avoir. S'ils ne l'ont pas, ils sont considérés comme des infiltrés ou des espions.
Dans la vraie vie, chacun aura une carte d'identité de résident exclusive, qui est un document légal utilisé pour prouver l'identité du titulaire. Grâce à la carte d'identité, nous pouvons demander des cartes de téléphone portable/cartes bancaires/prêts personnels/transport, etc. Il s'agit du certificat certifié.
Dans les applications Internet, les sites Web généraux (tels que Nuggets) ont deux modes, le mode invité et le mode connexion. En mode invité, vous pouvez parcourir normalement les articles sur le site Web. Une fois que vous souhaitez aimer/collecter/partager des articles, vous devez vous connecter ou créer un compte. Lorsque l'utilisateur se connecte avec succès, le serveur émettra un jeton au navigateur utilisé par l'utilisateur. Ce jeton est utilisé pour indiquer votre identité. Chaque fois que le navigateur envoie une demande, il apportera ce jeton avec lui et vous pourrez l'utiliser. it. Fonctionnalités non disponibles en mode invité.
Que sont les Cookies
HTTP est un protocole sans état (pas de mémoire pour le traitement des transactions, à chaque fois que le client et le service Lorsque le la session client est terminée, le serveur n'enregistrera aucune information de session ) : Chaque requête est totalement indépendante. Le serveur ne peut pas confirmer les informations d'identité du visiteur actuel, et ne peut pas distinguer l'expéditeur de la dernière requête de celui-ci. l'expéditeur est la même personne ? Par conséquent, afin de suivre les sessions (pour savoir qui me rend visite), le serveur et le navigateur doivent activement maintenir un état. Cet état est utilisé pour informer le serveur si les deux requêtes avant et après proviennent du même navigateur. Cet état doit être atteint via des cookies ou des sessions.
Le cookie est stocké sur le client : Un cookie est un petit morceau de données envoyé par le serveur au navigateur de l'utilisateur et enregistré localement. Il sera utilisé la prochaine fois que le navigateur fera un. la demande au même serveur est transportée et envoyée au serveur.
Les cookies ne sont pas inter-domaines : Chaque cookie sera lié à un seul nom de domaine et ne pourra pas être utilisé sous d'autres noms de domaine Entre le nom de domaine de premier niveau et le. nom de domaine de deuxième niveau Il est autorisé à être partagé et utilisé ( dépend du domaine) .
La session est un autre Le mécanisme pour enregistrer l'état de la session du serveur et du client
la session est implémentée sur la base de cookies. La session est stockée côté serveur et le sessionId sera stocké dans le cookie du client
Processus d'authentification de session :
Lorsque l'utilisateur demande le serveur pour la première fois, le serveur en fonction des informations pertinentes soumises par l'utilisateur, créer la session correspondante
Renvoyer les informations d'identification uniques de cette session, SessionID, au navigateur lorsque la demande revient
Après que le navigateur ait reçu le Informations SessionID renvoyées par le serveur, il stockera ces informations dans Cookie , et le cookie enregistre à quel nom de domaine appartient ce SessionID
Lorsque l'utilisateur accède au serveur pour la deuxième fois, la requête déterminera automatiquement s'il y a Il y a des informations de cookie sous ce nom de domaine. S'il y en a, les informations de cookie seront également automatiquement envoyées au serveur. Le serveur obtiendra l'ID de session du cookie, puis recherchera les informations de session correspondantes en fonction de l'ID de session. introuvable, cela signifie que l'utilisateur n'est pas connecté ou que la connexion n'est pas valide. Si la session est trouvée, cela prouve que l'utilisateur s'est connecté et peut effectuer les opérations suivantes.
Selon le processus ci-dessus,
SessionID est un pont reliant Cookie et Session La plupart des systèmes utilisent également ce principe pour vérifier l'état de connexion de l'utilisateur.
Recommandations de sujets connexes :
session php (sujet)
La différence entre Cookie et Session
Sécurité : La session est plus sécurisée que le cookie. La session est stockée côté serveur, tandis que le cookie est stocké côté serveur. côté client.
Les types de valeurs d'accès sont différents : Cookie ne prend en charge que le stockage de données de chaîne. Si vous souhaitez définir d'autres types de données, vous devez les convertir en chaîne. stocker n’importe quel type de données.
Les périodes de validité sont différentes : Les cookies peuvent être configurés pour être conservés pendant une longue période, comme la fonction de connexion par défaut que nous utilisons souvent, la session a généralement un délai d'expiration court, le client est fermé (par défaut) ou la session expire. Tout échouera.
Différentes tailles de stockage : Les données enregistrées par un seul cookie ne peuvent pas dépasser 4K. La session peut stocker beaucoup plus de données que les cookies, mais lorsqu'il y a trop de visites, elle occupera trop de serveur. ressources.
Qu'est-ce que le jeton
Jeton d'accès
Les informations d'identification de la ressource requises pour accéder à l'interface de ressource (API)
La composition d'un token simple : uid (l'identité unique de l'utilisateur), time (l'horodatage de l'heure actuelle), sign (signature, les premiers chiffres du token sont compressés avec un hachage algorithme) Une chaîne hexadécimale d'une certaine longueur)
Caractéristiques :
Le serveur est sans état et a une bonne évolutivité
Prise en charge des appareils mobiles
Sécurité
Prise en charge des appels inter-programmes
Processus d'authentification par jeton :
Le client utilise le nom d'utilisateur et le mot de passe pour demander la connexion
Le serveur reçoit la demande et vérifie le nom d'utilisateur et le mot de passe
Après une vérification réussie, le serveur émettra un jeton et enverra le jeton au client
Une fois que le client aura reçu le jeton, il le stockera, par exemple dans un cookie In ou dans localStorage
Chaque fois que le client demande des ressources au serveur, il doit apporter le jeton émis par le serveur
Le serveur reçoit la demande, puis vérifie que la demande du client contient un jeton, si la vérification est réussi, les données demandées seront renvoyées au client
Chaque demande doit porter le jeton, et le jeton doit être placé dans l'en-tête HTTP
L'authentification utilisateur basée sur les jetons est une méthode d'authentification sans état côté serveur, et le serveur n'a pas besoin de stocker les données des jetons. Le temps de calcul d'analyse du token est échangé contre l'espace de stockage de la session, réduisant ainsi la pression sur le serveur et réduisant les requêtes fréquentes sur la base de données
Le token est entièrement géré par l'application, afin qu'il puisse éviter la politique de même origine
Jeton d'actualisation
Un autre jeton——jeton d'actualisation
le jeton d'actualisation est un jeton spécifiquement utilisé pour actualiser les jetons d'accès. S'il n'y a pas de jeton d'actualisation, vous pouvez également actualiser le jeton d'accès, mais chaque actualisation nécessite que l'utilisateur saisisse le nom d'utilisateur et le mot de passe de connexion, ce qui sera très gênant. Avec le jeton d'actualisation, ce problème peut être réduit. Le client utilise directement le jeton d'actualisation pour mettre à jour le jeton d'accès sans que l'utilisateur n'effectue d'opérations supplémentaires.
La période de validité du jeton d'accès est relativement courte. Lorsque le jeton d'accès devient invalide en raison de son expiration, vous pouvez utiliser Actualiser. Jeton pour l'obtenir Nouveau jeton, si le jeton d'actualisation expire également, l'utilisateur ne peut que se reconnecter.
Le jeton d'actualisation et le délai d'expiration sont stockés dans la base de données du serveur et ne seront vérifiés que lors de la demande d'un nouveau jeton d'accès. Cela n'affectera pas le temps de réponse de l'interface métier et n'a pas besoin d'être maintenu comme le. Session en mémoire pour gérer un grand nombre de requêtes.
La différence entre le jeton et la session
La session est un mécanisme qui enregistre l'état de la session du serveur et du client, rendant le serveur avec état et capable d'enregistrer les informations de la séance. Le jeton est le jeton, l'identifiant de ressource requis pour accéder à l'interface de ressource (API). Le jeton rend le serveur apatride et ne stocke pas les informations de session.
Session et Token ne sont pas contradictoires. En tant que Token d'authentification d'identité, la sécurité est meilleure que Session, car chaque requête est signée et peut empêcher les attaques de surveillance et de rejeu, tandis que Session doit s'appuyer sur la couche liaison. .pour assurer la sécurité des communications. Si vous devez implémenter une session avec état, vous pouvez toujours ajouter une session pour enregistrer un état côté serveur.
La soi-disant authentification de session stocke simplement les informations de l'utilisateur dans la session. En raison de l'imprévisibilité de SessionID, elle est considérée comme sûre pour le moment. Et Token, s'il fait référence à OAuth Token ou à un mécanisme similaire, fournit l'authentification et l'autorisation pour les utilisateurs et l'autorisation pour l'application. Le but est de donner à une application le droit d'accéder aux informations d'un utilisateur. Le jeton ici est unique. Il ne peut pas être transféré vers d’autres applications ou vers d’autres utilisateurs. La session ne fournit qu'une simple authentification, c'est-à-dire que tant qu'il existe ce SessionID, on considère que cet utilisateur possède tous les droits. Elles doivent rester strictement confidentielles. Ces données ne doivent être stockées que sur le site et ne doivent pas être partagées avec d'autres sites Web ou applications tierces. Donc pour faire simple : Si vos données utilisateur doivent être partagées avec un tiers, ou permettre à un tiers d'appeler l'interface API, utilisez Token. S’il s’agit toujours uniquement de votre propre site Web et de votre propre application, peu importe ce que vous utilisez.
Qu'est-ce que JWT
JSON Web Token (JWT en abrégé) est actuellement la solution d'authentification inter-domaines la plus populaire.
est un mécanisme d'authentification et d'autorisation.
JWT est une norme ouverte basée sur JSON (RFC 7519) implémentée pour passer les revendications entre les environnements d'applications Web. Les revendications JWT sont généralement utilisées pour transmettre des informations d'identité d'utilisateur authentifiées entre les fournisseurs d'identité et les fournisseurs de services afin d'obtenir des ressources à partir des serveurs de ressources. Par exemple, utilisé pour la connexion de l'utilisateur.
JWT peut être signé à l'aide de l'algorithme HMAC ou d'une clé publique/privée RSA. Du fait de l’existence de signatures numériques, les informations transmises sont crédibles.
Le didacticiel d'introduction au JSON Web Token du professeur Ruan Yifeng est très facile à comprendre, je n'entrerai donc pas dans les détails ici
Générer JWT
jwt.io/ www.jsonwebtoken.io/
Principe de JWT
Processus d'authentification JWT :
L'utilisateur saisit son nom d'utilisateur/mot de passe pour se connecter, serveur Après une authentification réussie, un JWT sera renvoyé au client
Le client enregistre le jeton localement (généralement le stockage local est utilisé, mais les cookies peuvent également être utilisés)
Lorsque l'utilisateur souhaite accéder à un itinéraire protégé ou lors de la demande de ressources, vous devez utiliser le mode Bearer pour ajouter JWT dans le champ Autorisation de l'en-tête de la demande. Son contenu ressemble à ce qui suit
Authorization: Bearer <token>复制代码</token>
Copier après la connexion
La route de protection côté serveur sera vérifiée Les informations JWT dans l'en-tête de la requête L'autorisation, si légale, autorise le comportement de l'utilisateur
Parce que JWT est autonome (il contient certaines informations de session), cela réduit le besoin pour interroger la base de données
Étant donné que JWT n'utilise pas de cookies, vous pouvez utiliser n'importe quel nom de domaine pour fournir vos services API sans vous soucier du partage de ressources entre domaines (CORS)
Parce que le statut de l'utilisateur est n'est plus stocké dans la mémoire du serveur, il s'agit donc d'un mécanisme d'authentification sans état
Comment utiliser JWT
Le client reçoit le JWT renvoyé par le serveur, qui peut être stocké dans un cookie ou stocké dans localStorage.
Lorsqu'un utilisateur souhaite accéder à un itinéraire ou à une ressource protégée, il peut le mettre dans un cookie et l'envoyer automatiquement. Cependant, cela ne peut pas traverser le domaine, une meilleure approche consiste donc à le mettre dans le fichier. En-tête de requête HTTP. Dans le champ Autorisation du message, ajoutez le JWT en mode Bearer.
GET /calendar/v1/events
Host: api.example.com
Authorization: Bearer <token>复制代码</token>
Copier après la connexion
Le statut de l'utilisateur ne sera pas stocké dans la mémoire du serveur. Il s'agit d'un
mécanisme d'authentification sans état
La route de protection du serveur sera vérifiée. Les informations JWT. dans l'en-tête Autorisation de la demande, si elle est légale, autorise le comportement de l'utilisateur.
Étant donné que JWT est autonome, cela réduit le besoin d'interroger la base de données.
Ces fonctionnalités de JWT nous permettent de nous appuyer entièrement sur ses fonctionnalités sans état pour fournir des services d'API de données, ou même de créer un Téléchargez des services de streaming.
Étant donné que JWT n'utilise pas de cookies, vous pouvez utiliser n'importe quel nom de domaine pour fournir vos services API sans
vous soucier du partage de ressources entre domaines (CORS)
Méthode 2
En cas de cross-domaine, vous pouvez placer le JWT dans le corps de données de la requête POST.
Méthode 3
Transfert via URL
http://www.example.com/user?token=xxx复制代码
Copier après la connexion
Utiliser JWT dans le projet
Adresse du projet
La différence entre Token et JWT
La même :
Les deux sont des jetons pour accéder aux ressources
Les deux peuvent enregistrer des informations utilisateur
Les deux rendent le serveur apatride
Les deux ne peuvent accéder aux ressources protégées sur le serveur qu'après une vérification réussie
Différence :
Jeton : lorsque le serveur vérifie le jeton envoyé par le client, il doit également interroger la base de données pour obtenir des informations sur l'utilisateur, puis vérifier si le jeton est valide.
JWT : le jeton et la charge utile sont cryptés et stockés sur le client. Le serveur n'a besoin que d'utiliser le déchiffrement de clé pour la vérification (la vérification est également implémentée par JWT lui-même. Il n'est pas nécessaire d'interroger ou de réduire la requête). base de données Parce que JWT contient des informations utilisateur et des données cryptées.
Méthodes d'authentification frontales et back-end courantes
Cookie de session
Vérification du jeton (y compris JWT, SSO)
OAuth2.0 (autorisation ouverte)
Cryptage commun algorithme
L'algorithme de hachage, également connu sous le nom d'algorithme de hachage, fonction de hachage, fonction de hachage, est une méthode qui extrait des données de tout type de données. petites "empreintes digitales" numériques. Les algorithmes de hachage remanient les données pour créer une nouvelle valeur de hachage.
L'algorithme de hachage est principalement utilisé pour garantir l'authenticité des données (c'est-à-dire l'intégrité), c'est-à-dire que l'expéditeur envoie le message d'origine et la valeur de hachage ensemble, et le destinataire utilise la même fonction de hachage pour vérifier si les données d'origine est authentique.
Les algorithmes de hachage ont généralement les caractéristiques suivantes :
Tout aussi rapide : les données originales peuvent calculer rapidement la valeur de hachage
Difficulté inverse : il est fondamentalement impossible de transmettre le hachage valeur Il est possible de déduire les données originales
Sensibilité de saisie : tant que les données originales changent un peu, la valeur de hachage obtenue est très différente
Évitement des conflits : il est difficile de trouver des valeurs différentes données originales pour obtenir la même valeur de hachage, le nombre d'atomes dans l'univers est approximativement compris entre 10 puissance 60 et puissance 80, donc 2 puissance 256 a suffisamment d'espace pour s'adapter à toutes les possibilités. Si l'algorithme est bon, la probabilité. de collision est très faible :
2 à la puissance 128 est 340282366920938463463374607431768211456, soit 10 à la puissance 39
2 à la puissance 160 est 1,46150163733090291 82036848327163e+4 8, qui est le 48ème le niveau de puissance de 10
2 à la puissance 256 est 1,1579208923731619542357098500869 × 10 à la puissance 77, soit 10 à la puissance 77
Ce qui précède ne garantit pas que les données seront falsifiées de manière malveillante, les données d'origine et la valeur de hachage peuvent être falsifiées de manière malveillante. Pour vous assurer qu'elles ne sont pas falsifiées, vous pouvez utiliser la clé publique et privée RSA. schéma de clé, combiné avec la valeur de hachage.
L'algorithme de hachage est principalement utilisé pour éviter les erreurs lors de la transmission informatique. Les premiers ordinateurs utilisaient les 7 premiers bits de données et le code de contrôle de parité du 8ème bit pour les protéger (l'efficacité des déchets de 12,5 % est faible), par exemple. un morceau de données ou un fichier, générez une valeur de hachage de 128 bits ou 256 bits via un algorithme de hachage. S'il y a un problème avec la vérification, une retransmission est requise.
FAQ
Questions à prendre en compte lors de l'utilisation de cookies
Parce qu'il est stocké sur le client, il est facilement falsifié par le client, et il doit être vérifié avant utilisation. Sécurité
Ne stockez pas de données sensibles, telles que les mots de passe des utilisateurs, les soldes des comptes
Utilisez httpOnly pour améliorer la sécurité dans une certaine mesure
Essayez de réduire la taille des cookies et la quantité de données pouvant être stockées Ne peut pas dépasser 4 Ko
Définissez le domaine et le chemin corrects pour réduire la transmission des données
Les cookies ne peuvent pas traverser les domaines
Un navigateur peut stocker jusqu'à 20 cookies pour un site Web Cookies, les navigateurs n'autorisent généralement que 300 cookies à stocker
Le terminal mobile ne supporte pas très bien les cookies et la session en a besoin à mettre en œuvre sur la base de cookies, donc le terminal mobile couramment utilisé est un jeton
Problèmes à prendre en compte lors de l'utilisation de sessions
Stocker les sessions sur le serveur Quand il y a. y a-t-il de nombreux utilisateurs en ligne en même temps, ces sessions occuperont plus de mémoire et devront être utilisées dans le service Le client nettoie régulièrement les sessions expirées
Lorsque le site Web adopte le déploiement de cluster, vous rencontrera le problème de savoir comment partager des sessions entre plusieurs serveurs Web. Étant donné que la session est créée par un seul serveur, mais que le serveur qui gère les demandes des utilisateurs n'est pas nécessairement le serveur qui a créé la session, le serveur ne peut pas obtenir d'informations telles que les informations de connexion qui ont été entrées auparavant dans la session.
Lorsque plusieurs applications souhaitent partager des sessions, en plus des problèmes ci-dessus, elles rencontreront également des problèmes inter-domaines, car différentes applications peuvent être déployées sur différents hôtes et un traitement des cookies inter-domaines doit être effectué. dans chaque candidature.
sessionId est stocké dans un cookie. Que se passe-t-il si le navigateur interdit les cookies ou ne prend pas en charge les cookies ? Généralement, le sessionId sera suivi du paramètre url pour réécrire l'url, la session n'a donc pas nécessairement besoin d'être implémentée par des cookies
Le terminal mobile ne supporte pas très bien les cookies. , et la session doit être basée sur des cookies. Mise en œuvre, les jetons sont donc couramment utilisés sur les terminaux mobiles
Problèmes à prendre en compte lors de l'utilisation de jetons
Si vous pensez que l'utilisation d'une base de données pour stocker des jetons entraînera un temps de requête trop long, vous pouvez choisir de le mettre en mémoire. Par exemple, redis est très adapté à vos besoins en matière de requête de jetons.
Le token est entièrement géré par l'application, il peut donc éviter la politique de même origine
Le token peut éviter les attaques CSRF (car aucun cookie n'est nécessaire)
Le terminal mobile ne prend pas très bien en charge les cookies et la session doit être mise en œuvre sur la base des cookies, donc le terminal mobile couramment utilisé est le jeton
Vous devez en tenir compte lors de l'utilisation du problème JWT
Étant donné que JWT ne repose pas sur les cookies, vous pouvez utiliser n'importe quel nom de domaine pour fournir vos services API sans vous soucier du partage de ressources entre domaines ( CORS)
JWT par défaut Il n'est pas crypté, mais il peut être crypté. Après avoir généré le jeton d'origine, il peut être à nouveau chiffré avec la clé.
Les données secrètes JWT ne peuvent pas être écrites sur un JWT sans cryptage.
JWT peut être utilisé non seulement pour l'authentification mais également pour l'échange d'informations. Une utilisation efficace de JWT peut réduire le nombre de fois où le serveur interroge la base de données.
Le plus grand avantage de JWT est que le serveur n'a plus besoin de stocker la session, de sorte que les activités d'authentification et d'authentification du serveur peuvent être facilement étendues. Mais c'est aussi le plus gros inconvénient de JWT : comme le serveur n'a pas besoin de stocker l'état de session, il ne peut pas supprimer un jeton ni modifier les autorisations du jeton pendant son utilisation. C'est-à-dire qu'une fois le JWT émis, il sera toujours valide jusqu'à son expiration, à moins que le serveur ne déploie une logique supplémentaire.
Le JWT lui-même contient des informations d'authentification, et une fois divulgué, n'importe qui peut obtenir toutes les autorisations du jeton. Afin de réduire le vol, la période de validité de JWT doit être relativement courte. Pour certaines autorisations plus importantes, les utilisateurs doivent être à nouveau authentifiés lorsqu'ils les utilisent.
JWT convient à l'authentification de commande unique. Émettez un JWT avec une période de validité très courte Même s'il est exposé, le risque est très faible puisqu'un nouveau JWT sera généré pour chaque opération. Il n'est pas nécessaire de sauvegarder le JWT, qui est un état véritablement transparent.
Afin de réduire le vol, JWT ne doit pas être transmis en code brut via le protocole HTTP, mais doit être transmis via le protocole HTTPS.
Eléments à prendre en compte lors de l'utilisation d'algorithmes de chiffrement
Ne jamais stocker les mots de passe en texte clair
Toujours utiliser ha Utiliser l'algorithme de hachage pour traiter les mots de passe. N'utilisez jamais Base64 ou d'autres méthodes de codage pour stocker les mots de passe. Cela revient à stocker des mots de passe en texte brut, pas de codage . Le codage et le cryptage sont des processus bidirectionnels, tandis que les mots de passe sont confidentiels et ne doivent être connus que de leurs propriétaires. Ce processus doit être unidirectionnel. Le hachage est utilisé à cette fin. Il n'existe jamais de décodage d'un hachage, mais il y a décodage lorsqu'il y a codage, et il y a décryptage lorsqu'il y a cryptage.
N'utilisez jamais d'algorithmes de hachage faibles ou compromis comme MD5 ou SHA1, utilisez uniquement des algorithmes de hachage de mot de passe forts.
Ne jamais afficher ni envoyer de mots de passe en texte clair, même au propriétaire du mot de passe. Si vous avez besoin de la fonction « mot de passe oublié », vous pouvez générer aléatoirement un nouveau mot de passe
à usage unique (c'est important) et envoyer ce mot de passe à l'utilisateur.
Solution de partage de session sous architecture distribuée1. Réplication de session
Si la session sur un serveur change (ajout, suppression ou modification), le nœud Tout le contenu de cette session sera sérialisé puis diffusé à tous les autres nœuds, que les autres serveurs aient besoin ou non de la session, pour assurer la synchronisation de la session
Avantages : Défaut -tolérant, les sessions entre différents serveurs peuvent répondre en temps réel. Inconvénients : Cela exercera une certaine pression sur la charge du réseau. Si le nombre de sessions est important, cela peut provoquer une congestion du réseau et ralentir les performances du serveur.
2. Stratégie de liaison de session/IP collante
Utilisez le mécanisme ip_hash dans Ngnix pour diriger toutes les requêtes pour une certaine IP vers le même serveur. le serveur. Lorsque l'utilisateur demande pour la première fois, l'équilibreur de charge transmet la demande de l'utilisateur au serveur A. Si l'équilibreur de charge définit une session persistante, alors chaque demande ultérieure de l'utilisateur sera transmise au serveur A, ce qui équivaut à L'utilisateur et le serveur A sont collés ensemble. C'est le mécanisme de session persistante.
Avantages : Simple, pas besoin de faire de traitement sur la session. Inconvénients : Manque de tolérance aux pannes. Si le serveur actuellement accédé tombe en panne et que l'utilisateur est transféré vers le deuxième serveur, ses informations de session seront invalides. Scénarios applicables : La panne a un faible impact sur les clients ; la panne du serveur est un événement à faible probabilité.
. Méthode d'implémentation : En prenant Nginx comme exemple, des sessions persistantes peuvent être réalisées en configurant l'attribut ip_hash dans le module en amont.
3. Partage de session (couramment utilisé)
Utilisez des solutions de mise en cache distribuées telles que Memcached et Redis pour mettre en cache la session, mais Memcached ou Redis doit être un cluster
Mettez le session en Storage dans Redis, bien que l'architecture devienne complexe et nécessite un accès supplémentaire à Redis, les avantages apportés par cette solution sont également grands :
réalise le partage de session
peut être utilisé horizontalement Extension ; (ajout du serveur Redis);
La session ne sera pas perdue au redémarrage du serveur (mais veuillez également faire attention au mécanisme d'actualisation/invalidation de session dans Redis
Non seulement le) ; La session peut être partagée entre les serveurs, mais elle peut même être partagée entre les plates-formes (telles que le Web et l'application)
4. 🎜>
Session de stockage vers la base de données pour assurer la persistance de la session
Avantages : S'il y a un problème avec le serveur, la session ne être perdu Inconvénients : Si le nombre de visites sur le site Web est très important. Le stockage des sessions dans la base de données mettra beaucoup de pression sur la base de données et des frais supplémentaires seront nécessaires pour maintenir la base de données.
Tant que vous fermez le navigateur, la session va-t-elle vraiment disparaître ?
Non. Pour les sessions, à moins que le programme ne demande au serveur de supprimer une session, le serveur la conservera. Le programme envoie généralement une instruction pour supprimer la session lorsque l'utilisateur se déconnecte.
Cependant, le navigateur n'informe jamais activement le serveur qu'il est sur le point de se fermer avant de se fermer, le serveur n'a donc aucune chance de savoir que le navigateur a été fermé. La raison de cette illusion est que la plupart des mécanismes de session utilisent des cookies de session. L'identifiant de session est enregistré et l'identifiant de session disparaît après la fermeture du navigateur, et la session d'origine ne peut pas être trouvée lors de la nouvelle connexion au serveur. Si le cookie défini par le serveur est enregistré sur le disque dur, ou si une méthode est utilisée pour réécrire l'en-tête de requête HTTP envoyé par le navigateur et envoyer l'identifiant de session d'origine au serveur, la session d'origine peut toujours être ouverte lorsque le navigateur est ouvert à nouveau. C'est précisément que la fermeture du navigateur n'entraînera pas la suppression de la session, obligeant le serveur à définir un délai d'expiration pour la session. Lorsque le temps écoulé depuis la dernière utilisation de la session par le client dépasse ce délai d'expiration, le le serveur considérera le client. La session ne sera supprimée qu'après l'arrêt de l'activité pour économiser de l'espace de stockage.
Adresse du projet
Utilisation de JWT dans le projet
Postscript
Cet article est uniquement basé sur le mien, je comprends que j'ai parlé de connaissances théoriques, car je ne suis pas très familier avec les connaissances back-end/algorithmes. S'il y a des erreurs, veuillez me le faire savoir. Merci beaucoup
Si cet article l'est. utile pour vous, s'il vous plaît donnez-lui un like ~~
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
