Deployment – Neohope的网络笔记

深入浅出Jetty：功能、特性及核心实现

Posted on 2026/03/08 by neohope — No Comments ↓

深入浅出系列

深入浅出Jetty：功能、特性及核心实现

在Java Web服务器领域，Jetty始终以“轻量、灵活、高性能”的标签占据一席之地，无论是嵌入式部署场景，还是高并发生产环境，都能看到它的身影。不同于Tomcat的“重量级全能”，Jetty以模块化设计为核心，凭借优秀的架构设计和高效的算法支撑，成为微服务、嵌入式应用的首选服务器之一。本文将从Jetty的核心功能、显著特点入手，层层拆解其底层架构和核心算法，揭秘这些特性背后的技术支撑。

一、Jetty 核心功能：不止是Web服务器

Jetty本质上是一个开源的Java Web服务器和Servlet容器，由Eclipse Foundation维护，核心定位是“轻量且可扩展”，其功能覆盖了Web服务的全流程，同时兼顾灵活性和兼容性，具体可分为以下5类核心功能：

1. 基础Web服务功能

作为Web服务器，Jetty支持HTTP/1.1、HTTP/2、HTTPS等主流网络协议，能够监听端口、接收客户端请求、处理请求并返回响应，完美兼容Java EE规范，完整支持Servlet 3.1/4.0/5.0、JSP、WebSocket，可通过集成Jasper等引擎支持JavaServer Pages（JSP），能直接部署和运行Java Web应用程序、部署WAR包，满足常规Web应用的部署需求。

同时，它提供了完整的SSL/TLS配置支持，可通过代码或配置文件快速启用HTTPS，保障数据传输安全，还支持JAAS（Java认证和授权服务）和JNDI（Java命名和目录接口），进一步完善企业级应用的安全与命名服务需求。

此外，Jetty原生支持HTTP/2和WebSocket协议，能满足现代Web应用对低延迟和实时通信的需求，既可以高效提供静态文件服务，也能通过Servlet处理动态请求，实现静态与动态内容的高效处理，其中WebSocket服务器支持全双工通信，特别适用于实时应用场景；同时完美支持Server-Sent Events (SSE)，满足长连接通信需求。

2. 嵌入式部署功能

这是Jetty最具特色的功能之一，其轻量级和模块化的设计使其可以被直接嵌入到Java应用程序中，无需单独部署独立的Web服务器，为应用提供HTTP服务。仅需几行Java代码，就能快速启动一个完整的Web服务器，让应用程序自带Web服务能力，极大简化了部署流程，尤其适合桌面应用、微服务、自动化测试等场景。例如，Spring Boot早期版本默认使用Jetty作为嵌入式服务器，正是看中了它的轻量和便捷性。

3. 灵活的配置与扩展功能

Jetty支持多种配置方式，包括XML配置、Java代码配置、Maven/Gradle依赖配置等，默认配置即可满足大多数场景需求，同时允许开发者根据业务需求自定义配置，如线程池大小、连接器参数、日志级别等。此外，它的模块化设计让扩展变得简单，开发者可以按需加载功能模块，无需加载无关组件，比如不需要JSP支持时，可直接关闭JSP模块，进一步精简体积。同时，Jetty支持热部署与热重载功能，能够实现应用的热更新，极大便利了开发和调试工作，提升开发效率。

4. 监控与运维功能

Jetty内置JMX支持，可实时监控服务器的运行状态，包括线程池状态、连接数、请求处理耗时等关键指标，方便开发者进行性能排查和运维管理。同时，它支持自定义日志配置，可集成Logback、Log4j等主流日志框架，通过日志精准定位请求处理过程中的问题，此外还支持通过Admin Context进行可视化运维。

二、核心优势：轻量、高效、灵活

Jetty的功能之所以能灵活适配多种场景，核心在于其独特的设计特点，这些特点也决定了它与其他Web服务器（如Tomcat、Undertow）的差异，具体可总结为以下5点：

1. 轻量级，启动速度快

Jetty的核心JAR包仅约1MB大小，远小于Tomcat的核心体积，内存占用极低，核心库体积小、资源消耗低，非常适合微服务和云原生环境。同时，它的启动流程简洁，无需加载过多无关组件，启动时间可控制在几秒内，这对于开发测试、微服务部署等对启动速度有要求的场景至关重要——开发者在调试时可快速重启服务器，微服务集群可实现快速扩容和部署。此外，Jetty支持Docker、Kubernetes等容器化部署，采用无状态设计，具备极强的云原生友好性，适配云原生架构的部署需求。

2. 模块化设计，可按需扩展

Jetty的所有功能都以模块形式存在，基于OSGi的模块化设计，模块之间相互独立，支持按需加载，开发者可以根据需要选择和组合功能模块，避免资源浪费。例如，HTTP模块、WebSocket模块、JSP模块、SSL模块等均可独立启用或关闭，这种设计不仅让Jetty保持了轻量，还能灵活适配不同业务场景：嵌入式应用可只加载核心Web模块，而复杂Web应用可按需添加Servlet、Session等模块。Jetty的模块还支持依赖管理，比如HTTP模块依赖于服务器模块，服务器模块又依赖于线程池和日志模块，确保模块间的协同工作。

3. 高性能，支持高并发

Jetty基于非阻塞I/O模型和事件驱动机制，原生支持NIO/HTTP2/WebSocket异步处理，能够用更少的线程处理更多的客户端连接，相比传统BIO模型（一个连接对应一个线程），其并发处理能力大幅提升，可轻松应对数千甚至数万个并发连接，这也是其高并发与高性能的核心体现，能实现高性能与低延迟，适合高并发场景。同时，它支持Servlet 3.1+ 的异步处理模型，可有效提高请求吞吐量，再通过内存缓冲区复用、线程池优化等机制，进一步降低资源消耗，提升请求处理效率，适配高并发Web应用场景。

4. 嵌入式友好，集成性强

Jetty的设计初衷就是支持嵌入式部署，其API简洁易用，开发者可通过少量代码快速集成到Java应用中，无需修改应用本身的逻辑，易于嵌入与扩展。同时，Jetty通过Handler机制方便地进行功能扩展，满足不同业务的定制化需求。除了Spring Boot，Hadoop、Eclipse IDE等知名项目也集成了Jetty：Hadoop的NameNode和JobTracker通过Jetty呈现管理页面，Eclipse IDE则利用Jetty提供内置Web服务支持。

5. 兼容性强，适配广泛

Jetty全面兼容Java EE规范，支持最新的Servlet版本，同时兼容HTTP/1.1、HTTP/2、WebSocket等主流协议，可无缝部署各类Java Web应用。此外，它支持多种操作系统（Windows、Linux、Mac）和JDK版本，适配不同的部署环境，无论是开发测试环境还是生产环境，都能稳定运行。

三、核心架构

Jetty的所有功能和特点，都依赖于其简洁而强大的核心架构。不同于Tomcat的“Service-Connector-Container”三层架构，Jetty的架构更加轻量化，核心由“Server-Connector-Handler”三大组件构成，再配合线程池、缓冲区池等辅助组件，形成一个高效、可扩展的整体架构，其核心架构体系包含整体分层设计和核心组件架构，可概括为“一个核心、两大组件、三大辅助”。

1. 核心组件：Server（服务器实例）

Server是Jetty的核心调度中心，作为顶层容器和生命周期管理器，负责管理整个服务器的生命周期（启动、停止、重启），协调Connector、Handler、线程池等所有其他组件的启动、运行和停止，统筹管理所有组件的工作。它就像一个“总指挥”，接收Connector传递的请求，将请求分发到Handler链进行处理，同时管理线程资源和组件依赖。

Server的核心职责包括：初始化所有组件、启动Connector和Handler、管理全局线程池、处理组件间的协同逻辑。开发者通过Server实例可配置端口、线程池、SSL等核心参数，也可添加多个Connector和Handler，实现多端口监听和多请求处理逻辑。

