Analyze the SESSION principle in PHP and issues to note when applying to large websites

PHP SESSION Principle
We know that session is a method to maintain user session data on the server side, and the corresponding cookie is to maintain user data on the client side. The HTTP protocol is a stateless protocol. After the server responds, it loses contact with the browser. At the earliest, Netscape introduced cookies into the browser so that data can be exchanged across pages by the client. So how does the server remember the sessions of many users? What about data?

First of all, the client and server must be contacted one by one. Each client must have a unique identifier so that the server can identify it. It is recommended that there are two methods of unique identification: cookie or specified through GET. The default configuration of PHP will create a cookie named "PHPSESSID" when using a session (can be specified by modifying the session.name value in php.ini). If the client disables cookies, you can also specify to pass the session id to via GET. Server (modify parameters such as session.use_trans_sid in php.ini).

When we check the server-side session.save_path directory, we will find many files similar to sess_vv9lpgf0nmkurgvkba1vbvj915. This is actually the data corresponding to the session id "vv9lpgf0nmkurgvkba1vbvj915". The truth is here. The client passes the session id to the server. The server finds the corresponding file based on the session id. When reading, it deserializes the file content to get the session value. When saving, it is serialized first and then written.

This is the fact, so if the server does not support session or you want to customize the session, you can DIY it. Use PHP's uniqid to generate a session id that will never be repeated, and then find a place to store the session content. You can also learn how to do it. flickr stores sessions in a MySQL database.

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, how will your session content be stored? ; 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"), of course this must be executed before session_start.

session affects system performance
session does affect system performance on websites with high traffic volume. One of the reasons affecting performance is caused by 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 directory hashing. 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, so 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. PHP The manual recommends using the Reiserfs file system, but the future of Reiserfs is worrying. The author of Reiserfs killed his wife, and SuSE abandoned Reiserfs.

In fact, there are many ways to store sessions, which can be viewed through php -i|grep "Registered save handlers", such as Registered save handlers => files user sqlite eaccelerator can be saved through files, users, sqlite, and eaccelerator. If The server has memcached installed, and there is an option for mmcache. Of course there are many more, such as MySQL, PostgreSQL, etc. All are good choices.

Session synchronization
Our front-end may have many servers. The user logs in on server A, plants the session information, and then accesses some pages of the website and may jump to server B. If there is no server on server B at this time, Since the session information is not specially processed, 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 visits 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, re-establish the session on server B. This method is actually very useful. It is very useful if the website has many sub-channels and the servers are not in the same computer room. The sessions cannot be synchronized and you want to log in uniformly.

Of course, another method is to maintain the session at the load balancing layer and bind the visitor to a certain server. If all his visits are on that server, there is no need for session synchronization. These are all operations and maintenance levels. s things. That's all. Choose to use sessions according to your own applications. Don't be timid just because everyone says sessions affect system performance. Knowing the problems and solving them is the key. If you can't afford to offend or hide, you are not suitable here.