Q1: 我们要做什么？ → 网络审计软件
Q2: 网络审计的本质是什么？ → 被动观察 + 结构化记录 网络中的明文通信
Q3: "被动观察"的物理基础是什么？ → 网卡混杂模式下逐帧捕获比特流
Q4: "结构化记录"的本质是什么？ → 从无差别的字节流中，按协议分层规则提取语义字段
Q5: 那整个系统的最小抽象是什么？ → 一个 **流式 ETL 管道**：
     Extract(抓帧) → Transform(逐层解码+语义提取) → Load(存储+推送)

事实：抓包是 IO 密集型，每秒可能数千帧
问题：线程池在高并发 IO 场景下线程上下文切换开销大
选择：Kotlin 协程 = 用户态轻量级线程，10 万级并发无压力
验证：协程 Channel 天然提供背压（buffered channel 满了就挂起生产者）
     → 完美匹配 "不丢帧" 的硬约束

事实：libpcap 是 C 库，JNI 调用有内存管理风险
问题：课程项目开发周期 4 周，没时间调 JNI 段错误
选择：Pcap4J = 纯 Java 封装 libpcap，API 友好，跨平台
验证：Pcap4J 已内置以太网帧 / IP / TCP / UDP 的解析类
     → 省掉 L2~L4 的手动解析，聚焦 L7 应用层解析（得分大头）

事实：告警是单向推送（服务端 → 浏览器），不需要客户端上行
问题：WebSocket 是双向的，对于单向场景是 over-engineering
选择：SSE = 基于 HTTP 的单向推送，原生浏览器支持，实现简单
验证：Ktor 原生支持 SSE，3 行代码搞定
     → 满足 ≤ 10 秒延迟的评分要求

事实：审计日志需要高速写入 + 复杂查询（按协议/时间/IP 过滤）
问题：SQLite 单写锁，并发写入会阻塞管道
选择：PostgreSQL 支持并发写入 + JSONB 字段存协议特有字段
验证：JSONB 让所有协议共用一张 audit_logs 表
     → 通用字段是列，协议特有字段进 JSONB，schema 简洁

事实：6 个协议各自格式不同，但输入输出是统一的
问题：if-else 判断协议类型 → 违反开闭原则，加新协议要改老代码
选择：定义 ProtocolParser 接口，每个协议一个实现类，注册到 Map<Port, Parser>
验证：新增协议 = 新写一个类 + 注册一行
     → Codex 可以并行生成 6 个 Parser，互不干扰

正向理由：每层解码逻辑独立，单一职责，可独立单测
反向验证：如果都写在一个函数里——
  → 函数 200+ 行，改 IP 解析怕影响 TCP 解析
  → 违反开闭原则（加 IPv6 支持要改整个函数）
  → 不可测试（无法单测 IP 解码而不经过 Ethernet）

问题：一个 HTTP 请求可能跨越多个 TCP 段（分片）
      一个 TCP 段也可能包含多个 HTTP 请求（管线化）
事实：协议解析器需要的是「完整的应用层消息」，不是「单个 TCP 段」
结论：在分发给 L7 Parser 之前，必须有一层 TCP 流重组

┌─────────────────────────────────────────────────┐
│              ProtocolParser 接口                  │
├─────────────────────────────────────────────────┤
│ + protocol: ProtocolType                         │
│ + ports: Set<Int>                                │
│ + parse(stream: StreamContext): AuditRecord?     │
│ + isComplete(buffer: ByteArray): Boolean         │
└─────────────────────────────────────────────────┘
          △         △         △         △
          │         │         │         │
    HttpParser  FtpParser  DnsParser  SmtpParser ...

接口：只定义契约，不强制继承链
     → HTTP 和 DNS 的解析逻辑完全不同（文本 vs 二进制），抽象类的公共方法会是空的
     → Kotlin 接口可以有默认实现，需要时仍可复用

没有状态机：收到 RETR file.txt 时，不知道是谁在操作
            → 得回溯之前的包找 USER 命令
            → 复杂、易错、性能差

有状态机：  StreamContext 里维护当前状态 + 已知 username
            → 收到 RETR 时直接组装完整 AuditRecord
            → O(1) 查找，无回溯

POP3 命令流:
  C: USER alice          → 记录用户名
  S: +OK
  C: PASS secret         → (可选记录)
  S: +OK
  C: RETR 1              → 开始接收邮件
  S: +OK ... (邮件内容)  → 解析邮件头: From/To/Subject/MIME 附件
  C: QUIT

事实：Kotlin SharedFlow 是协程原生的多播热流
优势：
  1. 天然支持多个 collector（fan-out）
  2. 可配置 buffer 大小（背压控制）
  3. 协程安全，无需手动加锁
  4. replay=0 意味着只推新事件，不堆积历史
结论：零依赖，零 bug 风险，功能完全匹配

方案A（6 张表）：HttpLog, FtpLog, TelnetLog ...
  → 全协议联合查询需要 UNION 6 张表 → 慢、代码复杂
  → 前端 "全部审计记录" 页面要拼 6 个接口

