About deposit Session,cookie or database or Memcache, part of the online transcription

From efficiency considerations: Cookies > Memcache > Databases
Cookies have no effect on server-side loads, and if encryption and decryption consume a bit more CPU. Bandwidth will consume a bit more, all HTTP request headers under the same domain name will be accompanied by a cookie, so in the large traffic, JS, CSS, pictures placed under another domain name will save this portion of traffic.
Memcache will consume some server memory
Database connection is a typical bottleneck, can be exempt from the

From security Considerations: memcache/Databases > Cookies
Cookies are stored on the client side and need to be considered more secure
Memcache, databases are on the server side, a little bit safer relative to cookies

From server scalability considerations: Cookies > memcache/databases
If you have more than one backend server, you need to share session data
Memcache, database can be used to share the session between multiple servers, but easy to form a single point of bottleneck, under heavy load need to consider storage routing and so on
Cookies do not need to share session data on the server side at all, and rest stateless style coincidence, rest stateless style see below.
Scalability this point is not absolute, if the Nginx Ip_hash way to organize multiple back-end upstream do not need to share the session, but these require back-end architecture considerations and design, and the cookie does not have this aspect of extensibility issues
Add: Cookies are not in fact not in the extensibility of any problem need to consider, say "absolutely no" a bit absolute, scalability, this kind of thing, complexity is higher, need practical analysis of actual problems. In a relatively simple and ideal situation, the scalability of cookies will be better.

Why passing SessionID in a request is generally considered unrestful, and it is a very restful practice to include the user's credentials in each request
Stateless means that any Web request must be completely isolated from other requests, and when requested, the request itself contains all the information required by the corresponding end for that request.
Rest stateless style
The restful architecture has two different interpretations of the state: the status of the application (Application states) and the resource status (Resource state).
Application Status: Refers to the status information associated with a particular request
Resource status: Reflects the specific state of a stored server-side resource at a particular point in time, which is not changed by the user's request, and any user requests for that resource at the same time will get the performance of that State (representation).
The restful architecture requires that the server side does not maintain any resources related to a particular HTTP request, so the application state must be provided by the requester during the request.
The session ID can be considered a key to identify a session state, and passing it to the server means a request: "Please take out this state message for me", that is, the request assumes that the response Fang Pao has status information. Because the state associated with a particular request belongs to the application state, and the restful schema requires that any such state be provided by the requester, passing the session ID is considered a unrestful practice. In turn, user credential, as an application state, is expected to be provided by the requester, so passing the user credentials in the request (ignoring security issues) is consistent with the RESTful architecture specification

Nginx Ip_hash Way: Each request according to the hash result of the access IP allocation, so that each visitor fixed access to a back-end server, can solve the session sharing problem.

For the cookie to save the verification code, still cannot eliminate the machine attack, the machine can be through the way of the cookie, and then send the corresponding verification code in the request to access, so the service of the Verification Code judgment, has been correct.
There may be a way to verify that the code is put on a timestamp, and then encrypted to grow into a cookie, but even with a timestamp, it is not possible to avoid attacks within the scope of your timestamp.

Save the session file
Session mechanism, after the server Session_Start (), will send a Set-cookie field in the response header, the next request, the cookie will take PHPSESSID, The server then finds the corresponding file to save the session based on the PHPSESSID.
So the duration of the session is divided into the client and server side.
Client
Session.cookie_lifetime=0, closing the browser session will expire
Server-side
Validity of Session.gc_maxlifetime//session
Session.gc_probability
Session.gc_divisor
Session.gc_divisor and session.gc_probability together define the probability of starting the GC (garbage collection garbage collection) process at each session initialization.
This probability is calculated by Gc_probability/gc_divisor. For example, 1/100 means that there is a 1% probability of starting the GC process in each request.
When gc_probability/gc_divisor=1 means that every request to call Session_Start () executes a garbage collection mechanism that deletes the session file with the disk expiration. A pro-test.
If the gc_maxlifetime is modified individually, even if the session is invalidated, the session can still be used if no garbage collection mechanism is triggered, when the request comes in again. So the session does log in, it may be because the client retains the PHPSESSID resulting in a few days of re-access or login status

About deposit Session,cookie or database or Memcache, part of the online transcription