The difference between a cookie and a session

Cookie Mechanism

Cookies are small pieces of text that the server stores on the local machine and are sent to the same server with each request. The IETF RFC 2965 HTTP State Management mechanism is a generic cookie specification. The Web server sends cookies to the client using HTTP headers, and in the client terminal, the browser parses the cookies and saves them as a local file, which automatically binds any requests from the same server to these cookies.

Specifically, the cookie mechanism uses a scheme that maintains state on the client. It is the storage mechanism of session state on the client side, and he needs the user to open the cookie support of the clients. The purpose of cookies is to resolve the problem of stateless defects in the HTTP protocol.

Orthodox cookie distribution is implemented by extending the HTTP protocol, and the server prompts the browser to generate the appropriate cookie by adding a special line of instructions to the HTTP response header. However, purely client-side scripts such as JavaScript can also generate cookies. And the use of cookies by the browser in accordance with certain principles in the background automatically sent to the server. The browser checks all stored cookies and, if a cookie declares a scope greater than or equal to the location of the resource to be requested, sends the cookie to the server on the HTTP request header of the requesting resource.

The contents of the cookie mainly include: name, value, expiration time, path and domain. The path together with the domain constitutes the scope of the cookie. If you do not set an expiration time, the cookie will be closed for the duration of the browser session. This cookie, which is the lifetime of the browser session, is referred to as a session cookie. Session cookies are generally not stored on the hard disk but are kept in memory, although this behavior is not regulated. 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 the 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 session mechanism uses a solution that maintains state on the server side. At the same time, we also see that because of the server-side hold state of the scheme in the client also need to save an identity, so the session mechanism may need to use the cookie mechanism to achieve the purpose of preserving the identity. The session provides a convenient way to manage global variables.

Session is for each user, the value of the variable is saved on the server, with a sessionid to distinguish which user session variable, this value is accessed by the user's browser when the server is returned, when the customer disables the cookie, This value may also be set to be returned to the server by get.

As far as security is concerned: when you visit a site that uses a session and create a cookie on your own machine, it is recommended that the session mechanism on the server side be more secure because it does not arbitrarily read the information stored by the customer.

　 session mechanism

The session mechanism is a server-side mechanism that uses a hash-like structure (or perhaps a hash table) to hold information.

When a program needs to create a session for a client's request, the server first checks to see if the client's request contains a session ID (called the session ID.), and if it is included, it has previously created a session for this client. The server will follow the session ID to retrieve the session (not retrieved, a new one), if the client request does not include session ID, then create a session for this client and generate a session ID associated with this session, The value of session ID should be a string that is neither duplicated nor easy to be found, and the session ID will be returned to the client in this response to save.

This session ID can be saved by using a cookie, so that the browser can automatically play the logo to the server during the interactive process. Generally the name of this cookie is similar to Seeesionid. However, a cookie can be artificially banned, and there must be other mechanisms that can still pass the session ID back to the server when the cookie is banned.

A technique that is often used is called URL rewriting, which attaches the session ID directly behind the URL path. There is also a technique called form-hidden fields. Is that the server automatically modifies the form, adding a hidden field so that the session ID can be passed back to the server when the form is submitted.

Both the cookie and session can be tracked, but the principle of completion is not quite the same. Under normal circumstances both can satisfy the demand, but sometimes can not use the cookie, sometimes can not use the session. The following is a comparison of the characteristics of the two and the place of application.

　　1. Different access modes

Only ASCII strings can be stored in a cookie, and if the requirement is to access Unicode characters or binary data, the requirement is first encoded. There is no direct access to Java objects in cookies. To store slightly more complex information, it is difficult to use cookies.

In the session, you can access any type of data, including not limited to string, Integer, List, map, and so on. Session can also be directly stored in Java beans and even any Java class, objects, etc., the use of very easy. The session can be considered a Java container class.

　　2. Differences in privacy policies

Cookies are stored in client-side readers and are visible to clients, and some programs on the client may snoop, copy, or modify the contents of a cookie. The session is stored on the server, is transparent to the client, and there is no risk of sensitive information disclosure.

If you choose a cookie, the best way is to try not to write sensitive information, such as your account password, to the cookie. It is best to encrypt the cookie information like Google and Baidu, submit it to the server, and then decrypt it to ensure that the information in the cookie can be read as long as I understand it. And if the choice session is more convenient, anyway, is placed on the server, the session of any privacy can be effectively protected.

　　3. The difference in validity

Anyone who has used Google knows that Google's login information is valid for a long time if they sign in to Google. Google will permanently record the user's login information without having to log back in every visit. To achieve this effect, it is a good choice to use cookies. You only need to set the cookie expiration time property to a very large number.

Since the session relies on a cookie named Jsessionid, and the cookie Jsessionid expiration time is acquiesced to –1, simply close the reader the session will be invalidated, so the session can not complete the information forever effective effect. Using URL rewrite can not be done. And if the timeout period of the set session is too long, the server accumulates more sessions, the more likely to incur memory overflow.

　　4. Differences in server pressure

Session is stored on the server side, each user will produce a session. If the number of concurrent access users is very large, it will produce a lot of sessions, consuming a lot of memory. Therefore, like Google, Baidu, Sina such a high number of concurrent visits to the site, is unlikely to use the session to track customer sessions.

While the cookie is stored on the client, it does not occupy server resources. Cookies are a good choice if you have a lot of concurrent readers. For Google, Baidu, Sina, cookies may be the only option.

　　5. browser support for different

Cookies are supported by the client browser. If the client disables cookies or does not support cookies, session tracking is invalidated. With regard to WAP applications, regular cookies are useless.

If the client browser does not support cookies, you need to use session and URL rewrite. It is important to note that all the URLs used in the session program are URL-rewritten, otherwise the session track will fail. For WAP applications, Session+url address rewriting may be its only option.

If the client supports cookies, the cookie can be both set to the browser window and the child window is valid (setting the expiration Time to –1), or it can be set to be valid in all reader windows (set the expiration time to an integer greater than 0). However, the session can only be valid within the Reader window and its subwindow. If two browser windows are irrelevant, they will use two different sessions. (IE8 under different window sessions coherent)

　　6. Differences in cross-domain support

Cookies support cross-domain access, such as setting the Domain property to ". Biaodianfu.com", and all domain names with the suffix ". biaodianfu.com" are able to access the cookie. Cross-domain cookies are now commonly used in networks such as Google, Baidu, Sina, and so on. The session does not support cross-domain access. The session is valid only within the domain where he is located.

Only using cookies or simply using the session may not achieve the desired results. At this point, you should try to use both cookies and session. The combination of cookie and session will accomplish many unexpected effects in practical projects.

The difference between a cookie and a session