The significance of Session is probably understood by everyone who is engaged in web development. It is just to solve the problems caused by HTTP being a stateless protocol, so I won’t go into details. The main thing I want to talk about here is how the server and the client interact using sessions.
Look at the flow chart below:
When a user visits the site for the first time, PHP will use the session_start() function to create a session ID for the user. This is the unique identification for the user. Each visiting user will get a unique session ID. This session ID will be stored in the cookie in the response header and then sent to the client. This way the client will have a session ID given to him by the site.
When the user visits the site for the second time, the browser will send the locally stored cookie (which contains the session ID obtained last time) to the server along with the request. After receiving the request, the server will detect whether If there is a session ID, the corresponding session file will be found and the information in it will be read; if not, a new one will be created just like the first time.
Usually the exit function of the site is actually to call the session_destroy() function (it may be more complicated), delete the user's session file, and then clear the user's cookies. In this way, there is no contact between the client and the server.
The red box in the picture is a complete HTTP request. Because HTTP is stateless, after a request is completed, the client and the server no longer have any relationship, and no one knows each other. However, due to some needs (such as maintaining login status, etc.), the server and the client must be kept in contact, and the session ID becomes the medium for this contact.
Through the above analysis, we can know that session actually relies on cookies. When a user visits a certain site, the browser will automatically search for available cookies based on the site the user visits. If there are available cookies, they will be sent with the request. Sent to the server. Each time a response from the server is received, the local cookie information is updated.
Of course, you can also use GET to pass the session ID, but GET is not recommended because it is unsafe.
As you can see from the flow chart above, the server actually stores some of the data generated in the session file. The name of the file is "sess" plus the session ID, and the storage location of these files. It is the session.savepath value found by phpinfo().
We can clearly see from the above picture that the server and client save the same session ID information, which is the key to keeping the two in contact.
There are advantages and disadvantages. The main problem brought by sessions is the impact on performance. You can imagine that for a web site with tens of millions of users, if each user saves the session file, then every time the user accesses Just searching for the corresponding session file will consume a lot of system resources. So at this time it is necessary to make some custom settings for session storage, such as sub-directories or hashes, etc. In addition to saving to the session file, you can also abandon the session function that comes with PHP, implement the session yourself, and store the session information in the database. In this way, it is best to set up the cache of the database, otherwise tens of millions of data will be processed too much. Frequent retrieval is also quite resource consuming.
This connection between the client and the server must be time-limited, so the session needs to be cleared regularly. This issue needs to be considered in two aspects. One is to clear the server-side session file, and the other is to clear the client's cookie information, because both of them save half of the information.
The PHP GC process can scan the session storage directory to clear session files, but this process is particularly resource-consuming, so PHP defaults to a 1% chance to clean up an expired session when a session is started, so it does not mean that a user When a session expires, its corresponding session file will be cleared immediately, and there is a 99% chance that it will not be cleared. This requires us programmers to do it ourselves. You can store an expiration time in the session information, and the value is the time of the user's last visit. When a user visits, the current time is subtracted from the last access time to see if it times out. If it times out, the corresponding session file is deleted, and the Expires attribute of the cookie is set to a negative value so that the cookie information on the client side also expires. In this way, the browser It will be deleted automatically.