Home >Backend Development >PHP Tutorial >Detailed explanation of the working principle and usage of Session in php_PHP tutorial
Many of my friends will ask how Session works and what is the difference between it and cookies. Let’s introduce to you the working principle of Session. Friends who need to know more can enter for reference.
1. What is Session
2.Session forms a session life cycle from the time the user accesses the page to the time the user disconnects from the website. During the session, the client is assigned a unique SessionID to identify the current user and distinguish it from other users.
3. During the Session, the Session ID will be saved in two locations: the client and the server. For the client, a temporary cookie is used to save it (the cookie name is PHPSESSID) or passed through the URL string. The server is also saved in the form of a text file. In the specified Session directory.
4.Session accepts each access request through ID, thereby identifying the current user, tracking and maintaining user specific information, and Session variables (during Session activity, numeric or text information can be stored in Session), such as session_name, etc., these variables The information is saved on the server side.
5.SessionID can be saved to the database as session information for session persistence, so that each user's login times, online status, online time, etc. can be tracked.
session.name=PHPSESSID; the name of the session used in the cookie
•session.save_handler=files; control method for saving/retrieving data
•session.save_path=/tmp; The parameter passed to the controller when save_handler is set to a file. This is the path where the data file will be saved.
•session.use_cookies=1;Whether to use cookies
How to operate session in php:
session_start(); //Use this function to open the session function
$_SESSION //Use predefined global variables to manipulate data
Use unset($_SESSION['key']) //Destroy the value of a session
Easy to operate, everything is implemented by the server; since the processing is in the background, everything also looks safe. But what mechanism does session use, how is it implemented, and how is the session state maintained?
By the way, if we want to use LVS of the server, that is, multiple servers, we generally use memcached session, otherwise some requests will not be able to find the session.
A simple memcache configuration:
The code is as follows | Copy code | ||||
session.save_handler = memcache
|
Of course, if you must use files file caching, we can use nfs to store all session files in one place.
Just now, the session-id returned to the user is eventually saved in memory. Here we can also set parameters to save it in the user's url.
Why do you have to execute session_start() before using session?
After understanding the principle, the so-called session is actually a session id on the client side and a session file on the server side. Executing session_start() before creating a new session tells the server to plant a cookie and prepare the session file, otherwise your session content How to save; executing session_start() before reading the session tells the server to quickly deserialize the session file according to the session id.
Only one session function can be executed before session_start(). session_name(): read or specify the session name (for example, the default is "PHPSESSID"). This of course must be executed before session_start.
session affects system performance
Session does affect system performance on websites with high traffic. One of the reasons affecting performance is the file system design. When there are more than 10,000 files in the same directory, file positioning will be very time-consuming. PHP supports session directories. hash, we can modify session.save_path = "2;/path/to/session/dir" in php.ini, then the session will be stored in two-level subdirectories, each directory has 16 subdirectories [0~f] , but it seems that PHP session does not support creating directories, you need to create those directories in advance.
Another problem is the efficiency of small files. Generally, our session data is not too large (1~2K). If there are a large number of 1~2K files on the disk, the IO efficiency will definitely be very poor. The PHP manual recommends using the Reiserfs file system, but the future of Reiserfs is worrying. The author of Reiserfs killed his wife, and SuSE also abandoned Reiserfs.
In fact, there are many ways to store sessions, which can be viewed through php -i|grep "Registered save handlers". For example, Registered save handlers => files user sqlite eaccelerator can be saved through files, users, sqlite, and eaccelerator. If memcached is installed on the server, there is also an option for mmcache. Of course there are many more, such as MySQL, PostgreSQL, etc. All are good choices.
session synchronization
We may have many servers on the front end. The user logs in on server A, plants the session information, and then visits some pages of the website and may jump to server B. If there is no session information on server B at this time, If no special treatment is taken, problems may occur.
There are many types of session synchronization. If you store it in memcached or MySQL, it is very easy. Just specify it to the same location. If it is in file form, you can use NFS to store it uniformly.
Another way is to use encrypted cookies. When the user successfully logs in on server A, an encrypted cookie is planted on the user's browser. When the user accesses server B, check whether there is a session. If so, Of course, no problem. If not, check whether the cookie is valid. If the cookie is valid, recreate the session on server B. This method is actually very useful. If the website has many sub-channels, the server is not in the same computer room, the sessions cannot be synchronized and you want to log in unifiedly, it is very useful
Example question
Existing systems A and B; Assume that system A is a web system that can run independently, that is, it can handle sessions directly with the browser. System B is based on mobile and needs to call the functional interface of system A.
While A remains unchanged, that is, login verification and session storage remain unchanged, system B can handle the front-end user's request.
The solution provided here is implemented using PHP
After the user successfully logs in, the session-id of the saved session will be returned to system B, and then system B will bring session_id every time it requests other interfaces.
ASystem A adds session_id (session_id) before session_start;
This way system B can safely call A