In the program, session tracking is a very important thing. Theoretically, all request actions for one user should belong to the same session, and all request actions for another user should belong to another session, and they should not be confused. For example, any item that user a buys in a supermarket should be placed in A's shopping cart, regardless of when user a buys it, it belongs to the same session and cannot be placed in User B or User C's shopping cart, which is not part of the same session.
The Web application transmits data using the HTTP protocol. The HTTP protocol is a stateless protocol. Once the data has been exchanged, the client-to-server connection is closed, and exchanging the data again requires establishing a new connection. This means that the server is unable to track the session from the connection. That is, user a purchases a product into the shopping cart, and when the product is re-purchased, the server is unable to determine whether the purchase is a session of user A or User B. To track this session, you must introduce a mechanism.
Cookies are such a mechanism. It can compensate for the lack of HTTP protocol stateless. Before the session, basically all websites use cookies to track conversations.
Because HTTP is a stateless protocol, the server does not know the identity of the client from the network connection. What do we do? Give the client a pass, one per person, who must bring their own pass for whoever accesses it. This allows the server to confirm the identity of the client from the pass. That's how cookies work.
A cookie is actually a small piece of text information. The client requests the server and, if the server needs to log the user state, uses response to issue a cookie to the client browser. The client browser will save the cookie. When the browser requests the site again, the browser submits the requested URL along with the cookie to the server. The server checks the cookie to identify the user state. The server can also modify the contents of the cookie as needed.