Reply content:
Instead of talking about the session and cookie in PHP, let's look at what the session and cookie are in the normal web.
Cookies are actually technology at the end of the browser. Since HTTP itself is stateless, it is generally not known to the server side who each request is, so a Web session allows temporary storage of some content in the HTTP header via Set-cookie on the client, The client needs to enclose the contents of the current cookie for each HTTP request in this session (the cookie is disabled). The conversation here is usually defined by a domain name.
But there are two big drawbacks to cookies: 1. Cookies are stored on the client, so cookies can be read, misappropriated, and modified. This means that for any key information, such as login information, if it is kept with a cookie, others will be able to read and revise it. 2. Other masquerading sites may have access to your cookie content directly.
So how do you access this information to make it difficult for the client to arbitrarily hack cookies to disguise other users? Generally, there are two main classes of methods: 1. Encrypt the cookie, save only one signature with self-authentication in 2.cookie, and then store the key data at the server end. This is the session.
Session is the application of cookies. Encrypted storage in the client session is the easiest to implement, does not bring additional storage burden on the server, many of the new small micro-framework of the session is implemented by this means (and not stored on the service side). The second is the storage on the server side, the optional storage includes not limited to memory, file, external database and so on.
PHP comes with a library, the cookie is added to the response, such as the need for client storage, such as Cookie,session is in a cookie session_id, and then by default in the form of files to store storage on the server side.
Incidentally, the modern browser generally support localstorage, one of it through the front-end access to the backend is not available to users, the security is slightly better, and the amount of storage can be mostly, Sunline has a certain ability to prevent low-end crawler. If you do not consider the old browser compatibility, with the localstorage+ front-end separation, in the form of Ajax through JS return localstorage content (session_id or encrypted storage content) in lieu of cookies more recommendable. A cookie is the presence of data on the client
Session is to put the data on the server side, the client only save one ID first floor said very well.
In fact, the biggest difference is that the cookie exists on the client side, the session server. And in general, the session really depends on the session ID in the cookie, in fact, the session ID you can also decide, and then use the session to specify the session ID. The role of session ID is to specify the session file, so the cookie is disabled, you can use this trick.
Add that, in the distributed architecture, the session should be used with caution, because the session data loss may occur, of course, you can also rewrite the session, the session exists in the cache or in the database. You can understand that the cookie is someone's home box, the session is the box of their own home, the advantages of the box? Save something.
