在写完[《Java 网络编程原理 - 应用程序是如何建立 TCP 连接并响应网络请求的？》](/post/162) 一文以后，也是了解了 Tomcat 的底层原理，同时掌握了网络通信的原理和各种序列化方式，我就想着如何自己实现一个 Tomcat web 容器呢？

核心功能是来接收浏览器的请求，同时根据请求过来的信息，进行路由到接口上进行数据处理，根据最后处理的数据结果进行响应。

![image.png](https://blog.liushigong.cn/static/img/e898809a571e63484a706b6451cd8abc.image.webp)

## 如何实现一个简单的 Tomcat Web 容器？

我得构架设计思路图如下，实现一个简单的 Web 容器：

![image.png](https://blog.liushigong.cn/static/img/4437266be9b15af0cae44c306145ec86.image.webp)

## 创建 BIO 模型的 Web 服务器

通过 main 方法进行启动，结合 `ServerSocket` 创建一个 TCP 服务器，监听 8080 端口，通过多线程处理多个客户端连接，当然也可以改用 NIO 模式，一个线程足以。

`handleClient` 方法中是对客户端的数据流进行读取和响应，通过输入流读取 HTTP 请求，封装成自定义的 `MyServletRequest` 请求对象。

```
java

/**
 * Web 服务器
 * 
 * @author Created by Liushigong on 2025-12-24
 */
public class WebTcpServer {

    /**
     * 服务器监听的端口
     */
    private static final int SERVER_PROT = 8080;

    /**
     * 线程池，用于处理客户端连接
     */
    private static final Executor executor = Executors.newFixedThreadPool(10);

    /**
     * 启动服务
     */
    public static void start() {
        // 创建服务器Socket
        ServerSocket serverSocket = null;
        try {
            serverSocket = new ServerSocket(SERVER_PROT);

            // 持续监听新的连接
            while (true) {
                // 阻塞，直到有客户端连接
                Socket clientSocket = serverSocket.accept();
                // 为每个客户端连接创建一个新的线程来处理，避免阻塞主线程
                executor.execute(() -> handleClient(clientSocket));
            }
        } catch (IOException e) {
            System.err.printf("服务器启动或运行异常: %s\n", e.getMessage());
        } finally {
            // 关闭服务器socket
            if (serverSocket != null && !serverSocket.isClosed()) {
                try {
                    serverSocket.close();
                    System.out.println("服务器已关闭。");
                } catch (IOException e) {
                    System.err.printf("关闭服务器socket时发生错误: %s\n", e.getMessage());
                }
            }
        }
    }

    private static void handleClient(Socket clientSocket) {
        try (
                // 使用 try-with-resources 确保流自动关闭
                BufferedReader in = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
                OutputStream clientOut = clientSocket.getOutputStream();
        ) {

            // 构建请求对象
            MyServletRequest request = new MyServletRequest();
            // 读取客户端消息
            String clientMessage;
            // 持续读取客户端消息
            while ((clientMessage = in.readLine()) != null) {
                // 解析请求成功后，返回响应
                if (parse(request, clientMessage)) {
                    // 调用请求接口
                    MyServletResponse response = MappingFactory.invoke(request);
                    // 发送HTTP响应头
                    clientOut.write(response.getResponseHeaders().getBytes(StandardCharsets.UTF_8));
                    // 发送响应体
                    clientOut.write(response.getResponseData());
                    clientOut.flush();
                    break;
                }
                ;
            }
        } catch (IOException e) {
            System.err.printf("处理客户端连接时发生错误: %s\n", e.getMessage());
        } finally {
            try {
                // 关闭客户端socket
                clientSocket.close();
            } catch (IOException e) {
                System.err.printf("关闭客户端socket时发生错误: %s\n", e.getMessage());
            }
        }
    }

    public static boolean parse(MyServletRequest request, String message) {
        // 当前线程的对象
        if (message.contains("GET") || message.contains("POST")) {
            String data = message.substring(message.indexOf("/"), message.indexOf(" HTTP/"));
            request.setPath(data);
        } else if (message.contains("Host")) {
            String data = message.substring(message.indexOf(" ") + 1);
            request.setHost(data);
        } else if (message.contains("sec-ch-ua-platform")) {
            String data = message.substring(message.indexOf("\"") + 1, message.lastIndexOf("\""));
            request.setPlatform(data);
        }
        // 遇到空行，表示HTTP头部结束
        return message.isEmpty();
    }

    public static void main(String[] args) {
        // 初始化控制器
        WebController.init();
        // 启动服务
        start();
    }

}
```

## 映射器工厂处理请求

映射器工厂中存储了 url 与控制器对象和方法的缓存信息，当数据流读取完成以后，根据请求路径从 Map 缓存中查找对应的 Servlet 进行反射调用，获取响应数据进行返回。

```
java

import java.lang.reflect.Method;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

/**
 * 映射器工厂
 *
 * @author Created by Liushigong on 2025-12-24
 */
public class MappingFactory {

    /**
     * url 与 方法映射
     */
    private static final Map<String, Method> mapping = new ConcurrentHashMap<>();

    /**
     * url 与 对象映射
     */
    private static final Map<String, Object> objectMap = new ConcurrentHashMap<>();

    /**
     * 注册映射关系
     *
     * @param path url
     * @param object 对象
     * @param method 方法
     */
    public static void register(String path, Object object, Method method) {
        mapping.put(path, method);
        objectMap.put(path, object);
    }

    public static Method get(String path) {
        return mapping.get(path);
    }

    /**
     * 调用方法
     *
     * @param request 请求信息
     * @return 响应信息
     */
    public static MyServletResponse invoke(MyServletRequest request) {
        // 请求信息
        MyServletResponse response = new MyServletResponse();
        if (request.getPath() == null) {
            response.setStatus(400);
            response.setBody("<html><body><h1>400 Bad Request</h1></body></html>");
        }
        else if (!objectMap.containsKey(request.getPath())) {
            response.setStatus(404);
            response.setBody("<html><body><h1>404 Not Found</h1></body></html>");
        }
        else {
            try {
                // 调用方法
                Object body = get(request.getPath()).invoke(objectMap.get(request.getPath()), request);
                response.setBody(String.valueOf(body));
            } catch (Exception e) {
                response.setStatus(500);
                response.setBody("<html><body><h1>500 Internal Server Error</h1></body></html>");
            }
        }
        return response;
    }
}
```

## 控制器的实现

定义 `@WebPath` 注解用来标识控制器的接口信息，此处在启动时直接调用 `init()` 初始化控制器的方法，到映射器工厂中进行缓存。

```
java

import cn.hutool.core.util.ReflectUtil;

import java.lang.reflect.Method;
import java.util.List;

/**
 * 自定义控制器
 *
 * @author Created by Liushigong on 2025-12-24
 */
public class WebController {

    @WebPath(path = "/test")
    public String test(MyServletRequest request) {
        return request.getPath() + " 调用成功，噢耶！";
    }

    @WebPath(path = "/test1")
    public String test1(MyServletRequest request) {
        return request.getPath() + " 调用成功，噢耶！";
    }

    @WebPath(path = "/test2")
    public String test2(MyServletRequest request) {
        return request.getPath() + " 调用成功，噢耶！";
    }

    @WebPath(path = "/test3")
    public String test3(MyServletRequest request) {
        throw new RuntimeException("测试异常");
    }

    /**
     * 初始化控制器
     */
    public static void init(){
        // 当前对象
        WebController webController = new WebController();
        // 获取所有带 @WebPath 注解的方法
        List<Method> publicMethods = ReflectUtil.getPublicMethods(WebController.class, method -> method.isAnnotationPresent(WebPath.class));
        for (Method method : publicMethods) {
            WebPath webPath = method.getAnnotation(WebPath.class);
            // 注册到映射器工厂
            MappingFactory.register(webPath.path(), webController, method);
        }
    }
}
```

自定义注解，用来标识接口信息

```
java

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD, ElementType.TYPE})
public @interface WebPath {

    /**
     * URL路径地址
     */
    String path();
}
```

自定义请求对象

```
java

@Data
public class MyServletRequest {

    /**
     * 请求路径
     */
    private String path;

    /**
     * 请求主机
     */
    private String host;

    /**
     * 请求平台
     */
    private String platform;
}
```

自定义的响应体对象

```
java

import lombok.Data;

import java.nio.charset.StandardCharsets;

/**
 * @author Created by Liushigong on 2025-12-24
 */
@Data
public class MyServletResponse {

    /**
     * 响应状态码
     */
    private int status = 200;

    /**
     * 响应体类型
     */
    private String contentType = "text/html;charset=UTF-8";

    /**
     * 响应体
     */
    private String body;

    /**
     * 获取响应体字节数组
     */
    public byte[] getResponseData() {
        return body.getBytes(StandardCharsets.UTF_8);
    }

    /**
     * 生成HTTP响应头
     */
    public String getResponseHeaders() {
        // 空行分隔头和体
        return "HTTP/1.1 " + status + " OK\r\n" +
                "Content-Type: " + contentType + "\r\n" +
                "Content-Length: " + getResponseData().length + "\r\n" +
                "Connection: close\r\n" +
                "\r\n";
    }
}
```

## 整体的测试效果

当页面上访问 <http://localhost:8080/test> 时，效果如下

![image.png](https://blog.liushigong.cn/static/img/4e54491f359239eb5c900750e865855f.image.webp)

访问 <http://localhost:8080/test3> 时，效果如下

![image.png](https://blog.liushigong.cn/static/img/9fce0e9698bf2db80a87c0eeef211316.image.webp)

访问 <http://localhost:8080/test4> 时，效果如下

![image.png](https://blog.liushigong.cn/static/img/0f0c1035941fcef6415669578ce0f5ad.image.webp)

短短几个类就能实现这么一个轻量级的web服务器，整体效果还是很不错的。

上述实现省略了 **Servlet 解析的过程**，直接通过 `WebController.init()` 进行的初始化，扩展性上我并没有做太多处理，这主要是因为当前我并没有交给 Spring IOC 容器管理 Bean 对象。

如果想要集成 Spring，可以依赖 `spring-context`、`spring-core` 等jar包，以下是启动IOC容器的方式：

```
java

// 启动 IOC 容器
ConfigurableApplicationContext applicationContext = new AnnotationConfigApplicationContext();
applicationContext.refresh();
```

将 Servlet 注册成 Bean 对象以后，可以结合 `BeanPostProcessor #postProcessAfterInitialization` 后置处理，自定义个 `@Controller` 一类的注解，用来标识是控制器，然后自动解析请求接口，进行映射器自动注册的操作，后续通过请求进行分发路由进行调用。

像接口的拦截器，参数解析器和结果响应处理器等都可以进行补充，有兴趣的小伙伴可以看下我画的 Spring MVC 的执行流程图，自行扩展实现。

![image.png](https://blog.liushigong.cn/static/img/17c25d33c11fb8c2c621bed17ec79e9e.image.webp)

Java 网络编程原理 - 如何实现一个简单的 Tomcat Web 容器？

Java 网络编程原理 - 应用程序是如何建立 TCP 连接并响应网络请求的？

在海底捞二面的时候，面试官问了我一个大文件流传输的问题，用的 IO 会有哪些，我回答了 `BIO`、`NIO` 的内容，后来复盘了一下，觉得对网络编程方面的知识内容没有掌握彻底，还得再接再厉啊。

从一个最常见的场景入手，来看下你掌握网络编程的深度: **“浏览器输入 `www.taobao.com` 回车之后发生了什么？”**，你是否能回答上来这个问题呢？今天我将由浅入深的探索网络编程的原理，从 `0-1` 的告诉你网络交互的全流程，同时将涉及的基础内容都整理出来，做复习之用。

![image.png](https://blog.liushigong.cn/static/img/c95703175272d87c242145ba028fc3c8.image.webp)

## 计算机网络的体系结构

计算机网络的体系结构是我们学习的重点，需要搭建自己的思维模型，掌握网络的结构模型。

### OSI 参考模型

国际标准化的开放系统互联参考模型，也就是我们常说的 **OSI 参考模型**，它通过分层结构，将计算机网络分为七层，分别是：`应用层 → 表示层 → 会话层 → 传输层 → 网络层 → 数据链路层 → 物理层`，每一层都有特定的功能。

![image.png](https://blog.liushigong.cn/static/img/6215e0ae2f3322f737607bd8677a388e.image.webp)

**应用层：**

应用层提供给用户网络服务，像文件传送、电子邮件、P2P应用等。

**表示层：**

表示层用于处理应用实体间交换数据的语法，其目的就是解决格式与数据表示的差别，从而为应用层提供一个统一的数据格式。

**会话层：**

会话层是指用户与用户的连接，通过在两台计算机之间建立、管理和终止通信来完成会话。

**传输层：**

传输层是端到端的层次，也是进程到进程的层次，数据的通信表面上看是在两台主机之间进行，实质上是发生在两个主机的进程之间。

为了防止传送途中报文的丢失，两个主机进程之间需要实现端到端控制。因为，传输层的功能主要包括 **复用/分解（区分发送和接收主机上的进程）**、**端到端的可靠数据传输**、连接控制、流量控制和拥塞控制机制等。

**网络层：**

网络层解决的核心问题是如何分组通过交换网络传送至目的主机，因此，网络层的主要功能是数据转发与路由。网络层会对进入交换网络的通信量加以控制，比避免通信量过大造成交换网络性能下降。同时，网络层也具备寻址功能，确保分组可以被正确传输到目的主机，例如 Internet 网络中的 IP 地址。

**数据链路层：**

数据链路层的主要功能是实现在相邻节点之间数据可靠有效的传输。为了实现有效的差错控制，采用了一种以 “帧” 为单位的数据块传输方式。

**物理层：**

物理层的主要功能是在传输介质上实现无结构比特流传输。

### TCP/IP 参考模型

因特网是全球覆盖范围最广、用户数量最多的互联网，采用了 TCP/IP 参考模型。这是一个四层协议的体系结构，依次是 `应用层 → 传输层 → 网络层 → 网络接口层`

![image.png](https://blog.liushigong.cn/static/img/978c7a5b7be97bfbcb2527704036e203.image.webp)

TCP/IP 体系结构相当于将 OSI 体系结构的会话层和表示层合并到了应用层，将物理层和数据链路层合并到了网络接口层。

![image.png](https://blog.liushigong.cn/static/img/b29967890160a6cb8cbeb0ec48d639cb.image.webp)

### 五层原理参考模型

TCP/IP 体系结构为了将不同的网络接口进行互联，其网络接口层并没有规定什么具体内容。然而，这对于我们学习计算机网络的完整体系而言，就会缺少一部分内容。因此，在学习计算机网络原理时往往采用折中的办法，也就是综合 OSI 参考模型喝 TCP/IP 参考模型的优点，采用一种五层原理参考模型，五层分别是：`应用层 → 传输层 → 网络层 → 数据链路层 → 物理层`。

三种参考模型的整体对比效果图如下：

![image.png](https://blog.liushigong.cn/static/img/e12076aa3cabac084e6f05a12089f4ae.image.webp)

## 因特网的体系结构

实际应用的网络中几乎没有按照 OSI 参考模型创建的。OSI 参考模型是一种理论体系结构，是国际标准；而五层参考模型则是适合教学上的参考模型；TCP/IP 参考模型则是我们因特网体系结构真正应用的模型。

### DNS 域名系统

用户在使用应用时，需要指定服务的IP地址和端口号，但是各种各样的 IP 地址让人望而生怯，所以就需要为服务主机起一个更容易读懂，有一定含义的名称，这就是域名的由来。

在使用网络应用时，在我们输入域名来指定访问的主机，单实际网络通信必须使用 IP 地址，如何将域名映射为协议使用的 IP 地址呢？ 这就是域名系统（Domain Name System, DNS）的任务。

在应用通信前先需要请求 DNS 应用，将域名映射为 IP 地址，这个过程叫做域名解析。DNS域名解析分为以下两种方式：

* 静态域名解析

> 静态域名解析是通过静态域名解析表进行的，即手动建立域名和IP地址之间的对应关系表，该表的作用可以将一些常用的域名放入表中。当DNS客户端需要域名所对应的IP地址时，即到静态域名解析表中去查找指定的域名，从而获得所对应的IP地址，提高域名解析的效率

* 动态域名解析

> 动态域名解析需要专用的域名解析服务器（DNS服务器）运行域名解析服务器程序，提供从域名到IP地址的映射关系，负责接收客户提出的域名解析请求。

为提高查询速度，在解析域名时，首先采用静态域名解析的方法，如果静态解析不成功，再采用动态域名解析的方法。

DNS解析过程 - 本地缓存查询

当用户在浏览器中输入域名时，首先检查本地缓存（如hosts文件、DNS客户端缓存）是否有该域名的记录，如果有则直接返回IP地址，hosts文件是我们最常用的手段，工作中经常对域名的绑定IP进行重定向。

### 统一资源定位符

统一资源定位符（Uniform Resource Locator, URL）就是访问网络地址获取文档资源的。一般格式由四部分组成：

```
text

<协议>://<主机>:<端口>/<路径>
```

访问的 `http://liushigong.cn` 域名，实际全路径为 `http://liushigong.cn:80/`，默认 80 端口是不展示的，此处的路径为根路径 /，此处协议为应用层的协议。

应用层的协议如下：

![image.png](https://blog.liushigong.cn/static/img/80623859070e2957f5b9847c43e55748.image.webp)

### 聊一聊 http 和 https

接下来我们来了解一下开发中最常用 http/https 应用层协议，它们是基于传输层 TCP 协议进行统一封装通信数据的。

HTTP 也就是超文本传输协议，从名称上看就能分析出，其本质就是一个文本传输的格式，也称为协议。当浏览器进程访问 URL 时会发起与 WEB 服务的连接，当连接建立完成后，会通过连接向 Web 服务发送 Http 协议的报文，而这个过程也分为2种连接方式：

**1）非持续连接方式**

HTTP/1.0 采用非持续连接方式，在每次浏览器进程的请求都要与服务器建立一次 TCP 连接，当收到响应后就立即关闭连接，总结来看就是使用 **短连接**，每个请求需重新建立 TCP 连接，导致高延迟

**2）持续连接方式**

HTTP/1.1 支持持续连接方式，相比于非持续连接方式，浏览器进程在请求没有响应以前，可以连续发送多个 HTTP 请求报文，这样等服务器响应一个个请求的报文后再关闭。其引入 **持久连接**（默认开启 keep-alive），允许在同一个 TCP 连接上复用多个请求，并支持管道化（多个请求可同时发送，无需等待响应）。

队头阻塞

HTTP/1.1 虽然连接复用，提高了性能，但同样存在了一些缺陷，其中最主要的就是 **队头阻塞(Head-Of-Line Blocking)**。

队头阻塞是指当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据。

针对队头阻塞：

1. 将同一页面的资源分散到不同域名下，提升连接上限。虽然能公用一个 TCP 管道，但是在一个管道中同一时刻只能处理一个请求，在当前的请求没有结束之前，其他的请求只能处于阻塞状态。
2. 减少请求数量
3. 内联一些资源：css、base64 图片等
4. 合并小文件减少资源数

HTTP/2.0 采用二进制 **分帧**、**多路复用** 和 **头部压缩** 以显著提升性能。它们的关联点在于都基于请求/响应模型，并逐步演进以解决前版本的性能瓶颈。

队头阻塞问题的解决

HTTP/2.0 是基于 SPDY 协议，允许在一个连接上无限制并发流。多路复用，就是在一个 TCP 连接中可以存在多个流。一个域名对应一个连接，一个流代表了一个完整的请求-响应过程。帧是最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。

TCP 为了保证可靠传输，有一个“超时重传”机制，丢失的包必须等待重传确认。HTTP2 出现丢包时，整个 TCP 都要等待重传，那么就会阻塞该 TCP 连接中的所有请求。

**总结对比**

| 特性 | HTTP/1.0 | HTTP/1.1 | HTTP/2.0 |
| --- | --- | --- | --- |
| 连接类型 | 短连接 | 持久连接 + 管道 | 多路复用（单一连接） |
| 数据格式 | 文本 | 文本 | 二进制分帧 |
| 头部传输 | 重复完整发送 | 重复完整发送 | 压缩（HPACK） |
| 服务器行为 | 被动响应 | 被动响应 | 支持主动推送 |
| 队头阻塞 | 存在（请求串行） | 部分解决（管道） | 彻底解决（流并行） |

HTTPS（HyperText Transfer Protocol Secure）是一种通过 SSL/TLS 协议实现加密传输的超文本传输协议，用于保障网络通信安全。它并非独立协议，而是 HTTP 与 SSL/TLS 的结合体，通过加密通信内容、验证服务器身份和检测数据篡改，防范窃听、中间人攻击等安全威胁。

任何网站都应使用 HTTPS，尤其是那些需要登录凭据的网站。在现代 Web 浏览器（例如 Chrome）中，未使用 HTTPS 的网站与使用 HTTPS 的网站的标记有所不同。URL 栏中如出现挂锁，则表示该网页是安全的。Web 浏览器非常重视 HTTPS；Google Chrome 和其他浏览器将所有非 HTTPS 网站标记为不安全。

![image.png](https://blog.liushigong.cn/static/img/88b965225acadf27e9e522a2643288f6.image.webp)

**HTTPS 如何工作？**

HTTPS 使用加密协议对通信进行加密。该协议称为传输层安全性 (TLS)，但以前称为安全套接字层 (SSL)。该协议通过使用所谓的 **非对称公钥基础架构** 来保护通信。这种类型的安全系统使用两个不同的密钥来加密两方之间的通信：

* 私钥 - 此密钥由网站所有者控制，并且如读者所推测的那样，它是私有的。此密钥位于 Web 服务器上，用于解密通过公钥加密的信息。
* 公钥 - 所有想要以安全方式与服务器交互的人都可以使用此密钥。用公钥加密的信息只能用私钥解密。

![image.png](https://blog.liushigong.cn/static/img/4a43c6ae462c2ba959031271d9aed71f.image.webp)

### TCP 传输层协议

TCP 是面向连接的传输层协议，应用程序在使用 TCP 之前，必须建立 TCP 连接。在数据传输完成后，必须释放已经建立的 TCP 连接。

TCP 提供双全工通信服务，即 TCP 允许通信双方的应用进程在任何时候都能发送数据和接收数据。TCP 为每块客户数据配上一个 TCP 首部，从而形成多个 TCP 报文段。这些报文段被交付给网络层，网络层将其分别封装在网络层 IP 数据报中，然后将这些 IP 数据报发送到网络中，最终到达目标主机。

![image.png](https://blog.liushigong.cn/static/img/bb3bed0d6a8e26cff34f4596dc26c9df.image.webp)

TCP 连接管理中包括对连接的建立与拆除。TCP 连接建立主要通过的是 “三次握手” 的过程。

![image.png](https://blog.liushigong.cn/static/img/0c0063a951c81effaef0fedc23afcde0.image.webp)

* 第一次握手：客户端向服务端请求建立连接，`SYN=1`（建立连接），`seq=x`（序列号），客户端进入 `SYN_SENT`（同步已发送）状态。
* 第二次握手：服务端向客户端返回确认并请求建立连接，`SYN=1`（建立连接），`ACK=1` （已收到），`ack=x+1`（确认号为收到的序列号加一），`seq=y`（序列号），服务端进入 `SYN_RCVD`（同步已接收）状态。
* 第三次握手：客户端向服务端发送确认报文，`ACK=1` （已收到），`ack=y+1`（确认号为收到的序列号加一），`seq=x+1`（序列号），三次握手完成以后，2个主机之间，就可以传输数据啦~

为什么不采用二次握手建立连接？而一定采用三次握手建立连接呢？

TCP 采用三次握手建立连接，是为了确保双方连接彼此都清楚对方状态，从而保证可靠、稳定的建立连接，有效预防过期失效的连接请求达到后，导致无效链接的建立。

因为网络存在数据丢失，第二次握手控制段可能丢失，这样会导致主动发起连接的一方由于没有收到第二次握手控制段，则无法建立连接，而接受连接建立的一方则认为连接已建立，从而出现无效链接。另外，还是为了防止已失效的 TCP 连接请求报文段突然有传送到了 TCP 服务器进程。

当数据传输完成后，两台主机需要通过四次会话断开连接，这个过程我们称为 “四次挥手”。

![image.png](https://blog.liushigong.cn/static/img/386be9c8ae67ead3f77064f0a856bfeb.image.webp)

* 第一次挥手：客户端向服务端请求断开连接，`FIN=1`（断开连接），`seq=u`（序列号），客户端进入 `FIN_WAIT_1`（终止等待1）状态。
* 第二次挥手：服务端向客户端返回确认报文，`ACK=1` （已收到），`ack=u+1`（确认号为收到的序列号加一），`seq=v`（序列号），服务端进入 `CLOSE_WAIT`（关闭等待）状态，客户端进入 `FIN_WAIT_2`（终止等待1）状态。
* 第三次挥手：服务端完成数据传输后，向客户端发送断开连接请求，`FIN=1`（断开连接），`ACK=1` （已收到），`ack=u+1`（确认号为收到的序列号加一），`seq=w`（序列号），服务端进入 `LAST_ACK`（最后确认）状态。
* 第四次挥手：客户端向服务端返回确认报文，`ACK=1` （已收到），`ack=w+1`（确认号为收到的序列号加一），`seq=u+1`（序列号），客户端进入 `TIME_WAIT`（时间等待）状态，服务端进入 `CLOSED`（关闭）状态。

客户端处于 `TIME_WAIT` 状态时，TCP 连接还未释放掉，等待 2个 MSL（Maximum Segment Lifetime，最大段生命周期）的时长后，客户端进入 `CLOSE` 状态。

### 网络层

当 TCP 连接建立以后，开始进行数据传输，自上而下，就到了网络层，网络层的主要任务就是将分组从源主机经过多个网络和多段链路传输到目的主机，可以将此任务划分为 **分组转发** 和 **路由选择** 两个功能，这里就不展开讲了，有兴趣的小伙伴可以自行学习。

在 TCP/IP 体系结构中，网络层的核心协议为 IP协议。在因特网当中，所有的异构网络的网络层都是使用了协议 IP，组成了IP网络，可以直接进行通信，无需关注寻址方案、路由选择协议等实现。

![image.png](https://blog.liushigong.cn/static/img/ced00d7a91c191c5380fc20274263cf7.image.webp)

### Web 服务进程

为了在不同的操作系统中区分不同的 PID 进程，采用端口号来标识和区分不同应用进程。端口号的长度为16比特，取值范围是 `0 ~ 65535`，分为两大类：

**服务端使用的端口号**

* 全球通用端口号：取值范围是 `0 ~ 1023`

![image.png](https://blog.liushigong.cn/static/img/ee8d76e082f003ea43dd26658bafd7d0.image.webp)

* 登记端口号：取值范围是 `1024 ~ 49151`

这类端口号是为没有熟知端口号应用程序使用的。

**客户端使用的短暂端口号**

这类端口号仅在客户端使用，由客户进程在运行时动态选择，又称为临时端口号，取值范围是 `49152 ~ 65535`

注意

端口号是为了标识计算机中的各应用进程，只具有本地意义，在不同计算机中使用相同端口号没有任何关系，相互独立

我们使用最多的 WEB 服务莫过于 Nginx，在通过 IP 找到服务器主机，又通过端口号定位到我们的 Web 服务以后，通过反向代理，指向了我们的应用进程。

## 浏览器输入 `www.taobao.com` 回车之后发生了什么？

从整体来看，在输入域名后，会根据 url 查看浏览器是否缓存了该页面，通过 DNS 查询本地 hosts 缓存，路由器缓存，ISP缓存和根域名服务器去查询对应的IP。

浏览器将请求数据封装为 HTTP 请求报文，通过 TCP 三次握手建立连接，在传输层将报文封装为报文段，在经过网关和路由器后发送给 Web 服务，也就是通过端口号定位，到了我们的应用上面。

对于淘宝来说，请求会先到 nginx 服务器上，然后 nginx 采用默认的轮询算法进行负载均衡，将请求的报文发送给 Servlet 容器。

Servlet 容器接收到请求之后会解析请求行，请求体，请求头，然后交给 MVC 处理，像我们最常用的 Spring MVC，通过 `DispatcherServlet` 接收到请求后，通过请求路径返回相应的拦截器和 `Controller`，也就是我们的 MVC 的执行流程。

当 `Controller` 接口执行完成以后，会产生 Response 对象进行响应报文数据，浏览器接收 response 先攻数据后， 解析 HTTP 响应报文的头部包含了状态码（Status-Code），并进行缓存和解码，最后浏览器渲染页面

下一章分析应用网络IO的处理

上述流程中是从浏览器出发，找到 Web 服务的过程，那我们 Web 服务是如何与 TCP 建立的连接呢？对于我们开发者来说，如何提高网络并发性能才是根本，接下来我将深入应用中去探索这一过程。

Java 网络编程原理 - 从输入域名到后端交互的全流程解析

今日面试时，面试官问到了 “三色标记法”，我得回答是根据垃圾回收的 可达性分析算法，在垃圾回收时进行的并发标记的处理，然后讲了实现思路，与G1垃圾回收器中采用 **原始快照** 解决的并发标记问题，说到其本质就是垃圾回收与应用运行时的一种并发处理，与 MVCC 并发事务类似，都是针对于并发下的处理。

其实我在这是进行的 **埋点**，希望面试官来问我 MVCC 机制，我接下打算结合日志体系如何保障事务 ACID 来吊打他，结果面试官转弯来问到那并发事务中，为什么不采用原始快照的形式解决呢？

![image.png](https://blog.liushigong.cn/static/img/9d5fbac1b27c166c0a7d3faaee903c7e.image.webp)

## 为什么 MySQL 没有采用三色标记法来解决并发问题？？

当遇到这个问题时，我的脑袋都是懵的，在我的理解当中，这俩个虽然解决的问题类似，但是 **内核不一样** 啊，像垃圾回收的并发标记，是针对与堆内存中的垃圾对象进行标记，而如何判断垃圾对象是通过可达性分析的算法，根据引用是否可达，也就是 `GC ROOTS` 的对象引用链进行标记处理的。

再来看 Mysql 中并发事务的处理，采用了 MVCC 机制，其底层是通过 `隐藏字段，rowId, 事务ID，回滚事务ID`,`undo log 回滚日志`,`Read View 读视图` 3部分组成，具体实现就不过多陈述了，可以查看我得文章 [《数据库 - 深入了解 Mysql 事务与并发控制》](/post/84)，MVCC 中是通过 `Read View` 控制了并发事务的可见性，保障了事务之间的隔离性。

两者对比，原始快照是在并发处理期间，存储对对象不可达的对象联，在并发标记完成后，根据当前不可达的对象链路基于原始的一致性快照重新标记的动作；MVCC 是通过存储事务的版本链进行的实现，接下来我将结合自己的了解与 AI 进行深度分析一下。

### 问题内核不同

三色标记法是用于垃圾回收的，解决的是内存中对象回收的问题，确保不被引用的对象被正确回收，同时允许用户线程并发运行。

MVCC 在数据库事务中，是为了保证数据的一致性、隔离性，思考的角度是多个事务并发读写时，如何保证 `ACID` 特性，为数据创建多个版本，每个事务看到一致的快照

### 并发问题的本质不同

在垃圾回收中，并发问题主要在于标记对象的同时，用户线程可能改变对象的引用关系，导致漏标或误标。三色标记法通过跟踪引用变化来保证标记正确。

在数据库事务中，并发问题主要在于 **多个事务对同一数据的读写冲突** ，需要解决 **脏读**、**不可重复读**、**幻读** 等问题。

MVCC通过版本控制来避免事务之间的直接冲突。

### 技术实现上的差异

三色标记法需要跟踪对象引用的变化，通常需要内存屏障（barrier）来捕获引用更新，这在垃圾回收器中是可行的，因为对象引用的更新是内存操作，可以由虚拟机监控。

在数据库中，数据的读写是通过事务进行的，数据库需要维护多个版本的数据，并决定每个事务应该看到哪个版本。这需要维护版本链，并根据事务的隔离级别和开始时间来选择版本。

### 持久化与一致性要求

垃圾回收关注的是内存管理，不需要考虑持久化，也不需要考虑多个操作之间的逻辑一致性（只关注对象是否被引用）。

数据库事务要求持久化，并且要求保证事务的原子性、一致性、隔离性和持久性（ACID）。MVCC 通过版本控制来实现隔离性，同时配合日志（如 `redo log`、`undo log`）来保证原子性和持久性。

### 个人的思考与总结

虽然 `三色标记法` 和 `MVCC` 都是处理并发问题的技术，但它们解决的问题领域和设计目标不同。

其中也存在相似之处，都是并发处理，都是基于快照，不同的是并发下解决的问题不同，所以思考维度不同，同样快照的实现也不同，三色标记的快照是整个内存的快照记录，而并发事务是针对于当前行数据的快照，而且还是个版本快照链路，为了异常是回滚事务使用。

提示

是的，并发事务下要思考回滚，还要思考 mysql 崩溃后的数据一致性问题，而 JVM 无需这些考虑

对于数据库系统，如果采用类似的三色标记法来处理并发事务，可能需要对每行数据的读写都进行跟踪，这可能会带来更大的开销，而且并不能直接解决事务隔离性问题。

总体来看，虽然三色标记法和MVCC都是处理并发问题的技术，但我们从解决问题的内核上，并发的要求上，持久化上，还有性能上对比来看，MySQL 采用 MVCC 来解决并发事务问题是最合适的。

面试记录 - MVCC 并发事务结合 JVM 并发标记的思考

在面试中回答过多次分库分表的问题以后，经过几次复盘，我对分库分表的内容已然掌握的炉火纯青，接下来我将根据实际的业务场景，系统性地总结分库分表的回答思路与个人思考的解决方案。

## 为什么分库分表？

在回答分库分表的问题以前，你是否清晰的了解到你们业务中分库分表的目的？需要以结果为导向，描述业务场景中遇到的问题，以及通过分库分表解决的是哪些问题。

![image.png](https://blog.liushigong.cn/static/img/479d75825969e47ce81095636a999fe5.image.webp)

首先我们需要描述下业务的背景，以及遇到的问题，例如我当前的业务场景如下：

> 我们主要是做光伏电站建设的，每个电站下会有 `1` 到 `2` 个逆变器，每个逆变器在光照后会进行发电的工作，每隔 `5分钟` 会传输一条发电量数据，一个逆变器平均每天产生 `120` 条发电量数据，一年可到到 `4w` 多条数据。
>
> 我们公司整体规划的目标是第一年建站 `2w`，第二年到 `10w` 个电站，由于电站的数量是一个持续增长的过程，很快我们的数据量达到几千万，查询电站下逆变器的发电量信息的性能急剧下降，为此我们采用了分库分表。

描述完场景，我们来引用下分库分表解决了哪些问题

> 分库分表主要解决了 mysql 读写分离下，写入的性能瓶颈问题，提高系统的吞吐量，同时也解决了单表下数据量存储过大，从而导致的查询性能缓慢的问题。基于我们的业务场景，此处也是为了解决海量数据存储的问题。

接下来结合业务场景，我们来考虑拆分的维度，以及分片数量的考量

> 分库分表的拆分维度主要分为垂直分库、垂直分表、水平分库、水平分表4个维度，根据我们的数据量上的预估，在3年内会达到 `百亿`，而一条数据占用 `1.6K` 左右，从数据量与内存占用的角度，我们拆分的维度为 `水平分库` 和 `水平分表`，拆分为 `8` 个库，每个库下 `128` 张表，每张表可平均存储千万数据。

分库分表后，我们需要结合业务来进行分片键的抉择

> 从业务模块的角度进行考虑，我们是展示的是电站分页信息，详情中展示所有逆变器信息，每个逆变器下展示近期的发电量折线图。整体关系为 `电站 1 → n 逆变器 1 → n 发电量`，基于此场景我们选择 `电站ID（psId）` 作为分库的分片键，选择 `逆变器ID（inveterId）` 作为分表的分片键，这样保证了查询同一电站下的逆变器数据在同一个数据库中，同一个逆变器的发电量数据都在同一个表当中，提升查询的效率。

选择了分片键，我们需要考虑如何将数据更均匀的分布到表中，如何选择分片的路由算法，与分片键组成 **分片策略**

> 其实分片算法有很多，其核心保障均分分配，防止数据倾斜问题。因此分表算法不需要太精密，太复杂，只需要能实现均分分配就行了。弄得太复杂的算法，反而肉眼无法识别，算不明白，这不是很麻烦么。
>
> 所以一般就是 `取模算法`，而我们的业务也是基于取模算法，对电站ID取模，对逆变器ID取模。

到这我们的业务场景已经描述清楚了，接下来就到了面试官的提问环节，大体的方向就是基于我们设计的方案实现，以及分库分表所带来的问题。

## 分库分表所带来的问题？

分库分表看似美好，其实也带来了很多的分布式问题。

![image.png](https://blog.liushigong.cn/static/img/6d3ed6d957a752c4add96eb62b35b4e7.image.webp)

接下来我将总结一下面试官可能会问到的问题。

**你们分库分表后是如何保证唯一性ID不重复的？**

> 分库分表以后，分布式序列ID就需要我们自行维护。默认有 UUID、雪花算法两种方案，UUID 基本我们就不考虑，毕竟不符合我们的B+树底层存储结构，也容易造成页分裂，索引碎片化等问题。常用的就是雪花算法，也可以自定义实现，例如结合 Leaf 的号段模式，实现自增的主键ID。
>
> 而我们此处采用的是数据库自增ID，根据我们的业务场景，此处的ID并不存在任何意义，所以使用默认的自增主键即可。

**采用取模算法，如果扩容是如何保障数据的均匀分布的**

> 取模算法是不支持动态伸缩的，所以说需要需要扩容，我们需要采用 `一致性哈希` 的算法作为路由算法，一致性哈希算法的实现原理就是通过一个 `0 - 2^32` 长度的哈希环，类似于循环数组，通过对物理节点进行哈希取模，映射到哈希环中，通过对分片键进行哈希取模，到哈希环中顺时针查找到物理节点，则为存储的节点，本质就是 `路由寻址` 的方式。通过扩容后新增物理节点映射到哈希环上，将部分指向物理节点的数据，改指向最近的新节点即可。

联想到 Redis Cluster 哈希槽

其实现本质也是 `一致性哈希算法`,通过对 Key 进行哈希取模，映射到哈希槽上，也是我们当前 Key 实际存储的节点。

**有没有遇到数据倾斜的问题？如何解决的**

> 对于数据分布不均的问题，`一致性哈希` 算法中，采用虚拟节点的形式，一个物理节点下有多个虚拟节点，映射到哈希中，分片键哈希取模映射到哈希环时，寻址找到虚拟节点时，最终会路由到屋里节点上。虚拟节点越多，数据分布的也更均匀。

**分库分表后，排序、遍历、分组、聚合等查询是如何实现的？**

> 像我们使用 ShardingJDBC 中，是通过 `执行引擎` 进行实现的，最核心的是 `归并引擎`， 从结构划分，可分为`流式归并`、`内存归并` 和 `装饰者归并`。像流式归并中，是逐条从结果集中获取正确的数据，遍历、排序以及流式分组都属于流式归并的一种。而内存归并，则是将所有数据加载到内存中，然后进行分组，聚合封装结果集进行返回。而装饰者归并是在流式归并和内存归并的基础上，进行统一的功能增强，主要有分页归并和聚合归并2种处理。
>
> 核心就是数据库的结果集是逐条返回的，无需一次性加载到内存中。

**分库分表后，分页的多条件查询如何实现？深度分页是如何处理的？**

> 分页的条件查询，基本分为2种实现，`简单查询` 和 `复杂查询`。
>
> 如果是简单查询，例如我们想根据订单号（一个订单号就是一个电站，也是一个psId）查询所有分片数据，可以采用基因法，在订单号的设计之初，携带上基因分子，这个基因分子可以是分片键也就是逆变器二进制的后7位（分表数量是128，2的7次方，取模128即可获取到路由表），也可以直接是取模数（后四位类似 0128），在通过订单号查询时，即可获取到分片表，进行直接路由查询。
>
> 如果是复杂查询，可以结合ES，构建复杂查询条件的 `索引结构`，包含主键的ID，在通过ES进行复杂条件查询后，返回其ID，然后通过ID直接查询数据库表即可。
>
> 对于深度分页，为了避免加载大量数据到内存中，我们采用 `select * from tablename where id > 999999 limit 10;` 的方式，结合ES深度分页，最佳方案也是通过 `Search After` 实现， 原理与上述sql类似，通过记录上个分页排序值，继续查找下一页的数据，但是此原理实现的方案有一个缺点，就是不允许跳页。

实现原理

分库分表中的实现也是通过 `执行引擎` 实现的，结构上采用 `装饰者归并`。

**跨库事务的一致性是如何保障的**

> 其实跨库的事务实现，也就是分布式事务的一种处理，ShardingJDBC 中提供了基于 `XA 协议的两阶段事务` 和
> 基于 `Seata 的柔性事务` 两种方式，其本质就是分布式事务中 `CP` 与 `AP + BASE` 的抉择。
>
> 开始描述分布式事务的内容，从CAP原理 + BASE理论，到 DTP 全局事务模型 与 XA 的两阶段提交，以及具体实现 2PC；再到最终一致性的各种实现方案。