Talk about Session implementation mechanism and the difference with Cookie?

1. Why are there Session and Cookie?.

According to the early HTTP protocol, the TCP connection must be re-established every time a request-reponse is made. The TCP connection is re-established every time, so the server cannot know whether the last request and this request came from the same client. Therefore, HTTP communication is stateless . The server thinks that each request is a brand new request, regardless of whether the request comes from the same address.

But this also brings problems. If you do not use Session or Cookie, it means that if you log in to a shopping website, each time you request is stateless, the server of the shopping website cannot determine your identity and login and No, it means that in order to stay logged in, you must log in once when browsing a certain product, and log in again when browsing another product.

Who is willing to go to shopping websites with this kind of user experience? So there is a cookie, which stores a small amount of user information on the user’s own computer, because it is global under the same domain name, so when the user visits, the server can read the information in the cookie from any page under that domain name. To judge the login status.

However, cookies exist on the client side, and the storage size is also limited. The user can also disable it, or even see it and modify it, and the security is extremely poor . In order to be safe, and to easily read global information, a new storage session mechanism, Session, appeared.

2. Who is who in the Session (implementation mechanism)

With Session, you can letThe user's multiple HTTP requests in a session are associated, so that multiple pages can read the value in the Session field. Session information is stored on the server side, which also solves the security problem well.

But there are also doubts. If several clients connect to the server, the server will create a session object Session for each client's session. How to distinguish which Session corresponds to which client?

The answer is that most containers use the Cookie mechanism to implement the Session mechanism, that is to say, use the Cookie to store the correspondence between the "client" and the "session object in the server".

2.1 The process of using Cookie to realize the session mechanism is: (look carefully)

• When the container creates a new HttpSession object, it will generate a random number, called the session ID, and encapsulate the ID value into a cookie called JSESSIONID, and return it to the client;
• For subsequent requests, when calling the request.getSession method to obtain the session object, the container will first obtain the value of JSESSIONID from the request, find the corresponding session object based on the value, and return it for use;
• If the JSESSIONID value is not obtained, the container thinks that the current request has no associated session object and will repeat the first step to generate it.

If you still don't understand, let me tell you some examples in life:

• I went to the restaurant and ordered the steak and got the number plate (JSESSIONID)
• After you walk away a few steps, the waiter forgets who you are (disconnecting the server is stateless)
• If you want to pick up your steak, you need this number to get the waiter (Cookie and corresponding conversation object)
• The waiter can confirm that you are a customer according to the number plate, you have ordered a meal, and will give you your corresponding steak (confirmed status to start using)
  

3. Handling of blocked cookies

Cookies can be blocked in the browser settings (because they are stored on the client side, they can be visible and can be modified). According to the implementation mechanism of the session, if the cookie is disabled, the session will also be affected.

If the cookie is blocked, then according to its implementation mechanism, the JSESSIONID cookie cannot be found, and it will be considered as the first login, so the session cannot be used to maintain the user's login status.

Solution: Forcibly pass JSESSIONID (Cookie) to related resources
. Another mechanism for tracking Session is proposed in the Java Servlet API. If the client browser does not support Cookies,The container can rewrite the URL requested by the client and add the JSESSIONID to the URL information.

The HttpServletResponse interface provides a method to rewrite URL:
public String encodeURL(String url)
For example:<a href = <%=response.encodeURL("admin/doServlet")%> >URL重写访问</a>

Note as shown
:

First determine whether the current Web component enables Session,

• If Session is not enabled, return the parameter url directly

• If Session is enabled, then determine whether the client browser supports Cookies

  • If cookies are supported, return the parameter url directly
  • If cookies are not supported, add JSESSIONID information to the parameter url, and then return the modified url

4. The difference between Cookie and Session

• Both save user information, the difference is that the Session is stored on the server side, and the Cookie is stored on the client side
• Any object can be saved in the session, and cookies can only save strings
• Session is closed when the session ends. Cookies can be stored on the client hard disk for a long time or temporarily in the browser memory
• Session is used to store important information, and Cookie is used to store unimportant user information

---

Summary: It is only used for reading materials and study notes in normal study. If you are willing to read it carefully then I believe you can also get some help. Pay attention to me, I also want to have fans hahahaha, a beginner who is just getting started