Shulou(Shulou.com)06/02 Report--

This article mainly introduces how to use HTTP conversation, the article is very detailed, has a certain reference value, interested friends must read it!

Best practice: browse for suggestions for implementing HTTP sessions.

Enable security integration for protecting HTTP sessions

The HTTP session is identified by the session identity. The session identity is a pseudo-random number generated at run time. Session hijacking is a known attack HTTP session that can be blocked when all requests over the network are forced through a secure connection (meaning HTTPS). However, not every configuration in the customer environment enforces this constraint because of the performance impact of the SSL connection. Because of this mitigation, HTTP sessions are vulnerable to hijacking attacks, and because of this weakness WebSphere Application Server has an option to tightly combine HTTP sessions with WebSphere Application Server security. Enable security in WebSphere Application Server so that sessions are protected in such a way that only the users who created them are allowed to access them.

Use javax.servlet.http.HttpSession.invalidate () to release the HttpSession object when you are done.

The HttpSession object lives in the Web container until:

The application uses the javax.servlet.http.HttpSession.invalidate method to explicitly and programmatically release it; frequent, programmatic invalidation is part of the application logout function.

When HttpSession expires (default = 1800 seconds or 30 minutes), WebSphere Application Server destroys the assigned HttpSession. Based on session management settings, WebSphere Application Server can only maintain a certain number of HTTP sessions in memory. In the case of distributed sessions, when the maximum cache limit is reached in memory, the session management tool removes the most recently used (LRU) session from the cache to make room for the session.

Avoid trying to save and reuse HttpSession objects outside of each servlet or JSP file.

The HttpSession object is a feature of HttpRequest (you can get it only through the req.getSession method), and its copy is valid only for the lifetime of the service method of the servlet or JSP file. You cannot cache a HttpSession object and reference it outside the scope of a servlet or JSP file.

Implement the java.io.Serializable interface when developing new objects to be stored in a HTTP session.

Serializability of classes is enabled by classes that implement the java.io.Serializable interface. Implementing the ava.io.Serializable interface allows objects to be serialized correctly when using distributed sessions. Classes that do not implement this interface do not serialize or de-serialize their state. Therefore, if the class does not implement the Serializable interface, JVM cannot maintain the state of the class to the database or to another JVM. All subtypes of a serializable class are serializable. Examples are as follows:

[object Object] [object Object]

Ensure that all instance variable objects that are not marked as transient are serializable. Unserializable objects cannot be cached.

In order to comply with the Java Servlet specification, when a distributed servlet container cannot support the mechanisms required to migrate sessions of stored objects, the container must create an IllegalArgumentException for those objects. An exception is created only if distributable is selected.

HTTPSession API does not publish the transactional behavior of the session.

Distributed HTTPSession support does not guarantee the transactional integrity of attributes in a failover scheme or when a session kinship is interrupted. Use transaction-aware resources, such as Enterprise Java Beans, to ensure the transactional integrity required by the application.

Make sure that the Java object you added to the session is in the correct classpath.

If you add Java objects to the session, put the class files for those objects in the correct classpath (application classpath if sharing across Web modules is used in enterprise applications, or Web module classpath if Servlet 2.2 compliant session sharing is used) or in a directory that includes other servlet used in WebSphere Application Server. In the case of a session cluster, this operation applies to each node in the cluster.

Because HttpSession objects are shared between servlet that users may access, consider site-wide naming conventions to avoid conflicts.

Avoid storing large object graphs in HttpSession objects.

In most applications, each servlet requires only a fraction of the total session data. However, by storing the data as a large object in the HttpSession object, the application forces WebSphere Application Server to process all the data each time.

Leverage session kinship to help you get a high cache hit rate in WebSphere Application Server.

WebSphere Application Server has the functionality of the HTTP Server plug-in that helps with session kinship. The plug-in reads cookie data (or encoded URL) from the browser and helps direct the request to the appropriate application or clone (based on the specified session key). This feature increases the use of in-memory caching and reduces hits to the database or another WebSphere Application Server instance.

Maximize the use of conversational kinship and avoid interrupting kinship.

Correct use of conversational kinship can enhance the performance of WebSphere Application Server. Session affinity in a WebSphere Application Server environment is a way to maximize the in-memory cache of session objects and reduce the number of reads to the database or another WebSphere Application Server instance. Session kinship works through a session object in the server instance of the cached application with which the user is interacting. If the application is deployed on multiple servers in the server group, the application can direct users to any of the servers. If the user starts at server1 and then enters server2 after a while, the server must write all session information to an external location so that the server instance (where server2 is running) can read the database. You can use session kinship to avoid database reading. With session kinship, the user will start on the server1 for the first request; then, for each subsequent request, the user will be directed back to server1. Server1 must only look at the cache to get session information; server1 never needs to call the session database to get that information.