方案B（1 张表 + JSONB）：
  → 全协议查询 = 一个 SELECT → 简单
  → 按协议过滤 = WHERE protocol = 'HTTP' → 一样快
  → 协议特有字段进 JSONB，GIN 索引支持 JSON 路径查询
  → schema 变更零成本（加新字段不用 ALTER TABLE）

问题：SSE 数据需要同时驱动 4+ 个组件
方案A（组件 prop 传递）：根组件接 SSE → 层层传 → prop drilling 地狱
方案B（Pinia 全局状态）：SSE → Store → 任意组件 inject → 扁平
结论：Pinia 是 Vue 3 官方状态管理，SSE 写 Store，组件自取所需

密封类优势演示：

sealed interface AuditEvent {
    data class HttpEvent(...) : AuditEvent
    data class FtpEvent(...) : AuditEvent
    data class TelnetEvent(...) : AuditEvent
    data class DnsEvent(...) : AuditEvent
    data class SmtpEvent(...) : AuditEvent
    data class Pop3Event(...) : AuditEvent
}

when (event) {
    is HttpEvent -> ...
    is FtpEvent -> ...
    // 如果漏了某个 → 编译器直接报错 ❌
    // 比 if-else + String type 安全 100 倍
}

每个 Task 提交给 Codex 时，提示词结构应包含：

1. 【角色】你是 Kotlin 网络安全开发者
2. 【上下文】给出接口定义 + 数据模型（从 Task 2 产出）
3. 【输入】明确入参类型（如 StreamContext）
4. 【输出】明确返回类型（如 AuditEvent.HttpEvent）
5. 【约束】错误处理、日志规范、不要阻塞协程
6. 【测试】附带单元测试用例的输入输出对

test-all-protocols.sh 的逻辑流：

1. curl http://nginx/index.html              → 触发 HTTP 审计
2. curl http://nginx/admin/secret.html        → 触发 HTTP + 告警（敏感 URL）
3. ftp -n ftpserver <<< "USER alice; PASS 123; RETR secret.doc; QUIT"
                                               → 触发 FTP 审计
4. echo "ls -la" | telnet telnetserver         → 触发 TELNET 审计
5. nslookup example.com dnsserver              → 触发 DNS 审计
6. swaks --to bob@test.com --from alice@test.com \
         --server smtpserver --attach file.pdf → 触发 SMTP + 附件审计
7. fetchmail --protocol POP3 popserver          → 触发 POP3 审计

问题：开发环境没有真实的交换机镜像端口
方案：Docker bridge 网络 + 容器内混杂模式
原理：
  1. 所有容器在同一个 Docker bridge 网段
  2. 审计系统容器用 --net=host 或 --cap-add=NET_RAW
  3. Pcap4J 在 bridge 接口上抓包 = 等效于镜像端口
验证：tcpdump -i docker0 可以看到所有容器间流量

演示动作：
  1. 打开 Dashboard → 当前审计记录为空
  2. 在终端执行 curl http://webserver/index.html
  3. 切到 Dashboard → 表格实时出现一行 HTTP 记录
     → 展示 srcIP, dstIP, URL, Method, Timestamp
  4. 再执行 curl http://webserver/api/users
  5. Dashboard → 第二行出现 → 饼图 HTTP 占比变化 → 折线图跳动

讲解话术：
  "每一个 HTTP 请求，从网卡抓包到 Dashboard 展示，
   延迟不到 1 秒。这背后是 Kotlin 协程 Channel 管道 +
   SSE 实时推送。"

演示动作：
  1. 用 swaks 发送一封带附件的邮件
  2. Dashboard → SMTP 记录出现
     → 点击展开：发件人、收件人、标题、附件名、附件大小
  3. 强调："附件大小是通过 MIME boundary 间 Base64 长度计算的"

讲解话术：
  "SMTP 解析是本项目最复杂的模块——它是一个 8 状态的
   状态机，从 EHLO 到 DATA 到 MIME 解析，逐层深入。"

演示动作：
  1. 在终端 telnet 到服务器
  2. 输入 login: hacker → 输入 password → 执行 cat /etc/passwd
  3. Dashboard → TELNET 记录出现 + 红色告警弹窗弹出！
     → 弹窗内容: "TELNET 登录检测: hacker @ 192.168.1.100"
     → 告警声效播放（可选）
  4. 点击告警 → 跳转到该条审计详情

讲解话术：
  "告警引擎在事件产生的同一毫秒内进行规则匹配，
   SSE 推送到前端弹窗，端到端延迟 < 1 秒，
   远低于评分要求的 10 秒。"

问题：开发时不可能每次都真实发送 6 种协议的流量
方案：
  1. 用 tcpdump -w test.pcap 录制一次完整的测试流量
  2. 开发时用 Pcap4J 的 PcapHandle.openOffline("test.pcap") 回放
  3. 结果与 Wireshark 的解析结果逐字段对比
优势：
  → 可重复：同一个 pcap 文件跑 100 次结果一致
  → 可回归：改了 HTTP Parser 不怕影响 FTP Parser
  → 可 CI：放到自动化测试里

为什么要录屏？
  → Murphy 定律：答辩现场网络可能出问题
  → 备选方案：如果 live demo 失败，立刻切到录屏
  → 专业感：提前录好的视频可以加字幕、高亮关键区域
  → 建议：用 OBS 录制 1080p，3~5 分钟精华版