-
别再死记“MAC是物理地址”，不懂怎么配合，你永远配不好网络！
01 MAC地址 长度：48位（6字节），如 00:e0:fc:12:34:56 作用：在同一个广播域内标识设备，交换机靠它转发帧 特点： 全球唯一（理论上） 工作在数据链路层（Layer 2） 不会跨路由器传递（每跳重新封装） ✅ 关键理解：MAC地址只在本地网段有效。跨网段通信时，目标MAC始终是下一跳网关的MAC。 02 IP地址 长度：IPv4为32位，如 192.168.1.10 作用：实现端到端逻辑寻址，支持跨网络路由 特点： 可变（可手动/自动分配） 工作在网络层（Layer 3） 全程不变（源IP和目的IP从起点到终点不变） ✅ 关键理解：IP决定“去哪里”，MAC决定“这一步怎么走”。 03 子网 子网掩码：如 255.255.255.0（即 /24） 作用： 划分网络号 + 主机号 判断目标IP是否在同一网段 控制广播范围，提升安全与效率 举个例子： IP: 192.168.10.50Mask: 255.255.255.0 → 网络号 = 192.168.10.0 → 同一子网：192.168.10.1 ~ 192.168.10.254→ 不同子网：192.168.11.1 → 需经网关转发 ✅ 判断规则：(本地IP & 子网掩码) == (目标IP & 子网掩码) → 同网段，直通；否则，发给网关。 04 “铁三角”如何协同工作？ 场景：PC1（192.168.10.10/24） ping PC2（192.168.20.10/24） PC1检查目标IP → 192.168.20.10 & 255.255.255.0 ≠ 192.168.10.0 → 不同网段！发给网关（192.168.10.1） PC1发ARP请求 → “谁是192.168.10.1？请回复MAC”→ 网关回应自己的MAC（如 Router-MAC-A） PC1封装帧 源MAC：PC1-MAC 目标MAC：Router-MAC-A 源IP：192.168.10.10 目标IP：192.168.20.10 路由器收到后 源MAC：Router-MAC-B（VLAN20接口MAC） 目标MAC：PC2-MAC IP不变！ 剥离二层帧，解析IP包 查路由表，发现192.168.20.0/24出口为VLANIF20 发ARP查PC2的MAC 重新封装新帧： 核心结论： IP全程不变 MAC每跳重写 子网决定是否需要网关 ……
SE_Tianle 2025-12-29
23 0 0 -
Tomcat工作原理
Tomcat 是基于 Java 的开源 Servlet 容器，实现了 Servlet/JSP 规范，核心作用是处理 HTTP 请求并将结果返回给客户端。其工作原理可拆解为「架构设计、请求处理流程、核心组件协作」三部分，以下是通俗易懂的全维度解析： 一、Tomcat 核心架构（组件分层） Tomcat 采用「分层 + 模块化」设计，核心组件按职责划分，底层依赖 Java NIO（8.0+ 默认）实现高性能 IO 处理： 核心组件 作用 类比（便于理解） Server Tomcat 顶级组件，代表整个服务器实例，包含一个或多个 Service 一栋办公楼 Service 绑定「连接器 + 引擎」，一个 Service 对应一个端口（如 8080）的服务集群 办公楼的一个业务部门 Connector（连接器） 监听指定端口，接收 HTTP 请求，解析为 Tomcat 内部 Request 对象，转发给 Engine 部门的前台（接收访客） Engine（引擎） 处理 Connector 转发的请求，是 Servlet 处理的核心入口，包含多个 Host 部门的核心处理中心 Host（虚拟主机） 对应一个域名（如 localhost），一个 Engine 可配置多个 Host 处理中心下的不同业务组 Context（上下文） 对应一个 Web 应用（如 /demo 项目），一个 Host 可包含多个 Context 业务组下的具体业务模块 Wrapper 对应一个 Servlet 实例，Context 的最小处理单元 模块中的具体办事人员 核心关系：Server → Service → (Connector + Engine) → Host → Context → Wrapper → Servlet 二、Tomcat 核心工作流程（请求处理全链路） 以「浏览器访问 http://localhost:8080/demo/hello」为例，拆解 Tomcat 处理请求的完整步骤： 步骤 1：Connector 监听并接收请求 Connector 绑定 8080 端口，通过「Acceptor 线程」监听客户端连接； 接收到 HTTP 请求后，由「Poller 线程」（NIO 模式）将连接交给「Worker 线程池」处理； Worker 线程解析 HTTP ……
SE_Yang 2025-12-26
13 0 0 -
从 Centos 切换到 Ubuntu
从 Centos 切换到 Ubuntu 1. 前言 Centos 是一个不错的发行版，但是它的各个版本都已经停止维护了。CentOS 7 于 2024 年 6 月 30 日正式停止支持，CentOS 8 更是早在 2021 年 12 月 31 日就停止维护了。而且后续学习中不支持部分软件版本，从长远使用、学习、生态等多方面考虑，将其切换到 Ubuntu 是不错之举。 其实从一开始就直接接触 Ubuntu 也是不错的选择，但这些都是后话了，各有优劣吧。从 Centos 切换到 Ubuntu 的朋友可以体验到不同系统的优劣，直接使用 Ubuntu 倒是可以省去一些小麻烦，但归根结底，二者基本可以做到无缝互通，命令大差不差，遇到不一样的简单查一下就行了。下面开始教学如何从 Centos 切换到 Ubuntu，基本上比较简单，少部分涉及 Centos 的一点基础。 2. 系统切换 到自己的云服务器厂商后台找到切换镜像，选择 Ubuntu 22.04 版本进行安装，几分钟后就会完成，注意完成后要重新设置密码！ 重要提醒：切换系统前一定要备份好重要数据，系统切换会清空所有数据！ 3. 使用 Xshell 进行连接 这里的操作和连接 Centos 一模一样，直接输入公网 IP 和对应的账密就能进行登录。 1. 创建普通账户 同样的，我们还是创建一个普通账户： adduser 用户名 紧接着会让我们设置和确认密码，正常输入就行。完了后就会发现和 Centos 的区别：它会让我们设置该账户的信息，比如全名、房间号码、工作电话、家庭电话等。为了方便可以一路回车表示默认，个人使用会比较方便快捷，当然，如果你想要进行设置也行。 2. 赋予 sudo 权限 关键步骤：创建用户后需要赋予 sudo 权限，否则无法执行管理员命令，这里有两个方法： 方法一： 和 Centos 一样，使用 root 账户执行命令：vim /etc/sudoers，按下 i 键进入插入模式，找到大约第 100 行左右的位置（附近会有 root ALL=(ALL) ALL 的字眼），在其下方添加以下内……
SE_Wang 2025-12-26
29 0 0 -
微软ppt和wps之间的兼容性问题
微软 PPT 与 WPS 演示之间存在一定的兼容性问题，主要集中在高级功能、格式解析、字体渲染和特殊效果等方面，但基础功能与通用格式（.ppt/.pptx）的兼容性较好，日常简单文档通常不会有明显问题。 一、常见兼容性问题类型 问题类别 具体表现 影响程度 格式与排版 页面布局错乱、文本框移位、表格变形、图片拉伸 中高 字体显示 字体替换（如 WPS 特有的字体在 Office 中缺失）、字号与行距变化 中 动画与切换 复杂动画失效、平滑切换效果异常、时间轴错乱 中高 特殊对象 3D 模型、SmartArt 图形、宏（VBA）、嵌入式对象无法正常显示或运行 高 文件修复提示 Office 打开 WPS 编辑的 PPT 时弹出 "内容有问题，是否修复"，修复后可能丢失内容 高 WPS 特有功能 WPS 智能图表、WPS 艺术字、WPS 模板等在 Office 中无法识别或显示异常 中 二、兼容性问题的核心原因 底层技术差异：两者采用不同的渲染引擎和 XML 解析方式，对 OpenXML 标准的实现存在细微差别 功能支持范围不同：Microsoft PowerPoint 有部分高级功能（如复杂宏、3D 模型、缩放定位）在 WPS 中支持有限，反之亦然 文件格式区别：WPS 默认的.dps 格式在 PowerPoint 中无法直接打开，必须另存为.pptx 格式 版本迭代滞后：老旧版本的 WPS 或 Office 无法适配最新文件格式和功能 字体处理机制不同：WPS 与 Office 对字体嵌入的处理方式存在差异，可能导致文件无法打开或显示异常 三、兼容性问题的解决方法 1. 基础设置优化 在 WPS 中开启 **"保存为与 Microsoft Office 兼容格式"和"保存时检查兼容性"**（文件→选项→常规与保存） 保存文件时，优先选择 **Office 兼容模式 (.pptx)** 而非普通.pptx 格式 避免使用 WPS 特有功能，尽量使用双方都支持的标准功能 2. 字体与排版处理 使用通用字体（如宋体、微软雅黑、Arial 等）……
SE-YangYao 2025-12-26
37 0 0 -
安全盲区：打通网络≠开放权限，必须把关的这一点
业务部门要访问新系统，赶紧把网络打通！” 你迅速配置路由、放通防火墙策略，测试连通——ping 通了，telnet 端口也开了，搞定！ 但几天后，安全团队找上门： “为什么财务服务器能被市场部任意访问？”“谁在什么时候访问了核心数据库？日志在哪？” 网络通了，不等于权限就该开；连上了，不代表可以随便用。 今天来和大家探讨一个被严重低估的运维盲区：网络连通性 ≠ 访问授权。 并为你提供一套“最小权限 + 可审计”落地框架，让每一次开通都经得起安全审查。 一、网络连通 ≠ 权限开放：三层模型 正确做法： 三层联动，缺一不可。 错误示范： 仅放通IP+端口 → 任何人在该网段都能访问 无身份验证 → 无法区分“张三”和“李四” 无日志记录 → 出事找不到责任人 二、安全开通四步 第1步：明确业务需求（Who + What + Why） 谁需要访问？（具体用户/角色，而非整个部门） 访问什么资源？（精确到IP+端口+URL路径） 为什么需要？（业务场景说明，留存审批） 示例：“市场部经理王五（工号M1001）需在工作时间访问HR系统 /api/org-chart 接口，用于季度汇报。” 第2步：实施最小权限（Least Privilege） 网络层：源IP限定为用户终端或跳板机，非整个网段 ❌ permit 10.10.20.0/24 → 10.10.50.10:443✅ permit 10.10.20.105 → 10.10.50.10:443 传输层：仅开放必要端口（如HTTPS 443，非全端口） 应用层：对接SSO或账号系统，按角色授权 第3步：强制身份认证与会话控制 通过堡垒机或零信任网关访问敏感系统 会话水印、录屏、剪贴板禁用 临时权限：设置有效期（如2小时），自动回收 第4步：开启全链路审计 网络设备：记录会话日志（NetFlow/sFlow） 防火墙：开启命中日志（含源/目的IP、时间、动作） 应用系统：记录操作日志（谁、何时、做了什么） 关键：日志需集中存储，防篡改，保留≥180天（满足等保/GDPR） 三、……
18 0 0 -
如何保证事务消息的最终一致性？
保证 RocketMQ 事务消息的最终一致性（即「本地事务执行结果」与「消息投递 / 消费结果」最终一致），核心是构建「生产端一致性 + 消费端一致性 + 全局兜底补偿」的闭环体系，依托 RocketMQ 事务消息的原生机制，结合业务层的可靠性设计。以下是可落地的全流程方案，覆盖核心原理、关键措施和实操细节： 一、核心前提：理解事务消息的一致性基础 RocketMQ 事务消息的最终一致性，底层依赖「半消息 + 本地事务 + 事务回查」的原生机制： 半消息：Broker 暂存消息但不投递，保证「消息能成功写入 Broker」； 本地事务绑定：消息投递与否完全依赖本地事务执行结果； 事务回查：Broker 主动校验本地事务状态，解决「生产者宕机 / 网络异常导致状态丢失」的问题。 在此基础上，需通过业务层设计弥补原生机制的不足，形成完整闭环。 二、生产端：保证「本地事务 ↔ 消息状态」一致 生产端是一致性的核心入口，需确保「本地事务成功则消息必投递，本地事务失败则消息必回滚」。 1. 本地事务状态必须持久化（核心！） 问题：若本地事务状态仅存于内存，生产者宕机后，Broker 回查时无法获取真实状态，导致一致性破坏。解决方案：将本地事务状态写入数据库 / 事务日志表，回查时从持久化存储读取（而非内存）。 java 运行 // 1. 定义事务日志表（核心字段：tx_id/order_id/status/create_time） // 2. 执行本地事务时，记录状态 private boolean executeLocalTx(String orderId) { // 步骤1：执行核心业务（如扣减库存） boolean bizSuccess = deductStock(orderId); // 步骤2：记录事务日志（落地DB，关键！） saveTxLog(orderId, bizSuccess ? "SUCCESS" : "FAIL"); return bizSuccess; } // 3. 事务回查时，从DB读取状态（而非内存） private boolean checkLocalTx(……
18 0 0 -
【Linux系统编程】（十七）揭秘 Linux 进程创建与终止：从 fork 到 exit 的底层逻辑全解析
在 Linux 操作系统的世界里，进程是资源分配与调度的基本单位，就像一个个忙碌的 工人，支撑着整个系统的高效运转。而进程的创建与终止，正是这些 “工人” 从诞生到完成使命离场的完整生命周期。其中，fork 函数是创建新进程的核心工具，exit、_exit 等函数则主导了进程的优雅退出。本文将带大家深入底层，详细拆解 Linux 进程创建与终止的每一个关键环节，让你彻底搞懂这背后的技术原理与实践技巧。下面就让我们正式开始吧！ 一、进程创建：fork 函数的 “分身术” 1.1 fork 函数初识：一次调用，两次返回的神奇操作 在 Linux 中，要创建一个新进程，fork 函数是当之无愧的核心。它就像一台 “分身机器”，能让一个已存在的进程（父进程）复制出一个全新的进程（子进程），两个进程拥有相同的代码段、数据段（初始状态），却能各自独立运行，开启不同的执行旅程。 首先，我们来看 fork 函数的基本用法。它的头文件和函数原型如下（bash 环境中调用需借助 C 语言编译执行，后续代码案例均提供完整可运行方案）： #include <unistd.h> pid_t fork(void); 光看原型可能觉得平平无奇，但 fork 函数有一个极具迷惑性的特点：一次调用，两次返回。这是什么意思呢？简单来说，父进程调用 fork 后，内核会完成一系列操作，最终父进程和子进程都会从 fork 函数返回，但返回值却截然不同： 子进程中，fork 返回 0； 父进程中，fork 返回子进程的 PID（进程 ID）； 若调用失败，fork 返回 - 1。 为了让大家更直观地感受这个过程，我们来看一个完整的实战代码。先编写 C 语言代码文件 fork_demo.c： #include <stdio.h> #include <unistd.h> #include <stdlib.h> int main(void) { pid_t pid; printf("Before: pid is %d\n", getpid()); // 打印父进程PID // 调用fork创建子进程 if ((pid = fork()) == ……
11 0 0 -
有哪些专用的网卡驱动工具可以进行离线驱动安装？
一、国产主流网卡版驱动工具（适合新手，一键操作） 这类工具集成主流网卡驱动库，安装后可先解决网卡驱动问题，联网后再更新其他驱动，体积通常在500MB-1GB之间。 工具名称 核心特点 优势 不足 适用场景 驱动精灵万能网卡版 内置 99% 主流网卡驱动，支持 Win10/11，带网络修复工具 驱动库全，识别率高，操作简单 部分版本有捆绑，需手动取消 新装系统、个人电脑无网场景 驱动人生网卡版 专注网卡驱动，界面简洁，无广告绿色版可选 稳定性好，驱动匹配精准 驱动库略少于驱动精灵 个人 / 办公电脑，追求纯净体验 360 驱动大师网卡版 集成 360 安全组件，驱动库全面，支持硬件检测 安全防护，适合小白用户 部分用户反感 360 全家桶 家用电脑，重视安全检测 使用步骤（通用）： 在能上网的电脑下载对应工具的网卡版安装包 保存到 U 盘，插入无网电脑 安装并运行，工具自动扫描硬件 一键安装匹配的网卡驱动 安装完成后重启，网络恢复后可更新其他驱动 二、专注网卡驱动的轻量工具（体积小，专攻网卡） 这类工具仅集成网卡驱动，体积100-300MB，启动快，适合仅需解决网卡问题的场景。 1. 3DP Net（万能网卡驱动） 核心优势：专为网卡驱动设计，支持 Win7-Win11，自动识别网卡型号并安装匹配驱动 特别亮点：可在 PE 环境下使用，适合系统崩溃后的驱动修复 体积：约 200MB，绿色免安装版可选 使用：解压后运行，自动检测→选择驱动→一键安装，无需复杂操作 2. 万能网卡驱动离线包 核心优势：纯驱动包，无多余功能，双击即可自动安装 体积：约 150MB，支持主流网卡芯片（Intel、Realtek、Broadcom） 适用：追求极简操作，仅需安装基础网卡驱动的场景 三、全驱动离线工具（适合批量装机，驱动库完整） 这类工具集成几乎所有硬件驱动（网卡、显卡、声卡等），体积3-10GB，适合多台电脑批量部署。……
20 0 0 -
链路聚合 vs 堆叠：提升带宽和可靠性，怎么选？
作为网工常面临一个经典问题： “两台交换机之间带宽不够，还怕单点故障，是该用链路聚合？还是上堆叠？” 两者都能提升带宽、增强冗余，但目标不同、架构不同、适用场景也不同。 用错方案，轻则浪费预算，重则引发环路或管理混乱。 今天就来从原理、优势、限制、典型场景四个维度，彻底讲清： 链路聚合与堆叠的本质区别，以及如何根据业务需求做出正确选择。 一、一句话定义 ✅ 简单说： 链路聚合：解决“链路”问题（带宽+冗余） 堆叠：解决“设备”问题（简化管理+高可用） 二、链路聚合（LACP）详解 工作原理： 将2~8条物理链路捆绑成一个逻辑通道（Port Channel） 使用哈希算法（如源/目的MAC、IP、端口）分配流量 任意一条链路故障，流量自动切换到其余链路（毫秒级） 典型拓扑： [Server] —— (eth0 + eth1) —— [LACP] —— [Core-SW]↑两条1G链路 → 逻辑2G 优点： ✅ 跨厂商兼容（标准协议 IEEE 802.3ad） ✅ 无需特殊硬件（普通交换机支持） ✅ 可连接不同设备（如服务器连两台不同交换机，需vPC/MC-LAG） 缺点： ❌ 仍需STP防环（若形成环路） ❌ 单流无法突破单链路带宽（如一个TCP流最大1G） ❌ 管理复杂度未降低（每台设备仍独立配置） 三、堆叠（Stacking）详解 工作原理： 通过专用堆叠线缆（或万兆光口）连接多台交换机 所有成员共享一个IP、一个配置文件、一个MAC表 控制平面集中（主交换机管理），数据平面分布式转发 典型拓扑： [Access Stack] = [SW1] + [SW2] + [SW3] （逻辑一台）↓[Core-SW] 优点： ✅ 统一管理：登录一台，配置全栈 ✅ 跨设备链路聚合天然支持（如服务器连SW1和SW2，可直接做LACP） ✅ 高可靠性：主交换机故障，备机秒级接管（无STP收敛延迟） ✅ 扩展端口密度：像扩展模块一样增加端口 缺点： ❌ 厂商绑定：华为堆叠不能和H3C混用 ❌ 距离受限：堆叠线通常≤3米（……
18 0 0 -
如何保证事务消息的最终一致性？
保证 RocketMQ 事务消息的最终一致性（即「本地事务执行」与「消息投递 / 消费」的最终一致），核心是依托 RocketMQ 事务消息的「半消息 + 本地事务 + 事务回查」机制，同时配合生产端可靠性、消费端幂等性、异常兜底策略形成闭环。以下是分维度的落地方案，覆盖核心原理、关键措施和避坑要点： 一、核心原理：事务消息最终一致性的底层逻辑 RocketMQ 事务消息的最终一致性依赖「两阶段提交 + 回查兜底」，核心流程保证： 第一阶段：生产者发送「半消息」（Broker 暂存，不可投递），确保消息能成功写入 Broker； 第二阶段：执行本地事务，根据结果向 Broker 发送「提交 / 回滚」指令： 提交：Broker 投递消息给消费者，保证「本地事务成功 → 消息必投递」； 回滚：Broker 删除半消息，保证「本地事务失败 → 消息不投递」； 兜底机制：若生产者宕机 / 网络异常导致 Broker 未收到指令，Broker 定时回查生产者，确认本地事务状态后补全操作，避免「状态丢失」。 二、生产端：保证「本地事务 ↔ 消息状态」一致 生产端是最终一致性的核心，需确保「本地事务执行结果」与「消息提交 / 回滚」严格匹配： 1. 本地事务状态必须持久化（核心！） 问题：若本地事务状态仅存于内存，生产者宕机后，Broker 回查时无法获取真实状态，导致一致性破坏； 解决方案：将本地事务状态（成功 / 失败）写入数据库 / 事务日志，回查时从持久化存储读取，而非内存。 java 运行 // 示例：本地事务执行后，记录事务日志（关键） private boolean doLocalBiz(String orderId) { // 1. 执行本地事务（如扣减库存） boolean success = deductStock(orderId); // 2. 记录事务日志（落地到DB，用于回查） saveTxLog(orderId, success ? "SUCCESS" : "FAIL"); return success; } // 事务……
11 0 0
中间件
