<h1 class="pgc-h-arrow-right" data-track="1" > preface</h1>
We know that HTTP is a stateless protocol, and the server doesn't know which request was initiated by which user. There are scenarios where we need to know which user initiated the request and which user acted on it. For example, in a marketplace service, where a user initiates a request to place an order, the server needs to identify which specific user it is. Therefore, the server needs to use some mechanism to identify and record the user's information, status, etc.
The Session mechanism is implemented, which allows the STATEless protocol's HTTP to be stateful. The server creates its own unique Session for each user requesting the server to identify and track this user. Sessions are stored on the server side, can be stored in files, memory, data, etc., and have a unique identification Session ID. After the server creates a Session, the server tells the client via the HTTP protocol to record the Session ID in a local cookie. In this way, each subsequent request of the same client sends a cookie to the server, and the server can find out which user is stored on the server side by checking out the Session stored in the cookie through the Session ID stored in the cookie.
<h1 class="pgc-h-arrow-right" data-track="13">Session</h1>
Session Chinese meaning session, statute of limitations. In fact, it is the session state of one-to-one interaction between the client and the server, which is an abstract concept. Many people think that a Session is a Session object obtained by the following code, but this is just a more versatile implementation with the help of cookies. Sessions are implemented in many ways.
Because most applications use cookies to implement Session tracking, that is, the above line of code. Cookies are physical. When the client requests the session and creates the session for the first time, the server tells the client via the HTTP protocol (set-cookie for http response headers) that the Session ID needs to be recorded in the local cookie. The value of key is JSESSIONID.
In this way, each subsequent request from the same client will send a cookie to the server, and the server can find out which user is stored on the server side by checking out the Session stored in the cookie through the Session ID stored in the cookie.
However, the client browser can disable cookies, so this method will be problematic. However, we can use URL rewriting techniques to implement Session tracking, that is, to add a representative user ID or Session ID to all request parameters on the request server side.
Earlier we said that Sessions can be stored in files, memory, databases, etc. Where the specific storage of conversation information is actually determined according to its own business, everything that is divorced from the business scenario to talk about the technical architecture is playing rogue, the technology itself is not good or bad, but what business scenario is suitable for what technology, which is also the architect's ability to consider the technical selection.
However, the Session mechanism needs to consider the Session consistency problem in cluster services. Session synchronization can be done in the cluster service, but this method has some disadvantages, such as synchronization trouble, synchronization delay, and wasted storage space for multiple machines storing the same Session. Another common method is to use a dedicated Session service cluster to save user session information, such as the Redis cache service, which can not only build a cluster mode to achieve high availability and scalability, but also perform fast based on memory.
<h1 class="pgc-h-arrow-right" data-track="24">Cookie</h1>
Cookie is a client technology, but also many people to implement the session session of the selection, the server side can let the client write some information to the local cookie, to achieve the purpose of session tracking. However, be aware of the fact that cookies are disabled locally in your browser.
Speaking of cookies, I have to say that many advertisers, websites, etc. use our personal privacy to track, analyze our behavior, and make personalized recommendations. Many websites use third-party cookies to obtain user information and send them to the server to record the user's behavior trajectory. You've definitely also come across discussions on other apps to prevent hair loss, and then you open Taobao to be surprised to find that you recommend a variety of anti-hair loss shampoos. However, some browsers have disabled third-party cookies or optimized them, such as Safari, Mozilla, etc.
We can manually set some information into the cookie, so that the client can not only use this information, but also in subsequent requests, the server can also do the corresponding processing according to this information.
We can view the cookie information stored locally through our browser, and other websites can also scan and use the cookies stored by us, so some security or confidential information should not be stored in the cookie as much as possible, because the data security is relatively low. Under normal circumstances, more important information such as user login information is stored in the server session, and other information such as session ID can be stored in cookies.
And the size of a single cookie is also limited, different browser restriction rules are different, the general size is a few Kilobytes. Different browsers also have restrictions on the number of cookies under a domain name, generally dozens, and there is also a strategy of eliminating when the number is saturated, so the use should pay attention to these situations and try not to exceed the limits of the browser.
Author: Chen Pi's JavaLib
Original link: https://blog.csdn.net/chenlixiao007/article/details/118873800