Home >Backend Development >PHP Tutorial >PHP session running process_PHP tutorial
PHP session running process_PHP tutorial
- WBOYOriginal
- 2016-07-13 10:33:22794browse
I have been using sessions to store data, but I have never summarized the use of sessions and their working principles. Today I will summarize them here.
The introduction here is mainly based on the PHP language. The operations in other languages may be different, but the basic principles remain the same.
How to operate session in php
session_start(); //Use this function to open the session function
$_SESSION //Use predefined global variables to manipulate data
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?
Session implementation and working principle
The browser and the server use http stateless communication. In order to maintain the state of the client, session is used to achieve this purpose. But how does the server identify different clients or users?
Here we can use an example from life. If you attend a party and meet many people, how will you distinguish different people? You may use a unique identifier based on the face shape, the user's name, or the person's ID card. In the session mechanism, such a unique session_id is also used to identify different users. The difference is that every request by the browser will bring the session_id generated for it by the server.
A brief introduction to the process: when the client accesses the server, the server sets the session according to the requirements, saves the session information on the server, and passes the session_id indicating the session to the client browser, and the browser saves this session_id in the memory. (There are other storage methods, such as writing in the URL), we call it a cookie without expiration time. After the browser is closed, this cookie will be cleared, and it will not contain the user's temporary cookie file. In the future, the browser will add this parameter value to every request, and the server can obtain the client's data status based on this session_id.
If the client browser is closed unexpectedly, the session data saved by the server will not be released immediately. The data will still exist at this time. As long as we know the session_id, we can continue to obtain the session information through requests. But at this time, the background session still exists, but the session save has an expiration time. Once there is no client request after the specified time, he will clear the session.
The following introduces the session storage mechanism. The default session is saved in files, that is, session data is saved in the form of files. In php, the method of saving the session is mainly selected based on the configuration session.save_handler of php.ini.
By the way, if we want to make a server LVS, that is, multiple servers, we generally use memcached session, otherwise some requests will not be able to find the session.
A simple memcache configuration:
session.save_handler = memcache session.save_path = "tcp://10.28.41.84:10001"
Of course, if you must use files file caching, we can use nfs to store the files and locate all saved session files in one place. As mentioned 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.
Example question
Existing systems A, 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 keeping A unchanged. In this case, that is, when 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. System A adds session_id (session_id) before session_start; in this way, system B can call A safely.