PHP session Expiration Question _php tutorial

Session processing is a problem that all Web applications must face. The processing of session expiration in PHP is very different from other solutions, which is related to the working mechanism of PHP.

In the traditional Client/server application, for the session failure situation, can be handed over to the network protocol itself to deal with. Whether the client side actively shuts down the connection or the connection is interrupted due to a network exception, the server side can be notified of the event that triggered the connection interruption. As long as you programmatically respond to this event, perform the specified action. But for Web applications, the situation is completely different. The HTTP protocol itself is stateless, which means that the connection is disconnected every time client/server completes a request/response process. After disconnecting, the server does not know whether the client continues to be "online" and continues to send the next request. In other words, regardless of whether the client user has closed the browser window, or if the user is only reading the current page and is ready to continue browsing in the next second, or the user is completely unable to send the next request because of Windows crash/power outage/hard drive/cable being unplugged/Earth explosion The server is ignorant. (in HTTP 1.1, the browser can use the Keep-alive parameter to notify the server not to actively disconnect after responding to a request, thereby achieving a physical long connection.) However, this is only a measure to improve the performance of the network transmission, HTTP is still logically stateless. Therefore, the current session can only be judged by some kind of simulation. If a session does not make a request to the server after more than a certain period of time, the server will determine that the user is "offline", the current session is invalidated, and the event that triggered the connection is interrupted. To do this, the server needs to run a background thread that periodically scans all session information to determine if the session has timed out.

The principle of PHP processing session is no exception, but in the specific way of implementation, but different. This is because, because of PHP working mechanism, it does not have a background thread, to periodically scan the session information and determine whether it is invalid. The solution to this is that when a valid request occurs, PHP determines whether to invoke a GC (garbage Collector), depending on the probability. The GC's job is to scan all session information, subtracting the last modification time of the session (modified date) with the current time, with the configuration parameter (config option) session.gc_ The Maxlifetime value is compared, and if the lifetime has exceeded Gc_maxlifetime, the session is deleted. This is easy to understand, because if the GC code is called every time the request is made, PHP will be inefficient. This probability depends on the value of the configuration parameter Session.gc_probability/session.gc_divisor (which can be modified by the php.ini or Ini_set () function). By default, session.gc_probability = 1,session.gc_divisor=100, which means that there is a 1% possibility to start the GC. These three parameters, Session.gc_maxlifetime/session.gc_probability/session.gc_divisor can be modified by the php.ini or Ini_set () function. Remember, however, that if you use the Ini_set () function, you must call Ini_set () at the beginning of each page.

This leads to another problem, Gc_maxlifetime can only guarantee the minimum time for the session to survive, not be able to save the session information will be deleted immediately after the time. Because GC is started by probability and may not be started for a long time, a large number of sessions will still be valid after gc_maxlifetime. Of course, the probability of this happening is small, but if your application is very accurate in the expiration of the session, this can cause serious problems. One way to solve this problem is to increase the odds of session.gc_probability/session.gc_divisor, and if you mention 100%, it will solve the problem completely, but it will obviously have a serious impact on performance. Another way is to discard the PHP GC, in the code to determine the current session's survival time, if beyond the Gc_maxlifetime, the current session is emptied.

The duration of the session in PHP is 1440 seconds (24 minutes) By default, that is, if the client does not refresh for more than 24 minutes, the current session will be invalidated. To modify this default, the correct workaround is to modify the configuration parameter session.gc_maxlifetime.

I have searched the Internet for the solution of this problem, and found the results of strange. Some say to set up "Session_life_time", as far as I know, PHP does not have this parameter. Some say to call Session_set_cookie_params, or set Session.cookie_lifetime, which is only used to set the lifetime of the client-side cookie, in other words, When the client-side cookie is less than the server-side session lifetime, modifying this value is valid and cannot exceed the session lifetime of the server side for a simple reason, when the server-side session has failed, It doesn't make sense to have a client-side cookie that has a longer life time. Others say to call Session_cache_expire, this parameter is used to inform the browser and proxy, the current page content should be cached for how long, and the lifetime of the session is not directly related.

That sounds like a perfect solution. However, when you try to modify the value of the session.gc_maxlifetime in practice, you will likely find that this parameter basically does not work, the session is still valid for 24 minutes of the default value. It may even appear that it works properly in the development environment and is not valid on the server!

In order to solve this problem thoroughly, we need to further analyze the working details of PHP.

By default, the session information in PHP is saved in the temporary file directory of the system as a text file. This path is specified by the configuration parameter Session.save_path. Under Linux, this path is typically TMP, which is typically c:windowstemp under Windows. When there are multiple PHP applications on the server, they keep their session files in the same directory (because they use the same session.save_path parameter). Similarly, these PHP applications will launch the GC at a certain probability, scanning all session files.

The problem is that when the GC is working, it does not differentiate between sessions at different sites. For example, site A's gc_maxlifetime is set to 2 hours, and Site B's gc_maxlifetime is set to the default of 24 minutes. When the GC of Site B starts, it scans the common temporary files directory and removes all session files that are more than 24 minutes, regardless of whether they come from site A or B. In this way, site A's gc_maxlifetime setting is no more than a dummy.

Finding the problem is a simple solution. Call the Session_save_path () function at the beginning of the page, which modifies the Session.save_path parameter and points to a dedicated directory, such as Tmpmyapp, that holds the session's directory. In this way, the Gc_maxlifetime parameter works fine.

Using a common session.save_path also causes security problems, because this means that other PHP programs on the same server can also read your site's session files, which could be used for hacking. Another problem is efficiency: in a busy site, there may be thousands of session files, and many different sites of the session files are placed in the same directory, whether it is a single file read or write, or traverse all files for GC, will undoubtedly lead to performance degradation. Therefore, if your PHP application is running on the same server as another PHP application, you are strongly advised to use your own session.save_path.

Strictly speaking, this is a bug in PHP. When PHP is in the GC, it should distinguish between session files from different sites and apply different gc_maxlifetime values. Currently, the latest PHP 5.2.X still has this problem.

As mentioned above, in a busy site, there may be thousands of session files, even if the different sites of the Session.save_path directory, the number of session files of a single site can still lead to efficiency problems. In order to solve this problem, several feasible methods are as follows:

If PHP is running under a Linux system, replace the default Ext2/ext3 file system with the ReiserFS file system. ReiserFS has a great increase in access performance for a large number of small files than Ext2/ext3.

Point Session.save_path to a memory path. This means that the session file reads and writes only in memory and does not perform disk operations.

Session.save_path accepts an additional n parameter that specifies the series of the directory. For example, "5;/tmp" will result in the creation of a session file like this:/tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174if. For specific instructions, see: Http://cn.php.net/manual/en/session.configuration.php#ini.session.save-path

The ultimate solution is to abandon the session processing mechanism of PHP, and to take over all session processing operations by itself, through the Session_set_save_handler () function. By taking over the session processing, you can save all the sessions in a dedicated database (often using memory tables) to completely solve the problems caused by the session file, and can easily realize the sharing and replication of the session. This is also a common way for large PHP applications to be used. The use of the Session_set_save_handler () function, the online and related books are described in detail, here no longer repeat. It is worth mentioning that even in this way, the probability of starting the GC still depends on the session.gc_probability/session.gc_divisor.

http://www.bkjia.com/PHPjc/752506.html www.bkjia.com true http://www.bkjia.com/PHPjc/752506.html techarticle session processing is a problem that all Web applications must face. The processing of session expiration in PHP is very different from other solutions, which is related to the working mechanism of PHP ...

