Understanding ASP. NET session Status

I. session Status
HTTP is a stateless protocol, so it does not automatically indicate whether a request sequence is from the same client, or even whether a single browser instance is still active to view a page or site. With the built-in session Status function of ASP. NET, we can use
1. automatically identifies and classifies requests for logical application sessions from a single browser client to the server.
2. Store session-range data on the server for cross-browser requests.
3. Trigger appropriate session lifetime management events (Session_OnStart, Session_OnEnd, etc.) that can be processed in application code)
Ii. session Status Identification
When creating a session, the server generates a separate identifier for each session. The ID is represented by a 120-bit SessionID string, which only contains the ASCII characters allowed in the URL. SessionID is generated by algorithms that ensure uniqueness and randomness. The purpose of uniqueness is to ensure that the session does not conflict, the purpose of ensuring randomness is to ensure that malicious users cannot use the new SessionID to calculate the SessionID of an existing session.
Iii. session state storage
Three storage methods are available for session status.
1. In-process session Status mode (Inproc): When a WEB program is created, the in-process session Status mode is used by default. This mode is also widely used. In this mode, the session status is stored in the local ASP. NET auxiliary process. So far, the in-process session Status mode may be the fastest access option. However, the more data stored in sessions, the more memory the Web server consumes, which may increase the risk of performance reduction.
2.. NET status server mode (StateServer): The session status is stored in a remote process (for example, in the indows NT service named aspnet_state.exe)
3. SQL mode (SQLServer): Session status is stored in a dedicated database table managed by SQL Server.
. The NET status server mode and SQL mode can both be called the out-of-process session mode. When storing data, you need to serialize and store the data to an external repository. When reading and writing data, data deserialization is required to be copied to the local session dictionary. Therefore, the request performance is reduced by 15% (out-of-process) to 25% (SQL Server ). Note that this is just a rough estimate. However, in the out-of-process storage solution, the session status remains longer, making the application more powerful, because it can prevent Microsoft? Internet Information Service (IIS) and ASP. NET fail. By separating session states from applications, you can also easily extend existing applications to the Web Farm and Web Garden architectures. In addition, session states are stored in external processes, which fundamentally eliminates the risk of periodic data loss caused by process loops.