Why we use session and cookie
The question of why to use session and Cookie is to start with the stateless nature of the HTTP status protocol.
a stateless protocol is a protocol that has no memory ability to deal with things . A lack of state means that if the previous information is required for subsequent processing, it must be re-transmitted, which may result in an increase in the amount of data transferred per connection. On the other hand, it responds quickly when the server does not need the previous information.
HTTP is a Hypertext Transfer Protocol, as the name implies, this protocol supports the transmission of hyper-text. What is hypertext? To be blunt is to use HTML to write pages. In general, we use the client browser to access the server's resources, the most common URLs are HTML-suffix files, so it can be said that hypertext is the most important resources on the network.
Since the purpose of the HTTP protocol is to support hypertext transmission, that is, the transfer of resources, then the client browser sends a request to the HTTP server, and then the HTTP server will believe that the resources sent back to the client, whether for the client or the server, there is no need to record this process, Because each request and response is relatively independent, just like when we drop a coin in front of a vending machine to buy a product, there is no need to record the transaction process. In general, a URL corresponds to a unique hypertext, and the HTTP server is absolutely fair and impartial, regardless of who will return the same hypertext based on the URL request received. It is this uniqueness that makes it meaningless to record the behavior of the user, so the HTTP protocol is designed as a stateless connection protocol that meets its own needs.
HTTP protocol This feature has advantages and disadvantages, the advantage is that the release of the server, every request "donuts", will not cause unnecessary connection occupation, the disadvantage is that each request will transfer a large number of duplicate information content.
In order to solve the problem that HTTP transmits a lot of duplicate information content, the cookie and the session appear, they can save the state for the user.
Cookies
A cookie is a solution that maintains state through the client. By definition, a cookie is a special message that the server sends to the client, which is stored as a text file on the client, and then each time the client sends a request to the server, the special information is brought.
More specifically, when a user uses a browser to access a Web site that supports cookies, the following steps are available:
1. The user will provide personal information including the user name and submit to the server
2, the server in the client will be transmitting the corresponding hypertext, and send back these personal information. Of course, this information is not stored in the HTTP response body (Response body), but is stored in the HTTP response header (Response header)
3, when the client browser receives a response from the server, the browser will store this information in a unified location
4, after the client sends a request to the server, the corresponding cookie will be returned to the server again, and this time, the cookie information is stored in the HTTP request header
For example, I asked for a http://www.sina.com.cn/with so many cookies in my request header:
May think this cookie is confusing, make a clear version of:
Simply explain this form:
1, Name=value, key-value pairs, cookies including session are stored in the form of key-value pairs
2, domain, refers to the name that generated the cookie
3, path, refers to the path under which the cookie was generated
4, Expires/max-age, refers to the cookie expiration time/maximum failure time (that is, the number of seconds after expiration)
5, size, this is obvious, refers to the size of the occupied bytes
6, Secure, if this property is set, then only the SSH connection will be returned to the cookie
With the implementation of a technology such as cookies, the server will be able to dynamically generate the content corresponding to the client by analyzing the cookie information stored in the request header to obtain information from the client, after receiving the request from the client browser. The storage address of the cookie in the computer is:
My computer is Win8, in C:\Users\dell1\AppData\Local\Microsoft\Windows\INetCache .
can also be opened via IE browser: Browser -- tools -->internet options - browser history - Settings -- view files
Session
The session is another solution relative to the cookie, which is maintained by the server. Session refers to the storage space that the server creates for the client, and the information stored in it is used to save the state.
First, the session is created during the process of running the server-side program, and different language-implemented applications have different ways of creating the session. When the session is created, the server generates a unique SessionID for the session, and after the SessionID is created, the session-related method can be called to add content to the session. This content will only be saved in the server, only SessionID sent to the client. When the client sends the request again, the SessionID is taken, and the server receives the request and then finds the corresponding session according to SessionID, which is used again. Such a process that allows the user's state to be maintained.
Second, each session has a SessionID, where is this ID stored? There are two ways of doing this:
1, through the URL access, the URL will take one, jsessionid=xxxxxx, etc., so that each time the request is sent SessionID to the server
2. Access via cookie (this is the default for Tomcat), which is a session cookie, which differs from persistent cookies, which we often say cookie,session The cookie to note is stored in the browser memory (as far as the browser memory, which is related to the browser, for example, I use a 360 browser, which is 360se6\user data\default this path) instead of writing to the hard disk. At the beginning of the program execution, the server generates a SessionID and carries the client browser's cache through the cookie, the next time the server detects if there is a cookie, if it has the ID, if it does not regenerate into one. This is why after closing the browser, then go into the session has no, in fact, the server side session is not empty, but SessionID changed.
Moreover, the browser is closed, the session is not the argument is not correct. If the browser is closed, the server saves the session data is not immediately released, the data will also exist, as long as we know the SessionID, we can continue to request the session information. Session inside the data are placed on the server side, through the SessionID guarantee will not access errors, the service side automatically manage the session, if no access within the specified time, then release the session.
Last mention two points;
1, SessionID is usually not visible, but when we disable the browser's cookie, the Web server will use URL rewrite to pass SessionID, so that you can see SessionID in the Address bar
2. Session cookie can not be used across Windows
Further discussion on cookies and session
Cookies and sessions have advantages and disadvantages, and in large Internet systems, it is not possible to use cookies and session alone, and the use of cookies has the following drawbacks:
1, the use of cookies to convey information, with the number of cookies and the increase in traffic, it occupies a large network bandwidth, imagine if the cookie occupies 200 bytes, if a day of PV has several billion, then it to occupy how much bandwidth?
2. Cookies are not secure because cookies are stored on the client, so these cookies can be accessed and settings can be added and modified via plugins. So from this point of view, we're going to use Sesssion,session to store the data on the server, just pass a sessionid through the cookie, so the session is better for storing user privacy and important data
But the session also has drawbacks:
1, not easy to share between polymorphic servers, this is a fatal weakness
2, the session is stored in the server, so the session if too much will consume the performance of the server
In that case, we can take advantage of the advantages of cookies and the session, to circumvent their shortcomings, develop a distributed session framework, of course, this is something, and then may write an article dedicated to this.
Session and Cookie