Understanding Tomcat Connectors
Understanding Tomcat Connectors
Connector elements are Tomcat's links to the outside world, allowing Catalina to receive requests, pass them to the correct web application, and send back the results through the Connector as dynamically generated content.
In this article, we'll learn how Tomcat uses Connectors in its element hierarchy, take a look at some basic syntax for configuring Connectors, and explain the uses of Tomcat's two Connector types: HTTP and AJP.
How A Connector Works
Each Connector element represents a port that Tomcat will listen to for requests. By arranging these Connector elements within hierarchies of Services and Engines, a Tomcat administrator is able to create a logical infrastructure for data to flow in and out of their site.
In addition to routing user-generated requests to the appropriate Services, connectors can also be used to link Tomcat to other supporting web technologies, such as an Apache web server, to efficiently balance the load of work across the network.
The Connector element only has one job - listening for requests, passing them on to an Engine, and returning the results to its specified port.
On its own, the Connector can't function - the only information this element contains is a port to listen on and talk to, and some attributes that tell it exactly how to listen and talk.
Information about what Server the specified port is located on, what Service the connector is a part of, and what Engine connections should be passed to is provided to the Connector by its location Tomcat's nested element hierarchy.
Tip: Tcat's live diagnostic feeds gives you fast, centralized insight into Connector performance across your entire Tomcat infrastructure. Download Tcat now.
Nesting Connector Elements
To learn how to nest an Connector to achieve the functionality you need, let's look at a simplified Tomcat server configuration:
<Server>
<Service>
<Connector port="8443"/>
<Connector port="8444"/>
<Engine>
<Host name="yourhostname">
<Context path="/webapp1"/>
<Context path="/webapp2"/>
</Host>
</Engine>
</Service>
</Server>
There are two Connector elements here, listening for connections on ports 8443 and 8444. It is important to note that an OS will only allow one connector on each port, so every connector you define will require its own unique port.
As you can see, both Connector elements are nested inside a single generic Service element, which is in turn contained within a single Server. This arrangement tells the Connectors to listen to their specified ports on their containing server, and to pass any connections only to the Engine belonging to their containing Service, which will process the requests and pass the results back to the Connectors.
Using the current arrangement, both Connectors will pass all requests to the same Engine, which will in turn pass all these requests to both of its contained web applications. This means that each request will potentially generate two responses, one from each application.
Now let's assume that we want to change this configuration, so that instead of receiving two responses for every request received by either Connector, we want each Connector to pass requests from its port only to one specific web application. To achieve this functionality, we simply need to rearrange the element hierarchy so that it resembles something like this:
<Server>
<Service name="Catalina">
<Connector port="8443"/>
<Engine>
<Host name="yourhostname">
<Context path="/webapp1"/>
</Host>
</Engine>
</Service>
<Service name="Catalina8444">
<Connector port="8444"/>
<Engine>
<Host name="yourhostname">
<Context path="/webapp2"/>
</Host>
</Engine>
</Service>
</Server>
Great! Now we have two different Services, with two different Connectors, passing connections from two different ports on the same Server to two different Engines for processing. Although obviously more complicated in real-world situations, all Tomcat Connector-related configuration builds upon these simple rules of element hierarchy.
Types of Connectors
There are two basic Connector types available in Tomcat - HTTP and AJP. Here's some information about how they differ from one another, and situations in which you might use them.
HTTP Connectors
Although Tomcat was primarily designed as a servlet container, part of what makes it so powerful is Catalina's ability to function as a stand-alone web server. This functionality is made possible by the HTTP Connector element.
This Connector element, which supports the HTTP/1.1 protocol, represents a single Connector component listening to a specific TCP port on a given Server for connections.
The HTTP Connector has many attributes that can be modified to specify exactly how it functions, and access functions such as proxy forwarding and redirects.
Two of the most important attributes of this Connector are the "protocol" and "SSLEnabled" attributes.
The "protocol" attribute, which defines the protocol the Connector will use to communicate, is set by default to HTTP/1.1, but can be modified to allow access to more specialized protocols. For example, if you wanted to expose the connectors low level socket properties for fine tuning, you could use the "protocol" attribute to enable the NIO protocol. Setting the "SSLEnabled" attribute to "true" causes the connector to use SSL handshake/encryption/decryption.
HTTP Connectors can also be used as part of a load balancing scheme, in conjunction with an HTTP load balancer that supports session stickiness, such as mod_proxy. However, as AJP tends to handle proxying better than HTTP, this usage is not common.
For an exhaustive overview of HTTP Connector attributes, consult the most recent Apache Tomcat Documentation site.
AJP Connectors
AJP Connectors work in the same way as HTTP Connectors, but they use the AJP protocol in place of HTTP. Apache JServ Protocol, or AJP, is an optimized binary version of HTTP that is typically used to allow Tomcat to communicate with an Apache web server. AJP Connectors are most commonly implemented in Tomcat through the plug-in technology mod_jk, a re-write of the defunct mod_jserv plug-in with extensive optimization, support for more protocols through the jk library, and Tomcat-specific functionality. The mod_jk binaries and extensive documentation are available on the Tomcat Connector project website.
This functionality is typically required in a high-traffic production situation, where Tomcat clusters are being run behind an Apache web server.
This allows the Apache server to deliver static content and proxy requests in order to balance request loads effectively across the network and let the Tomcat servers focus on delivering dynamic content.
Want to learn more? There are many detailed articles about fronting Tomcat with Apache, load balancing, and other AJP Connector related subjects available on Apache's Tomcat Documentation site
Connector elements are Tomcat's links to the outside world, allowing Catalina to receive requests, pass them to the correct web application, and send back the results through the Connector as dynamically generated content.
In this article, we'll learn how Tomcat uses Connectors in its element hierarchy, take a look at some basic syntax for configuring Connectors, and explain the uses of Tomcat's two Connector types: HTTP and AJP.
How A Connector Works
Each Connector element represents a port that Tomcat will listen to for requests. By arranging these Connector elements within hierarchies of Services and Engines, a Tomcat administrator is able to create a logical infrastructure for data to flow in and out of their site.
In addition to routing user-generated requests to the appropriate Services, connectors can also be used to link Tomcat to other supporting web technologies, such as an Apache web server, to efficiently balance the load of work across the network.
The Connector element only has one job - listening for requests, passing them on to an Engine, and returning the results to its specified port.
On its own, the Connector can't function - the only information this element contains is a port to listen on and talk to, and some attributes that tell it exactly how to listen and talk.
Information about what Server the specified port is located on, what Service the connector is a part of, and what Engine connections should be passed to is provided to the Connector by its location Tomcat's nested element hierarchy.
Tip: Tcat's live diagnostic feeds gives you fast, centralized insight into Connector performance across your entire Tomcat infrastructure. Download Tcat now.
Nesting Connector Elements
To learn how to nest an Connector to achieve the functionality you need, let's look at a simplified Tomcat server configuration:
<Server>
<Service>
<Connector port="8443"/>
<Connector port="8444"/>
<Engine>
<Host name="yourhostname">
<Context path="/webapp1"/>
<Context path="/webapp2"/>
</Host>
</Engine>
</Service>
</Server>
There are two Connector elements here, listening for connections on ports 8443 and 8444. It is important to note that an OS will only allow one connector on each port, so every connector you define will require its own unique port.
As you can see, both Connector elements are nested inside a single generic Service element, which is in turn contained within a single Server. This arrangement tells the Connectors to listen to their specified ports on their containing server, and to pass any connections only to the Engine belonging to their containing Service, which will process the requests and pass the results back to the Connectors.
Using the current arrangement, both Connectors will pass all requests to the same Engine, which will in turn pass all these requests to both of its contained web applications. This means that each request will potentially generate two responses, one from each application.
Now let's assume that we want to change this configuration, so that instead of receiving two responses for every request received by either Connector, we want each Connector to pass requests from its port only to one specific web application. To achieve this functionality, we simply need to rearrange the element hierarchy so that it resembles something like this:
<Server>
<Service name="Catalina">
<Connector port="8443"/>
<Engine>
<Host name="yourhostname">
<Context path="/webapp1"/>
</Host>
</Engine>
</Service>
<Service name="Catalina8444">
<Connector port="8444"/>
<Engine>
<Host name="yourhostname">
<Context path="/webapp2"/>
</Host>
</Engine>
</Service>
</Server>
Great! Now we have two different Services, with two different Connectors, passing connections from two different ports on the same Server to two different Engines for processing. Although obviously more complicated in real-world situations, all Tomcat Connector-related configuration builds upon these simple rules of element hierarchy.
Types of Connectors
There are two basic Connector types available in Tomcat - HTTP and AJP. Here's some information about how they differ from one another, and situations in which you might use them.
HTTP Connectors
Although Tomcat was primarily designed as a servlet container, part of what makes it so powerful is Catalina's ability to function as a stand-alone web server. This functionality is made possible by the HTTP Connector element.
This Connector element, which supports the HTTP/1.1 protocol, represents a single Connector component listening to a specific TCP port on a given Server for connections.
The HTTP Connector has many attributes that can be modified to specify exactly how it functions, and access functions such as proxy forwarding and redirects.
Two of the most important attributes of this Connector are the "protocol" and "SSLEnabled" attributes.
The "protocol" attribute, which defines the protocol the Connector will use to communicate, is set by default to HTTP/1.1, but can be modified to allow access to more specialized protocols. For example, if you wanted to expose the connectors low level socket properties for fine tuning, you could use the "protocol" attribute to enable the NIO protocol. Setting the "SSLEnabled" attribute to "true" causes the connector to use SSL handshake/encryption/decryption.
HTTP Connectors can also be used as part of a load balancing scheme, in conjunction with an HTTP load balancer that supports session stickiness, such as mod_proxy. However, as AJP tends to handle proxying better than HTTP, this usage is not common.
For an exhaustive overview of HTTP Connector attributes, consult the most recent Apache Tomcat Documentation site.
AJP Connectors
AJP Connectors work in the same way as HTTP Connectors, but they use the AJP protocol in place of HTTP. Apache JServ Protocol, or AJP, is an optimized binary version of HTTP that is typically used to allow Tomcat to communicate with an Apache web server. AJP Connectors are most commonly implemented in Tomcat through the plug-in technology mod_jk, a re-write of the defunct mod_jserv plug-in with extensive optimization, support for more protocols through the jk library, and Tomcat-specific functionality. The mod_jk binaries and extensive documentation are available on the Tomcat Connector project website.
This functionality is typically required in a high-traffic production situation, where Tomcat clusters are being run behind an Apache web server.
This allows the Apache server to deliver static content and proxy requests in order to balance request loads effectively across the network and let the Tomcat servers focus on delivering dynamic content.
Want to learn more? There are many detailed articles about fronting Tomcat with Apache, load balancing, and other AJP Connector related subjects available on Apache's Tomcat Documentation site
Comments
Post a Comment