After reviewing session today, I have a better understanding, and I also have a few doubts. Please help me analyze it.
The first question is that in PHP, session has a garbage collection mechanism. The principle is that the garbage collection mechanism may be triggered as many times as session_start
is triggered. So my question is, if my session has passed 1440 seconds, but the recycling is not triggered immediately, maybe not within 5 minutes, can I still get the session data at this time?
The second question is about the principle of session expiration. The books all say that it is based on the modification time of the session file. My questions are as follows: 1) When I normally visit a website, without modifying the session data, do I exit accurately after 1440 seconds? 2) Or does it mean that every time I refresh the web page, the session file will be modified filemtime
? What is the execution principle of session.
The third problem is the setting problem of PHP's session_set_save_handler
. Only by knowing how session handles filemtime
can we write session_set_sa well. The
, because if the read
method in ve_handlerfilemtime
is modified every time the web page is refreshed, it must be modified in read
< code>filemtime.
阿神2017-05-16 13:04:04
In principle, you cannot get it, because the obtained code is read through PHP, and the reading process will check again whether it has expired. If it expires, you will still not be able to get it.
1) The configured time in php.ini is accurate and non-invalid. The default is 1440. You can modify this setting in the program, but it is still recommended to modify the configuration file. Why is it said that right and wrong are invalid? Because PHP is not memory-resident, it needs to use each request to confirm whether certain scheduled tasks are triggered. This is one of the reasons. The second is to reduce the performance loss caused by each garbage collection. PHP sets two parameters to control The probabilities of garbage collection are session.gc_probability and session.gc_pisor respectively. gc_probability/gc_pisor is the probability. For example, if it is 1/100, then it will only be triggered once for at least 100 requests.
2) Every time it is refreshed, filetime will change.
Viewed the session implementation of the Laravel framework. The following are file storage and database storage forms:
public function read($sessionId)
{
if ($this->files->exists($path = $this->path.'/'.$sessionId)) {
if (filemtime($path) >= Carbon::now()->subMinutes($this->minutes)->getTimestamp()) {
return $this->files->get($path);
}
}
return '';
}
public function read($sessionId)
{
$session = (object) $this->getQuery()->find($sessionId);
if (isset($session->last_activity)) {
if ($session->last_activity < Carbon::now()->subMinutes($this->minutes)->getTimestamp()) {
$this->exists = true;
return;
}
}
if (isset($session->payload)) {
$this->exists = true;
return base64_decode($session->payload);
}
}
No related code similar to refreshing filetime was found.
仅有的幸福2017-05-16 13:04:04
After testing, in the case of file storage, set session.gc_maxlifetime to 30 seconds. If it exceeds 30 seconds, the session data can still be released. And in the next refresh case, filemtime will indeed be changed to the current one.
Can anyone explain why and change the custom storage to memcache or will the database be stored in the same format as the file?