Chapter 3-3：流水线、滑动窗口、GBN 与 SR 学习指南本节是可靠数据传输 rdt 的继续部分。上一节 rdt3.0 已经解决了“可靠性”问题：比特错误、丢包、ACK 丢失、重复分组都能处理。但 rdt3.0 仍然有一个严重缺陷：
它可靠，但太慢。
Chapter 3-3 的核心任务，就是从 rdt3.0 的性能瓶颈出发，引出 pipelining 流水线协议，再进一步讲 sliding window 滑动窗口，最后比较两种典型流水线协议：GBN 和 SR。
0. 本节核心主线rdt3.0 的 stop-and-wait 模式是：
12345发送一个分组↓等待 ACK↓收到 ACK 后再发下一个分组
这种方式逻辑简单、可靠性强，但链路利用率很低。尤其在高带宽、长 RTT 的链路上，发送方大部分时间都在等 ACK，而不是在真正发送数据。
所以本节主线可以概括为：
flowchart TD
A[rdt3.0 可靠但低效] --> B[stop-and-wait 一次只发一个分组]
B --> C[链路大部分时间空闲]
C --& ...
Chapter 3-2：可靠数据传输 rdt 原理学习指南这份课件虽然文件名是 Chapter3-2，但主体内容是 可靠数据传输 reliable data transfer, rdt，而不是目录意义上的“多路复用与解复用”。
本节的核心问题是：
底层信道不可靠，但上层应用希望看到可靠通信，传输层协议应该如何设计？
0. 本节核心主线可靠数据传输不是简单地“把 packet 发出去”，而是要保证：
数据最终被正确地、按协议预期地交付给接收方上层。
底层信道可能出现的问题包括：
分组比特出错；
数据分组丢失；
ACK / NAK 控制报文损坏；
ACK 丢失；
分组或 ACK 延迟到达；
发送方无法直接知道接收方的真实状态。
所以 rdt 协议要用一套机制把不可靠信道包装成可靠服务。
❗ 本节核心结论：rdt 的本质，是在不可靠信道上，通过 checksum、ACK、sequence number、timer 等机制，让上层看到一个可靠的数据传输抽象。1. 可靠服务抽象与可靠服务实现要先区分两个层次：
层次
含义
可靠服务抽象
上层看到的通信好像是可 ...
Chapter 3.1：传输层的核心边界——从主机通信到进程通信Chapter 3.1 的核心任务，是建立传输层的基本框架：传输层到底服务谁、它和网络层的边界在哪里、TCP 与 UDP 在 Internet 传输层中分别提供什么样的服务。
这一节不需要立刻深入 TCP 三次握手、可靠数据传输算法或拥塞控制细节。真正重要的是先抓住一句话：
❗ 本节核心结论：网络层负责把数据送到正确的主机；传输层负责把数据交给这台主机上的正确进程。1. 传输层服务的对象不是主机，而是进程传输层提供的是 process-to-process logical communication，即不同主机上应用进程之间的逻辑通信。
这句话里最关键的词不是“主机”，而是 进程 process。
一台主机上可以同时运行很多应用：
浏览器；
微信；
QQ；
Steam；
邮件客户端；
Web 服务器；
数据库服务。
网络层的 IP 地址只能把数据送到某一台主机。例如，一个 IP 数据报到达 192.168.1.5，网络层只能判断：
这个包是发给 192.168.1.5 这台主机的。
但它并不知道这个数据应该交给浏 ...
以下根据附件《第18讲 多核与多处理器II.md》整理生成。
第18讲：多核与多处理器 II 学习指南本讲承接上一讲“多核不是免费加速”的主线，进一步讨论两个问题：
正确性问题：程序员写下来的代码顺序，为什么不一定等于其他 CPU 核心观察到的顺序？
性能问题：即使用了 MCS 锁这类可扩展锁，为什么在多核、NUMA 环境下仍然可能性能很差？
❗ 本节核心结论：多核程序不能只按“代码书写顺序”理解共享内存访问，而必须考虑内存一致性模型。同步原语不仅提供互斥，也提供访存顺序保证；而在高核数和 NUMA 环境下，锁本身可扩展不代表临界区数据访问也可扩展。1. 本章知识地图
flowchart TD
A[多核共享内存程序] --> B[代码顺序不等于硬件可见顺序]
B --> C[乱序执行]
C --> D[内存一致性模型]
D --> E[严格一致性]
D --> F[顺序一致性]
D --> G[TSO]
D --> H[弱序一致性]
H --> I[barrie ...
以下根据附件《第17讲 多核与多处理器I.md》整理生成。
第17讲：多核与多处理器 I 学习指南本讲的主线是：多核不是简单的“核心越多越快”。多核确实带来并行能力，但也引入了缓存一致性、锁竞争、可扩展性断崖、虚假共享和乱序执行等问题。
❗ 本节核心结论：多核系统的核心矛盾是：核心数增加带来并行能力，但共享数据、私有缓存和锁竞争会引入正确性问题与性能问题。多核优化的关键不是“多加核心”，而是减少核心之间的协调成本。1. 本章知识地图
flowchart TD
A[单核性能遇到瓶颈] --> B[增加 CPU 核心数]
B --> C[多线程并行执行]
C --> D[每个核心有私有缓存]
D --> E[同一地址可能有多个缓存副本]
E --> F[缓存一致性问题]
F --> G[MSI / 目录式一致性]
G --> H[一致性通信开销]
H --> I[锁竞争与可扩展性断崖]
I --> J[Back-off]
I --> K ...
以下根据附件《第16讲 同步原语III.md》整理生成。
第16讲：同步原语 III 学习指南本讲讨论的是：同步原语本身可能带来的问题。
前面学习的互斥锁、条件变量、信号量、读写锁、RCU 都是为了让多个线程安全共享资源。但只要线程开始“持有资源”“等待资源”，系统就可能出现新的并发问题：
死锁
活锁
优先级反转
❗ 本节核心结论：同步原语解决了共享资源竞争的正确性问题，但如果资源申请顺序、等待方式和调度优先级设计不好，就会产生死锁、活锁、优先级反转等问题。1. 本章知识地图
flowchart TD
A[同步原语] --> B[多个线程竞争多个资源]
B --> C[死锁 Deadlock]
C --> D[检测与恢复]
C --> E[死锁预防]
C --> F[死锁避免]
E --> G[破坏四个必要条件]
F --> H[银行家算法]
E --> I[trylock 方案]
I --> J[活锁 Livelock]
...
以下根据附件《第15讲 同步原语II.md》整理。
第15讲：同步原语 II 学习指南同步原语 II 的主线是：在互斥锁之外，操作系统还需要更丰富的同步机制来处理“条件等待”“有限资源”“读写分离”和“极端读多写少”的场景。
❗ 本节核心结论：互斥锁只能解决“同一时刻谁能进入临界区”的问题；条件变量、信号量、读写锁和 RCU 分别进一步解决“什么时候能继续”“资源数量够不够”“读者能否并行”“读路径能否几乎无锁”的问题。1. 本章知识地图
flowchart TD
A[互斥锁 / 自旋锁] --> B[条件变量]
B --> C[信号量]
C --> D[读写锁]
D --> E[RCU]
A --> A1[只解决临界区互斥]
B --> B1[条件不满足时阻塞等待]
C --> C1[把资源数量和等待唤醒结合]
D --> D1[读读并行，读写互斥]
E --> E1[读者无锁直读，写者复制更新]
这张图展示了同步原语的升级路 ...
第14讲 同步原语 I：从竞争条件到互斥锁本文根据《第14讲 同步原语I.md》的对话转录整理而成。核心问题是：当多个线程或进程同时访问共享资源时，如何保证它们不会因为执行顺序不可控而破坏数据一致性。
1. 本讲要解决什么问题前面学习 IPC 时，共享内存解决的是“多个进程能不能看到同一块数据”。但共享内存本身并不保证安全。
真正的问题是：
多个线程或进程同时访问同一份共享数据时，谁先读、谁先写、谁能修改、谁必须等待？
如果没有同步机制，就可能出现：
两个线程同时修改同一个变量；
两个生产者写入同一个缓冲区位置；
一个线程读到另一个线程写了一半的数据；
程序结果依赖不可预测的调度顺序。
所以本讲的主线是：
12345678910111213共享数据 ↓并发访问 ↓竞争条件 ↓临界区 ↓互斥访问 ↓同步原语 ↓互斥锁 / 自旋锁 / Ticket Lock
❗ 本节核心结论： 同步原语解决的不是“能不能共享数据”，而是“共享数据怎样被安全访问”。2. 为什么 balance++ 会出错很多人会误以为：
1balance++;
是一条不可分割的语句。
但在机器 ...
第13讲 进程间通信：共享内存、消息队列与同步语义本文根据《第13讲 进程间通信.md》的对话转录整理而成。核心问题是：进程间通信 IPC 不只是“两个进程能传数据”，还要解决数据放在哪里、谁来读取、何时等待、如何避免覆盖和读空，以及通信双方是否需要直接认识彼此。
1. 为什么需要进程间通信进程默认拥有独立的地址空间。一个进程不能随意访问另一个进程的内存，这是操作系统提供隔离性和安全性的基础。
但现实系统中，进程之间经常需要协作。例如：
浏览器进程和渲染进程交换页面数据；
shell 通过管道把一个命令的输出交给另一个命令；
服务器主进程把请求分发给 worker 进程；
多个进程共享同一批计算结果；
客户端进程向服务端进程发送请求。
因此，操作系统需要提供 IPC，Inter-Process Communication，即进程间通信机制。
IPC 的核心问题可以分为三类：
数据如何传递
是放在共享内存中，还是通过内核转发？
通信双方如何建立关系
是直接指定对方进程，还是通过中间对象通信？
通信操作如何等待
是同步等待，还是异步返回？
2. IPC 的两 ...
第12讲 调度 II：多核调度、负载衡量与能耗感知本文根据《第12讲 调度II.md》的对话转录整理而成。核心问题是：当系统从单核走向多核、异构多核后，调度器不仅要决定“谁运行”，还要决定“在哪个 CPU 上运行”，并在负载均衡、缓存友好、性能与能耗之间做取舍。
1. 从单核调度到多核调度在单核调度中，核心问题主要是：
下一个运行哪个任务？
这个任务运行多久？
但在多核系统中，还要增加一个问题：
这个任务应该在哪个 CPU 核上运行？
因此，多核调度可以概括为：
多核调度 = 选任务 + 选 CPU + 控制运行时长
这比单核调度复杂得多。因为不同 CPU 核之间可能存在负载差异、缓存差异，甚至性能与功耗差异。
例如在一个四核系统中，任务 A 可以放在 CPU0，也可以放在 CPU2。表面上只是换一个 CPU，实际上会影响：
该 CPU 是否已经很忙
该 CPU 缓存中是否已有任务 A 的数据
该 CPU 是大核还是小核
迁移任务是否会破坏局部性
系统整体能耗是否会上升
flowchart TD
A[就绪任务] --> B{多核调度器} ...
