Some questions about the Session in PHP

What is a Session?

In Web application development, the session is called a conversation. is primarily used to save data for a visitor.
Because of the HTTP stateless features, the server will not remember the client, on the server side, each request is completely new.
So, how does the server know which visitor is asking for it? How do you map different data to the right visitors? The answer is to give the visitor a unique ID that gets the data in the Session.

For example: When we go shopping in the supermarket, we are not allowed to bring items into the store by the security guard, we must store the items in the supermarket storage box. We gave him the item, how he knew who it was, and he gave us a different key. When we want to take our items, open the corresponding box with a unique key.

Like the above analogy, the Session can be understood as the "box" that holds our data, and of course, these "boxes" are on the service side. The server gives the visitor the only "key", which is called session_id. With their own session_id, visitors can get their own server-side data.

SESSION_ID is passed to the visitor (client) in two ways: URL or cookie. For details see: Transfer session ID

What does Session and Cookie matter

Cookies are also technologies that are generated by the presence of HTTP stateless features. It is also used to save the visitor's identity and some data. Each time the client initiates an HTTP request, it adds the Cookie data to the HTTP header and submits it to the server. This allows the server to know the visitor's information based on the content of the Cookie.
It can be said that the session and the cookie do similar things, but the session is to save the data on the server, through the client submitted by the session_id to obtain the corresponding data, and the cookie is to save the data on the client, each time the request is initiated to submit data to the server.

As mentioned above, session_id can be passed by URL or cookie, because the URL is more insecure and inconvenient to use than the cookie, so it is generally a cookie to pass session_id.
The server generates session_id, which is sent to the client via HTTP messages (such as a browser), and the client receives the instructions to create a cookie that holds the session_id. Cookies are stored in the form of Key/value, which looks like this: Phpsessid=e4tqo2ajfbqqia9prm8t83b1f2. In PHP, the name of the cookie that holds session_id is known by default as PHPSESSID, which can be modified by session.name in php.ini or by a function session_name ().

Why not recommend using the files-type Session processor that comes with PHP

In PHP, the default session processor is files, and the processor can be implemented by the user (see: Custom Session Manager). I know there are many mature Session processors: Redis, Memcached, MongoDB ...
Why is it not recommended to use the files type processor that comes with PHP, which is given in the official PHP manual:

Either by calling the function session_start () to open the session manually or by using the configuration item Session.auto_start to automatically open the session, for file-based session data saving (the default behavior of PHP), the session data file is locked at the beginning of the session. Until the PHP script finishes or explicitly calls Session_write_close () to save the session data. During this time, other scripts do not have access to the same session data file.

Refer to the following: basic usage of Session

To prove this, let's Create 2 files:
Files: session1.php

Php
 
  

Files: session2.php

Php
 
  

In the same browser, first access the http://127.0.0.1/session1.php, and then immediately access the http://127.0.0.1/session2.php in the new tab of the current browser. The experiment found that session1.php waited 5 seconds for output, and session2.php waited for nearly 5 seconds to output. A separate access to session2.php is second. Access the session1.php in one browser and then immediately access the session2.php in a different browser. The result is that session1.php waits 5 seconds for output, while session2.php is seconds away.

Analyze the cause of this phenomenon: in the example above, the cookie is used to pass session_id by default, and the scope of the cookie is the same. In this way, the 2 addresses are accessed in the same browser, and the session_id submitted to the server is the same (to mark the visitor, which is the effect we expect). When accessing session1.php, PHP saves the path to the session file on the server according to the SESSION_ID submitted (default to/tmp, via Session.save_path in php.ini or function Session_save_pa Th () to modify) found the corresponding Session file, and lock it. If you do not explicitly call Session_write_close (), the file lock will not be released until the current PHP script finishes executing. If there is a time-consuming operation in the script (such as sleep (5) in the example), then another request that holds the same session_id can only be forced to wait because the file is locked, and then a request blocking situation occurs.

In this case, after using the Session, immediately display the call Session_write_close () is not solve the problem? For example above, call Session_write_close () in front of sleep (5).
Indeed, such session2.php will not be blocked by session1.php. However, the display called session_write_close () means that the data is written to the file and ends the current session. Then, you must call Session_Start () again when you want to use the Session in the following code.

For example:

Php
 
  

The official scheme:

This can be a serious problem for a large number of sites that use Ajax or concurrent requests. The simplest way to solve this problem is if you modify the variables in the session, you should call Session_write_close () as soon as possible to save the session data and release the file lock. Another option is to replace the file session Save manager with a session save manager that supports concurrent operations.

