Session mechanism and related application of Session

The session is an important concept in web development, and in most Web applications the session is used as a ready-made object, but some of the more complex Web applications can be used in a session that does not meet the actual needs, When encountering such a situation we need to understand the mechanism of the session more deeply, this article will comb the next session of the relevant knowledge, for the design can replace the Web container comes with the session mechanism to play a foundation.

The concept of the 1.1 session

In computer jargon: A session is an interval of time between an end user and an interactive system, usually the time elapsed between registering into the system and the logoff system, and, if necessary, a certain amount of space to operate.

Specific to the Web application of the session, we have done web development, here I do not put forward the definition of the session in the Web, first and everyone to talk about the technical background and the session.

Early Web applications or early sites are a kind of static resources to deal with the site, the main function is to view the document, look at the picture, and now the Web application and early differences have been very large, the Internet site more accurate definition should be the Internet software is the website is software, The website represents the software and the definition of the early software is not the same, the early software is running in a single machine environment, and the popularity of the internet to the software and network technology integration, which requires that the website represents the software should have a memory function for transaction processing, transaction processing memory function is what we often say to have state. The core HTTP protocol to implement Web application technology is a stateless protocol, HTTP this design may be a legacy problem, perhaps stateless HTTP is the simplest and most effective means of communication, but when the site becomes software, the state of the maintenance is a very important function.

So in Web application development There is the technology to keep the HTTP link state: One is the cookie technology, the other is the session technology.

Cookie technology is a client-side solution (of course, with the advent of HTML5, more robust and secure technologies than cookies appear, but given the lack of popularity of HTML5, do not do the content discussed in this article), cookies are special information sent to the client by the server, This information is stored as a text file in the client, and then each time the client sends a request to the server, it brings the special information. Let's be more specific: When a user uses a browser to access a Web site that supports cookies, the user provides personal information including the user's name and submits it to the server, and the server sends back the personal information when it sends the corresponding hypertext to the client. Of course, this information is not stored in the HTTP response body (Response body), but is stored in the HTTP response header (Response header), when the client browser receives a response from the server, the browser will store this information in a unified location, For the Windows operating system, we can find the stored cookie from: [System disk]:\documents and settings\[user name]\cookies directory, and since then, when the client sends the request to the server, will send the corresponding cookie back to the server again. This time, the cookie information is stored in the HTTP request header. With the implementation of a technology such as cookies, when the server receives a request from the client's browser, it is able to generate the client-specific information by analyzing the cookie stored in the request header, which dynamically generates the content corresponding to that client. Usually, we can see the "Please remember Me" option from the login screen of many websites, if you check it and then log in, then the next time you visit the site will not need to repeat the cumbersome login action, and this feature is implemented through a cookie.

Session technology is the service-side solution, which is maintained through the server state. Since the term session contains a lot of semantics, it is necessary to clarify the meaning of the session here. First, we usually translate sessions into conversations, so we can refer to a series of interactions between the client browser and the server as a session. From this semantics, we will refer to the duration of the session, what is done during the session and so on, and second, the session refers to the server side for the client to open up the storage space, in which the information is used to hold the state. From this semantics, we will refer to what is stored in the session, how to get the matching content from the session according to the key value. To use the session, the first step is of course to create a session. So when is the session created? Of course, it is created in the process of running the server-side program, the different language implementation of the application has different methods to create the session, and in Java by calling HttpServletRequest's GetSession method (using True as a parameter) created. When the session is created, the server generates a unique session ID for the session, and the session ID is used to regain the session that was created in the subsequent request, and after the session is created, You can call the session related methods to add content to the session, which will only be saved in the server, sent to the client only session ID, when the client sends the request again, the session ID will be taken, Once the server accepts the request, it will find the corresponding session based on the session ID, which is used again. Formally, the state of the user is maintained.

From this we can conclude that the session is a service-side solution to solve the problem of stateless HTTP protocol, which can make a series of interaction between client and server become a complete transaction, which can make the website become a real software.

1.2 The relationship between a cookie and a session

Although the cookie and session scheme belong to the client and the server, but the implementation of the session of the server is dependent on the cookie of the client, I mentioned that the server will generate the session ID value when executing the session mechanism. This ID value is sent to the client, each time the client requests that the ID value will be sent to the HTTP request header to the server, and this ID value is stored in the client, the storage container is a cookie, so when we completely forbidden the browser's cookie, Server session will not be able to use the normal (note: Some data said ASP to solve this problem, when the browser cookie is banned, the server session can still be used normally, ASP I have not tried, but for many web sites with PHP and JSP written, I found that the ban on cookies, the site of the session is not normal access)

The principle of 1.3 session implementation

Java Web containers have implemented the session mechanism, the implementation of the logical ideas are consistent, but the specific scheme may be a certain difference, here I take the Tomcat container as an example, the next session to explore the implementation of the mechanism.

is the Tomcat source session implementation:

The path to implement the package is: Org.apache.catalina.session,tomcat external to provide a session call interface is not in this implementation package, the external interface is under the package Javax.servlet.http HttpSession, and implement the standards in the package Ession is a standard implementation provided by Tomcat, and of course external Tomcat does not want users to manipulate standardsession directly, but instead provides a Standardsessionfacade class, The component of the session in the Tomcat container is the servlet, and the servlet operation session is done through Standardsessionfacade, This prevents the programmer from directly manipulating the security issues that Standardsession brings. (Standardsessionfacade uses the façade (appearance) mode in design mode, which allows components of different logic layers to be decoupled).

The class with the manager in the implementation class is the tool class used to manage the session, which is responsible for creating and destroying the Session object, where Managerbase is the base class for all session management tool classes and is an abstract class. All classes that implement the session management function inherit this class, which has a protected method, which is the method of creating the SessionID value (the mechanism for the ID value generation of the session of Tomcat is a random number plus time plus the JVM ID value, The ID value of the JVM is calculated based on the server's hardware information, so the ID values of the different JVMs are unique, and the Standardmanager class is the default session management implementation class in the Tomcat container. It stores the session information in the memory of the server where the Web container resides. Persistentmanagerbase is also the inheriting Managerbase class, which is the base class for all persisted stored session information, Persistentmanager inherits Persistentmanagerbase, But this class is just a static variable and a GetName method, which does not seem to make sense at present, and for persistent storage Session,tomcat also provides Storebase abstract class, which is the base class for all persisted storage sessions. In addition Tomcat also gives the file storage Filestore and data storage Jdbcstore two implementations.

1.4 The problems brought by the session in the practical application

By the session implementation mechanism described above, we will find that in order to compensate for the stateless features of the HTTP protocol, the server consumes a certain amount of memory and CPU to store and process the session computation overhead. This is the low number of concurrent connections for Tomcat, the Web container (the default connection count in the Tomcat Official document is 200) one reason. Therefore, many Java language Web sites, in the production environment before the Web container will add a static resource server, such as: Apache server or Nginx server, static resource server does not solve the HTTP stateless problem function, Therefore, the server that deploys the static resources will not give up memory or CPU compute resources to deal with functions such as session, which can handle each HTTP request more efficiently, so the number of concurrent connections of the static resource server is higher. So we can make those requests that have no status to keep the request directly in the static server processing, and to carry out the status of the request is in the Java Web container processing, so as to better improve the efficiency of the site.

In order to improve the security and concurrency of the web site, the number of servers deployed on the server is usually greater than or equal to two units, and the services provided by multiple servers are equivalent, but there will certainly be different web containers on different servers. We know from the above that the implementation mechanism of the session is the internal mechanism of the Web container, which causes the ID value of the session generated in a Web container to be different, so when a request to a server, the browser gets a response, The client saves the ID of the session generated on the a server, and when another request is distributed to the B server, the Web container on Server B does not recognize the ID value of the session, nor does it have the corresponding recorded information for this sessionid. At this point, you need two different Web containers for session synchronization. The Tomcat container has an official solution that is to use the APACHE+TOMCAT+MOD_JK scheme, which broadcasts to another Web container when the information of the session in a Web container changes. When another Web receives a broadcast, it synchronizes the session information to its own container, which consumes system resources, and when traffic increases, it can seriously affect the efficiency and stability of the website.

I now do the site has a solution, when the user requests the site will first send the request to the hardware load balancer device, the device can intercept the client sent over the session ID value, and then we based on this ID value to find the server that generated the session, Send the request directly to this server. This solution seems to solve the session sharing problem, in fact, the result is the cluster system eventually changed back to a single point system, if the processing request of the Web container hangs, then the user's related session operation is discarded. In addition, this approach interferes with the load balancing calculation of the load Balancer server, so that the distribution of the request is not fair.

General large-scale Internet company's website is a separate channel composed of, for example, we often Baidu, Baidu search, Baidu Music, Baidu Encyclopedia and so on, I believe they will not give these different channels to a development team to complete, should each channel is an independent development team, Because each channel application is a standalone Web application, there is a cross-site session synchronization problem, cross-site logins can use a single sign-on (SSO) solution, but no matter what solution, cross-site session sharing is still a problem to avoid.

1.5 Technical solution to solve the session related problems

As mentioned above, there are two issues that need to be resolved in the session:

1) session storage should be independent of the Web container, but also independent of the server that deploys the Web container;

2) How to perform efficient session synchronization.

Before we talk about solving these problems, we should first consider how the next session is efficient, is there a memory, a file, or a database? Files and databases are stored in the session data is cured to the hard disk, the way to operate the hard disk is that the efficiency of the io,io operation is much lower than the operating memory of the data, so the file and database storage method is not desirable, so the session data stored in memory is the best choice. Therefore, the best solution is to use distributed cache technology, such as: Memcached and Redis, to separate the session information storage is also a way to solve the session synchronization problem.

Tomcat session synchronization also has the use of memcache solution, you can participate in the following article:

Http://blog.sina.com.cn/s/blog_5376c71901017bqx.html

But this solution only solves the synchronization problem, the session mechanism is still tightly coupled with the Web container, we need an efficient, scalable solution, then we should not simply separate the session to store, but design a completely independent session mechanism, It can provide each Web application with the function of session and can realize session synchronization, the following is a distributed session scheme implemented with zookeeper:

Http://www.open-open.com/lib/view/open1378556537303.html

Session mechanism and related application of Session