Analyze the operation principle of jetty

Previously wrote a simple article on the use of jetty, jetty for the Java Web Developer is not unfamiliar, he is a servlet container, but relatively simple design for Tomcat, but also relatively simple and flexible to use, I am learning and using openfire when contacting Jetty,openfire using jetty to develop its powerful management backstage.

In my recent project I also want to use jetty to develop a background management program, but the disadvantage of using jetty to develop a background management program is in the cluster environment, the cluster environment for the management of the background it is best to use tomcat such a separate deployment, easy to manage.

Start with the code to briefly introduce the jetty of the next few cores:

Core class: Org.mortbay.jetty.Server

Core interface: Org.mortbay.component.LifeCycle

Core thread pool encapsulation: Org.mortbay.thread.QueuedThreadPool

Core IO processing class: Org.mortbay.jetty.nio.SelectChannelConnector

Core servlet processing class: Org.mortbay.jetty.servlet.ServletHandler

Based on the debug trace for the source code, I drew a simple diagram of how the jetty HTTP request:

Figure 1--Jetty operation schematic diagram

I am debugging on Windows jetty, so there is no epoll, only the selector IO multiplexing model.

Here's a screenshot of my debugging:

Figure 2--Debug screenshot

Figure 2 to see the threading model from the bottom up.

It can be seen that although the thread that handles the connection request handles the specific request data is managed by Queuedthreadpool, this is a two completely different thread, in design mode this is actually the observer pattern, also called the Publish and subscribe mode. In NiO, the process is essentially event-driven, which means resting without incident.

The principle of jetty is based on NIO, and here's a simple selector io multiplexing idea:

1, the listener registers the type of event to be monitored in the manager;

2, when there are events registered in the manager, if there is a listener registered type of event, the manager will notify the event to the previously registered listener;

3, the listener removes the event from the manager and processes it as appropriate.

The reader is advised to understand the model of the observer, after all, his thinking is still very wide application.

There are two key tools in Jetty: A tool class that parses HTTP request data-Org.mortbay.jetty.HttpParser and the tool class used to generate the sound data: org.mortbay.jetty.HttpGenerator, read these two classes while understanding the HTTP protocol and servlet specification.

Because the bottom layer of HTTP is TCP/IP, here is an intuitive TCP connection, which is, of course, implemented using the socket:

This is my local browser connection test, you can see some of the connection-related parameters.

Of course, Jetty also supports HTTPS, as follows:

As with Tomcat, you need a security certificate, you can generate a certificate with JDK, and then test the jetty HTTPS connection, which later continues, interested in studying the next TLS, The recent SSL3.0 and OpenSSL are not safe, although TLS is standardized on the SSL3.0, but the SSL3.0 of TLS to modify the unreasonable, after all, standardization is still reliable.

About TLS: Apple announced its APNs to SSL3.0 closed, I took a closer look at the code in our project, the original we have been using TLS, can be seen how important standardization.