A Tomcat <Connector> element's protocol attribute can be set to "HTTP/1.1", to org.apache.coyote.http11.Http11Nio2Protocol, or to the APR/native implementation. What do those choose between, and which would you deploy today?

## What the attribute actually selects The name is misleading. `protocol="HTTP/1.1"` looks like it declares an HTTP version, but what it really selects is which **Coyote connector implementation** — that is, which socket-handling strategy — Tomcat uses for this port. HTTP/2 is added separately, as an upgrade protocol nested inside the connector, not by changing this attribute. Historically there were four implementations: - **BIO** — one thread blocked per connection, for the connection's entire life. Removed in Tomcat 8.5. - **NIO** (`Http11NioProtocol`) — non-blocking Java sockets driven by a selector. This is what `HTTP/1.1` gives you on current Tomcat. - **NIO2** (`Http11Nio2Protocol`) — the same non-blocking idea expressed with the JDK's asynchronous channel API and completion handlers rather than an explicit selector loop. - **APR/native** (`Http11AprProtocol`) — socket and TLS handling pushed down into the C Apache Portable Runtime plus OpenSSL, via the tomcat-native library. Deprecated in Tomcat 10.1 and removed in Tomcat 11. ```xml <!-- default: NIO --> <Connector port="8080" protocol="HTTP/1.1"/> <!-- explicit NIO2 --> <Connector port="8080" protocol="org.apache.coyote.http11.Http11Nio2Protocol"/> ``` ## Why non-blocking mattered so much Under BIO, a connection and a thread were the same resource. A browser holding a keep-alive connection open for 60 seconds of thinking time owned a thread for those 60 seconds, so `maxThreads` was effectively a limit on *connected clients*, and a few thousand mostly-idle clients could park a server that was doing no work at all. NIO breaks that coupling. A small pool of acceptor and poller threads watches all sockets; a request-processing thread from the exec pool is taken only once a complete request is readable, and returned as soon as the response is written. That is the structural reason `maxConnections` defaults to 8192 while `maxThreads` defaults to 200 — the two are now measuring different things. It is also what makes long-polling and asynchronous servlets viable: a request suspended with `AsyncContext` holds no exec thread while it waits. ## NIO versus NIO2 in practice NIO2's promise is that the JDK, and beneath it the OS, drives completion rather than Tomcat polling readiness. On paper this can reduce syscalls; in practice benchmarks over the years have not shown a consistent, meaningful win for typical HTTP workloads, and NIO is the more heavily exercised path in the wild. Choosing NIO2 is defensible if you have measured your own workload and it wins; choosing it because it sounds newer is exactly the kind of unmeasured tuning an interviewer is probing for. ## The APR story, and what replaced it APR mattered for two reasons. First, in the BIO era it offered a genuinely different, event-driven socket model. Second, it did TLS with OpenSSL, which for a long time was substantially faster than the JVM's JSSE implementation and supported features JSSE lagged on. Both advantages eroded: NIO removed the I/O gap, and the JVM's TLS implementation improved considerably. What survived is the useful half. You can still run OpenSSL-backed TLS on the NIO or NIO2 connectors by installing tomcat-native and pointing the connector's SSL implementation at OpenSSL — the C library does the crypto, while the socket handling stays pure Java. So "we need APR for OpenSSL performance" has not been a reason to use the APR connector for several releases. ## What this means when you are asked to tune The practical upshot is that the connector implementation is almost never the lever worth pulling. If someone proposes switching implementations to fix a latency or throughput problem, the questions to ask first are what the exec threads are actually doing (a thread dump usually shows them blocked on a downstream dependency, not on I/O), whether `maxThreads` and `maxConnections` are sized for the traffic shape, and whether TLS handshake cost is being paid repeatedly because connections are not being reused. Changing `protocol` moves none of those numbers. One genuinely version-sensitive point is worth stating explicitly in an interview: because the APR connector was removed in Tomcat 11, an upgrade from an older release will fail to start if `server.xml` still names `Http11AprProtocol`. That is a real migration trap, and noticing it is more valuable than reciting the implementations.