preface
This paper makes an introduction and summary of Cookie and Session respectively, and makes a comparative analysis of the two knowledge points respectively, so that everyone can have a deeper understanding of Cookie and Session, and bring enlightenment to their flexible application in development work.
The cookie mechanism
Cookies are small pieces of text that the server stores on the local machine and sends to the same server with every request. IETF RFC 2965 HTTP State Management Mechanism is a generic cookie specification. The Web server sends cookies to the client using HTTP headers. At the client, the browser parses these cookies and saves them as a local file, which automatically attaches to these cookies any request from the same server.
Specifically, the cookie mechanism adopts the scheme of maintaining state in the client. It is a storage mechanism for session state on the client side, which requires the user to open the client side cookie support. Cookies are an effort to address the statelessness of the HTTP protocol.
The legitimate cookie distribution is implemented by extending the HTTP protocol. The server prompts the browser to generate the corresponding cookie according to the instructions by adding a line of special instructions in the HTTP response header. However, pure client-side scripts such as JavaScript can also generate cookies. Cookie is used by the browser in accordance with certain principles in the background automatically sent to the server. The browser checks all stored cookies, and if the declared scope of a cookie is greater than or equal to the location of the requested resource, it sends the cookie to the server in the HTTP header for the requested resource.
The contents of the cookie mainly include: name, value, expiration time, path and field. The path, together with the field, forms the scope of the cookie. If the expiration time is not set, it means that the lifetime of the cookie is during the browser session. Close the browser window and the cookie disappears. A cookie whose lifetime is the browser session is called a session cookie. Session cookies are generally not stored on disk but in memory, although this behavior is not specified by the specification. If an expiration date is set, the browser will save cookies to hard disk, close the browser and open the browser again. These cookies will remain valid until the set expiration date is exceeded. Cookies stored on the hard disk can be shared between different browser processes, such as two IE Windows. Different browsers have different ways of handling cookies that are stored in memory.
The Session mechanism, on the other hand, uses a solution that maintains state on the server side. At the same time, we also see that since the server-side state preservation scheme also needs to save an identity on the client side, the session mechanism may need to use the cookie mechanism to achieve the purpose of saving the identity. Sessions provide a convenient way to manage global variables.
The value of the session variable is stored on the server. A SESSIONID is used to identify the user’s session variable. This value is returned to the server by the user’s browser during access.
In terms of security: when you visit a site that uses sessions 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 client.
The session mechanism
The session mechanism is a server-side mechanism in which the server uses a hash table-like structure (or perhaps a hash table) to store 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 already contains a session identifier (called the session ID). If so, it indicates that a session has been created for the client before. If the client request does not contain a session ID, then a session is created for this client and a session ID associated with this session is generated. The value of the session ID should be a string that is neither repeated nor easily found to be counterfeited, and this session ID will be returned to the client in the response for preservation.
The session ID can be stored as a cookie, so that the browser can automatically display the session ID to the server in accordance with the rules during the interaction. Usually the name of the cookie is something like seeeSionID. While cookies can be artificially banned, there must be some other mechanism to pass the session ID back to the server even if the cookie is banned.
One commonly used technique is URL rewriting, where the session ID is appended directly to the URL path. Another technique is called form hidden fields. The server automatically modifies the form by adding a hidden field so that the session ID can be passed back to the server when the form is submitted.
Cookies and Sessions can both do Session tracking, but they do it differently. In general, both of them can meet the requirements, but sometimes cookies and sessions cannot be used. The following is an analogy to clarify the characteristics of the two as well as the applicable place.
1. Different access methods
Cookie can only store ASCII string, if the need to access Unicode characters or binary data, the need to encode first. Cookies also do not allow direct access to Java objects. Cookies are harder to use to store slightly more complex information.
Session can access any type of data, including but not limited to String, Integer, List, Map, etc. Session can also directly store Java beans and any Java classes, objects, etc., which is very easy to use. Think of Session as a Java container class.
2. Different privacy policies
Cookie is stored in the client reader and is visible to the client. Some programs of the client may snoop, copy and even correct the contents of the Cookie. The Session is stored on the server, which is transparent to the client, and there is no risk of sensitive information leakage.
If you choose cookies, it is better to avoid writing sensitive information such as account number and password into cookies. It is better to encrypt the Cookie information like Google and Baidu, and then decrypt it after submitting it to the server, so as to ensure that the information in the Cookie can be read and understood by myself. However, if you choose Session, it will be much easier. In any case, it is on the server, and any privacy in the Session can be effectively protected.
3, the difference in the validity period
As anyone who has ever used Google knows, if you’ve logged into Google, your Google login information will be valid for a long time. Instead of logging in again with every visit, Google persistently logs the user’s login information. To achieve this effect, using cookies is a good choice. Just set the Cookie’s expiration time property to a very, very large number.
Because Session relies on a Cookie named JSESSIONID, and the expiration time of Cookie JSESSIONID is acquiestively -1, as long as the reader is closed, the Session will be invalid, so the Session cannot complete the effect of the information is valid forever. Rewriting with URL addresses can’t be done either. In addition, if the Session timeout is set too long, the server will accumulate more sessions, the more likely to cause memory overflow.
4. The difference in server pressure
Sessions are stored on the server side, and each user generates a Session. If there are a lot of concurrent users, there will be a lot of sessions and a lot of memory. Therefore, websites with high concurrent traffic, such as Google, Baidu and SINA, are unlikely to use sessions to track customer conversations.
The Cookie is kept in the client and does not occupy the server resources. Cookies are a good choice if there are a lot of concurrent readers. For Google, Baidu and SINA, Cookie may be the only choice.
5. Different browser support
Cookies are supported by the client browser. Session tracing is invalidated if the client has cookies disabled or does not support cookies. For applications on WAP, regular cookies are not useful.
If the client browser does not support cookies, Session and URL address rewriting are required. Note that all URLs that use the Session program must be rewritten, otherwise Session tracking will be invalidated. Session+URL rewriting is probably the only option for WAP applications.
If the client supports cookies, cookies can be set to valid in the browser window and child Windows (set the expiration time to -1), but also can be set to valid in all reader Windows (set the expiration time to some integer greater than 0). But the Session can only be valid in the reader window and its child Windows. If two browser Windows are unrelated, they will use two different sessions. Session coherence of different Windows in IE8
6. Cross-domain support differences
Cookie supports cross-domain access. For example, if the domain attribute is set to “.biaodianfu.com “, all domain names with the suffixes of “.biaodianfu.com “can access the Cookie. Cross-domain cookies are now widely used in the Internet, such as Google, Baidu, SINA, etc. Sessions do not support cross-domain access. A Session is only valid within its domain name.
Using cookies alone or sessions alone may not achieve the desired effect. Try using both cookies and sessions. The collocation of Cookie and Session can achieve many unexpected effects in practical projects.