深入理解 Web 服务器、Servlet 容器与现代 Java Web 架构

前言

在 Java Web 开发中，我们经常听到诸如"Web 服务器"、"Servlet 容器"、"Undertow"、"Tomcat"等术语。对于初学者甚至有一定经验的开发者而言，这些概念容易混淆，尤其在当前前后端分离、微服务盛行的架构背景下，更易产生"是否还需要传统 Web 服务器""Servlet 是否过时"等疑问。

---

一、HTTP 请求的本质：一切始于协议

要理解 Web 服务器，首先要回到最底层：HTTP（HyperText Transfer Protocol）。

HTTP 是一种应用层协议，定义了客户端（如浏览器、移动端 App）与服务器之间如何交换信息。一个典型的 HTTP 请求包含：

• 请求方法（GET、POST 等）
• URL 路径（如 /api/users）
• 请求头（Headers，如 Content-Type、Authorization）
• 请求体（Body，如 JSON 数据）

而服务器的响应则包含：

• 状态码（200、404、500 等）
• 响应头
• 响应体（HTML、JSON、图片等任意内容）

关键点：HTTP 协议本身不关心响应体是 HTML 还是 JSON------它只负责传输字节流。因此，任何能接收 HTTP 请求并返回合法 HTTP 响应的程序，都可以称为"Web 服务器"。

---

二、Web 服务器（Web Server）：网络请求的第一道门

1. 定义

Web 服务器是指能够监听网络端口（如 80、443、8080），接收 HTTP 请求，并返回 HTTP 响应的软件程序。

2. 核心职责

• 监听 TCP 端口，建立连接
• 解析 HTTP 请求报文
• 根据请求路径查找资源（如静态文件）
• 生成并发送 HTTP 响应
• 处理连接管理、超时、Keep-Alive 等网络细节

3. 典型代表

• Nginx：高性能、轻量级，擅长静态资源服务、反向代理、负载均衡。
• Apache HTTP Server：功能丰富，模块化设计，历史悠久。
• Caddy：现代化、自动 HTTPS 支持。

⚠️ 注意：Nginx 和 Apache 本身不能直接运行 Java 代码。它们主要用于处理静态内容或作为反向代理将动态请求转发给后端应用服务器。

---

三、动态内容的需求催生 Servlet

早期 Web 主要以静态页面为主。但随着业务复杂度提升，人们需要根据用户身份、数据库状态等动态生成内容。例如：

• 显示当前登录用户信息
• 查询商品列表并渲染成 HTML
• 提供 RESTful API 返回 JSON 数据

在 Java 生态中，Servlet 技术规范（由 Jakarta EE，原 Java EE 制定）成为处理动态 Web 内容的标准方案。

1. 什么是 Servlet？

Servlet 是一个运行在服务器端的 Java 接口（javax.servlet.Servlet），用于扩展 Web 服务器的功能，处理客户端请求并生成动态响应。

开发者通过实现该接口（通常继承 HttpServlet）编写业务逻辑：

@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) 
            throws IOException {
        resp.setContentType("application/json;charset=utf-8");
        resp.getWriter().println("{\"message\": \"Hello from Servlet!\"}");
    }
}

2. Servlet 的特点

• 基于 Java，跨平台
• 生命周期由容器管理（init → service → destroy）
• 支持多线程并发处理
• 可访问 HTTP 请求/响应对象、Session、Cookie 等

✅ 重要澄清：Servlet 并不局限于生成 HTML 。它可以返回任意 MIME 类型的内容，包括 text/html、application/json、image/png 等。因此，在 REST API 场景下，Servlet 同样适用。

---

四、Servlet 容器：Servlet 的运行环境

Servlet 本身只是一个 Java 类，无法独立监听端口或解析 HTTP。它必须运行在一个托管环境 中------这就是 Servlet 容器（Servlet Container）。

1. 定义

Servlet 容器是实现了 Jakarta Servlet 规范的运行时环境，负责：

• 加载和初始化 Servlet 类
• 管理 Servlet 实例的生命周期
• 将 HTTP 请求映射到对应的 Servlet
• 调用 service() 方法处理请求
• 管理会话（Session）、安全、过滤器（Filter）、监听器（Listener）等

2. 常见 Servlet 容器

容器	特点
Apache Tomcat	最广泛使用的开源 Servlet 容器，支持完整 Servlet/JSP 规范
Eclipse Jetty	轻量、嵌入式友好，常用于测试和微服务
Undertow	Red Hat 开发，基于非阻塞 I/O，高性能、低内存占用
GlassFish	完整 Jakarta EE 应用服务器，包含 Servlet 容器及其他企业级组件

---

五、Web 容器：Web 服务器 + Servlet 容器的融合体

现代 Java Web 容器（如 Tomcat、Jetty、Undertow）已不再仅仅是"Servlet 容器"，它们同时具备完整的 Web 服务器功能。