2. 核心组件：Connector（连接器）

Connector是Jetty与客户端交互的“门户”，作为网络接口，负责处理网络连接、监听端口、接受客户端连接，并将请求分发给处理线程。它基于Java NIO实现，核心抽象接口包括`Connector`、`EndPoint`、`Connection`，通过SelectorManager管理网络事件，并将连接抽象为Connection对象进行协议解析，将客户端请求封装后传递给Handler链，同时将Handler处理后的响应返回给客户端。Jetty支持多种Connector类型，适配不同的协议和I/O模型，包括NIO、HTTP/2、SSL等连接器，具体实现类如下：

A. ServerConnector：标准NIO连接器，默认的HTTP/1.1连接器，基于Java NIO实现，支持非阻塞I/O，是最常用的连接器；

B. HTTP2ServerConnector：支持HTTP/2协议，适用于高并发、低延迟的场景，对应HTTP2ServerConnection实现；

C. SslConnector：提供HTTPS支持，封装了SSL/TLS加密逻辑，对应SslConnection实现，保障数据传输安全；

D. HttpConnection：专门负责HTTP/1.1协议的解析和处理，是HTTP/1.1请求的核心处理组件；

E. HTTP2ServerConnector：支持HTTP/2协议，适用于高并发、低延迟的场景；

F. SslConnector：提供HTTPS支持，封装了SSL/TLS加密逻辑，保障数据传输安全。

Connector的内部结构进一步拆分，通过Acceptor、SelectorManager、Connection三个子组件协同工作：Acceptor负责阻塞接受客户端连接，将连接设置为非阻塞模式后交给SelectorManager；SelectorManager管理多个Selector，通过多路复用监听I/O事件；Connection则封装应用层协议差异，处理请求和响应的数据读写。

3. 核心组件：Handler（处理器）

Handler是Jetty处理请求的核心逻辑载体，负责对客户端请求进行具体处理（如安全验证、会话管理、Servlet调用等），其链式架构是Jetty架构的核心，采用职责链模式（Chain of Responsibility）设计，核心接口为`Handler.handle(Request, Response)`，通过一系列Handler处理请求（如ServletHandler、ResourceHandler），这种架构的优势在于灵活可配置，易于定制处理逻辑，实现组件可插拔，具备极高的扩展性。与Tomcat的Container不同，Jetty的Handler采用“链式结构”（Handler Chain），本质是责任链模式的实现，多个Handler可以嵌套组合，请求会依次经过链中的每个Handler，每个Handler专注于单一职责，实现解耦。

Handler的关键实现类丰富，可根据业务需求灵活组合，常见类型包括：

A. ServletHandler：管理Servlet映射和调用，是Servlet容器功能的核心实现；
B. HandlerCollection：顺序执行多个Handler，实现多逻辑组合处理；
C. HandlerList：顺序执行多个Handler，直到某个Handler返回true即停止执行；
D. ContextHandlerCollection：基于请求路径的上下文路由，实现多Web应用的路径隔离；
E. WebAppContext：负责完整Web应用的生命周期管理，适配标准Web应用部署；
F. SessionHandler：处理用户会话，管理会话的创建、销毁和存储；
G. SecurityHandler：负责安全验证，如用户认证、权限控制等；
H. ContextHandler：处理请求的上下文路径，管理Web应用的上下文配置；
I. ResourceHandler：处理静态资源（如HTML、CSS、JS文件）的请求。

开发者可以自定义Handler，添加到Handler链中，实现自定义的请求处理逻辑，这种设计让Jetty的扩展变得异常灵活。

4. 辅助组件：线程池、缓冲区池、选择器（完善线程模型架构）

除了三大核心组件，Jetty的架构还包含三个关键辅助组件，它们是保障高性能和轻量性的重要支撑，其中ThreadPool是核心辅助组件之一，Jetty的线程模型架构分工明确，具体分为三类线程，配合线程池实现高效调度：

A. 线程池（QueuedThreadPool）：即Worker线程池，与Server和Connector集成，负责提供工作线程来执行具体的业务逻辑，将I/O事件处理与业务处理分离，避免阻塞，其核心作用是管理处理请求的线程，优化线程创建和销毁带来的性能开销。Jetty采用全局共享的线程池，所有Connector和Handler共享线程资源，相比Tomcat每个Connector独立线程池的设计，更能提高线程利用率，减少资源浪费。线程池通过任务队列管理请求任务，支持工作窃取算法和优先级队列，实现线程池动态伸缩，优化线程调度效率；

B. Acceptor线程：专门负责监听端口、接受客户端连接，默认配置1-2个线程，避免过多线程阻塞在连接接受环节；

C. Selector线程：负责管理NIO Channel的I/O事件，默认配置数量与CPU核数一致，通过多路复用机制高效监听多个连接的I/O状态，确保I/O事件的快速响应；

D. 缓冲区池（ByteBufferPool）：负责复用ByteBuffer，减少内存分配和垃圾回收（GC）压力，通过桶式内存分配算法，根据缓冲区大小进行分类管理，实现高效复用；

E. 选择器（Selector）：基于Java NIO的Selector机制，实现I/O多路复用，让单个线程可以监听多个客户端连接的I/O事件，大幅提升并发处理能力，这也是NIO Selector机制的核心作用——单线程处理大量连接，减少线程上下文切换开销；

F. 缓冲区池（ByteBufferPool）：负责复用ByteBuffer，减少内存分配和垃圾回收（GC）压力，通过桶式内存分配算法，根据缓冲区大小进行分类管理，实现高效复用；

G. 选择器（Selector）：基于Java NIO的Selector机制，实现I/O多路复用，让单个线程可以监听多个客户端连接的I/O事件，大幅提升并发处理能力，这也是NIO Selector机制的核心作用——单线程处理大量连接，减少线程上下文切换开销；

5. 架构交互流程

Jetty的核心组件交互流程简洁清晰，可概括为以下步骤：

A. 客户端发送请求，Connector的Acceptor接受连接，将连接设置为非阻塞模式后交给SelectorManager；

B. SelectorManager通过Selector监听连接的I/O事件，当有数据可读时，由Connection组件读取请求数据并封装为HttpChannel；

C. HttpChannel将请求传递给Server，Server将请求分发到Handler链；

D. 请求依次经过Handler链中的各个Handler（如SecurityHandler、SessionHandler、ServletHandler），最终由ServletHandler调用具体的Servlet处理请求；

E. 处理完成后，响应数据通过HttpChannel写回Connector，由Connector返回给客户端。

四、核心算法：支撑高性能与灵活性的底层动力

如果说架构是Jetty的“骨架”，那么核心算法就是Jetty的“肌肉”，它支撑着Jetty的高性能、高并发和轻量性。Jetty的核心算法主要集中在I/O处理、线程调度、内存管理和请求解析四个方面，每一种算法都针对性地解决了Web服务器的核心痛点。

1. I/O多路复用算法（Reactor模式）

Jetty基于Java NIO的Selector机制，实现了Reactor模式，这是其高并发能力的核心支撑。Reactor模式在Connector中实现，通过一个或多个线程（Reactor）利用Selector多路复用器来监听和分发大量连接的网络事件（如可读、可写），是实现高并发的基础。Reactor模式通过一个“反应器”（SelectorManager）监听多个I/O事件，当事件触发时（如客户端连接、数据可读），反应器将事件分发给对应的处理器（Connection）处理，实现“单线程监听、多线程处理”的高效模式。

具体来说，SelectorManager管理多个ManagedSelector（实际的Selector实例），每个ManagedSelector负责监听一部分客户端连接的I/O事件。当Acceptor接受一个新连接后，会选择一个ManagedSelector，将连接注册到该Selector上，并绑定对应的EndPoint和Connection。Selector通过select()方法阻塞监听事件，当有事件发生时，遍历触发的SelectionKey，交由Connection处理数据读写。这种算法让单个线程可以管理数千个客户端连接，大幅降低线程资源消耗，提升并发处理能力。

同时，非阻塞I/O（NIO）贯穿于网络通信的始终，无论是Connector接收请求还是Handler处理响应，都使用非阻塞的方式，确保线程不会被I/O操作长时间占用，这正是NIO Selector机制的核心应用，通过单线程处理大量连接，减少线程上下文切换开销。

此外，Jetty还采用Eat What You Kill线程消费模式，让接受连接的线程直接处理请求，进一步减少线程上下文切换；同时通过Produce Consume生产者-消费者模式，分离I/O读取和业务处理，提升处理效率；在SSL处理上，采用异步TLS握手，避免阻塞Selector线程，优化SSL连接性能。

2. 线程调度算法（工作窃取算法）

Jetty的QueuedThreadPool采用工作窃取（Work-Stealing）算法，优化线程调度效率，避免线程空闲和任务堆积。线程池内部维护一个任务队列（BlockingQueue），当工作线程完成自身任务后，会主动从其他线程的任务队列中“窃取”任务执行，而不是一直空闲等待。

这种算法的优势在于，能够平衡各个线程的任务负载，避免某些线程任务堆积而其他线程空闲的情况，尤其适合高并发场景下的任务调度。同时，QueuedThreadPool支持配置最小线程数、最大线程数和空闲超时时间，可根据请求量动态调整线程数量，进一步优化资源利用率——请求量小时，减少线程数量降低内存消耗；请求量高时，增加线程数量提升处理能力。

3. 内存管理算法（桶式内存分配+缓冲区复用）

为了减少内存分配和GC压力，Jetty采用ByteBufferPool管理内存缓冲区，核心算法是桶式内存分配和缓冲区复用，同时结合零拷贝优化技术——通过使用ByteBufferPool池化技术复用直接内存（Direct Buffer），数据可以直接在用户空间和内核空间之间传输，减少了内存拷贝和垃圾回收（GC）压力，这也是ByteBufferPool池化技术的核心价值。ByteBufferPool是核心接口，主要实现类包括ArrayByteBufferPool（基于数组的池化实现，轻量高效），同时支持MappedByteBuffer（大文件内存映射，实现零拷贝传输）；此外，DefaultServlet通过sendfile系统调用传输静态文件，进一步实现零拷贝优化，提升静态资源传输性能。ByteBufferPool将缓冲区按照大小分为不同的“桶”（如1KB、2KB、4KB等），每个桶对应一个缓冲区队列，当需要使用缓冲区时，从对应大小的桶中获取空闲缓冲区；使用完成后，将缓冲区归还给对应的桶，实现复用。

这种算法避免了频繁创建和销毁ByteBuffer带来的内存开销和GC压力，同时通过ConcurrentBucketMap数据结构管理不同大小的桶，确保缓冲区的高效获取和归还。此外，缓冲区复用机制还能减少内存碎片，提升内存使用效率，这也是Jetty内存占用低的重要原因之一。

4. 请求解析算法（确定有限状态机DFA）

Jetty的HttpParser组件负责解析HTTP请求报文，核心采用确定有限状态机（DFA）算法，实现高效的增量解析——HTTP报文解析器（HttpParser）采用增量解析的方式，能够高效地处理不完整或流式的HTTP数据，提升了协议解析的性能。HTTP请求报文的结构具有固定的格式（如请求行、请求头、请求体），DFA算法通过定义不同的状态（如解析请求行、解析请求头、解析请求体），根据输入的字符流切换状态，逐步完成请求解析。

相比传统的字符串匹配算法，DFA算法的解析效率更高，能够快速识别请求报文的各个部分，同时支持增量解析——无需等待整个请求报文接收完成，即可逐步解析已接收的部分，减少请求处理延迟。这种算法确保了Jetty在高并发场景下，能够快速处理大量HTTP请求，提升整体响应速度。

五、总结：Jetty的核心竞争力与适用场景

Jetty之所以能在众多Web服务器中脱颖而出，核心在于其“轻量、灵活、高性能”的平衡——模块化架构让它能够按需扩展，适配不同场景；非阻塞I/O和高效算法让它在高并发场景下表现优异；嵌入式设计让它能够轻松集成到各类Java应用中。Jetty通过其高效的NIO架构、灵活的Handler链和优化的资源管理（线程、缓冲池），在保持轻量级的同时提供了企业级的Web服务能力，特别适合微服务架构和云原生环境。

从底层逻辑来看，Jetty的功能和特点是相互支撑的：轻量级源于模块化设计和内存优化算法；高性能源于Reactor模式、工作窃取算法和DFA解析算法；灵活性源于Handler链式结构和可插拔模块。这些架构和算法的有机结合，让Jetty成为嵌入式应用、微服务、高并发Web应用的理想选择。

如果你的项目需要快速启动、低内存占用，或者需要嵌入式部署、高并发处理能力，那么Jetty无疑是一个值得深入学习和使用的Web服务器。深入理解其核心架构和算法，不仅能帮助我们更好地使用Jetty，还能为我们设计高性能的Web应用提供思路和借鉴。

如果觉得这篇文章对你有帮助，欢迎点赞、收藏，也可以在评论区留言，聊聊你在使用Jetty时遇到的问题～

深入浅出Nginx：功能、特性及核心实现

Posted on 2026/03/08 by neohope — No Comments ↓

深入浅出系列

深入浅出Nginx：功能、特性及核心实现

Nginx 是一款高性能的 HTTP 和反向代理服务器，以其高并发、低内存消耗和高稳定性著称，广泛应用于互联网架构的流量入口、负载分发等场景，同时支持多种现代协议与云原生集成，是企业级架构的核心组件。本文介绍了Nginx的功能、特点及其核心架构与算法。

一、核心功能

Nginx 的核心功能围绕“流量处理、分发与优化”展开，覆盖从客户端请求接收到底层服务响应的全链路，兼顾性能、安全性与扩展性：

1. Web服务器

A. 静态资源服务：直接托管 HTML、CSS、JS、图片、视频等静态文件，支持目录索引、文件权限控制、路径别名配置。

B. 索引和自动索引：支持手动配置索引页面，也可开启自动索引功能，方便查看目录下的文件列表。

C. 缓存加速：包含静态文件缓存、FastCGI缓存、代理缓存三大类，可灵活配置缓存策略，减轻后端压力。

D. 大文件传输优化：借助 sendfile 零拷贝机制、TCP_NOPUSH 和 TCP_NODELAY 选项，提升大文件传输效率，减少延迟。

E. 补充特性：支持 Range 分片传输（断点续传）、Gzip/Brotli 压缩、静态资源缓存策略（如 expires 头设置），大幅提升静态资源加载速度，降低带宽消耗。

2. 反向代理 (Reverse Proxy)

A. HTTP/HTTPS反向代理：作为客户端与后端应用服务器（如 Tomcat、Node.js、PHP-FPM）的中间层，接收客户端所有请求，转发至对应后端服务，再将后端响应回传给客户端。

B. 负载均衡：集成多种负载均衡算法，实现流量的合理分发（详情见“负载均衡”模块）。

C. SSL/TLS终端（SSL termination）：集中处理 HTTPS 协议的 SSL/TLS 加密与解密操作，后端服务器仅需处理明文 HTTP 请求，无需承担加密解密的 CPU 开销。

D. WebSocket代理：支持 WebSocket 长连接代理，实现客户端与后端服务的双向实时通信（如聊天、实时通知等场景）；同时支持 gRPC 代理，适配微服务架构下的远程调用场景。

E. 补充特性：隐藏后端服务器真实 IP 和部署结构，提升系统安全性；支持请求/响应头改写、URL 重写，适配后端服务路径调整；支持多层代理嵌套，灵活适配复杂架构。

3. 负载均衡 (Load Balancing)

A. 协议支持：支持 HTTP、TCP、UDP 三种协议的负载均衡，可适配 Web 服务、数据库、Redis、RPC 等多种后端服务。

B. 健康检查：包含主动健康检查（定期探测后端服务器状态）和被动健康检查（根据请求响应状态判断），自动剔除故障节点、恢复正常节点。

C. 会话保持（Session Persistence）：通过 IP 哈希等算法，确保同一客户端的请求固定分配到同一后端服务器，解决 Session 共享问题。

D. 动态配置：借助 upstream zone 共享内存，实现负载均衡后端节点的动态配置，无需重启服务即可更新节点信息。

E. 补充特性：支持会话保持（配合 IP 哈希等算法），保障用户连续访问体验；可配置备份服务器，当所有主节点故障时，自动切换至备份节点。

4. 缓存系统

A. 代理缓存（Proxy Cache）：缓存后端服务的响应结果（如接口返回数据、动态页面渲染结果），后续相同请求可直接从 Nginx 缓存返回，无需请求后端。

B. FastCGI缓存：专门针对 FastCGI 协议（如 PHP 服务）的缓存机制，优化动态页面的访问速度。

C. 缓存失效策略：支持基于时间的过期失效、主动清理等策略，同时支持缓存切片（Cache Slicing），提升大文件缓存的效率。

D. 补充特性：支持内存缓存与磁盘缓存结合，可配置缓存过期时间、缓存清理策略；支持按 URL、请求头、Cookie 等维度精准缓存，同时支持缓存命中统计，便于优化缓存策略。

5. SSL/TLS功能

A. SNI（Server Name Indication）支持：可在同一 IP 和端口下部署多个 HTTPS 域名，实现多域名共享证书或独立证书部署。

B. OCSP Stapling（在线证书状态协议装订）：减少 HTTPS 握手延迟，避免客户端查询证书状态时的额外网络请求。

C. SSL会话复用（Session Reuse）：复用已建立的 SSL 会话，减少握手开销，提升 HTTPS 访问速度。

D. 动态证书加载：NGINX Plus（商业版本）支持无需重启服务，动态加载新的 SSL 证书，提升运维效率。

E. 补充特性：支持 SSL/TLS 协议版本控制、加密套件配置；支持证书自动续期、多证书管理，适配多域名 HTTPS 部署。

6. 其他关键功能

A. 协议支持：支持 HTTP/2、HTTP/3（QUIC）协议，提升网络传输效率，适配现代浏览器与应用场景。

B. 压缩功能：支持 gzip、brotli 两种主流压缩算法，压缩响应内容，降低带宽消耗，提升加载速度。

C. 访问控制：支持 IP 黑白名单、Basic Auth 基础认证，限制非法访问，提升服务安全性。

D. 速率限制（Rate Limiting）：通过漏桶、令牌桶等算法，限制单位时间内的请求数，防止突发流量冲垮后端服务。

E. 重写引擎（Rewrite Module）：支持 URL 重写、路径跳转，适配业务路由调整、SEO 优化等场景。

F. 日志系统：包含 Access Log（访问日志）和 Error Log（错误日志），可配置日志格式，便于问题排查与流量分析。

二、核心架构

Nginx 的高性能和高稳定性，源于其“简洁、高效、可扩展”的底层架构设计，核心围绕进程管理、事件处理和模块化设计展开，同时适配云原生场景的扩展需求：

1. Master-Worker 多进程架构

A. Master Process（管理进程）：负责读取并解析 Nginx 配置文件（nginx.conf），验证配置合法性；管理端口绑定、Worker 进程生命周期（启动、停止、重启、平滑升级）；接收外部信号（如 reload、stop），并同步给所有 Worker 进程；不处理任何网络请求，仅负责管理协调。

B. Worker Processes（工作进程）：实际处理客户端的网络事件（连接建立、请求接收、响应返回）和业务逻辑（静态资源读取、反向代理、缓存查询等）；多个 Worker 进程平等竞争客户端连接，进程间相互独立，无共享资源，避免锁竞争。

C. Cache Manager（缓存管理进程）：负责管理缓存文件的元数据，执行缓存过期清理策略，确保缓存资源合理利用。

D. Cache Loader（缓存加载进程）：Nginx 启动时，将磁盘上的缓存数据加载到内存索引中，提升缓存查询效率。

其中，Master 进程为单进程，占用资源极少，是 Nginx 服务的“大脑”；Worker 进程数量通常配置为等于或略大于 CPU 核心数，充分利用多核 CPU 资源。

2. 事件驱动架构 (Event-Driven)

A. 单线程事件循环：每个 Worker 进程运行一个单线程事件循环，避免多线程上下文切换开销，提升资源利用率。

B. 非阻塞 I/O：所有网络操作均为非阻塞模式，当 Worker 进程处理 I/O 操作（如读取磁盘文件、转发请求到后端）时，若操作未就绪，不会阻塞进程，而是立即返回，继续处理其他就绪事件。

C. Reactor模式：使用 I/O 多路复用技术集中管理连接事件，基于“事件通知-回调处理”的逻辑，实现一个线程处理多个连接。

D. 底层实现：Linux 系统下使用 epoll 机制，FreeBSD/Mac 系统下使用 kqueue 机制，Solaris 系统下使用 /dev/poll 机制，Windows 系统下使用 IOCP 完成端口机制，均为高效的 I/O 多路复用机制。

3. 进程模型细节

A. CPU亲和性：Worker 进程可绑定到特定 CPU 核心，减少 CPU 缓存失效，提升处理效率。

B. 惊群效应避免：通过 `SO_REUSEPORT` 选项或互斥锁机制，确保只有一个 Worker 进程处理新连接，避免多个进程同时竞争连接导致的资源浪费。

C. 优雅重启：支持零停机配置重载（执行 nginx -s reload）和二进制升级，Master 进程加载新配置或新二进制文件后，逐步替换旧 Worker 进程，确保业务零中断。

三、核心算法与机制

Nginx 的各项功能和特性，均依赖底层高效算法的支撑，核心算法围绕事件处理、负载分发、内存管理和连接处理展开，兼顾效率与公平性：

1. I/O多路复用算法

不同操作系统的实现机制
A. Linux：epoll 机制，支持边缘触发（ET）和水平触发（LT），时间复杂度 O(1)，可高效处理大量连接。
B. FreeBSD/macOS：kqueue 机制，高效事件通知机制，适配 BSD 系列系统的特性。
C. Windows：IOCP（完成端口）机制，适合 Windows 系统下的高并发场景。

关键机制
A. epoll事件循环：通过 `epoll_wait()` 系统调用监控文件描述符状态，当事件就绪时，触发回调函数处理，无需轮询所有连接。
B. 连接状态机：每个连接在 `ngx_connection_t` 结构中维护自身状态（如连接建立、数据读取、数据发送、连接关闭），确保连接处理的有序性。

2. 负载均衡算法

常用算法说明及适用场景

A. Round Robin（轮询）：默认算法，按时间顺序依次分配请求，支持权重配置；适用于服务器性能均衡、请求处理时间相近的场景。

B. Least Connections（最少连接）：实时统计每台后端服务器的当前活跃连接数，将新请求分配给连接数最少的服务器；适用于长连接应用、请求处理时间差异大的场景。

C. IP Hash（IP哈希）：基于客户端 IP 地址进行 CRC32 哈希计算，根据哈希结果分配固定后端服务器；适用于需要会话保持、无共享 Session 的场景。

D. Generic Hash（自定义Key哈希）：基于自定义 Key（如 URI、请求头）进行哈希分配；适用于缓存服务器、特定业务路由场景。

E. Least Time (Plus)（最低响应时间）：结合最低平均响应时间和最少连接数分配请求；仅 NGINX Plus 支持，适用于对延迟敏感的应用。

F. Random (Plus)（随机选择）：随机选择后端服务器，可结合 Two Choices 策略优化；仅 NGINX Plus 支持，适用于大规模分布式环境。

一致性哈希

A. 支持 Ketama 一致性哈希算法（通过 `hash … consistent` 配置），当后端服务器集群扩容或缩容时，可最小化缓存失效范围，减少业务影响。

3. 内存管理算法

A. 内存池（Pool）：Nginx 启动时，预先分配一大块内存（内存池），请求处理过程中，从内存池中申请所需内存，请求处理完成后，统一释放整个内存池（或部分内存块），避免频繁调用 malloc/free 系统调用，减少内存碎片和系统开销。

B. Slab分配器：用于共享内存（如 upstream zone）的管理，高效管理固定大小的内存对象，提升内存利用率。

C. 数据结构：使用链表与红黑树，分别用于定时器管理、缓存索引等场景，确保高效的增删改查操作。

D. 补充说明：内存池分为全局内存池和请求级内存池，请求级内存池随请求结束而释放，资源管理更高效；共享内存由 Master 进程创建，所有 Worker 进程可读写，通过信号量实现进程间同步。

4. 哈希算法
A. CRC32：主要用于 IP Hash 和 Generic Hash 的计算，确保哈希结果的均匀性。
B. MurmurHash：用于 Nginx 内部部分哈希表的计算，具有高效、低碰撞的特点。

5. 连接处理算法
A. 监听套接字共享：所有 Worker 进程共享监听端口，通过内核负载均衡（SO_REUSEPORT）或互斥锁分配新连接，确保连接分配的均匀性。
B. accept队列管理：处理 SYN 队列和 Accept 队列的连接，避免队列溢出，确保新连接能够及时被处理。
C. HTTP流水线解析：采用增量式 HTTP 请求解析方式，边接收数据边解析，降低请求处理延迟。

四、关键设计特点

Nginx 的设计始终围绕“高性能、高可用、高灵活”三大目标，核心设计特点贴合企业级生产场景需求：

1. 高性能设计

A. 零拷贝：通过 `sendfile()` 系统调用，直接在内核态完成“磁盘 → 内核缓冲区 → 网卡”的数据传输，跳过用户态拷贝，减少 CPU 拷贝次数，提升传输效率。

B. 单线程Worker：每个 Worker 进程为单线程，消除多线程上下文切换开销，单个 Worker 可处理数万并发连接。

C. 内存效率：每个连接仅占用 100KB-1MB 内存，高并发场景下内存占用依然可控，远低于传统 Web 服务器。

2. 模块化架构

A. 核心模块：包含事件模块、HTTP 模块、Mail 模块、Stream 模块，负责 Nginx 的基础功能支撑。

B. 动态模块：支持将功能模块编译为动态 so 文件，运行时加载或卸载，无需重启服务，提升运维灵活性。

C. 第三方模块生态：拥有丰富的第三方模块（如 Lua 模块 OpenResty、Headers More 模块、WAF 模块 ngx_waf），可灵活扩展网关、限流、监控等功能，适配不同业务场景。

3. 配置系统

A. 声明式配置：采用层次化配置结构（main、events、http、server、location），结构清晰，易于理解和配置。

B. 变量系统：内置丰富的变量（如 `$uri`、`$args`、`$remote_addr` 等），同时支持自定义变量，可灵活适配业务配置需求。

C. 配置热加载：通过 `nginx -s reload` 命令，实现零停机更新配置，避免服务中断，提升运维效率。

4. 高可用机制

A. 健康检查：主动检测后端服务器状态（如 TCP 端口连通性、HTTP 响应状态），被动监控请求响应结果，及时发现故障节点。

B. 被动故障转移：根据 `max_fails`（最大失败次数）和 `fail_timeout`（失败超时时间）配置，自动剔除故障节点，故障节点恢复后自动重新加入集群。

C. 备份服务器：通过 `backup` 标记配置后备服务器，当所有主节点故障时，自动切换至备份服务器，保障服务连续性。

五、性能数据

Nginx 的高性能已在大量生产场景中得到验证，核心性能指标如下：

A. 单Worker吞吐量：可达 100,000 RPS（请求/秒），处理静态资源时性能更优。

B. 并发连接数：单实例可处理数百万并发连接（理论值），实际生产环境中可稳定支撑 10 万+ 并发连接。

C. 内存占用：每连接仅占用 100KB-1MB 内存，空闲状态下仅占用几 MB 内存。

D. 进程模型：通常配置 1 个 Worker 进程 per CPU 核心，充分利用多核资源。

六、架构对比

Nginx 与传统 Web 服务器（如 Apache Prefork 模式）在架构设计上存在显著差异，具体对比如下：

对比特性	Nginx	传统服务器（如Apache Prefork模式）
并发模型	事件驱动、非阻塞 I/O 模型	进程/线程每连接模型
内存占用	低（共享内存、小栈空间）	高（每个进程独立内存空间）
上下文切换	极少（单线程 Worker）	频繁（多线程调度）
可扩展性	水平/垂直扩展均优秀，适配大规模集群	垂直扩展受限，难以应对高并发场景
适用场景	高并发、静态服务、反向代理、负载均衡场景	动态内容、需要 .htaccess 灵活配置的场景

七、演进与扩展

Nginx 不断迭代演进，适配现代互联网架构的需求，核心扩展方向如下：

A. NGINX Plus：Nginx 的商业版本，在开源版本基础上，提供高级负载均衡、监控 API、动态配置、动态证书加载等增值功能，适合企业级生产环境。

B. 与云原生集成：支持作为 Kubernetes Ingress Controller，实现云原生环境下的流量入口管理；同时可作为 Service Mesh Sidecar，适配微服务架构的流量治理需求。

C. 现代协议支持：持续优化 HTTP/3（QUIC）、TLS 1.3、gRPC-Web 等现代协议的支持，提升网络传输效率和安全性，适配新一代应用场景。

如果觉得这篇文章对你有帮助，欢迎点赞、收藏，也可以在评论区留言，聊聊你在使用Nginx时遇到的问题～

【温故知新】Linux系统启动流程（BIOS+GRUB模式）

Posted on 2026/01/31 by neohope — No Comments ↓

一、硬件初始化阶段
1、电源自检（POST）
按下电源键，主板 BIOS 固件启动，依次检测 CPU、内存、硬盘控制器、显卡、外设等核心硬件，故障则通过蜂鸣 / 屏幕提示终止启动，无异常则进入下一步。
2、BIOS 固件初始化，定位启动设备并加载GRUB第一扇区
BIOS 加载自身固化驱动，初始化已检测通过的硬件，建立基础硬件运行环境，识别本地存储设备（硬盘/SSD）。BIOS 按 CMOS 中预设的启动顺序（硬盘/U盘/光驱），找到目标启动硬盘，读取硬盘主引导记录（MBR，磁盘首个 512 字节），加载其中的 GRUB 第一阶段（Stage1）引导程序，将控制权移交 GRUB。

二、引导加载阶段
3、GRUB Stage1 执行
MBR 中的 Stage1 程序无完整驱动，仅负责定位并加载硬盘中 **/boot 分区 ** 的 GRUB Stage1.5 程序（位于 MBR 之后、第一个分区之前的空闲扇区）。
4、GRUB Stage1.5 加载
加载 Stage1.5 并初始化，其集成了文件系统驱动（ext4/xfs 等），可直接识别 /boot 分区的文件系统，无需依赖其他程序。
5、GRUB Stage2 加载
通过 Stage1.5 读取 /boot/grub 目录下的完整 GRUB 程序（Stage2），加载 GRUB 核心模块，完成引导程序自身初始化。
6、内核加载准备
读取 /boot/grub/grub.cfg 配置文件，多系统场景显示启动菜单（超时选默认项），将 Linux 内核镜像（vmlinuz）、初始内存盘（initramfs/initrd）加载至物理内存，向内核传递根分区位置、启动参数等信息。

三、内核启动阶段
7、内核解压与初始化
内核在内存中自解压并运行，初始化 CPU、内存管理、进程调度、中断处理等内核核心子系统。
8、加载临时驱动与文件系统
挂载 initramfs 为临时根文件系统，加载硬盘、文件系统等内核原生未集成的必要驱动，为挂载真实根分区做准备。
9、挂载根文件系统
通过临时驱动识别并以只读模式挂载真实根文件系统（ext4/btrfs/xfs 等）。
10、切换根文件系统
从 initramfs 临时根切换至真实根分区，释放 initramfs 占用的内存资源。
11、启动第一个用户进程
内核启动首个用户空间进程（主流为 systemd，传统为 init），PID 固定为 1，内核将系统控制权完全移交用户空间，内核启动阶段完成。

四、用户空间初始化
12、初始化系统启动
systemd 读取核心配置文件（/etc/systemd/system/default.target），确定系统默认启动目标。
13、启动基础服务
按服务依赖关系并行启动基础核心服务：udev（硬件动态管理）、日志服务（journald/rsyslog）、/etc/fstab 配置的非根分区挂载（并将根分区从只读改为读写）等。
14、启动目标单元服务
根据默认启动目标（multi-user.target 命令行 /graphical.target 图形界面），启动对应服务组（如网络、SSH、定时任务等）。
15、登录界面 / Shell 就绪
启动字符终端 getty 进程或图形登录管理器（GDM/LightDM），显示登录提示 / 可视化登录界面，Linux 系统启动完成，进入可操作状态。

关键差异
1、BIOS 无 EFI 系统分区（ESP），依赖 MBR 加载引导程序，而 UEFI 直接从 ESP 加载 grubx64.efi。
2、BIOS 下 GRUB 为多阶段加载（Stage1→Stage1.5→Stage2），解决 MBR 空间不足（仅 512 字节）无法存储完整引导程序的问题；UEFI 下 GRUB 为单阶段直接加载。

引导方式	BIOS+GRUB	UEFI+GRUB
固件类型	传统 BIOS 固件（固化在主板，功能简单）	新式 UEFI 固件（模块化，功能丰富）
引导分区	无专用分区，依赖硬盘 MBR（512 字节）	专用 EFI 系统分区（ESP，FAT32 格式）
GRUB加载方式	多阶段（Stage1→1.5→2）加载	单阶段直接加载 grubx64.efi 文件
启动项存储	存储在主板 CMOS 中（掉电易丢失）	存储在 ESP 分区的 EFI 启动项中（更稳定）
硬件支持	最大支持 2TB 硬盘（MBR 分区表限制）	支持大于 2TB 硬盘（GPT 分区表）

【温故知新】Linux系统启动流程（UEFI+GRUB模式）

Posted on 2026/01/31 by neohope — No Comments ↓

一、硬件初始化阶段
1、电源自检（Power-On Self-Test, POST）
按下电源键后，主板 UEFI 固件执行核心硬件检测（内存、CPU、硬盘控制器、显卡等），硬件故障则终止启动并抛出提示，无异常则进入下一阶段。
2、固件初始化
UEFI 固件加载自身驱动，识别本地存储设备（硬盘 / SSD 等），初始化硬件运行环境，完成启动前基础准备。
3、启动管理器加载
UEFI 按预设启动项顺序，从EFI 系统分区（ESP）读取并加载 GRUB 引导程序核心文件（grubx64.efi）。

二、引导加载阶段
4、GRUB 第一阶段加载
UEFI 将系统控制权移交 GRUB，加载 GRUB 核心运行模块，完成引导程序自身初始化。
5、GRUB 配置文件解析
读取 /boot/grub/grub.cfg 配置文件，解析内核路径、启动参数，多系统场景显示启动菜单（超时后选默认项）。
6、内核加载准备
根据配置将 Linux 内核镜像（vmlinuz）、初始内存盘（initramfs/initrd）加载至物理内存，向内核传递根分区位置等关键启动参数。

Windows进程间通讯全解析：10大核心方式+场景选型，搞定进程协同

Posted on 2025/10/04 by neohope — No Comments ↓

Windows进程间通讯

Windows进程间通讯全解析：10大核心方式+场景选型，搞定进程协同

在 Windows 系统中，多个进程想要协同工作（比如浏览器调用下载工具、办公软件同步数据），就离不开 “进程间通讯（IPC）” 技术。不同场景下，有的需要高速传输大数据，有的需要实时同步状态，有的要跨网络通讯 —— 选对 IPC 方式，能让程序协作更高效、更稳定。今天就拆解 Windows 系统中常见的进程间通讯方式，帮你理清适用场景和核心逻辑。

一、内核对象同步：轻量级状态协同，保障进程有序执行
核心逻辑：利用 Windows 内核对象的信号状态，实现进程间的同步与互斥（比如避免多个进程同时操作同一资源），适用于简单状态通知。
代表技术：互斥量（Mutex，保证同一时刻只有一个进程访问资源）、信号量（Semaphore，控制同时访问资源的进程数量）、Event（事件对象，通过信号触发进程执行）；
优势：轻量级、效率高、系统原生支持，无需复杂配置；
适用场景：进程间同步（如多个进程读写同一文件时的锁机制）、简单状态通知（如 “任务完成” 信号触发下一个进程执行）。

二、共享内存类：高速传输大数据，性能优先之选
核心逻辑：多个进程共享同一块物理内存，直接读写内存实现数据传输，无需拷贝，是速度最快的 IPC 方式。
代表技术：共享内存（直接创建共享内存区域，进程间直接访问）、文件映射（将文件映射到内存，多个进程通过内存共享文件数据）、DLL 共享段（通过 DLL 的共享数据段，实现进程间数据共享）；
优势：传输速度极快（内存级读写）、无数据拷贝损耗、支持大容量数据传输；
注意点：需要自己实现同步机制（如搭配互斥量），避免数据竞争；
适用场景：高频大数据传输（如视频处理软件的帧数据传递、工业软件的实时数据共享）。

三、管道通讯：基于文件系统，适配本地进程交互
核心逻辑：模拟文件读写的方式，通过 “管道” 这一伪文件实现进程间字节流传输，是 Windows 原生的本地 IPC 方案。
代表技术：匿名管道（Pipe，仅支持父子进程或亲缘进程间通讯，单向传输）、命名管道（Named Pipe，支持任意本地进程间通讯，双向传输）；
优势：系统原生支持、使用简单、传输可靠；
适用场景：本地进程间字节流传输（如命令行工具的输出传递、本地服务与客户端的通讯）。

四、组件对象模型：跨进程调用，实现功能复用
核心逻辑：通过 COM（组件对象模型）、DCOM（分布式 COM）、OLE 技术等，将一个进程的功能封装为组件，供其他进程远程调用，实现功能复用。
代表技术：COM（本地跨进程组件调用，如 Office 组件嵌入其他软件）、DCOM（跨网络的 COM 调用，支持远程组件访问）、OLE（对象链接与嵌入，如文档中嵌入图片、表格）；
优势：封装性好、支持功能复用、接口标准化；
适用场景：跨进程功能调用（如第三方组件集成、软件插件扩展）、分布式系统的远程组件访问。

五、网络通讯类：跨机器 / 广域通讯，突破本地限制
核心逻辑：基于网络协议实现进程间通讯，不仅支持本地进程，还能跨 Windows 机器、跨网络通讯，是最通用的 IPC 方式。
代表技术：Socket（套接字，支持 TCP/UDP 协议，本地与跨网络通讯通用，如客户端 / 服务器架构）、NetBios 函数（早期 Windows 网络通讯接口，支持局域网内进程交互）；
优势：通用性强、支持跨机器 / 跨网络、适配各类数据传输场景；
适用场景：网络应用（如浏览器与服务器通讯）、跨机器进程协同（如分布式服务间调用）、客户端 / 服务器架构软件。

六、消息与钩子：Windows 原生机制，适配桌面应用交互
核心逻辑：利用 Windows 的消息机制或钩子函数，实现进程间的消息传递或行为监控。
代表技术：消息通知（Windows 消息队列，进程间发送自定义消息）、钩子函数（Hook，监控或拦截其他进程的消息 / 行为，如键盘钩子、鼠标钩子）、DLL 注入（通过注入 DLL，实现进程间消息传递或功能扩展）；
优势：深度适配 Windows 桌面应用、支持行为监控与消息触发；
适用场景：桌面应用交互（如窗口间消息通知）、进程行为监控（如安全软件的行为拦截）、软件功能增强（如通过 DLL 注入扩展第三方软件功能）。

七、中间件 / 存储介质：间接通讯，解耦进程依赖
核心逻辑：通过第三方存储介质或中间件传递数据，进程间不直接交互，降低耦合度，适配复杂场景。
代表技术：文件（通过读写同一文件传递数据，如日志同步、配置共享）、数据库（关系型 / 非关系型数据库，如多进程共享业务数据）、缓存中间件（Redis、etcd、zk，分布式场景下的配置同步与数据共享）、消息队列（MQ，异步通讯，如任务分发、数据异步传递）；
优势：解耦进程依赖、支持异步通讯、适配分布式场景；
适用场景：分布式系统（如微服务间通讯）、异步任务处理（如批量数据处理）、跨进程配置共享（如多进程读取同一数据库配置）。

八、其他特色方式：适配特殊场景需求
除了主流方式，还有一些针对特定场景的 IPC 方案：
动态数据交换（DDE）：早期 Windows 桌面应用的通讯方式，支持应用间数据实时同步（如 Excel 表格数据同步到 Word 文档）；
粘贴板（Clipboard）：简单直观的进程间数据传递，用户通过复制粘贴实现（如从浏览器复制文本到记事本）；
文件传输协议（FTP）：通过 FTP 协议实现文件级别的进程间 / 跨机器数据传输，适用于大容量文件共享。

总结：Windows IPC 选型核心逻辑 ——“按需匹配，兼顾效率与场景”
选择 IPC 方式时，核心看 3 个维度：
传输距离：本地进程选共享内存、管道、COM；跨网络选 Socket、中间件；
数据量与速度：大数据高速传输选共享内存、文件映射；小数据同步选内核对象、消息通知；
交互方式：同步通讯选 Socket、命名管道；异步通讯选 MQ、中间件；功能复用选 COM/DCOM。
Windows 的 IPC 方案覆盖了从本地轻量级同步到分布式跨网络通讯的全场景，掌握不同方式的核心逻辑，就能根据项目需求精准选型，让进程协同更高效。

你在开发中常用哪种 Windows IPC 方式？遇到过哪些兼容性或性能问题？欢迎在评论区留言交流～

WSL2中apt升级systemd时报错：无法锁定passwd文件

Posted on 2025/06/29 by neohope — No Comments ↓

1、环境：
Windows10+WSL2+Ubuntu24
PS:另一台电脑Windows11+WSL2+Ubuntu24，不会报错

2、再现方式及错误信息

# apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
...
...
Setting up systemd (255.4-1ubuntu8.8) ...
Initializing machine ID from random generator.
Failed to take /etc/passwd lock: Invalid argument
dpkg: error processing package systemd (--configure):
installed systemd package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)

3、错误发生原因
systemd升级的脚本，会调用systemd-sysusers，systemd-sysusers会尝试通过fcntl锁定文件，但WSL中fcntl实现效果与Linux中不同，导致脚本执行失败。
更进一步的解释：
Linux中文件锁是基于文件描述符的，子进程会自动继承该文件锁。
Windows中文件锁是基于进程的，子进程需要自行获取新的文件锁。
WSL中，实现方式，更接近与Windows，重复获取同一个文件的锁自然是失败的。

