在Java生态里，Tomcat这类Web容器看似神秘，但其最基础的通信模型完全可以靠JDK自带的网络包还原。我们只需要一个ServerSocket在指定端口阻塞等待，拿到客户端连接后，从Socket的输入流里按HTTP规范读取字符，做简单解析，再把构造好的响应写回输出流，一个能处理浏览器请求的微型服务器就跑起来了。这种方式不依赖任何第三方框架，适合用来理解HTTP协议与TCP传输之间的衔接关系。
ServerSocket监听与连接接收机制
ServerSocket是Java对TCP监听套接字的封装。它在构造时绑定本地端口，调用accept方法后线程会进入阻塞状态，直到操作系统接收到客户端的三次握手连接。每一个新连接都会返回一个独立的Socket对象，这个对象持有输入流与输出流，对应浏览器发来的请求数据和服务端要返回的响应数据。理解这一点很关键：Tomcat的接收器本质上也是不断调用类似的accept逻辑，再把Socket交给线程池处理。
在简易实现中，我们通常采用主线程accept、子线程处理请求的模式。如果不使用多线程，服务器一次只能服务一个浏览器，后续请求必须排队。下面是一个最基础的监听代码，它只做端口绑定和循环等待，把每个连接交给新线程执行，避免主线程被单个慢请求拖死。
import java.net.ServerSocket;
import java.net.Socket;
public class MiniServer {
public static void main(String[] args) throws Exception {
// 在8080端口启动TCP监听
ServerSocket server = new ServerSocket(8080);
System.out.println("迷你服务器已启动，监听8080");
while (true) {
// 阻塞等待浏览器连接
Socket client = server.accept();
// 每个连接交给独立线程处理
new Thread(new RequestHandler(client)).start();
}
}
}
上面的代码虽然简单，但暴露出几个工程上必须考虑的问题。首先是端口占用，如果8080已被其他程序绑定，构造ServerSocket会抛出BindException，实际项目里需要捕获并提示。其次是资源释放，客户端断开后如果没有关闭Socket，文件描述符会泄漏，长时间运行服务器会耗尽系统句柄。我们在处理器里应当用try-finally保证关闭。
HTTP报文解析：从字节流到请求对象
浏览器发来的数据严格遵守HTTP/1.1文本协议。最前面是请求行，例如GET /index.html HTTP/1.1，紧接着是若干请求头，每行以冒号分隔键值，头部结束由一个空行标志，如果有POST数据则空行之后是报文正文。我们在RequestHandler中通过BufferedReader按行读取，就能还原出这些方法、路径与参数。
需要注意，HTTP报文头必须是ASCII文本，但正文可能是表单、JSON或文件上传，编码方式由Content-Type头决定。简易服务器一般只处理GET和表单POST。解析时先读第一行拆出方法和URI，再循环读头直到空行，最后根据方法决定是否读取固定长度的body。下面代码展示了如何把一个Socket输入流转成可读的请求结构。
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.Socket;
import java.util.HashMap;
import java.util.Map;
public class HttpRequest {
public String method;
public String uri;
public Map<String, String> headers = new HashMap<>();
public String body;
public static HttpRequest parse(Socket socket) throws Exception {
BufferedReader reader = new BufferedReader(
new InputStreamReader(socket.getInputStream(), "UTF-8"));
// 读取请求行
String line = reader.readLine();
if (line == null) return null;
String[] parts = line.split(" ");
HttpRequest req = new HttpRequest();
req.method = parts[0];
req.uri = parts[1];
// 读取请求头
while ((line = reader.readLine()) != null && !line.isEmpty()) {
int idx = line.indexOf(":");
req.headers.put(line.substring(0, idx).trim(),
line.substring(idx + 1).trim());
}
// 若有正文则简单读取
if ("POST".equals(req.method)) {
req.body = reader.readLine();
}
return req;
}
}
这种解析方式在教学场景完全够用，但和真正Tomcat比还差得远。真实容器用字节缓冲区而非按行字符串，避免中文被错误截断；它还支持分块传输Transfer-Encoding: chunked、长连接复用以及超大header防御。我们的简易版只要能正确拿到URI和少量头，就能决定返回什么内容，这正是理解协议分层的好起点。
响应渲染：状态码、类型与内容写回
解析完请求，下一步是构造响应。HTTP响应同样以状态行开头，如HTTP/1.1 200 OK，然后是响应头，空行之后是正文。浏览器靠Content-Type决定如何渲染，例如text/html会解析成网页，application/json会展示纯文本。简易服务器常根据请求后缀映射类型，把本地文件或拼好的字符串写进OutputStream。
下面示例展示了如何返回一个固定HTML页面，并设置必要的头。注意输出时使用PrintWriter并指定UTF-8，否则中文容易变成乱码。写完后必须调用flush和close，否则浏览器会一直等待。若请求路径不存在，我们应当返回404状态和简单提示，而不是无声断开。
import java.io.OutputStream;
import java.io.PrintWriter;
import java.net.Socket;
public class ResponseWriter {
public static void writeHtml(Socket socket, String html) throws Exception {
OutputStream os = socket.getOutputStream();
PrintWriter writer = new PrintWriter(os, true);
writer.println("HTTP/1.1 200 OK");
writer.println("Content-Type: text/html;charset=UTF-8");
writer.println("Content-Length: " + html.getBytes("UTF-8").length);
writer.println();
writer.print(html);
writer.flush();
}
public static void write404(Socket socket) throws Exception {
OutputStream os = socket.getOutputStream();
PrintWriter writer = new PrintWriter(os, true);
writer.println("HTTP/1.1 404 Not Found");
writer.println("Content-Type: text/plain;charset=UTF-8");
writer.println();
writer.print("页面不存在");
writer.flush();
}
}
把前面三块拼起来，RequestHandler在子线程里先解析请求，再判断URI返回对应内容，一个模拟Tomcat的雏形就完成了。虽然它不支持Servlet规范、没有过滤器链，但已经能让我们看清：所谓Web服务器，不过是把Socket数据翻译成HTTP语义，再翻译成业务数据回写的过程。当你以后在Tomcat中配置Connector参数或排查请求超时，脑子里就会自然浮现出这层最朴素的读写模型。
ServerSocketHTTP报文解析Java_Web服务器修改时间：2026-08-15 07:12:15