1. 为什么能融合？

因为：

• 它们内置了 HTTP 协议解析器
• 能直接监听端口（如 8080）
• 能处理静态资源（HTML、CSS、JS）
• 能运行 Servlet 动态生成内容

因此，这类软件通常被称为 Web 容器（Web Container） 或 内嵌式 Web 服务器。

2. 在 Spring Boot 中的应用

Spring Boot 默认使用 内嵌式 Web 容器，无需外部部署：

<!-- 使用 Undertow 替代默认的 Tomcat -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

启动应用时，Spring Boot 会自动初始化 Undertow，监听配置的端口，并将所有请求交由 Spring MVC 的 DispatcherServlet 处理。

🔍 DispatcherServlet 是 Spring MVC 的核心，它本身就是一个标准的 Servlet，负责路由请求到对应的 @Controller 或 @RestController。

---

六、前后端分离架构下的角色分工

在现代 Web 开发中，前端（Vue/React/Angular）与后端（Spring Boot）通常完全解耦：

• 前端：负责 UI 渲染，通过 AJAX/Fetch 调用后端 API
• 后端：提供 RESTful 接口，返回 JSON 数据

这是否意味着"不再需要 Web 服务器"？答案是否定的。

1. 后端依然需要 Web 容器

即使只返回 JSON，后端仍需：

• 监听 8080 端口
• 解析 /api/users 这样的路径
• 验证 JWT Token
• 查询数据库
• 序列化对象为 JSON
• 设置 Content-Type: application/json

这一切都依赖于 Undertow/Tomcat 等 Web 容器提供的 HTTP 服务能力。

2. 前端通常由 Nginx 托管

生产环境中，常见架构如下：

用户浏览器
    │
    ├── 请求 /          → Nginx → 返回 index.html, app.js（静态资源）
    │
    └── 请求 /api/**    → Nginx → 代理到 http://backend:8080/api/**
                                 → Spring Boot (Undertow) → 返回 JSON

• Nginx：作为前端静态资源服务器 + 反向代理
• Undertow：作为后端 API 服务器（即 Web 服务器 + Servlet 容器）

两者各司其职，协同工作。

---

七、常见误解澄清

❌ 误解 1："返回 JSON 就不是 Web 服务器"

正解：Web 服务器的核心是处理 HTTP 请求/响应，与内容格式无关。返回 JSON 的 Spring Boot 应用，其内嵌的 Undertow 就是 Web 服务器。

❌ 误解 2："Servlet 只用于生成 HTML 页面"

正解 ：Servlet 是处理 HTTP 请求的通用机制。@RestController 本质仍是 Servlet 编程模型的高级封装。

❌ 误解 3："用了 Nginx 就不需要 Tomcat/Undertow"

正解：Nginx 无法执行 Java 代码。动态逻辑必须由后端 Web 容器处理。Nginx 通常只做代理和静态服务。

❌ 误解 4："Web 容器 = 应用服务器"

正解：

• Web 容器：仅支持 Servlet/JSP（如 Tomcat、Undertow）
• 应用服务器：支持完整 Jakarta EE 规范（如 EJB、JTA、JMS），如 WildFly、WebLogic

Spring Boot 应用通常只需 Web 容器。

---

八、Undertow 为何被称为"高性能异步 IO"？

Undertow 由 Red Hat 开发，设计目标是极致性能与灵活性：

• 基于 XNIO（扩展 NIO）：支持阻塞与非阻塞 I/O 混合模式
• 无共享状态架构：线程间无锁，适合高并发
• 灵活的 handler 链：可自定义处理流程，避免不必要的抽象开销
• 低内存占用：核心 JAR 仅数百 KB
• 支持 HTTP/2、WebSocket、ALPN 等现代协议

在基准测试中，Undertow 在高并发、小请求场景下通常优于 Tomcat 和 Jetty，尤其适合微服务 API 网关、实时通信等场景。

💡 注意：Undertow 不支持 JSP。若项目依赖 JSP，则必须使用 Tomcat 或 Jetty。

---

九、总结：现代 Java Web 架构全景图

组件	角色	是否必需
浏览器 / 移动端	HTTP 客户端	是
Nginx / CDN	静态资源分发、反向代理、SSL 终止	生产环境推荐
Spring Boot 应用	业务逻辑实现	是
内嵌 Web 容器（Undertow/Tomcat）	提供 HTTP 服务 + Servlet 运行环境	是（隐式存在）
Servlet（如 DispatcherServlet）	请求分发与处理中枢	是（框架内部使用）
Controller / Service	业务代码	是

🎯 核心结论 ：

无论你返回的是 HTML 还是 JSON，只要你的 Java 应用通过 HTTP 对外提供服务，就必然依赖 Web 服务器（即内嵌的 Web 容器） 和 Servlet 编程模型 。

Undertow、Tomcat 等不是"可选项"，而是现代 Java Web 应用的基础设施。