In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >
Share
Shulou(Shulou.com)06/03 Report--
This article mainly explains "the working principle and difference between cookie and session". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn the working principle and difference between cookie and session.
Why do you need cookie and session
In the history of Web, we know that the http protocol is used between the browser and the server, and this protocol is stateless, so the server cannot know who is browsing the web, but it is obvious that some web pages need to know the user's status, such as login, shopping cart and so on.
So in order to solve this problem, there have been four technologies, namely, hidden form field, URL rewriting, cookie,session, and the most important ones are cookie and session.
What is Cookie?
Cookie is a small piece of text saved by the browser on the user's computer. Generally speaking, when a user accesses the server through http, the server will return some Key/Value key-value pairs to the client browser and impose some restrictions on the data. When the conditions are met, the next time the user visits the server, the data will be fully brought back to the server through the request header. The server judges different users based on this information.
In other words, cookie is a piece of information transmitted by the server to the client and saved in the client. The Cookie is limited in size and quantity!
The creation of Cookie
There are currently two versions of Cookie that correspond to two setting response headers: "Set-Cookie" and "Set-Cookie2". Set-Cookie2 is not supported in Servlet, so let's look at the property items of Set-Cookie:
These attribute items, and everything else, are very clear. Let's take a look at the use of Domain:
Now, let's assume that there are two domain names:
Domain name A:a.b.f.com.cn domain name B:c.d.f.com.cn
Obviously, domain name An and domain name B are subdomains of f.com.cn
If the domain of Cookie in domain name An is set to f.com.cn, then both f.com.cn and its subdomains can obtain the Cookie, that is, both domain An and domain B can obtain the Cookie
If both domain name An and domain name B set the doamin of Cookie to f.com.cn, then the phenomenon of overwriting will occur.
If domain name A does not explicitly set the domain method of Cookie, then domain will be a.b.f.com.cn. The difference is that the subdomain name of domain A will not be able to obtain the Cookie.
OK, now that we know the property items of Set-Cookie, let's start creating Cookie
The Web server creates a Cookie by sending a http message called Set-Cookie:
Set-Cookie: value [; expires=date] [; domain=domain] [; path=path] [; secure]
Here we consider the question: when we create multiple Cookie on the server, do the Cookie end up in a single Header entry or as a separate Header?
We can see that when building the http to return the byte stream, all the items in the Header are written out in order without any modification. So you can imagine that when the browser receives the data returned by http, it parses each Header item separately.
Then, save it on the client, how to save it? Here we need to learn more about Cookie.
Classification of Cookie
Session-level Cookie: the so-called session-level Cookie means that Cookie becomes invalid after the browser is closed.
Persistence level Cookie: the Cookie saved on the hard disk is the hard disk level Cookie as long as the expiration time is set.
OK, now that the cookie is saved on the client side, when we request a URL, the browser will pass the qualified Cookie in the request header to the server according to the URL path.
Session
There are limits on the size and quantity of Cookie, and more and more Cookie represent the increase in the transmission volume of the client and server. Can you not pass all cookie values each time, but only pass a unique ID through this ID to find user information directly in the server? The answer is yes, this is our session.
Session works on the basis of Cookie. Every time the same client accesses the server, as long as the browser sets up an id and saves some information when the browser visits the server for the first time (for example, the user information is saved when logging in, depending on the specific situation), and the id is saved to the client through Cookie, and the client only sends this id to the server every time it interacts with the server, the state of the browser and server can be maintained. And this ID is usually a Cookie whose NAME is JSESSIONID.
In fact, there are four ways to make Session work:
Pass SessionID through URL
Pass SessionID through Cookie
Pass SessionID through SSL
Pass SessionID by hiding the form
The first situation:
When the browser does not support the Cookie feature, the browser will rewrite the user's SessionCookieName (default is JSESSIONID) into the URL parameter requested by the user. Format: / path/Servlet;name=value;name2=value2?Name3=value3
The third situation:
SessionID is set based on the value of the javax.servlet.request.ssl_session property.
Note: if the client supports Cookie and is rewritten by URL, Tomcat will still parse the SessionID in Cookie and overwrite the SessionID in URL
How Session works
First, take a look at the timing diagram of session's work.
First, create a session
When the client accesses the server, the server creates a Session for the client through the request.getSession () method. If the current SessionID does not have a corresponding HttpSession object, it creates a new one and adds it to the org.apache.catalina.Manager 's sessions container to save it, thus maintaining the state. Of course, this SessionID is the only one
II. Session preservation
As you can see from the figure, the session object has been saved in the Manager class, and StandardManager, as the implementation class, fetches the StandardSession object from the sessions collection of StandardManager through requestedSessionId.
Let's take a look at how to manage the life cycle of all StandardSession objects in StandardManager
When the Servlet container is closed:
StandardManager will persist StandardSession objects that do not expire (stop and start commands in the Servlet container must be called, not kill directly)
When the Servlet container restarts:
StandardManager initialization rereads the file and parses all session objects.
III. Destruction of session
There is a misunderstanding here, which is also my previous misunderstanding, that is, I understand the life cycle of session as a session, which is created as soon as the browser is opened and destroyed when the browser is closed.
The declaration period of session is from creation to timeout expiration.
In other words, when the session is created, the browser is closed and the session-level Cookie is destroyed. If the set time is not exceeded, the corresponding session of the SessionID is not destroyed.
Check for session failure
Checking whether each Session fails is done in a background thread of Tomcat (in the backgroundProcess () method); in addition to the background process verifying that the session is invalid, calling request.getSession () also checks whether the session expires, and of course, calling this method will recreate a new session if it expires.
Small knot
The similarities and differences between the two
Something in common (where it matters):
Both Session and Cookie exist to make the http protocol stateful again.
Session works through Cookie, and the SessionID transmitted by Cookie lets Session know who the client is.
Differences:
Session saves the information to the server, and Cookie saves the information on the client
Work flow
When the browser visits the server for the first time, the server creates the Session and brings the SessionID to the browser to save in the client through Cookie. At the same time, the server saves the corresponding client information in the session according to the business logic; when the client visits again, the server uploads the Cookie, and the server gets the SessionID in it to maintain the state.
At this point, I believe you have a deeper understanding of "the working principle and difference between cookie and session". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.