The way I recommend it is to use Redis as the processor for the Session.

Expand reading:

Why can't I store Session with memcached

How to use Redis as a PHP Session handler

When was the Session data deleted?

This is a question that is often asked by the interviewer.

First look at the instructions in the Official Handbook:

SESSION.GC_MAXLIFETIME specifies the number of seconds after which the data is considered "junk" and cleared. Garbage collection may start when the session starts (depending on session.gc_probability and session.gc_divisor). Session.gc_probability and Session.gc_divisor together to manage the probability that the GC (garbage collection garbage collection) process starts. This probability is calculated by Gc_probability/gc_divisor. For example, 1/100 means that there is a 1% probability of starting the GC process in each request. session.gc_probability defaults to 1,session.gc_divisor by default to 100.

Keep using the less appropriate analogy above: if we put the items in the store in the supermarket and don't take them away, after a long time (say, one months), the security guard will clean up the items in the storage boxes. Of course not over the deadline security will come to clean up, maybe he is lazy, or he did not think of this thing.

Take a look at the references to the two sections of the handbook:

If you use the default file-based session processor, the file system must maintain tracking access time (Atime). The Windows FAT file system does not work, so if you have to use the FAT file system or other file systems that cannot track atime, then you have to think of another way to handle the garbage collection of session data. Since PHP 4.2.3 Mtime (modified time) to replace the atime. So there's no problem with file systems that can't track atime.

GC run time is not accurate, with a certain probability, so this setting does not ensure that the old session data is deleted. Some session store processing modules do not use this setting item.

I am doubtful about this kind of deletion mechanism.

For example, if the gc_probability/gc_divisor is set to a larger size, or if the request volume of the website is larger, the GC process will be started more frequently.
Also, after the GC process starts, it is necessary to traverse the Session file list, compare the file modification time and the current time of the server, determine whether the file expires and decide whether to delete the file.
That's why I don't think I should be using the files-type Session processor that comes with PHP. Redis or Memcached is inherently supportive of the key/value expiration mechanism and is suitable for use as a session processor. or implement a file-based processor yourself, and determine whether the file expires when the corresponding single session file is obtained according to SESSION_ID.

Why the Session data will not be taken after restarting the browser

SESSION.COOKIE_LIFETIME Specifies the lifetime of the cookie sent to the browser in seconds. A value of 0 means "until the browser is closed." The default is 0.

In fact, the session data is not deleted (it is also possible that the probability is relatively small, see the previous section). Just close the browser, save the session_id Cookie is gone. That means you lost the key to opening the grocery store box (session_id).

In the same vein, browser cookies are manually erased or other software is removed to create this result.

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

This is called "anti-Stay", in order to protect the user account security.

This section is put in because the implementation of this function may be related to the deletion mechanism of the session (it is possible, because this function does not have to be implemented in the session, also can be implemented with cookies).
To put it simply, there is no operation for a long time, the Session file expiration of the server is deleted.

An interesting thing.

In the course of my experiment, I found a little interesting thing: I set the probability of GC startup to 100%. If there is only one visitor request, and the visitor initiates a second request even after a long time (exceeding the expiration date), then the session data is still present (the session file under the ' Session.save_path ' directory exists). Yes, obviously exceeded the expiration time, but not by GC deleted. At this point, when I use another browser to access (relative to another visitor), this request generated a new session file, and the last browser request generated by the session file is finally gone (the previous session file in the ' Session.save_path ' Disappeared under the directory).

Also, found that the session file is deleted, again request, or will generate the same as the previous file name of the session (because the browser is not closed, the request sent again session_id is the same, so the re-generated session file filename is the same). However, I do not understand is: this re-emergence of the creation of the file is the first time that the creation time, is it from the Recycle Bin back? (Yes, I did this experiment in the window.)

The reason I'm guessing is this: when the session is started, PHP finds and opens the corresponding session file based on session_id before it starts the GC process. The GC process only checks for files other than the current Session file, and finds out that it is out of date. All, even if the current Session file has expired, the GC has not deleted it.

I think this is unreasonable.

Since this is not a significant impact (after all, there is a lot of online requests, the current request of expired files by other requests aroused by the GC to kill the likelihood is relatively large) + I do not have the confidence to see PHP source code + I am not online using PHP's own files-type Session processor. Therefore, I have not studied this problem in depth. Please understand.

Php
 
  

Expand reading:

How to set a Session with a strict 30-minute expiration date

