Several questions about Session in PHP

What is Session in PHP?

In web application development, a Session is called a Session. It is mainly used to save the data of a visitor.
Because HTTP is stateless, the server does not remember the client. for the server, every request is completely new.
In this case, how does the server know which visitor is requesting it? How can we map different data to the correct visitor? The answer is to give the visitor a unique identity to obtain the data in the Session.

For example, when we go to the supermarket for shopping, we are told by the security guard that we cannot bring items into the store. we must store the items in the store box of the supermarket. We handed the item to him. How did he know who these items belong to? so he gave us different keys. When we want to take our items away, use the unique key to open the corresponding box.

Just like the above example, we can understand the Session as a "box" for storing our data. of course, these "boxes" are all on the server. The unique "key" provided by the server to visitors. this "key" is calledSession_id. Visitors can use their own session_id to obtain data on their own servers.

Session_id is sent to the visitor (client) in two ways: URL or cookie. For details, see transfer session ID.

What is the relationship between Session and Cookie?

Cookie is also a technology generated due to the stateless characteristics of HTTP. It is also used to save the visitor's identity and some data. Each time a client initiates an HTTP request, the Cookie data is added to the HTTP header and submitted to the server. In this way, the server can know the visitor information based on the Cookie content.
It can be said that the Session and Cookie are doing similar things, but the Session stores the data on the server and obtains the corresponding data through the session_id submitted by the client. the Cookie stores the data on the client, data is submitted to the server every time a request is initiated.

As mentioned above, session_id can be transmitted through URL or cookie. because the URL method is more insecure and inconvenient to use than the cookie method, it is generally used to pass session_id.
The server generates session_id and sends it to the client through an HTTP message (such as a browser). after receiving the message, the client creates a cookie with session_id as instructed. The cookie is saved in the form of key/value. it looks like this: PHPSESSID = e4tqo2ajfbqqia9prm8t83b1f2. In PHP, the cookie name for saving session_id is called PHPSESSID by default. this name can be modified through session. name in php. ini, or through the session_name () function.

Why is it not recommended to use the files Session processor in PHP?

In PHP, the default Session processor is files, which can be implemented by users (see Custom Session Manager ). I know many mature Session processors: Redis, Memcached, MongoDB ......
Why is it not recommended to use the files processor that comes with PHP? the official PHP Manual provides such a Note:

Whether you enable the session manually by calling the session_start () function or using the configuration item session. auto_start automatically enables the session. for file-based session data storage (default PHP behavior), the session data file is locked at the beginning of the session, until the PHP script is executed or session_write_close () is explicitly called to save session data. During this period, other scripts cannot access the same session data file.

For the above reference, see basic Session usage.

To prove this, we create two files:
File: session1.php

php
 

File: session2.php

php
 

Access http: // 127.0.0.1/session1.php in the same browser, and then access http: // 127.0.0.1/session2.php on the new tab of the current browser. The experiment found that session1.php waited five seconds for output, and session2.php waited nearly five seconds for output. However, access to session2.php is enabled in seconds. Access session1.php in one browser, and then access session2.php in another browser immediately. The result is that session1.php waits for 5 seconds for output, while session2.php opens in seconds.

Analyze the cause of this phenomenon: In the above example, the session_id is passed through Cookie by default, and the Cookie scope is the same. In this way, access these two addresses in the same browser, and the session_id submitted to the server is the same (in this way, the visitor can be marked, which is the expected effect ). When accessing session1.php, PHP saves the Session file path (/tmp by default) on the server based on the submitted session_id. session in ini. save_path or function session_save_path () to modify). find the corresponding Session file and lock it. If session_write_close () is not explicitly called, the filelock will not be released until the current PHP script is executed. If there are time-consuming operations in the script (such as sleep (5) in the example), the other request holding the same session_id is forced to wait because the file is locked, as a result, the request is blocked.

