Understanding Tomcat Connectors: Architecture, IO Models, and Nio/Nio2 Endpoints

Tomcat, the most widely used web container, consists of connectors and containers; connectors handle IO request conversion, network parsing, and request adaptation.

Tomcat Connector Structure and Principles

The connector receives browser requests, uses ProtocolHandler with EndPoint and Processor to parse and process IO, then adapts the request to a ServletRequest for the container.

The main functions of a Tomcat connector are:

Listening on network ports.

Receiving byte‑stream information of network requests.

Parsing the byte stream according to the protocol (HTTP/AJP) to create a Tomcat Request object.

Converting the Tomcat Request to a ServletRequest and passing it to the container.

Obtaining the container's ServletResponse and converting it back to a Tomcat Response.

Transforming the Tomcat Response into network byte streams and returning them to the client.

To achieve these functions, the connector relies on several components:

Endpoint : Listens on communication interfaces, abstracts the transport layer, and receives/sends network requests.

Acceptor : After the Endpoint receives a socket, the Acceptor monitors it; SocketProcessor implements Runnable and invokes the Processor.

Processor : Receives the socket from the Endpoint, parses it into a Tomcat Request, and hands it to the Adapter.

Adapter : Adapts requests/responses for different servlet containers, converting Tomcat Requests to ServletRequest and vice‑versa.

The article then introduces IO models and multiplexing, covering synchronous blocking IO, synchronous non‑blocking IO, and IO multiplexing (select/poll/epoll), using select as an example.

IO Model and Multiplexing

In multiplexing, a single select call can monitor multiple channels, allowing the process to perform other work while waiting for data readiness, improving efficiency compared to repeated reads.

NioEndpoint Component

NioEndpoint implements an IO multiplexing model and processes network requests through ten steps involving components such as LimitLatch , Acceptor , Poller , SocketProcessor , and Executor .

Network data arrives at the NIC and is copied to memory.

A receive queue stores the packets for NioEndpoint.

LimitLatch controls the maximum number of connections (default 10,000).

The Acceptor runs in a dedicated thread, accepting new connections and handing them to the Poller.

The Poller monitors channel readiness and creates a SocketProcessor task for ready channels.

The Executor thread pool runs the SocketProcessor , which invokes Http11Processor to read and parse the request.

Http11Processor forwards the request to the container and receives the response.

The response is sent back through the channel to the network.

AprEndpoint Component

AprEndpoint uses the Apache Portable Runtime (APR) native library via JNI to achieve non‑blocking IO multiplexing, suitable for scenarios with frequent OS interactions such as TLS‑encrypted traffic.

Nio2Endpoint Component

Nio2Endpoint differs from NioEndpoint by using asynchronous IO; it does not block the user process during data copying. The flow includes:

Data copied from NIC to memory and placed in a receive queue.

LimitLatch limits connections.

Asynchronous Acceptor receives connections as AsynchronousSocketChannel and wraps them in Nio2SocketWrapper .

Executor runs SocketProcessor , which calls Http11Processor to read/parse.

Http11Processor issues an asynchronous read, specifying a buffer and a completion handler.

When data is ready, the kernel copies it to the buffer and invokes the completion handler.

A new SocketProcessor processes the completed read, and the response is sent via the send queue.

Summary

The article first outlines Tomcat connector architecture, then focuses on the core Endpoint components and how they handle network IO, covering both NioEndpoint’s synchronous multiplexing and Nio2Endpoint’s asynchronous approach.