1. 操作系统 —— 进程、线程
一个进程内的线程共享进程级资源,如代码段、数据段、堆、已打开文件、信号量、定时器等;但每个线程有自己私有的运行时上下文,包括寄存器集合(其中包含栈指针SP)、线程栈、线程局部存储等,这些不能被其他线程共享。
2. 操作系统 —— 文件系统 —— 磁盘空间管理
假设某计算机的字长为32位,该计算机文件管理系统磁盘空间管理采用位示图(bitmap)记录磁盘的使用情况。若磁盘的容量为300GB,物理块的大小为4MB,那么位示图的大小为(__)个字。
A.2400 B.3200 C.6400 D.9600
思考方向:
总容量 -> 算块数 -> 算bit数 -> 根据字长算字数
第一步:理解位示图的核心规则
在位示图法中,1个二进制位(1 bit)刚好对应磁盘上的 1个物理块。
所以,我们要算出位示图需要多少个 bit,就必须先算出这个磁盘一共有多少个物理块。
第二步:计算磁盘上一共有多少个物理块
已知条件:磁盘总容量是 300GB,每个物理块的大小是 4MB。
单位换算:因为块的大小是 MB,我们需要先把总容量从 GB 换算成 MB。在计算机操作系统中,通常按照 1GB = 1024MB 来计算。
磁盘总容量 = 300 GB =307200 MB
计算块数:物理块总数 = 磁盘总容量 ÷ 物理块大小
物理块总数 = 307200 MB ÷ 4 MB =76800 个块
第三步:计算位示图需要多少个 bit
既然有 76800 个物理块,根据“1 bit 管 1 个块”的原则,位示图总共需要:
位示图总位数 =76800 bit
第四步:将 bit 转换成题目要求的单位“字”
题目问的是“位示图的大小为多少个字”。
已知条件:计算机的字长为 32 位。这意思是说,在这台计算机里,1 个字 = 32 bit。
计算字数:位示图的字数 = 位示图总位数 ÷ 字长
位示图的字数 = 76800 bit ÷ 32 bit/字 =2400 个字
基础知识点
1. 内存中的位示图(Bitmap)是什么样?
操作系统会在内存中开辟一小块空间,用一串二进制位来一一对应这8个硬盘块的状态。
如果在内存中,这串 bit 是这样的:
1 | 0 | 1 | 1 | 0 | 0 | 1 | 1(Bit 编号:0 1 2 3 4 5 6 7)
我们通常规定:1 代表已分配(已被占用),0 代表空闲。
2. 它们是如何对应的?
【内存中的位示图 (Bitmap)】 每个格子是 1 个 bit,编号对应硬盘块号。 块号: 0 1 2 3 4 5 6 7 ┌──┬──┬──┬──┬──┬──┬──┬──┐ 状态: │ 1│ 0│ 1│ 1│ 0│ 0│ 1│ 1│ (1=已分配, 0=空闲) └──┴──┴──┴──┴──┴──┴──┴──┘ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ | | | | | | | | |一|对|一|的|映|射|关|系| | | | | | | | | ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ 【硬盘物理块 (Disk Blocks)】 块号: 0 1 2 3 4 5 6 7 ┌──┬──┬──┬──┬──┬──┬──┬──┐ 实际: │用│空│用│用│空│空│用│用│ └──┴──┴──┴──┴──┴──┴──┴──┘ (数据) (空闲) (数据) (数据) (空闲) (空闲)3. 这个“图”如何工作?
当操作系统需要在这个硬盘上存一个新文件(需要1个空闲块)时:
扫描位示图:操作系统在内存中飞快地扫描这串 bit (
10110011)。查找“0”:它会寻找第一个出现的“0”。在我们的例子中,第一个“0”出现在编号 1的位置。
分配与标记:操作系统就知道“硬盘上的块1是空的”。于是它把文件写入硬盘块1,并立刻把内存位示图中的第1位从“0”改为“1”。
3. 实时操作系统
实时操作系统主要用于有实时要求的过程控制等领域。因此,在实时操作系统中,对于来自外部的事件必须在()。
A. 一个时间片内进行处理
B. 一个周转时间内进行处理
C. 一个机器周期内进行处理
D. 被控对象允许的时间范围内进行处理
解析:
A. 一个时间片内进行处理 —— 时间片属于分时操作系统的调度策略
B. 一个周转时间内进行处理 —— 周转时间是指任务提交到完成的总时间,是评价批处理系统效率的指标
C. 一个机器周期内进行处理 —— 机器周期非常短(纳秒级),通常不能作为实际控制任务的响应上限,且不具有实际工程意义
选择D
实时操作系统(RTOS)是一类能够在严格时间约束条件下完成任务处理的操作系统,广泛应用于工业控制、航空航天、军事、汽车电子等对响应时间有明确限制的系统中。
4. 关系数据库
派生属性
派生属性是指能够通过其他属性计算得到的属性,不应直接存储在关系模式中,而应在查询时动态计算。
比如 出生日期 —— 年龄
属性闭包 + 候选码
什么是属性闭包?
属性闭包(Attribute Closure)就是指:在已知某些属性的情况下,根据给定的规则(即函数依赖)能够推导出所有属性的集合。
专业的定义与符号表示
为什么要求属性闭包?
求属性闭包最大的实际应用之一就是寻找候选码(Candidate Key)
只要一个属性(或属性组)的闭包包含了该关系模式中的所有属性(也就是说,凭借它可以推导出所有其他属性的数据),它就有资格成为“超码”。如果在这个属性组里去掉任何一个属性,它就推导不出所有属性了(满足最小性),那么它就是“候选码”。
答案 D A
5. 分布式数据库
分布式数据库系统通常具备四种透明性:分片透明性、复制透明性、位置透明性和局部映像透明性(又称逻辑透明性),它们共同目的是让用户在使用数据时无需关心底层数据的组织与存储方式。
| 透明性类型 | 核心概念 | 解决的抽象层面 |
| 分片透明(Fragmentation) | 用户无需了解数据是如何被水平或垂直切分的,系统会自动定位相应的片段。 | 数据拆分结构 |
| 位置透明(Location) | 用户无需知道数据的物理存放站点;数据在节点间迁移时,应用程序代码无需修改。 | 物理存储位置 |
| 复制透明(Replication) | 用户无需关心数据在网络中存在多少个副本,系统会在后台自动完成多副本的同步、更新与维护。 | 数据冗余与副本 |
逻辑透明(Logical) (局部映像透明) | 用户无需关心各个物理站点具体使用的是什么数据库系统(如 Oracle、MySQL)及操作语言,系统会自动进行转换。 | 数据模型与操纵语言 |
6. 分页内存管理
分页内存管理的核心是将虚拟内存空间和物理内存空间皆划分为大小相同的页面,并以页面作为内存空间的最小分配单位。下图给出了内存管理单元的虚拟地址到物理地址的翻译过程,假设页面大小为4KB,那么CPU发出虚拟地址0010000000000100后,其访问的物理地址是(__)。
A.0110000000000100
B.0100000000000100
C.1100000000000000
D.1100000000000010
思考方向 :算偏移位数 -> 切分虚拟地址 -> 查表拼装物理地址
第一步:确定页内偏移的长度
虚拟地址和物理地址都是由两部分组成的:
虚拟地址= [虚拟页号] + [页内偏移]
物理地址= [物理块号/页框号] + [页内偏移]
关键点:无论怎么转换,“页内偏移”是完全不变的。我们只需要把前面的“虚拟页号”替换成“物理块号”即可。
要知道从哪里把地址切开,我们需要看页面大小 -->页内偏移
题目已知:页面大小为 4KB。
换算单位:4KB = 2^12 B
故地址的最后 12 位是页内偏移
第二步:提取页号和偏移量
CPU 发出的虚拟地址:0010000000000100(总共 16 位)
前面的部分(虚拟页号):
0010(转换成十进制就是2)后面的部分(页内偏移):
000000000100
第三步:查表替换(得到物理地址)
现在我们知道该虚拟地址对应的是第 2 页。接下来就要去“页表”里查,第 2 页被放在了内存的哪个物理块里。
查页表:在图中找到左侧索引为2的那一排。
找物理块号:对应的值是
110(后面的1是状态位,表示该页已调入物理内存)。拼装结果:将查到的物理块号
110,直接拼接上我们第二步保留下来的页内偏移000000000100。
拼接后的物理地址:1100000 0000 0100(15位) ——> 01100000 0000 0100(16位)
段页式内存管理
段页式管理结合了段式和页式的优点,先按程序的逻辑结构分为若干段,每段有独立的段号和段长,再将每个段分为若干等长的页。段页式管理需要段表(存放每段的页表起始地址)和页表(存放页号到物理块号的映射)共同完成地址转换。
其他真题选项
- 一个程序就是一段,使用基址极限对来进行管理:这是分区式管理的一种形式
- 一个程序分为许多固定大小的页面,使用页表进行管理:这是典型的页式存储管理方法
- 程序按逻辑分成多段,用一组基址极限对来进行管理,基址极限对存放在段表里:这是标准的段式管理描述
7. 区块链系统 —— “挖矿”机制
选项D:双花攻击的防御机制源于区块链结构本身(如最长链原则)和时间戳机制,但这些机制依赖于‘挖矿’所提供的工作量证明来赋予其安全性。中本聪设计的整个区块链系统(包括时间戳、共识机制以及作为其动力的挖矿)才是防止双重支付的关键。
在区块链的世界里,“挖矿”(Mining)其实是一个形象的借喻。从系统架构的设计层面来看,它本质上是分布式系统中的一种去中心化共识机制(主要是工作量证明,PoW)。 —— 选项C
简单来说,“挖矿”就是网络中的节点(矿工)通过消耗计算资源,竞争解决一个复杂的数学难题,从而获得打包交易、生成新区块的记账权,并以此获得系统发放的加密货币奖励的过程。 —— 选项A
7.1 核心原理:工作量证明 (Proof of Work, PoW)
这是挖矿的灵魂。因为在没有中心服务器的区块链网络中,必须防止有人恶意快速生成假账本。PoW 要求节点必须付出实打实的算力成本才能生成区块,从而提高了作恶的经济门槛。
7.2 数学难题与哈希函数 (Hash Function)
矿工们到底在算什么?其实是在做海量的“随机碰撞”。 —— 选项B
系统要求矿工将区块头(Block Header)的信息(包含前一个区块的哈希值、当前交易数据的默克尔树根、时间戳等)加上一个随机数(Nonce),进行 SHA-256 哈希运算。
运算出的结果必须满足一个特定的条件:前导零的个数必须达到系统要求。用数学公式表示就是:Hash(Block_Header + Nonce) ≤ Target
因为哈希函数的结果是完全随机且不可逆的,矿工只能不断地更换 Nonce 的值,一次又一次地计算,直到“蒙”对为止。这就是所谓的“算力竞争”。
7.3 难度动态调整 (Difficulty Adjustment)
系统如何保证出块时间的稳定?(例如比特币大约每 10 分钟出一个块)。
系统会根据全网算力的增减,自动调整上述公式中的 Target(目标值)。全网算力越强,要求的“前导零”就越多,找到正确 Nonce 的难度就呈指数级上升,以此来维持系统设计的出块节奏。
7.4 默克尔树 (Merkle Tree)
在验证交易时,系统不可能每次都遍历几千笔交易。默克尔树是一种二叉树结构,它将区块体内的所有交易数据两两哈希,最终生成一个唯一的“默克尔根(Merkle Root)”存放在区块头中。只要有任何一笔交易被篡改,默克尔根就会发生雪崩式的改变,这极大提升了系统校验数据的效率和安全性。
7.5 分叉与最长链原则 (Longest Chain Rule)
在极小的概率下,如果两个矿工同时算出了正确的哈希值,各自广播了新区块,系统该听谁的?
此时区块链会发生短暂的“分叉”。系统的规则是:只承认积累了最多工作量(即最长)的那条链为合法主链。其他节点会继续在他们最先收到的链上挖矿,随着时间推移,算力集中的那条链会迅速变长,另一条短链(孤块)就会被废弃,其包含的交易会被重新打回交易池。
7.6 激励模型 (Incentive Model)
为什么节点愿意耗费巨大的电力去计算?因为利益。挖矿成功的节点会获得双重收益:
出块奖励(Coinbase 交易):系统凭空增发给矿工的数字货币。
交易手续费:打包进该区块的所有交易所支付的“网络拥堵费”。
7.7 PoW 与 PoS 的核心架构对比
| 架构维度 | 工作量证明 (PoW - Proof of Work) | 权益证明 (PoS - Proof of Stake) |
| 核心机制 | 算力竞争:谁的计算速度快,谁就更有概率获得记账权。 | 资产质押:谁质押(锁定)在系统中的代币多、时间长,谁就更有概率被系统随机选中去记账。 |
| 节点角色 | 矿工(Miner) | 验证者(Validator) |
| 资源消耗 | 极高:需要消耗海量的电力和专门的硬件(如 ASIC 矿机)。 | 极低:几乎不需要额外的物理计算资源,普通服务器即可运行。 |
| 性能与吞吐量 (TPS) | 低:为了保证网络有足够的时间同步和验证复杂计算,出块时间通常被拉长(例如比特币约 10 分钟出块,TPS 在 7 左右)。 | 高:省去了繁重的哈希计算过程,出块速度极快,系统吞吐量(TPS)可以达到数千甚至更高。 |
| 安全性与攻击成本 | 51% 算力攻击:攻击者需要掌握全网 51% 以上的物理算力,成本极其高昂且极难实现。 | 51% 资产攻击:攻击者需要买下全网 51% 的质押代币。这会导致代币价格暴涨,且作恶会导致自身资产大幅贬值,经济上吃力不讨好。 |
| 架构设计初衷 | 追求极致的去中心化和绝对的安全性,宁愿牺牲性能。 | 解决 PoW 的能耗问题,并大幅提升系统的可扩展性(Scalability)。 |
7.8 公链与联盟链共识机制核心对比
| 架构维度 | PoW (工作量证明) | PoS (权益证明) | PBFT (实用拜占庭容错) |
| 典型代表 | 比特币 (Bitcoin) | 以太坊 (Ethereum 2.0) | 超级账本 (Hyperledger Fabric) |
| 适用网络架构 | 公有链 (完全开放) | 公有链 (完全开放) | 联盟链 / 私有链 (需许可准入) |
| 信任基础 | 物理算力成本 | 资产质押博弈 | 身份认证与节点白名单 |
| 性能吞吐量 (TPS) | 极低 (约 7-15) | 较高 (千级别) | 极高(万级别及以上) |
| 节点扩展性 | 无上限 (可达数万节点) | 较大 (数千节点) | 较差(通常在百个节点以内) |
| 数据最终性 (Finality) | 概率最终性 (存在分叉风险) | 概率/确定最终性 (视协议而定) | 绝对最终性(一经确认,绝不分叉) |
| 资源消耗 | 极高 (电力、矿机) | 极低 (普通服务器) | 极低 (常规网络与计算资源) |
8.Linux 系统
/etc/hostname:该文件用于存储当前主机的主机名
/dev/host.conf:不存在该路径,且 host.conf 文件的正确路径为 /etc/host.conf,它用于设置主机名解析顺序
/etc/resolv.conf:是 DNS 的主要配置文件,包含 nameserver、domain、search 等指令,指定 DNS 服务器 IP、默认域名和搜索域名顺序 ✔
/dev/name.conf:不存在该文件路径和用途
Linux 域名解析顺序
当我们在 Linux 终端输入ping www.google.com时,系统并不是直接去问/etc/resolv.conf里的 DNS 服务器,而是有一个严格的查询顺序:
本地缓存 / 浏览器缓存:首先看之前是否刚刚解析过。
本地静态映射 (
/etc/hosts):系统会优先查阅这个文件。如果你在这个文件里写死了一行127.0.0.1 www.google.com,那么系统就会直接把请求发给本地,根本不会去请求外网的 DNS 服务器。在开发测试、屏蔽广告或内网环境中,这个文件非常有用。DNS 配置文件 (
/etc/resolv.conf):只有当本地/etc/hosts里找不到时,系统才会去查看/etc/resolv.conf,向里面配置的nameserver(如8.8.8.8)发起网络查询。
谁来决定这个顺序?是由/etc/nsswitch.conf(Name Service Switch) 这个文件决定的。里面有一行hosts: files dns,明确规定了先找files(即 /etc/hosts),再找dns(即 /etc/resolv.conf)。
有时会出现的问题:修改 resolv.conf 会失效
在早期的 Linux 中,直接使用vim /etc/resolv.conf修改 DNS 是标准做法。但在现代 Linux 发行版(如 Ubuntu 18.04+、CentOS 8+)中,如果你直接修改它,重启网络后配置往往会丢失。
原因:现代系统引入了NetworkManager或systemd-resolved这样的动态网络管理守护进程。
现状:现在的
/etc/resolv.conf往往只是一个软链接(Symlink),指向由这些守护进程动态生成的文件(例如/run/systemd/resolve/stub-resolv.conf)。正确做法:现在修改 DNS,通常需要通过修改网卡配置文件(如 Ubuntu 的
/etc/netplan/*.yaml,或 CentOS/RHEL 的/etc/sysconfig/network-scripts/ifcfg-*),或者使用nmcli命令行工具,让系统网络管理器去自动更新resolv.conf。
9. 网络延迟
网络延迟通常由处理延迟、排队延迟、发送延迟和传播延迟构成。在服务器端,队列延迟(请求在队列中等待处理的时间)和磁盘 I/O 延迟(数据从磁盘读写所需的时间)是主要影响因素。
真题选项
- 在对等网络中,终端数量增多会导致每个节点分配到的转发时隙变小,从而延迟增大
- 路由器采用存储转发方式,延迟通常大于交换机(直接转发)
- Internet 服务传输路径长、节点多、流量大,延迟通常更大,不会最小化延迟
- 队列延迟和磁盘 I/O 延迟确实是服务器延迟的重要来源
10. 系统监视的常用方法与工具
系统监视是系统管理员和运维人员保障系统稳定运行的重要手段,有三种常见方式:
- 直接使用系统命令,如 UNIX/Linux 系统中的 ps、last 等
- 查阅日志文件,通过系统记录文件查阅系统在特定时间内的运行状态
- 使用综合监控工具,如集成命令、文件记录和可视化技术的监控工具等
其他真题选项
- 系统调用:这是应用程序与操作系统内核交互的接口,用于实现功能调用
- 系统接口:指系统对外提供的调用接口
- Windows 的 netstat:用于查看网络连接和端口状态,命令行工具
- Linux 的 iptables:是防火墙规则配置工具
- Windows 的 Perfmon:性能监视器(Performance Monitor),集成了命令、日志、可视化图表等功能,可监控 CPU、内存、磁盘、网络等多方面的性能,是典型的综合监控工具
- Linux 的 top:用于动态查看进程和资源占用情况,命令行工具
11. 电子政务的主要互动模式及其业务范围
电子政务通常分为以下几类:
政府对政府(G2G):包括政府内部或不同政府机构之间的信息采集、处理与共享、决策支持等业务 —— 人口信息采集、处理和利用业务
政府对企(事)业单位(G2B):包括政策发布、审批许可、营业执照颁发等为企业提供的服务
政府对居民(G2C):包括证件管理、公共安全信息、公共服务等面向居民的业务 —— 户籍管理业务
企业对政府(B2G):包括企业为政府提供服务、参与政府项目投标、纳税等活动 —— 参加政府工程投标活动
12. 软件工程
软件需求开发
在需求开发阶段,会形成包括项目范围文档、用例文档、软件需求规格说明书(SRS)、以及分析模型在内的一系列成果。这些成果在经过正式的需求评审并获得批准后,会形成(需求基线),它在客户和开发者之间构筑了产品功能需求和非功能需求的一个(需求约定), 是需求开发和需求管理之间的桥梁。
软件生命周期模型
软件过程是制作软件产品的一组活动及其结果。这些活动主要由软件人员来完成,软件活动主要包括软件描述、(软件开发)、软件有效性验证和(软件演化)。 其中,(软件描述)定义了软件功能以及使用的限制。
软件开发工具的分类及需求分析工具的类型
结构化设计
软件质量属性与信息隐蔽原则
基于构件的软件工程(CBSE)
敏捷开发
自动化测试
软件开发 —— 基于架构的软件开发(ABSD)
13. 软件架构评估
什么是敏感点和权衡点?
- 敏感点是指某个或某些构件的特性对某一质量属性的表现有显著影响,一旦该特性发生改变,质量属性的表现会有明显变化。
- 权衡点是指影响多个质量属性的特性,并且这些质量属性之间可能存在冲突,因此权衡点同时也是多个质量属性的敏感点。
答案 B A B
三层 C/S 架构
其他真题选项
- 内容分发:主要用于网络内容加速
- 镜像:是数据或系统的备份方式
设计模式
软件质量属性场景与常见架构策略(战术)
| 质量属性 | 核心关注点 | 典型架构策略 |
|---|---|---|
| 性能 | 响应时间、吞吐量 | 资源调度、缓存、异步处理 |
| 可用性 | 故障恢复、持续服务 | 心跳、主备切换、冗余设计 |
| 可修改性 | 变更成本、影响范围 | 抽象接口、模块化、插件化 |
| 安全性 | 数据保护、攻击防御 | 加密、认证授权、WAF |
| 易用性 | 用户体验、操作效率 | 一致性设计、反馈引导 |
| 可测试性 | 测试效率、覆盖率 | 可观测性、依赖隔离、自动化 |
软件架构 - 飞书云文档
14. SYN Flooding 攻击
14.1 攻击定义
SYN Flooding 是一种典型的拒绝服务攻击(DoS),它利用 TCP 协议三次握手的设计缺陷,通过恶意消耗目标服务器的系统资源,使其无法为合法用户提供服务。 —— 已考
14.2 核心原理
- 攻击者向目标服务器发送大量伪造源 IP 地址的 TCP SYN 连接请求包。
- 服务器收到 SYN 后,会回复 SYN-ACK 确认包,并为每个请求分配内存、维护连接状态,进入半连接状态。
- 由于源 IP 是伪造的,服务器永远收不到客户端的 ACK 确认包,导致大量半连接在队列中堆积。
- 当半连接队列被占满后,服务器无法再处理新的合法连接请求,最终导致服务瘫痪。
14.3 攻击流程
- 攻击者:发送大量伪造源 IP 的 SYN 包。
- 服务器:回复 SYN-ACK,维护半连接队列,等待 ACK。
- 结果:半连接队列耗尽,新连接被拒绝,服务不可用。
14.4 主要危害
- 服务器核心资源(连接队列、内存、CPU)被快速耗尽。
- 合法用户的正常请求被拒绝,业务中断。
- 难以溯源,因为攻击源 IP 是伪造的。
14.5 常见防护手段
- SYN Cookie 技术:服务器不直接维护半连接状态,而是通过算法生成验证值嵌入回复包,待客户端验证后再建立连接,避免资源占用。
- 调优半连接队列:适当增大队列长度,缓解短时间攻击压力。
- 防火墙 / IPS 过滤:限制单 IP 的连接请求频率,过滤异常源 IP。
- 流量清洗:通过专业设备清洗异常流量,只放行合法请求。14.6 常见网络攻击类型
- DoS(拒绝服务):通过消耗资源使目标无法提供服务,如 SYN Flood、UDP Flood。
- DDoS(分布式拒绝服务):由多台受控主机(僵尸网络)协同发起,攻击规模更大、更难防御。
- 协议漏洞攻击:如 Teardrop、Land,依赖特定系统缺陷,及时打补丁是关键防护手段。
| 攻击类型 | 核心原理 | 主要危害 | 典型防护手段 |
|---|---|---|---|
| SYN Flooding | 利用 TCP 三次握手,发送大量伪造源 IP 的 SYN 包,使服务器堆积大量半连接,耗尽资源 | 服务器连接队列耗尽,拒绝合法用户服务 | SYN Cookie、调优半连接队列、防火墙频率限制、流量清洗 |
| UDP Flood | 向目标发送大量 UDP 数据包,占用带宽与系统处理能力,常伪造源 IP | 网络带宽被占满,系统响应缓慢甚至瘫痪 | 流量清洗、UDP 访问控制、限速策略 |
| ICMP Flood (Ping Flood) | 发送大量 ICMP Echo Request(Ping)包,消耗目标 CPU 与带宽 | 目标主机忙于响应 Ping 包,无法处理正常业务 | 防火墙禁用不必要的 ICMP 响应、流量限速 |
| Teardrop 攻击 | 构造重叠或异常的 IP 分片,利用协议栈重组漏洞导致系统崩溃 | 操作系统内核崩溃、服务中断 | 及时打系统补丁、启用分片重组校验 |
| Land 攻击 | 发送源 IP 与目标 IP 相同的 SYN 包,使目标主机陷入自连接死循环 | 系统资源耗尽、服务不可用 | 防火墙过滤源目 IP 相同的报文、系统补丁修复 |
| Smurf 攻击 | 向广播地址发送伪造源 IP 的 ICMP 包,触发大量主机同时响应,放大流量 | 网络带宽被占满,目标主机被淹没 | 禁用 IP 广播响应、部署流量清洗设备 |
| DNS Amplification | 向开放 DNS 服务器发送小查询,触发大响应包,伪造源 IP 放大攻击流量 | 目标网络带宽被占满,业务中断 | DNS 服务器启用访问控制、部署反欺骗与流量清洗 |
| HTTP Flood | 模拟大量合法用户发起 HTTP 请求,耗尽 Web 服务器资源 | 网站响应缓慢、无法访问 | CDN、WAF、验证码、请求频率限制 |
15. Kerberos 认证
15.1 协议定义与设计目标
- 定义:Kerberos 是一种基于对称密钥加密的网络身份认证协议,设计用于在开放、不安全的网络环境中,为客户端和服务端提供安全的身份验证,同时支持单点登录(SSO)。
- 核心目标:在不可信网络中,避免密码明文传输,防止身份冒充和重放攻击。
15.2 核心组件
- KDC(密钥分发中心):Kerberos 的核心可信第三方,包含两个子服务:
- AS(认证服务器):验证用户身份,发放TGT(票据授予票据)。
- TGS(票据授予服务器):根据 TGT,发放用于访问特定服务的Service Ticket(服务票据)。
- 客户端:发起认证请求的用户或程序。
- 应用服务器:提供具体服务,需要验证客户端身份。
15.3 认证流程(三步握手)
- 客户端 → AS:请求 TGT。AS 验证身份后,使用用户密钥加密 TGT 和会话密钥返回。
- 客户端 → TGS:出示 TGT,请求访问特定服务的 Service Ticket。TGS 验证后,发放 Service Ticket。
- 客户端 → 应用服务器:出示 Service Ticket。应用服务器验证后,提供服务。
15.4 关键安全机制
- 时间戳与生命周期:所有票据都有有效期,并包含时间戳,有效防止重放攻击。
- 票据机制:用户无需重复输入密码,通过票据即可访问多个服务,实现单点登录。
- 对称加密:KDC 保存所有用户和服务的密钥,通信过程使用对称密钥加密,确保安全性。
15.5 易混淆概念辨析
- KDC vs CA:
- KDC:Kerberos 的核心组件,负责分发和验证票据,基于对称密钥。
- CA(证书颁发机构):公钥基础设施(PKI)的组件,负责颁发和管理数字证书,基于非对称密钥。
- 注意:Kerberos 认证中,用户是向KDC申请票据,而非向 CA 申请。
15.6 真题注意点
- KDC 职责:保存所有用户的账号和加密后的密码,负责票据的生成与验证。
- 重放攻击防护:通过时间戳和票据有效期实现。