In this case, after the Session is used up, it is immediately displayed that the problem is solved by calling session_write_close? In the preceding example, session_write_close () is called before sleep (5 ().
Indeed, session2.php will not be blocked by session1.php. However, if session_write_close () is called, data is written to the file and the current session is ended. To use Session in subsequent code, you must call session_start () again ().

For example:

php
 

Official solution:

This may be a serious problem for websites that use Ajax or concurrent requests. The simplest way to solve this problem is to modify the variables in the session, you should call session_write_close () as soon as possible to save the session data and release the filelock. Another option is to use the session save manager that supports concurrent operations to replace the file session save manager.

I recommend using Redis as the Session processor.

Extended reading:

Why can't I use memcached to store sessions?

How to use Redis as PHP Session handler

When is Session data deleted?

This is a frequently asked question by the interviewer.

Let's take a look at the instructions in the official manual:

Session. gc_maxlifetime specifies how many seconds later the data will be treated as "junk" and cleared. Garbage collection may start at session startup (depending on session. gc_probability and session. gc_pisor ). Session. gc_probability and session. gc_pisor are combined to manage the probability that gc (garbage collection) processes start. This probability is calculated using gc_probability/gc_pisor. For example, 1/100 means 1% of the probability of starting the gc process in each request. Session. gc_probability: 1 by default, and session. gc_pisor: 100 by default.

Let's continue with the inappropriate example above: if we put the items in the supermarket's storage box without taking them away, after a long time (for example, a month ), then the security guard will clean up the items in these buckets. Of course, the security guard will definitely clean up after the deadline is not exceeded. maybe he is lazy, or he doesn't even think about it.

Let's take a look at the reference of the two manuals:

If you use the default file-based session processor, the file system must keep track of access time (atime ). Windows FAT file system does not work, so if you must use a FAT file system or other file systems that cannot track atime, you have to find another way to handle session data garbage collection. Mtime (modification time) is used to replace atime since PHP 4.2.3. Therefore, it is okay for file systems that cannot track atime.

The GC running time is not accurate and may be contingent. Therefore, this setting item cannot ensure that the old session data is deleted. Some session storage processing modules do not use this setting.

I am skeptical about this deletion mechanism.

For example, if gc_probability/gc_pisor is set to a large value or the website has a large number of requests, the GC process starts frequently.
In addition, after the GC process is started, it is necessary to traverse the Session file list, compare the modification time of the file with the current time of the server, and determine whether to delete the file if the file expires.
This is why I don't think PHP's built-in files Session processor should be used. Redis or Memcached naturally supports the key/value expiration mechanism, which is suitable for session processors. Alternatively, you can implement a file-based processor. when you obtain a single Session file based on session_id, you can determine whether the file has expired.

Why can't Session data be retrieved after the browser is restarted?

Session. cookie_lifetime specifies the lifecycle of the cookie sent to the browser in seconds. The value 0 indicates "until the browser is closed ". The default value is 0.

In fact, the Session data is not deleted (or the probability is relatively small, see the previous section ). Only when the browser is closed, the Cookie for saving session_id does not exist. That is, you lost the key (session_id) to open the supermarket storage box ).

Similarly, the browser Cookie is manually cleared or other software is cleared.

Why is the browser open? I have been logged out without any operation for a long time.

This is called "Stay-free", to protect the security of user accounts.

This section is introduced because the implementation of this function may be related to the Session deletion mechanism (the reason is that it is possible because this function does not have to be implemented by Session and can also be implemented by using cookies ).
Simply put, the Session file on the server is deleted after a long period of time.

An interesting thing

During my experiment, I found something interesting: I set the GC startup probability to 100%. If there is only one visitor request and the visitor initiates the second request after a long time (beyond the expiration time), the Session data still exists ('session. the Session file in the save_path directory exists ). Yes, it is clearly beyond the expiration time, but it is not deleted by GC. At this time, when I use another browser for access (compared with another visitor), this request generates a new Session file, the Session file generated by the previous browser request is no longer available (the previous Session file is in 'session. save_path 'directory disappears ).

In addition, after the Session file is deleted, the Session file with the same file name will still be generated for the next request (because the browser is not closed, the session_id sent for the next request is the same, so the names of the re-generated Session files are the same ). However, what I don't understand is that the creation time of the re-emergence file is actually the first creation time. does it come back from the recycle bin? (Indeed, I did this experiment in the window)

I guess the reason is: after the Session is started, PHP finds and opens the corresponding Session file based on session_id, and then starts the GC process. The GC process only checks the files other than the current Session file, and kills the files that expire. All, even if the current Session file has expired, GC does not delete it.

I think this is unreasonable.

This situation has little impact (after all, there are a lot of online requests, and the current request's expired files are probably killed by the GC triggered by other requests) + I don't have the confidence to go to the PHP source code + I don't use the files Session processor that comes with PHP online. Therefore, I have not studied this issue in depth. Please forgive me.

Php
 

Extended reading:

How to set a strictly 30-minute overdue Session