The difference between a cookie and a session and its application

The concept of cookies

A cookie is a set of data that is stored on the client after a browser (user Agent) accesses some Web site, and is used to enable user-defined functions such as tracking users on the site.

The domain and path attributes of the cookie identify which Web site The cookie is sent to the browser, and the expires attribute of the cookie identifies the effective time of the cookie, and the data is automatically deleted when the cookie is valid.

If you do not set an expiration time, the cookie disappears when the browser window is closed as long as the cookie's lifetime is the browser session. This cookie, which has a lifetime of browsing session, is referred to as a session cookie. Session cookies are generally not saved on the hard disk but in memory. If the expiration time is set, the browser will save the cookie to the hard disk, turn it off and open the browser again, and these cookies remain valid until the set expiration time expires. Cookies stored on the hard disk can be shared between different browser processes, such as two IE windows. For cookies stored in memory, different browsers have different ways of handling them.

The concept of the session

The Session is stored on the server side similar to the Hashtable structure (each Web development technology implementation may be different, hereinafter referred to as Hashtable) to hold the user data, when the browser first send the request, The server automatically generates a Hashtable and a session ID to uniquely identify the hashtable and send it in response to the browser. When the browser sends the request for the second time, the session ID in the previous server response is placed in the request and sent to the server, the server extracts the session ID from the request and compares it with all the session IDs saved, and finds the corresponding Hashtable for the user.

In general, the server will save this HashTable for a certain amount of time (default 20 minutes), and after the time limit, the HashTable will be destroyed. Before the destruction, the programmer can store some of the user's data in the form of key and value temporarily in the Hashtable. Of course, there is also the use of the database to save the Hashtable serialization, the advantage is that there is no time limit, the disadvantage is that with the increase in time, the database will swell rapidly, especially when the traffic increases. In general, take the previous approach to relieve server pressure.

The client implementation form of session (that is, how to save the session ID)

The General browser provides two ways to save, and one that programmers use to customize the implementation of HTML-hidden fields:

[1] Use of cookies to save, this is the most common method, this article "Remember my login status" feature implementation is formally based on this way. The server sends the session ID to the browser by setting a cookie. If we do not set this expiration time, then this cookie will not be stored on the hard disk, and when the browser is closed, the cookie disappears and the session ID is lost. If we set this time to a few days later, then this cookie will be saved on the client hard drive, even if the browser is closed, the value still exists, and the next time you visit the site, it will be sent to the server.

[2] How to use the URL to append information, that is, like we often see JSP site will have aaa.jsp? Jsessionid=* the same. This is the same way that the first method does not set the cookie expiration time.

[3] The third Way is to add hidden fields in the page form, which is actually the same as the second way, except that the former sends the data by means of a GET, which uses post to send the data. But obviously the latter is more troublesome.

The difference between a cookie and a session:

The cookie data is stored on the client side and the session data is saved on the server.

Simply put, when you log on to a website, if the Web server side uses the session, then all the data is stored on the server, the client each time the server is requested to send the current session of the SessionID, The server determines the appropriate user data flag based on the current SessionID to determine whether the user is logged on, or has some kind of permission. Since the data is stored on the server, you can't forge it, but if you can get the SessionID of a logged-on user, it can be successful to forge the user's request with a special browser. SessionID is a server and client link when randomly assigned, generally there will be no duplication, but if there is a large number of concurrent requests, there is no possibility of duplication, I have encountered once. Login to a website, start to display their own information, and so on for a period of time expired, a refresh, actually show someone else's information.

If the browser is using a cookie, then all the data is stored on the browser side, such as when you log in, the server set the cookie User name (username), then, when you request the server again, the browser will username a piece sent to the server, These variables have certain special markings. The server is interpreted as a cookie variable. So as long as you do not close the browser, then the cookie variable is always valid, so it can be guaranteed for a long time not to drop the line. If you can intercept a user's cookie variable and then forge a packet to send the past, the server still thinks you're legit. Therefore, the use of cookies is more likely to be attacked. If it is set to a valid time, then it will save the cookie on the client's hard disk, the next time you visit the website, the browser first check whether there is a cookie, if any, read the cookie, and then sent to the server. If you save a forum cookie on a machine that is valid for one year, if someone invades your machine, copies your cookie, and places it under the directory of his browser, then he or she logs in as your identity. So a cookie can be forged. Of course, the forgery of the need for ideas, directly copy the cookie file to the cookie directory, the browser is not recognized, he has a index.dat file, stored the cookie file set up time, and whether there is modification, so you must first have to have the site of the cookie file, and to ensure that the time to deceive the browser, once in the school's VBB forum has done experiments, copy other people's Cookie login, take the name of others to post, no problem at all.

Session is a server-side storage space maintained by the application server, when the user connects to the server, a unique SessionID is generated by the server, which uses the SessionID as an identifier to access the server-side session storage space. And SessionID this data is saved to the client, saved with a cookie, when the user submits the page, the SessionID will be submitted to the server side, to access the session data. This process is not a developer intervention. So once the client disables cookies, the session will also expire.

The server can also pass the SessionID value through URL rewriting, so it is not entirely dependent on cookies. If the client cookie is disabled, the server can automatically save the session value by rewriting the URL, and the process is transparent to the programmer.

You can try it, even if you do not write cookies, use Request.getcookies (), the length of the cookie array is also 1, and the name of this cookie is jsessionid, and there is a long binary string, Is the value of the SessionID.

The difference between a cookie and a session and its application