cookie, session, sessionid with jsessionid, in order to understand the relationship between them, let's look interesting scenarios to help you understand.

We all know that the bank, the bank's income to the reception counter customer deposits / withdrawals business day, you can have several options:

With memories of counter staff to handle the receive counter staff for each customer deposits / withdrawals business, staff alone memory, to remember to each customer's appearance, and quickly the current customer deposits and the number of accesses per the amount of times access is. ----------- this manner indicates that state support for the agreement itself.

Use passbook way, then counter staff put each customer's deposit / withdrawal information is stored in this suriko, then keep to the customer, when the customer to deposit / withdrawals, as long as the books out, the staff view on the current passbook the customer deposits / withdrawals information at a glance. Of course, you immediately think of the customer to modify this information how to do? We also have measures on the back of each deposit / withdrawal records sealed. No stamp is fake information. But if the customer is really fake, of course, the seal can be forged. ------------- In this way the client side is on hold.

The use of bank cards the way, the bank issued to each user a bank card, a unique card number on the card, there is no other information to customers when deposits / withdrawals, took out a bank card, bank card number entered computer , soon showed the current deposit / withdrawal records the user. Security in this way will be greatly improved. The user wants only hands and feet to break the bank server to modify their deposit / withdrawal information, this will be very difficult. --------- This is the way to keep the server-side state.

Cookie generation process of the session

We all know that HTTP protocol itself is stateless, customers simply need to send a request to the server to download some files, sent by the client to the server for each request is independent. For the current web applications, HTTP is stateless, resulting in many applications had to spend a lot of effort to record the user's steps. Like the first case we described above, the bank staff to spend a lot of effort to keep the memory of every user / withdrawal records.

Programmers soon discovered that if we can provide some of the information generated on demand moving too, will greatly enhance the ability to interact with the web. On the one hand programmer to add forms, scripts, DOM and other client behavior in HTML, the web application to increase interactivity with the client. On the other hand the server CGI specification appeared measured dynamic response to client requests, the HTTP protocol as transport carrier adds file upload, Cookie and other characteristics. That cookie principle and use our passbook described above should record the user's way is the same as the same.

We have found through the previous example, by way of a cookie to store information, there may be a little set of security, because all information is written on the client, the client may have to modify or remove such information. Way then appeared session for saving user behavior, principles and bank card the way described earlier in this way is the same.

Specifically, the cookie mechanism uses a client program on hold, but the mechanism used to maintain session state on the server side program. We also see, the use of server-side program on hold in the client also needs to save a logo, so session cookie mechanisms may need the help of mechanisms to achieve the purpose of preservation of identity, but in fact it there are other options.

Mechanisms and principles of cookie and session

cookie mechanism. Orthodox cookie distribution is achieved by extending the HTTP protocol, the server indicated by a line with a special header in the HTTP response to the browser prompts the instructions to generate the corresponding cookie. However, a pure client-side scripting such as JavaScript or VBScript can also be generated cookie. The use of the cookie is automatically sent by the browser in accordance with certain principles to the server in the background. Browser to check all stored cookie, a cookie if the scope is not less than the stated location of the resources will be requested, put the cookie attached to the request to send the head of the resource HTTP request to the server.

the cookie should include: name, value, expiration time, path and domain. Together form the cookie path scope domain. If not set an expiration time, then the lifetime of the cookie for the duration of the browser session, close the browser window, cookie disappears. This period of life of the browser session cookie is called a session cookie. Session cookie is generally not stored on the hard but kept in memory, of course, such behavior is not the norm prescribed. If you set an expiration time, the browser cookie will be saved to your hard drive, open the browser again after closing, these cookie remain valid until the expiration time exceeds the set. cookie stored on the hard disk can be shared between different browser process, such as two IE windows. For cookie stored in memory, and different browsers have different approach.

session mechanism. session mechanism is a mechanism for the server, the server uses a structure similar to the hash table (also probably use a hash table) to store information.

When a program needs to create a session for the request of a client, the server first checks whether the client's request already contains a session identifier ------------ called sessionid, if it contains the instructions have previously been created for this client session, the server will follow this session sessionid retrieved using (not retrieved, it will create a new), if the client request does not contain sessionid, create a session for this client and with a generation this session associated sessionid, the value should be a sessionid neither duplicate nor easy to find a replica of the law of string, the sessionid returned to the client will be stored in this response.

Save this way it can be used sessionid cookie, so the browser can automatically play according to the rules this identity to the server during the interaction. The cookie names are generally similar to SEEESIONID. But cookie can be artificially prohibited, there must be other mechanisms in order to still be able to pass sessionid back to the server when the cookie is prohibited.

One technique often used is called URL rewriting, the sessionid is directly appended to the URL path. There is also a technique called hidden form fields. That is, the server will automatically modify the form, add a hidden field, in order to be able to pass sessionid back to the server when the form is submitted.

Jsessionid?

Jsessionid just for tomcat is called sessionid, in fact, sessionid; jsessionid might not be called up in other containers.

-------------------the latest update--------

Terry_Huang reply:

To give you an even more vivid example of previous college, often go to drink milk tea calories Division, each a drink, you can get a stamp (first drink when he will give you points cards), collect after six printing, you can get a cup of tea for free. This way, printing the information is stored on the customer's loyalty card, if you ill, then you do own a few quite similar to printing to cheat tea drink. Haha, like this is not more in line with the client side to maintain state. And go to the bank to get a bank card to withdraw money, we only need to save a card number, the more information is stored in the server, which is also more in line with the server on hold. hope this helps.

I may be describing not appropriate, loyalty cards and books are similar, the user's access information is stored on the passbook, passbook is in the hands of the customer (client) may now few people use a passbook, passbook or the bank has been canceled.