Home  >  Article  >  php教程  >  Analyze the implementation principles of session in PHP and issues that should be paid attention to when applying large websites

Analyze the implementation principles of session in PHP and issues that should be paid attention to when applying large websites

黄舟
黄舟Original
2016-12-13 11:58:301075browse

PHP SESSION principle
We know that session is a method of maintaining user session data on the server side, and the corresponding cookie is Keep 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, making Data can be exchanged across pages by the client, so how does the server remember the session data of many users?

First of all, we need to establish a one-to-one connection between the client and the server. Each client 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 uses session A cookie named "PHPSESSID" will be created (can be specified by modifying the session.name value in php.ini). If the client disables cookies, you You can also specify the session to be retrieved through GET The id is transmitted to the server (modify parameters such as session.use_trans_sid in php.ini).

When we look at the server-side session.save_path directory, we will find many files similar to sess_vv9lpgf0nmkurgvkba1vbvj915. This In fact, it is the data corresponding to the session id "vv9lpgf0nmkurgvkba1vbvj915". The truth is here, the client will session The id is passed to the server, and the server depends on the session Find the corresponding file by id. When reading, deserialize the file content to get the session value. When saving, serialize first and then write.

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

Why do you have to execute session_start() before using session?
Up After understanding the principle, the so-called session is actually a session id on the client side and a session on the server side. file, executing session_start() before creating a new session tells the server to plant a cookie and prepare the session file, otherwise your How to store session content; executing session_start() before reading the session tells the server to quickly follow the session id deserializes the session file.

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 System performance is indeed affected 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 hash, we can modify session.save_path = in php.ini "2;/path/to/session/dir", 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 The session data will not be 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. system, but the future of Reiserfs is worrying. The author of Reiserfs killed his wife, and SuSE also abandoned Reiserfs.

Actually there are many more The method of storing session can be viewed through php -i|grep "Registered save handlers", such as Registered save handlers => files user sqlite eaccelerator can be stored through files, users, sqlite, and eaccelerator. If the server is installed with memcached, there will also be mmcache. options. 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 visits some pages of the website and may jump to server B. If there is no session on server B at this time, If the information is not processed specially, problems may arise.
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 session, if it exists, of course there is 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 quite It is very useful if the website has many sub-channels, the servers are not in the same computer room, the sessions cannot be synchronized and you want to log in uniformly.

Of course there is another way It maintains the session at the load balancing layer and binds the visitor to a certain server. All his visits are on that server and there is no need for session synchronization. These are all things at the operation and maintenance level. Just say this There are so many, choose to use session according to your own application. Don't be timid because everyone says that session affects system performance. Knowing the problem and solving the problem are the key. If you can't afford to offend or hide, you are not suitable here.


Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn