提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
文章目录
- 前言
- 一. rocky 系统的启动流程，grub工作流程
- 1.rocky 系统的启动流程
- 2.grub工作流程
- 二. 内核设计流派及特点。
- 1、单内核（Monolithic Kernel）
- 2、微内核（Microkernel）
- 3、混合内核（Hybrid Kernel）
- 4、外核（Exokernel）
- 6、内核设计流派对比
- 三. systemd服务配置文件
- 1. 原理
- 2. 服务配置文件
- 3. 定制服务文件
- 四. DNS域名三级结构，DNS服务工作原理，涉及递归和迭代查询原理
- 1.DNS域名结构
- 2.DNS工作原理
- 3.递归查询
- 4.迭代查询
- 5. 核心区别
- 五. 实现私有DNS, 供本地网络主机作DNS递归查询。
- 1. 服务器端配置：
- 2. 客户端效果测试：
- 六. DNS服务器类型，解析答案，正反解析域，资源记录定义。
- 1. DNS服务器类型
- 2. 解析答案
- 3. 正反解析域
- 4. 资源记录
- 5. 常用命令总结
- 七. 对称加密和非对称加密，单向哈希算法的概念和加密原理
- 1 .对称加密
- 2. 非对称加密
- 3. 单向哈希算法
- 八. cdn原理
- 总结
前言
提示：这里可以添加本文要记录的大概内容：
例如：随着人工智能的不断发展，机器学习这门技术也越来越重要，很多人都开启了学习机器学习，本文就介绍了机器学习的基础内容。
一. rocky 系统的启动流程，grub工作流程
1.rocky 系统的启动流程
Rocky Linux 是一个基于 RHEL（Red Hat Enterprise Linux）的开源操作系统，其启动流程与 RHEL 类似。以下是 Rocky Linux 系统的启动流程：
- UEFi或BIOS初始化，运行POST开机自检
-
硬件自检（POST）：当计算机启动时，BIOS会执行一系列测试来检查硬件是否正常工作。如果发现问题，BIOS会通过声音或屏幕显示错误信息。 -
硬件初始化：BIOS会初始化主板上的各种硬件组件，包括CPU、内存、硬盘、显卡等，确保它们在操作系统加载前处于可用状态。
| 区别 | BIOS | UEFI |
|---|---|---|
| 接口和架构 | 使用传统的 16 位实模式接口，其代码和数据结构相对简单、固定，可扩展性较差 | 采用 32 位或 64 位的保护模式接口，基于驱动程序模型，具有更灵活的架构，支持插件式的驱动程序扩展 |
| 启动速度 | 启动过程较为复杂，需要进行一系列的初始化操作，包括自检、加载中断向量表等，启动速度相对较慢。 | 采用了更高效的启动方式，能够快速初始化硬件并加载操作系统，大大缩短了启动时间 |
| 硬件支持 | 对新硬件的支持能力有限，尤其是对于大容量硬盘、新型存储设备和一些高端硬件功能的支持可能存在问题 | 具备更好的硬件支持能力，能够识别和支持更大容量的硬盘，支持最新的硬件标准和技术，如 USB 3.0、SATA III 等 |
| 安全性 | 安全性相对较低，容易受到病毒、恶意软件等攻击，且缺乏有效的安全机制来保护系统启动过程 | 支持安全启动（Secure Boot）功能，能够验证操作系统和启动加载程序的数字签名，防止未经授权的软件在启动过程中运行，提高了系统的安全性 |
| 磁盘分区支持 | 通常使用 MBR（Master Boot Record）分区表，最多支持 4 个主分区，单个分区最大容量一般限制在 2TB 左右 | 一般使用 GPT（GUID Partition Table）分区表，支持更大数量的分区和更大的分区容量，能够满足大容量硬盘的需求 |
-
选择启动设备
根据bios设置选择启动优先级第一的设备
-
引导装载程序， centos7是grub2，加载装载程序的配置文件：
/etc/grub.d/， /etc/default/grub ，/boot/grub2/grub.cfg
-
加载initramfs驱动模块（可以实现根文件系统的挂载）
initramfs（initial ramdiskfilesystem）是一个在内存中的"临时根文件系统"，它在Linux内核启动之前被加载到内存中。
包含了内核启动所需的文件系统模块和驱动程序，使得内核能够顺利地加载真正的根文件系统。一旦真正的根文件系统加载完成，initramfs就会被卸载，系统将转移到真正的根文件系统上运行。
- 加载虚拟根中的内核
vmlinuz是一个压缩的内核镜像文件，包含了Linux内核的压缩版本以及相关的启动信息。
在系统启动时，引导加载程序（如GRUB）会加载vmlinuz文件，并将其解压缩到内存中。
然后，操作系统的控制权会转移到内核镜像，从而启动Linux操作系统。
vmlinuz文件包含了操作系统的核心功能、驱动程序和必要的文件系统支持，负责初始化硬件设备、管理 进程、提供系统调用接口等。
- 虚拟根的内核初始化，Centos7使用systemd代替init，第一个进程
| 特性 | systemd | SysVinit |
|---|---|---|
| 启动速度 | 并行启动，速度快 | 串行启动，速度较慢 |
| 启动速度 | 并行启动，速度快 | 串行启动，速度较慢 |
| 服务管理 | 统一工具（systemctl），支持依赖关系 | 分散脚本（/etc/init.d/），依赖需手动配置 |
| 系统资源监控 | 内置 cgroups 支持 | 需借助其他工具（如 top） |
| 日志系统 | 集成 journalctl | 依赖 syslog 等独立日志系统 |
| 运行级别 | 目标（target） | 概念 传统运行级别（0-6） |
- 执行initrd.target 所有单元，包括挂载 /etc/fstab
在systemd中，unit是一个基本概念，表示一个系统功能或服务。
unit表示不同类型的systemd对象，systemd会根据配置文件和设置，启动各种units，
包括服务（service）、设备（device）、挂载点（mount）、监听(socket)等。
每个unit都有一个名称和一个类型，systemd使用依赖关系来确保正确的启动顺序。
| unit类型 | 后缀 | 作用 |
|---|---|---|
| service | .service | 定义系统服务 |
| socket | .socke | t 定义进程间通信用的socket文件，可以延迟启动，按需启动 |
| target | .target | 不同服务的集合，用于模拟运行级别 |
| device | .device | 用于定义内核识别的设备 |
| mount | .mount | 定义文件系统挂载点 |
| automount | .automount | 文件系统的自动挂载点 |
| swap | .swap | 用于标识swap设备 |
| timer | .timer | 用于安排激活另一个单元的计时器 |
| path | .path | 用于定义文件系统中的文件或目录，常用于当文件系统变化时，延迟激活服务，如spool 目录 |
| slice | .slice | 通过 Linux 控制组节点 (cgroups) 限制资源 |
| scope | .scope systemd | 总线接口的信息，常用于管理外部系统进程 |
- 从initramfs根文件系统切换到磁盘根目录
挂载新根文件系统：将磁盘上的实际根分区挂载到initramfs中的临时目录（如/newroot）。准备挂载点转移：将initramfs中的关键文件系统（如/proc、/sys、/dev）重新挂载到新根文件系统的对应目录。执行 pivot_root：将根目录切换到新挂载的磁盘分区，并将initramfs移至新根下的临时目录。执行真正的 init：使用chroot命令切换到新根环境，执行系统的初始化进程（如systemd或init）。
- systemd执行默认target配置，配置文件/etc/systemd/system/default.target
[23:44:11 root@leige ~]#cat /etc/systemd/system/default.target
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Graphical Interface # 目标描述：图形界面
Documentation=man:systemd.special(7) # 文档路径
Requires=multi-user.target # 依赖：必须加载 multi-user.target
Wants=display-manager.service # 建议依赖：希望启动显示管理器服务（如gdm、lightdm）
Conflicts=rescue.service rescue.target # 冲突：与救援模式服务/目标互斥
After=multi-user.target rescue.service rescue.target display-manager.service # 启动顺序：在指定目标/服务之后启动
AllowIsolate=yes # 允许通过systemctl isolate切换到此目标
- systemd执行sysinit.target初始化系统及basic.target准备操作系统
sysinit.target 是系统启动的第一个主要目标，负责 底层系统初始化，包括：
- 挂载 /sys、/proc、/dev 等虚拟文件系统。
- 激活 swap 分区。
- 配置系统时钟（systemd-timedated）。
- 加载内核模块（如存储驱动、文件系统支持）。
- 初始化 LVM/RAID 设备。
- 生成随机数种子。
- 启动systemd-journald（系统日志服务）
basic.target 在 sysinit.target 完成后激活，负责启动 基础系统服务，包括：
- 配置网络接口（但不启动网络服务）。
- 启动用户和组管理服务。
- 设置主机名。
- 启动 cron 和 atd（任务调度服务）。
- 启动本地文件系统挂载（如/home、/opt）。
- 初始化系统语言环境。
-
systemd启动multi-user.target 下的本机与服务器服务
-
systemd执行multi-user.target 下的/etc/rc.d/rc.local
systemd通过rc-local.service服务单元控制rc.local的执行。默认情况下，若/etc/rc.d/rc.local可执行，该服务会被自动加入multi-user.target的依赖链中，并在系统初始化完成后运行
- Systemd执行multi-user.target下的getty.target及登录服务
getty（Grand Unified Terminal Type）是一个终端初始化程序，用于在终端设备（如物理控制台或虚拟终端）上创建登录界面，允许用户通过文本模式登录系统。
getty.target是一个 服务组目标（Socket/Service Target），用于统一管理所有终端的 getty服务单元。它的主要作用是： 为每个终端设备（如 tty1、tty2 等）启动对应的 getty 服务。确保终端登录服务在多用户模式下正常运行。
- systemd执行graphical需要的服务（可选）
2.grub工作流程
GRUB（GRand Unified Bootloader）是一个启动加载程序，用于启动操作系统。其配置文件在Linux系统的启动过程中起着至关重要的作用。
- Stage 1：MBR 中的引导程序存储在 MBR 的前 446 字节，负责从磁盘读取 Stage 1.5 或 Stage 2。
- Stage 1.5（可选）：当 GRUB 安装在非传统位置（如 GPT 磁盘或使用 LVM/RAID）时，Stage 1.5 用于识别文件系统（如 ext4、FAT），以便加载 Stage 2。
- Stage 2：核心引导程序加载后，GRUB 获得控制权，初始化硬件驱动（如磁盘、键盘），并读取配置文件 grub.cfg（路径：/boot/grub/grub.cfg）。grub.cfg 包含操作系统列表、内核参数、启动项等信息，通常由 grub-mkconfig 自动生成（基于 /etc/default/grub 和 /etc/grub.d/ 中的配置）。
分段存放作用：
0扇区，通过分区表，获取系统盘在哪一个分区
1-2047扇区，常见文件系统驱动，通过文件系统环境，获取读取OS文件的能力。
2048扇区+，根据配置，加载OS系统的boot启动文件信息，然后进行系统启动。
二. 内核设计流派及特点。
1、单内核（Monolithic Kernel）
设计思想：将所有系统服务（如进程管理、内存管理、文件系统、设备驱动等）集成在一个庞大的内核空间中，以单一进程形式运行。
特点：
高性能：组件间直接调用，无需跨空间通信，效率高。
结构紧凑：功能集中，代码高度整合，适合对性能要求苛刻的场景。
开发与维护复杂：模块间耦合度高，修改一个组件可能影响全局，调试难度大。
扩展性差：新增功能需修改内核代码，可能导致稳定性问题。
典型案例：
Linux（虽为单内核，但采用可加载模块（LKM）机制，允许动态添加驱动和服务，提升扩展性）。
FreeBSD、NetBSD 等传统 Unix 系统。
适用场景：
服务器、嵌入式系统（如 Android 基于 Linux 内核）、对性能敏感的桌面操作系统。
2、微内核（Microkernel）
设计思想：仅包含最核心的功能（如进程调度、内存管理、IPC（进程间通信）），其他服务（文件系统、网络协议、设备驱动等）以用户态进程形式运行。
特点：
模块化与扩展性强：非核心服务独立运行，新增功能只需修改用户态模块，不影响内核核心，便于维护和升级。
安全性高：用户态服务与内核隔离，单个模块故障不易导致系统崩溃。
跨平台性好：核心功能精简，易于移植到不同硬件架构。
性能开销大：服务间通过 IPC 通信，频繁交互会引入延迟（需优化通信机制，如消息传递、共享内存）。
典型案例：
Mach（早期微内核，用于 macOS 前身）。
QNX（实时操作系统，用于车载系统、工业控制）。
Windows NT（混合架构，部分组件借鉴微内核思想，如用户态子系统）。
适用场景：
实时系统（如汽车电子、医疗设备）、对稳定性和安全性要求高的嵌入式系统、分布式系统。
3、混合内核（Hybrid Kernel）
设计思想：融合单内核和微内核的优点，将部分性能敏感的服务（如文件系统、设备驱动）放入内核空间运行，其他服务保留在用户空间。
特点：
平衡性能与扩展性：关键服务在内核空间直接调用（减少 IPC 开销），非关键服务以用户态模块实现（降低耦合度）。
灵活可调：根据需求动态调整哪些服务在内核或用户空间运行。
典型案例：
Windows 内核（NT 架构）：内核空间包含执行体（Executive）、内核层（Kernel），用户空间包含子系统（如 Win32、POSIX）。
Linux 内核（严格属于单内核，但通过可加载模块机制实现部分混合特性）。
适用场景：
通用桌面操作系统（如 Windows、macOS）、需要兼顾性能和灵活性的场景。
4、外核（Exokernel）
设计思想：最小化内核功能，仅负责硬件资源分配和保护（如内存分区、CPU 时间片分配），应用程序直接管理资源（如文件系统、网络栈）。
特点：
极致轻量：内核仅提供底层资源抽象，不介入具体服务实现。
高定制性：应用程序可根据需求自定义资源管理逻辑，适合特定场景优化。
复杂性转移至用户空间：开发难度大，需应用层自行处理错误恢复、资源竞争等问题。
典型案例：
Nemesis（早期外核研究系统）。
SPIN（用于高性能计算和分布式系统）。
适用场景：
学术研究、高性能计算、需要高度定制化资源管理的专用系统（如云计算中的 unikernel）。
6、内核设计流派对比
| 内核类型 | 核心功能范围 | 性能 | 扩展性 | 安全性 | 典型场景 |
|---|---|---|---|---|---|
| 单内核 | 全功能集成于内核空间 | 高 | 低（依赖模块机制） | 中 | 服务器、桌面系统、嵌入式 |
| 微内核 | 仅核心功能（IPC、调度等） | 中（依赖IPC优化） | 高 | 高 | 实时系统、分布式系统 |
| 混合内核 | 关键服务在内核，其余在用户态 | 中高 | 中高 | 中高 | 通用操作系统（Windows、macOS） |
| 外核 | 仅资源分配与保护 | 极高（无内核干预） | 极高 | 高 | 定制化系统、unikernel |
三. systemd服务配置文件
1. 原理
Systemd：从 CentOS 7 版本之后开始用 systemd 实现init进程，系统启动和服务器守护进程管理
器，负责在系统启动或运行时，激活系统资源，服务器进程和其它进程
特性：
- 系统引导时实现服务并行启动
- 按需启动守护进程
- 自动化的服务依赖关系管理
- 同时采用socket式与D-Bus总线式激活服务
- socket与服务程序分离
- 向后兼容sysv init脚本
- 使用systemctl 命令管理，systemctl命令固定不变，不可扩展，
非由systemd启动的服务，systemctl无法与之通信和控制 - 系统状态快照
2. 服务配置文件
/usr/lib/systemd/system/ #每个服务最主要的脚本文件目录，类似于之前的/etc/init.d/
/run/systemd/system/ #系统执行过程中所产生的服务脚本，比上面目录优先运行
/etc/systemd/system/#管理员建立的执行脚本，类似于/etc/rcN.d/Sxx的功能，比上面目 录优先运行
查看主配置文件：
[01:29:40 root@rocky9-0 ~]#systemctl cat nginx.service
# /usr/lib/systemd/system/nginx.service
[Unit]
Description=The nginx HTTP and reverse proxy server #服务的描述信息
After=network-online.target remote-fs.target nss-lookup.target #定义启动顺序依赖
Wants=network-online.target #弱依赖关系
[Service]
Type=forking #表示 nginx 以守护进程方式启动（通过 fork() 创建子进程并退出父进程）。systemd 需通过 PIDFile 确认主进程 PID。
PIDFile=/run/nginx.pid #指定 nginx 主进程 PID 文件路径，用于 systemd 管理进程生命周期。
# Nginx will fail to start if /run/nginx.pid already exists but has the wrong
# SELinux context. This might happen when running `nginx -t` from the cmdline.
# https://bugzilla.redhat/show_bug.cgi?id=1268621
ExecStartPre=/usr/bin/rm -f /run/nginx.pid #启动前删除可能存在的旧 PID 文件，避免因旧文件的 SELinux 上下文错误导致 nginx 启动失败
ExecStartPre=/usr/sbin/nginx -t #启动前执行配置检查
ExecStart=/usr/sbin/nginx #启动 nginx 主进程的命令。
ExecReload=/usr/sbin/nginx -s reload #重载配置的命令（nginx -s reload 会平滑重启，不中断现有连接）。
KillSignal=SIGQUIT #优雅停止信号（SIGQUIT），允许 nginx 完成当前请求后退出。
TimeoutStopSec=5 #强制终止前的等待时间（5 秒）。若 5 秒内未完成优雅退出，则发送 SIGKILL 强制终止。
KillMode=mixed #混合终止模式，先终止主进程（PIDFile 中的进程），再终止所有子进程（通过 cgroup 追踪）。
PrivateTmp=true #为 nginx 创建独立的临时目录（/tmp 和 /var/tmp），与其他进程隔离，增强安全性。
[Install]
WantedBy=multi-user.target #定义服务的安装位置。multi-user.target 表示在多用户模式（非图形界面）下启动，对应系统运行级别 3。
3. 定制服务文件
示例：
自定义service的unit文件
[01:55:59 root@rocky9-0 ~]#cat /lib/systemd/system/nihao.service
[Unit]
Description=nihao
[Service]
TimeoutStartSec=0
ExecStart=/bin/sh -c "while true; do echo nihao; sleep 1; done"
ExecStop=/bin/kill sh
[Install]
WantedBy=multi-user.target
加载配置文件
[01:56:31 root@rocky9-0 ~]#systemctl daemon-reload
启动服务
[01:57:18 root@rocky9-0 ~]#systemctl enable --now nihao
Created symlink /etc/systemd/system/multi-user.target.wants/nihao.service → /usr/lib/systemd/system/nihao.service.
查看服务
[01:57:28 root@rocky9-0 ~]#systemctl status hello
Unit hello.service could not be found.
[01:57:37 root@rocky9-0 ~]#systemctl status nihao
● nihao.service - nihao
Loaded: loaded (/usr/lib/systemd/system/nihao.service; enabled; preset: disabled)
Active: active (running) since Mon 2025-05-19 01:57:28 CST; 13s ago
Main PID: 3642 (sh)
Tasks: 2 (limit: 10758)
Memory: 600.0K
CPU: 32ms
CGroup: /system.slice/nihao.service
├─3642 /bin/sh -c "while true; do echo nihao; sleep 1; done"
└─3658 sleep 1
May 19 01:57:32 rocky9-0.14 sh[3642]: nihao
May 19 01:57:33 rocky9-0.14 sh[3642]: nihao
May 19 01:57:34 rocky9-0.14 sh[3642]: nihao
May 19 01:57:35 rocky9-0.14 sh[3642]: nihao
May 19 01:57:36 rocky9-0.14 sh[3642]: nihao
四. DNS域名三级结构，DNS服务工作原理，涉及递归和迭代查询原理
1.DNS域名结构
DNS（Domain Name System）是一种分层、分布式数据库系统，用于将人类可读的域名转换为机器可读的IP地址。其结构设计为树状层次模型，从根域向下延伸，包含顶级域、二级域等子域划分，并通过递归或迭代查询实现域名解析。以下是DNS的核心结构组成和解析流程的详细分析：
- 域名层次结构
DNS的命名空间采用倒置树状结构，由多个层级组成，从右向左解析：
根域（.）：位于最顶层，全球仅13台根服务器（1台主根在美国，其余12台辅根分布于美国、欧洲、亚洲等地），负责指向顶级域服务器。
顶级域（TLD）：如、、等，分为通用顶级域（gTLD）和国家代码顶级域（ccTLD）。
二级域（SLD）：用户可注册管理的部分（如baidu中的baidu），其下可进一步划分子域（如mail.baidu）。
2.DNS工作原理
解析过程
本地缓存查询首先检查本地 DNS 缓存（浏览器、操作系统或路由器缓存），若有记录则直接返回 IP，无需联网。递归解析器请求若缓存中无记录，递归解析器（如运营商 DNS）向 根域名服务器 发送请求，根服务器返回 顶级域名服务器的地址。顶级域名服务器查询递归解析器向 顶级域名服务器请求，获取 biadu 权威服务器的地址。权威域名服务器响应递归解析器向 baidu 的权威服务器请求，权威服务器返回 www.baidu 对应的 IP 地址。返回结果递归解析器将 IP 地址返回给用户，并缓存结果以便后续使用。
3.递归查询
- 客户端向本地DNS服务器（如ISP提供的服务器）发送查询请求。
- 本地DNS服务器依次查询缓存、根服务器、顶级域名服务器、权威服务器，直到获得IP地址或错误信息。
- 结果返回：服务器将最终结果返回客户端，并缓存以提升后续效率
4.迭代查询
迭代查询又称重指引，当服务器使用迭代查询时能够使其他服务器返回一个最佳的查询点提示或主机地址。
- 客户端向本地DNS服务器发起递归查询请求。
- 若本地DNS服务器无缓存记录，则开始迭代查询：
· 首先查询根域名服务器，获取顶级域名服务器的IP地址；
· 接着查询顶级域名服务器，获取权威DNS服务器的地址；
· 最后查询权威DNS服务器，获取域名的最终IP地址。 - 本地DNS服务器将最终结果返回给客户端，完成递归查询。
5. 核心区别
| 维度 | 递归查询 | 迭代查询 |
|---|---|---|
| 发起方 | 客户端（由本地 DNS 服务器代理查询） | 客户端或 DNS 服务器（主动逐次查询） |
| 服务器行为 | 全程代理，直到返回结果 | 仅返回下一步服务器地址，不代理查询 |
| 查询次数 | 客户端仅一次请求（内部可能多次查询） | 多次请求（逐层级查询） |
| 典型场景 | 客户端 → 本地 DNS 服务器 | 本地 DNS 服务器 → 根服务器 → 顶级域服务器 → 权威服务器 |
| 协议支持 | 通常基于 UDP/53（递归服务器处理细节） | 基于 UDP/53，需客户端实现多步逻辑 |
| 资源消耗 | 递归服务器负担较重 | 分布式负担，单个服务器压力较小 |
五. 实现私有DNS, 供本地网络主机作DNS递归查询。
在自建的DNS服务中实现域名的自解析
1. 服务器端配置：
新增 zones 记录
root@ubuntu2402-013:~# tail -n5 /etc/bind/named.conf.default-zones
zone "test" {
type master;
file "/etc/bind/db.test";
};
设置具体解析规则
root@ubuntu2402-013:~# cat /etc/bind/db.test
test. 86400 IN SOA test-dns. admin.test. ( 123 3H 15M 1D 1W )
test. 86400 IN NS dns1.test. #指定域名指向权威DNS服务器
dns1.test. 86400 IN A 10.0.0.13 #正向解析记录
www.test. 86400 IN A 10.0.0.13 #正向解析记录
* 86400 IN A 10.0.0.199 #泛域名解析
查看规则文件的权限、修改权限，修改属主属组
root@ubuntu2402-013:~# ll /etc/bind/db.0
-rw-r--r-- 1 root root 255 Sep 23 2024 /etc/bind/db.0
root@ubuntu2402-013:~# chmod 644 /etc/bind/db.test
root@ubuntu2402-013:~# chown root:root /etc/bind/db.test
root@ubuntu2402-013:~# ll /etc/bind/db.test
-rw-r--r-- 1 root root 228 May 18 18:58 /etc/bind/db.test
语法检查
root@ubuntu2402-013:~# named-checkzone test /etc/bind/db.test
zone test/IN: loaded serial 123
OK
重载生效
root@ubuntu2402-013:~# rndc reload
server reload successful
在web服务主机上实现网站
部署nginx服务
root@ubuntu2402-013:~# apt update;apt install -y nginx
本机测试
root@ubuntu2402-013:~# curl localhost
www.test --- this page from 10.0.0.13
root@ubuntu2402-013:~# curl 10.0.0.13
www.test --- this page from 10.0.0.13
2. 客户端效果测试：
修改本地DNS服务器
[03:02:18 root@rocky9-0 ~]#cat /etc/resolv.conf
# Generated by NetworkManager
search localdomain 14
#nameserver 10.0.0.2
nameserver 10.0.0.13
客户端测试域名
[03:02:20 root@rocky9-0 ~]#host www.test
www.test has address 10.0.0.13
[03:02:34 root@rocky9-0 ~]#curl www.test
www.test --- this page from 10.0.0.13
[03:02:49 root@rocky9-0 ~]#ping www.test -c1
PING www.test (10.0.0.13) 56(84) bytes of data.
64 bytes from 10.0.0.13 (10.0.0.13): icmp_seq=1 ttl=64 time=0.165 ms
--- www.test ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.165/0.165/0.165/0.000 ms
泛域名测试
[03:03:15 root@rocky9-0 ~]#ping 32323.test -c1
PING 32323.test (10.0.0.199) 56(84) bytes of data.
^C
--- 32323.test ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
[03:03:37 root@rocky9-0 ~]#host 3232.test
3232.test has address 10.0.0.199
windows客户端测试
禁用网卡
修改虚拟机网卡DNS服务器
C:\Users\Administrator>ipconfig/flushdns
Windows IP 配置
已成功刷新 DNS 解析缓存。
C:\Users\Administrator>curl www.test.com
www.test.com --- this page from 10.0.0.13
六. DNS服务器类型，解析答案，正反解析域，资源记录定义。
1. DNS服务器类型
主域名服务器
负责维护一个区域的所有域名信息，是特定的所有信息的权威信息源，数据可以修改。
辅助域名服务器
当主域名服务器出现故障、关闭或负载过重时，辅助域名服务器作为主域名服务器的备份提供域名解析服务。辅助域名服务器中的区域文件中的数据是从另外的一台主域名服务器中复制过来的，是不可以修改的。
缓存域名服务器
从某个远程服务器取得每次域名服务器的查询回答，一旦取得一个答案就将它放在高速缓存中，以后查询相同的信息就用高速缓存中的数据回答，缓存域名服务器不是权威的域名服务器，因为它提供的信息都是间接信息。
转发域名服务器
负责所有非本地域名的本地查询。转发域名服务器接到查询请求后，在其缓存中查找，如找不到就将请求依次转发到指定的域名服务器，直到查找到结果为止，否则返回无法映射的结果。
2. 解析答案
肯定答案：存在对应的查询结果否定答案：请求的条目不存在等原因导致无法返回结果权威答案：直接由存有此查询结果的DNS服务器（权威服务器）返回的答案非权威答案：由其它非权威服务器返回的查询答案
3. 正反解析域
- 正向解析域（Forward Lookup Zone）
定义：将域名转换为 IP 地址的解析区域，存储A 记录（IPv4）或AAAA 记录（IPv6）。
核心作用：
用户访问网站时，浏览器通过正向解析获取服务器 IP 地址（如www.example → 192.168.1.1）。
支持泛域名解析（如*.example），简化子域名管理。
配置示例：
@ IN SOA ns.example. admin.example. (
2025051901 ; 序列号
3600 ; 刷新时间
1800 ; 重试时间
86400 ; 过期时间
3600 ) ; 否定缓存时间
@ IN NS ns.example.
@ IN A 192.168.1.1
www IN A 192.168.1.2
mail IN A 192.168.1.3
- 反向解析域（Reverse Lookup Zone）
定义：将 IP 地址转换为域名的解析区域，存储PTR 记录。
配置示例：
@ IN SOA ns.example. admin.example. (
2025051902
3600
1800
86400
3600 )
@ IN NS ns.example.
1 IN PTR example.
2 IN PTR www.example.
3 IN PTR mail.example.
4. 资源记录
区域解析库：由众多资源记录RR(Resource Record)组成
| 记录类型 | 定义 |
|---|---|
| SOA Start Of Authority | 起始授权记录；一个区域解析库有且仅能有一个SOA记录，必须位于解析库的第一条记录 |
| A：internet Address， | 将域名映射到 IPv4 地址（正向解析）。FQDN --> IP |
| AAAA： | 将域名映射到 IPv4 地址（正向解析）。FQDN --> IPv6 |
| PTR：PoinTeR | 将IP 地址映射到域名（反向解析）IP --> FQDN |
| NS：Name Server | 专用于标明当前区域的DNS服务器 |
| CNAME ： Canonical Name， | 为域名创建别名，实现同一资源的不同域名访问 |
| MX：Mail eXchanger， | 指定邮件服务器的域名及优先级，用于邮件路由。 |
| TXT： | 对域名进行标识和说明的一种方式，一般做验证记录时会使用此项，如：SPF（反垃圾邮件）记录，https验证等，如下示例： |
5. 常用命令总结
dig：(Domain Information Groper) 域名信息查询工具
dig 命令不会查询本地 hosts文件中定义的域名和IP对应关系，但是在systemd-resloved服务帮助下，
会使用hosts文件里面的记录。
[01:43:50 root@rocky9-0 ~]#dig www.baidu
; <<>> DiG 9.16.23-RH <<>> www.baidu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35305
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.baidu. IN A
;; ANSWER SECTION:
www.baidu. 5 IN A 183.240.99.169
;; Query time: 3 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Mon May 19 01:43:59 CST 2025
;; MSG SIZE rcvd: 47
host 命令可以根据域名查询得到对应的服务器IP地址
host 命令不会查询本地 hosts文件中定义的域名和IP对应关系，但是在systemd-resloved服务帮助下，
会使用hosts文件里面的记录。
[01:44:05 root@rocky9-0 ~]#host wwww.baidu
wwww.baidu is an alias for ps_other.a.shifen.
ps_other.a.shifen has address 110.242.68.66
nslookup：(name server lookup)，一个命令行下的网络工具，主要用来查询DNS记录，查看域名解析是否正常，也可用来诊断网络问题
nslookup 支持交互式和非交互式两种执行方式，在Windows系统中和Linux系统中都可以使用 当/etc/hosts文件里面存在 域名解析记录的时候，在systemd-resolved服务的帮助下，会使用hosts文件里面的域名和ip解析记录
[01:45:22 root@rocky9-0 ~]#nslookup wwww.baidu
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
Name: wwww.baidu
Address: 110.242.68.66
wwww.baidu canonical name = ps_other.a.shifen.
whois命令是一个用于查询域名和IP地址注册信息的工具，它可以帮助用户获取有关域名或IP地址的所
有者、注册商、注册日期、到期日期以及其他相关信息。
[01:47:54 root@rocky9-0 ~]#whois www.baidu
No match for "WWW.BAIDU.COM".
>>> Last update of whois database: 2025-05-18T17:47:41Z <<<
NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.
......
七. 对称加密和非对称加密，单向哈希算法的概念和加密原理
1 .对称加密
对称加密（Symmetric Key Encryption）是采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。
特性：
- 加密、解密使用同一个密钥，效率高；
- 将原始数据分割成-固定大小的块-，逐个进行加密
- 加密解密双方需要协商使用哪一种秘钥信息
缺陷：
- 密钥过多
- 密钥分发，无法保证获得秘钥的人都是好人。
- 数据来源无法确认
2. 非对称加密
对称加密算法（Asymmetric Key Encryption）在加密和解密时使用的是同一个秘钥；而非对称加密算法需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。
加密的两种方式：
1、用公钥加密数据，只能使用与之配对的私钥解密； 问题 - 因为公钥公开的原因，接收数据的一方，无法保证数据的来源是安全的。
2、用私钥加密数据，只能使用与之配对的公钥解密 问题 - 因为公钥公开的原因，发送数据的一方，加密数据在互联晚上几乎是裸奔。
特性：
数据加密：适合加密较小数据，比如: 加密对称密钥
数字签名：主要在于让接收方确认发送方身份
- 密钥长，算法复杂
- 加密解密效率低下，据说加密1分钟，解密数小时。
3. 单向哈希算法
单向哈希算法（One-Way Hash Algorithm），又称加密哈希函数（Cryptographic Hash Function），是一种将任意长度的输入数据映射为固定长度哈希值（Hash Value）的算法。其核心特性是单向性（不可逆），即从哈希值无法反向推导出原始数据，因此常用于数据完整性校验、密码存储、数字签名等场景。
核心特性
单向性（不可逆性）
输入数据通过哈希算法生成哈希值后，无法通过哈希值反推出原始输入。这是与加密算法（如 AES）的本质区别（加密算法可解密还原数据）。
确定性（一致性）
相同的输入数据必定生成相同的哈希值，无论计算多少次，结果始终一致。
固定输出长度
无论输入数据长度如何（如 1 字节或 1GB），哈希值的长度始终固定（如 MD5 输出 128 位，SHA-256 输出 256 位）。
快速计算
哈希算法需在合理时间内完成计算，适合处理大规模数据。
雪崩效应（Avalanche Effect）
输入数据的微小变化（如 1 位翻转）会导致哈希值发生显著变化，确保数据的敏感性。
抗碰撞性（Collision Resistance）
弱抗碰撞：难以找到两个不同的输入生成相同的哈希值。
强抗碰撞：在整个输入空间中，无法找到任意两个不同输入生成相同哈希值。
抗碰撞性是哈希算法安全性的核心指标。
典型应用场景：
数据完整性校验
验证文件是否被篡改：下载文件时对比官方哈希值（如 Linux 镜像的 SHA-256 校验）。
原理：原始文件哈希值与传输后的文件哈希值对比，一致则未被篡改。
密码存储
不存储用户明文密码，仅存储哈希值。用户登录时，将输入密码哈希后与数据库中的哈希值比对。
加盐（Salting）：为每个用户添加随机字符串（盐值），避免彩虹表攻击（如 Hash(密码 + 盐值)）。
示例：现代网站普遍使用 Bcrypt、Argon2 等慢哈希算法（增加破解时间）。
数字签名
对数据哈希后，用私钥加密哈希值生成签名，接收方用公钥解密并比对哈希值，确保数据完整性和身份认证（如 HTTPS 的 TLS 证书）
八. cdn原理
CDN （Content Delivery Network）内容分发网络
解析过程
- 用户向浏览器输入www.a这个域名，浏览器第一次发现本地没有dns缓存，则向网站的DNS服
务器请求 - 网站的DNS域名解析器设置了CNAME，指向了www.a.tbcdn,请求指向了CDN网络中的智能
DNS负载均衡系统 - 智能DNS负载均衡系统解析域名，把对用户响应速度最快的IP节点返回给用户；
- 用户向该IP节点（CDN服务器）发出请求
- 由于是第一次访问，CDN服务器会通过Cache内部专用DNS解析得到此域名的原web站点IP，向原
站点服务器发起请求，并在CDN服务器上缓存内容 - 请求结果发给用户
CND节点在线测试：https://tool.chinaz
监测节点数 77
最快(广东广州) 0.051s
最慢(浙江杭州) 1.083s
平均响应 0.212s
总结：CDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输得更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。
总结
提示：这里对文章进行总结：
例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。
发布评论