You can improve performance by not interrupting the kinship of the session. Some suggestions to help you avoid interrupting your relationship are:

If possible, combine all Web applications into a single application server instance and use models or clones to provide failover support.

When using a multi-frame JSP file, a session is created for the frame page, but not for the page in the frame. (see a later discussion in this topic. )

When working with multi-frame pages, follow these guidelines:

Create a session only in one frame or before accessing any frameset. For example, suppose there is no session associated with the browser, and the user accesses the multi-frame JSP file, and the browser makes a concurrent request for the JSP file. Because the request is not part of any session, the JSP file ends the creation of multiple sessions, and all cookie are sent back to the browser. The browser only executes the last cookie that arrived. Therefore, only the client can retrieve the session associated with the last cookie. It is recommended that you create a session before accessing a multi-frame page that leverages JSP files.

By default, the JSP file uses the request.getSession (true) method to get HTTPSession. So by default, if there is no session for the client, the JSP file creates a new session. Each JSP page in the browser is requesting a new session, but there is only one session for each browser instance. Developers can use the

Turn off automatic session creation in JSP files that do not access this session. Then, if the page needs to access the session information, the developer can use it to get the existing session created by the original session creation JSP file. This action helps you prevent the session kinship on the initial loading of the frame page from being interrupted.

Use only one framework to update the session data. When using framesets, requests go to the HTTP server concurrently. Modify session data in only one framework so that session changes are not overwritten by session changes in the recommended concurrent frameset.

Avoid using multi-frame JSP files, where frames point to different Web applications. This action results in the loss of a session created by another Web application because the JSESSIONID cookie from the first Web application is overwritten by the JSESSIONID created by the second Web application.

When applying security to servlet or JSP files (using sessions with enabled security integration), protect all pages (not just some pages).

When it applies to security and sessions, it protects all pages or nothing. Therefore, it makes no sense for access to session state that needs to be protected part of the time. When security integration is enabled in the session management tool, all resources that create or access the session must be protected or unprotected. You cannot mix protected and unprotected resources.

The problem with protecting only a few pages is that sessions created in protected pages are created with the identity of authenticated users. Only the same user can access sessions on other protected pages. To protect these sessions from unauthorized users, you cannot access them from pages that have not been protected. When a request from an unprotected page occurs, access is denied and an UnauthorizedSessionRequestException error is created. UnauthorizedSessionRequestException is a run-time exception; it is logged for you. )

Use manual updates and sync () methods or write applications based on time (reading session data), but updates are rare.

END_OF_SERVICE is used when writing frequency, and the LastAccess time field is updated whenever the application uses a session and data is read or written from that session. If you use a database session, a new write to the database is generated. This activity is a performance hit, and you can avoid using the Manual Update option and write the record back to the database only when the data value is updated (not the read or write of each record).

To use manual updates, open it in the session management service. In addition, the application code must use the com.ibm.websphere.servlet.session.IBMSession class instead of the normal HttpSession. In the IBMSession object, there is a sync method. This method tells WebSphere Application Server to write the data in the session object to the database. This activity helps developers improve overall performance by keeping session information only when necessary.

Note: an alternative to using manual updates is to use time updates to maintain data at different intervals. This operation provides results similar to manual update scenarios.

Implement the following recommendations for high performance:

If the application does not change session data frequently, manual updates and sync functions (or scheduled updates) are used to effectively retain session information.

Keep the amount of data stored in the session as small as possible. Simply use the session to hold the data, because sometimes too much data is stored in the session object. Determine the correct balance between data storage and performance to use sessions effectively.

If you use a database session, use a dedicated database for the session database. Avoid using application databases. This can help you avoid contention for JDBC connections and allow for better database performance.

If you use memory-to-memory sessions, using partitions (groups or individual replicas) as your cluster increases size and shrinks.

Verify that you have the latest fix pack for WebSphere Application Server.

Use the following tools to help monitor session performance.

Run com.ibm.servlet.personalization.sessiontracking.IBMTrackerDebug servlet. -to run this servlet, you must run the servlet caller that you want to run in the Web application. Alternatively, you can explicitly configure this servlet in the application you want to run.

Use the WebSphere Application Server resource analyzer provided with WebSphere Application Server to monitor active sessions and statistics for the WebSphere Application Server environment.

Use database tracking tools such as "Monitoring" in DB2.

The above is all the content of the article "how to use HTTP conversation". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.