openat(AT_FDCWD, "/etc/.pwd.lock", O_WRONLY|O_CREAT|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC, 0600) = 3
fcntl(3, F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = -1 EINVAL (Invalid argument)

4、如何绕过该错误

# 原文在此：https://github.com/microsoft/WSL/issues/10397

# 切换到/bin
# 将systemd-sysusers修改为systemd-sysusers.org
# 将systemd-sysusers做成一个echo的符号链接（用于欺骗升级脚本，让其以为得到了正确的结果）
# 切换回之前的目录
cd /bin && mv -f systemd-sysusers{,.org} && ln -s echo systemd-sysusers && cd -

# 修复包依赖
apt --fix-broken install

# 继续升级
apt-get upgrade

Linux5.9源码

Posted on 2021/10/01 by neohope — No Comments ↓

最近阅读了部分Linux5.9源码，添加了一些注释，感兴趣的同学可以看下。
https://github.com/neohope/NeoLinux/

Linux虚拟化管理

Posted on 2021/08/21 by neohope — No Comments ↓

1、内核模块初始化

module_init(vmx_init)->kvm_init
module_init(svm_init)->kvm_init

//其中，kvm_init
->kvm_arch_init
->kvm_irqfd_init
->kvm_arch_hardware_setup
->misc_register(&kvm_dev)

2、从数据结构角度，又可以看到了设备皆为文件的思想

static struct miscdevice kvm_dev = {
    KVM_MINOR,
    "kvm",
    &kvm_chardev_ops,
};

static struct file_operations kvm_chardev_ops = {
    .unlocked_ioctl = kvm_dev_ioctl,
    .llseek     = noop_llseek,
    KVM_COMPAT(kvm_dev_ioctl),
};

//初始化时，通过misc_register，实现了操作的绑定。

3、通过上面的数据结构，我们就可以找到创建虚拟机的方法，并生成控制文件
kvm_dev.kvm_chardev_ops.kvm_dev_ioctl
或者，ioctl系统调用KVM_CREATE_VM，效果也是一样的：

SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
->vfs_ioctl，会用到vfs_ioctl.unlocked_ioctl也就是kvm_dev_ioctl

->case KVM_CREATE_VM:
->        r = kvm_dev_ioctl_create_vm(arg);
->file = anon_inode_getfile("kvm-vm", &kvm_vm_fops, kvm, O_RDWR);

//其中，kvm_dev_ioctl_create_vm
->kvm_create_vm
->->kvm_arch_init_vm
->->hardware_enable_all
->->kvm_arch_post_init_vm
->->list_add(&kvm->vm_list, &vm_list);

4、生成虚拟CPU套路很相似，仍是文件操作

static struct file_operations kvm_vm_fops = {
    .release        = kvm_vm_release,
    .unlocked_ioctl = kvm_vm_ioctl,
    .llseek     = noop_llseek,
    KVM_COMPAT(kvm_vm_compat_ioctl),
};

//创建虚拟机时，通过anon_inode_getfile，实际上就把文件和kvm_vm_fops绑定了起来。
anon_inode_getfile("kvm-vm", &kvm_vm_fops, kvm, O_RDWR)

5、在调用ioctl时

SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
->vfs_ioctl，会用到vfs_ioctl.unlocked_ioctl也就是kvm_vm_ioctl

kvm_vm_ioctl->kvm_vm_ioctl_create_vcpu
->kvm_arch_vcpu_precreate
->kvm_vcpu_init
->kvm_arch_vcpu_create
->kvm_get_kvm
->create_vcpu_fd，生成设备文件inode
->kvm_arch_vcpu_postcreate

//其中，kvm_arch_vcpu_create
->kvm_mmu_create
->vcpu->arch.user_fpu = kmem_cache_zalloc(x86_fpu_cache, GFP_KERNEL_ACCOUNT);
->kvm_pmu_init(vcpu);
->kvm_hv_vcpu_init(vcpu);
->kvm_x86_ops.vcpu_create(vcpu);
->kvm_vcpu_mtrr_init(vcpu);
->vcpu_load(vcpu);
->kvm_vcpu_reset(vcpu, false);
->kvm_init_mmu(vcpu, false);  //包括init_kvm_tdp_mmu和init_kvm_softmmu两种虚拟化方式

6、启动虚拟机，还是文件操作

static struct file_operations kvm_vcpu_fops = {
    .release        = kvm_vcpu_release,
    .unlocked_ioctl = kvm_vcpu_ioctl,
    .mmap           = kvm_vcpu_mmap,
    .llseek     = noop_llseek,
    KVM_COMPAT(kvm_vcpu_compat_ioctl),
};

7、在调用ioctl时KVM_RUN

SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
->vfs_ioctl，会用到vfs_ioctl.unlocked_ioctl也就是kvm_vcpu_ioctl

kvm_vcpu_ioctl->
case KVM_RUN: 
  kvm_arch_vcpu_ioctl_run

//其中，
kvm_arch_vcpu_ioctl_run->vcpu_run->vcpu_enter_guest

8、IO同样有虚拟化和半虚拟化两种
一个处理函数为kvm_fast_pio，另一个为kvm_emulate_instruction

Linux系统调用03

Posted on 2021/08/17 by neohope — No Comments ↓

Linux系统调用的整体流程为：
1、应用程序【用户态】通过syscall或glibc进行内核功能调用，这一部分在glibc源码中进行的
2、CPU收到syscall，Linux内核响应syscall调用【内核态】，这一部分在linux源码中进行的
3、返回结果到应用程序【用户态】

本节，给Linux系统，增加一个新系统调用功能，获取cpu数量。

1、新建一个源码编译目录

mkdir kernelbuild

2、下载源码，解压

wget https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.10.59.tar.gz   

tar -xzf linux-5.10.59.tar.gz   

cd linux-5.10.59

3、清理

make mrproper

4、修改文件

4.1、arch/x86/entry/syscalls/syscall_64.tbl
#在440后面增加一行
441  common  get_cpus    sys_get_cpus

4.2、include/linux/syscalls.h
#在最后一个asmlinkage增加一行
asmlinkage long sys_get_cpus(void);

4.3、kernel/sys.c  
#在最后一个SYSCALL_DEFINE0后面增加下面几行
//获取系统中有多少CPU
SYSCALL_DEFINE0(get_cpus)
{
    return num_present_cpus();
}

5、内核配置

make menuconfig
make oldconfig

6、修改.config，去掉一个证书

CONFIG_SYSTEM_TRUSTED_KEYS=“”

7、编译

make -j4

8、安装

sudo make modules_install
sudo make install

9、测试
9.1、新建文件cpus.c

#include <stdio.h>
#include <unistd.h>
#include <sys/syscall.h>
int main(int argc, char const *argv[])
{
    //syscall就是根据系统调用号调用相应的系统调用
    long cpus = syscall(441);
    printf("cpu num is:%d\n", cpus);//输出结果
    return 0;
}

9.2、编译

gcc main.c -o cpus

9.3、运行

./cpus
在没有修改的内核上返回是-1
在修改过的为num_present_cpus数量

极客时间操作系统实战45讲 Linux系统调用源码

Linux系统调用02

Posted on 2021/08/17 by neohope — No Comments ↓

Linux系统调用的整体流程为：
1、应用程序【用户态】通过syscall或glibc进行内核功能调用，这一部分在glibc源码中进行的
2、CPU收到syscall，Linux内核响应syscall调用【内核态】，这一部分在linux源码中进行的
3、返回结果到应用程序【用户态】
本节处理第二部分：

二、linux内核部分

1、在make时，会通过syscall_64.tbl生成syscalls_64.h，然后包含到syscall_64.c，进行调用号与函数之间的绑定。
arch/x86/entry/syscalls/syscall_64.tbl
arch/x86/include/generated/asm/syscalls_64.h
arch/x86/entry/syscall_64.c

1.1、以sys_openat为例，在syscall_64.tbl中为

257    common    openat            sys_openat
441    common    get_cpus          sys_get_cpus

1.2、make后，在生成的syscalls_64.h中为

__SYSCALL_COMMON(257, sys_openat)

1.3 在syscall_64.c中，展开__SYSCALL_COMMON

#define __SYSCALL_COMMON(nr, sym) __SYSCALL_64(nr, sym)
//展开就是
__SYSCALL_64(257, sys_openat)

1.4、在syscall_64.c中，第一次展开__SYSCALL_64

#define __SYSCALL_64(nr, sym) extern long __x64_##sym(const struct pt_regs *);
#include <asm/syscalls_64.h>
#undef __SYSCALL_64

//展开就是
extern long __x64_sys_openat(const struct pt_regs *);

//也就是每个__SYSCALL_64都展开成了一个外部函数

1.5、在syscall_64.c中，第二次展开__SYSCALL_64

#define __SYSCALL_64(nr, sym) [nr] = __x64_##sym,

asmlinkage const sys_call_ptr_t sys_call_table[__NR_syscall_max+1] = {
    [0 ... __NR_syscall_max] = &__x64_sys_ni_syscall,
#include <asm/syscalls_64.h>
};

//展开其实就是指向了外部函数
[257]=__x64_sys_openat,

//全部展开结果，都会被包含到sys_call_table中，从而完成了调用号与函数之间的绑定。

2、当产生系统调用时
2.1、应用直接syscall或通过glibc产生了syscall

2.2、cpu会产生类似于中断的效果，开始到entry_SYSCALL_64执行

//文件路径arch/x86/entry/entry_64.S
SYM_CODE_START(entry_SYSCALL_64)
//省略代码
call   do_syscall_64
SYM_CODE_END(entry_SYSCALL_64)

//文件路径arch/x86/entry/entry_64.S，32位兼容模式，过程与64位类似
SYM_CODE_START(entry_SYSCALL_compat)
call   do_fast_syscall_32
SYM_CODE_END(entry_SYSCALL_compat)

2.3、调用do_syscall_64

#ifdef CONFIG_X86_64
__visible noinstr void do_syscall_64(unsigned long nr, struct pt_regs *regs)
{
    nr = syscall_enter_from_user_mode(regs, nr);
    instrumentation_begin();
    if (likely(nr < NR_syscalls)) {
        nr = array_index_nospec(nr, NR_syscalls);
        regs->ax = sys_call_table[nr](regs);
    }
    instrumentation_end();
    syscall_exit_to_user_mode(regs);
}
#endif

2.4、根据sys_call_table调用对应的功能函数

sys_call_table[nr](regs)
如果我们传入257，就会调用__x64_sys_openat
如果我们传入441，就会调用__x64_sys_get_cpus

2.5、但咱们实际写的函数sys_get_cpus，好像和实际调用函数__x64_sys_get_cpus，差了一个__x64，这需要一个wrapper

arch\x86\include\asm\syscall_wrapper.h
#define SYSCALL_DEFINE0(sname)                      \
    SYSCALL_METADATA(_##sname, 0);                  \
    static long __do_sys_##sname(const struct pt_regs *__unused);   \
    __X64_SYS_STUB0(sname)                      \
    __IA32_SYS_STUB0(sname)                     \
    static long __do_sys_##sname(const struct pt_regs *__unused)

#define __X64_SYS_STUB0(name)                       \
    __SYS_STUB0(x64, sys_##name)

#define __SYS_STUB0(abi, name)                      \
    long __##abi##_##name(const struct pt_regs *regs);      \
    ALLOW_ERROR_INJECTION(__##abi##_##name, ERRNO);         \
    long __##abi##_##name(const struct pt_regs *regs)       \
        __alias(__do_##name);

SYSCALL_DEFINE0(get_cpus)，会展开成为
__X64_SYS_STUB0(get_cpus) 
//然后
 __SYS_STUB0(x64, sys_get_cpus)
//然后
long __x64_sys_get_cpus(const struct pt_regs *regs);

这样前后就对上了，glibc和linux内核就通了。