Les cookies et la session sont tous deux destinés à maintenir l'état d'accès des utilisateurs. D'une part, c'est pour faciliter la mise en œuvre de l'entreprise, et d'autre part, il s'agit de simplifier la programmation des serveurs et d'améliorer les performances d'accès. Les cookies sont la technologie du client (c'est-à-dire le navigateur). Après avoir établi des cookies, chaque fois que vous visitez le serveur, les cookies seront apportés à la demande; La session est la technologie du serveur, qui stocke les informations d'accès aux utilisateurs sur le serveur.
Utilisez des cookies pour fournir des informations. À mesure que le nombre de cookies augmente et que le nombre de visites augmente, la bande passante qu'elle consomme deviendra de plus en plus grande; Lorsque vous utilisez la session pour enregistrer des informations, la plus grande faiblesse est qu'il n'est pas facile de partager entre plusieurs serveurs.
1 cookies
En termes simples, lorsqu'un utilisateur accède au serveur à l'aide de HTTP, le serveur renverra des informations de paire de valeurs de clé au navigateur client et ajoutera des restrictions à ces données. Lorsque l'utilisateur répondra aux restrictions, la prochaine fois que l'utilisateur accède au serveur, il apportera le jeu d'informations sur les paires de valeurs clés de cookie précédemment. Lorsque l'utilisateur entre dans une URL, le navigateur recherche les cookies associés à l'URL sur le disque dur local. Si le cookie existe, le navigateur envoie le cookie à votre site avec la demande de page.
Les cookies sont associés aux sites Web, et non à des pages spécifiques. Par conséquent, quelle que soit la page du site, le navigateur et le serveur échangeront des informations sur les cookies. Lorsqu'un utilisateur visite différents sites, chaque site peut envoyer un cookie au navigateur de l'utilisateur; Le navigateur stockera tous les cookies séparément.
Élément d'attribut cookie
Il existe actuellement 2 versions de cookies, version 0 et version 1. Ils ont 2 types d'identifiants d'en-tête de réponse, à savoir "Set-Cookie" et "Set-Cookie2".
Valeur d'attribut cookie 0
Valeur d'attribut cookie 1
Exemple d'utilisation de cookies en java
@OverRidePublic void Doget (HttpServLetRequest Request, HttpservletResponse Response) lève ioException {réponse.setContentType ("Text / Html; charset = utf-8"); printwriter out = réponse.getwriter (); cookie [] ")"); == null) {response.addCookie(new Cookie("name", "luoxn28"));}else {System.out.println(name);}out.println("hello world");}public static String getCoodie(Cookie[] cookies, String key) {if (cookies != null) {for (Cookie cookie : cookies) {if (cookie.getName (). equals (key)) {return cookie.getValue ();}}} return null;}Quelques précautions pour utiliser des cookies (prendre une utilisation Java comme exemple)
• Le nom et la valeur du cookie créé ne peuvent pas être des caractères non-ASSIC. S'il est chinois, il peut être codé via Rrlencoder, sinon une exception Java.lang.LelegalargumentException sera lancée.
• Lorsque plusieurs noms et valeurs de valeur apparaissent, ils sont en fait dans le même en-tête "cookie".
• La valeur des cookies peut économiser des marques de ponctuation autres que ";". Mais les caractères chinois ne peuvent pas être sauvés. Les ordures apparaîtront lors de la sauvegarde des caractères chinois.
Quelques restrictions sur les cookies
Un cookie est un champ dans l'en-tête HTTP. HTTP lui-même n'a aucune restriction sur ce domaine, mais les cookies sont finalement stockés dans le navigateur. Différents navigateurs ont des restrictions sur le stockage des cookies, comme indiqué dans le tableau suivant:
Si vous essayez de stocker plus de cookies, les cookies les plus anciens seront jetés.
2 session
La session résout le problème que lorsque le nombre de cookies augmente, la quantité de transmission de données entre le client et le serveur augmente. Lorsque le même client interagit avec le serveur, il n'a pas besoin de transmettre toutes les valeurs de cookie à chaque fois, mais seule une valeur d'ID est remise. Cet ID est généré lorsque le client accède au serveur pour la première fois, et chaque client est unique. Cette pièce d'identité est généralement un cookie dont le nom est JSessionID.
Comment fonctionne la session basée sur les cookies? Il peut être basé sur le paramètre de chemin d'URL; Il peut également être basé sur des cookies. Si le logo cookies dans le conteneur de contexte n'est pas modifié, il est également pris en charge par défaut. Lorsque le navigateur ne prend pas en charge la fonction Cookie, le navigateur réécrira le SessionCookiename de l'utilisateur vers le paramètre URL demandé par l'utilisateur. Sa méthode de livraison est telle que / path / servlet; name = xxx; name2 = xxx2? Name3 = xxx3. Sessioncookiename Si l'élément de configuration de session-config est configuré dans web.xml, l'attribut de nom sous le cookie-config est la valeur de cette sessioncookiename. Si l'élément de configuration de ses session-config n'est pas configuré, la session par défaut cookienamejiushi "jSessionID". Notez que les cookies associés à la session ne sont pas différents des autres cookies. Si le client prend également en charge les cookies, Tomcat analyse toujours l'ID de session dans le cookie et écrasera l'ID de session dans l'URL.
Comment fonctionne la session
Avec l'ID de session, le serveur peut créer un objet HTTPSESSE. La première fois que vous appelez la méthode request.getSession (). S'il n'y a pas d'objet HTTPSESSION correspondant, un nouvel objet sera créé et ajouté au conteneur des sessions d'org.apache.catalina.manager sera enregistré. Manage sauve tous les cycles de vie de la session, la session expire et est recyclée, le serveur est fermé et la session est sérialisée sur le disque. Notez qu'un client correspond à un objet de session, qui enregistre la valeur de session que nous avons créée.
La méthode de norme appelée par la méthode request.getSession () existera toujours, même si la session associée à ce client a expiré. S'il expire, un nouveau sera créé, mais la valeur de session précédemment définie sera perdue.
3 Comparaison des cookies et de la sécurité des sessions
Les cookies passent les données enregistrées du client au serveur via l'en-tête HTTP, puis du serveur au client. Toutes les données sont enregistrées dans le navigateur client. Ces données sont accessibles et les cookies peuvent même être ajoutés et modifiés via des plug-ins. La sécurité de tous les cookies est relativement médiocre. En comparaison, la session enregistre les données du côté serveur, ce qui est beaucoup plus sécurisé. Il ne nécessite qu'un cookie pour transmettre un ID de cookie, donc la session est plus adaptée à l'enregistrement de la confidentialité des utilisateurs et des données importantes.
Cadre de session distribué
Dans les grandes applications Internet, l'utilisation de cookies et de sessions n'est pas possible, car l'utilisation des cookies peut bien résoudre le problème de déploiement distribué des applications. Un grand système d'application Internet possède des centaines de machines et de nombreux systèmes d'applications différents fonctionnent ensemble. Étant donné que les cookies stockent des données dans le navigateur de l'utilisateur, chaque fois que l'utilisateur se rend visite, les données seront ramenées au serveur, ce qui résout le problème de l'incohérence des cookies causée par les demandes du même utilisateur traitées sur différents serveurs.
Étant donné que l'application est un cluster, la session ne peut pas être enregistrée dans la mémoire de chaque serveur. Si chaque serveur compte des centaines de milliers d'utilisateurs d'accès, la mémoire du serveur ne peut pas être hébergée. Même s'il peut être logé, il ne peut garantir que la session sera synchronisée avec d'autres serveurs. Par conséquent, le partage de ces séances nécessite de les sauver dans un cache distribué spécial, qui peut être lu et écrit à tout moment. Les performances doivent être suffisamment bonnes pour répondre aux exigences, telles que Memcache / Redis ou Taobao Open Source Distributed Framework Tair.
Question de soumission de formulaire répétée
Il existe de nombreux endroits sur le site Web qui ont répété les soumissions. Afin d'éviter les soumissions répétées des formulaires, il est nécessaire d'identifier chaque demande d'accès de l'utilisateur, afin que chaque demande d'accès soit unique au serveur. Afin d'identifier chaque demande de l'utilisateur, un élément de formulaire caché peut être ajouté au champ de formulaire demandé par l'utilisateur, et sa valeur est un jeton unique, tel que:
<form id = "form" metheth = "post"> ... <input type = Hidden Name = "token" value = "xxx" /> </ form>
Un jeton unique est généré lorsque l'utilisateur demande le formulaire et le définit à la session de l'utilisateur. Lorsque l'utilisateur se soumet, il vérifie si le jeton est cohérent avec le jeton enregistré dans la session. S'il est cohérent, cela signifie qu'il n'y a pas de soumission répétée. Dans le même temps, le jeton de la session est mis à jour vers une nouvelle valeur de jeton; Sinon, le jeton soumis par l'utilisateur n'est plus le jeton légal de la demande actuelle et la soumission échoue.
Ce qui précède est les choses sur les cookies et les sessions en Java que l'éditeur vous a présentés. J'espère que cela vous sera utile. Si vous avez des questions, veuillez me laisser un message et l'éditeur vous répondra à temps. Merci beaucoup pour votre soutien au site Web Wulin.com!