设计取舍

前五部分讲的是 rustls 怎么收发记录、怎么握手、怎么校验证书、怎么接密码学后端。这一部分只有一页，回头看这些代码背后的选择。README 的定位句「requires no configuration to achieve that security, and provides no unsafe features or obsolete cryptography by default」是总纲；每个取舍都落到具体的源码，说明换来了什么、放弃了什么，能量化的配本机实测或引用本卷前面各页的数字，机制本身只给链接。

1. 设计取舍：sans-IO 让一个核心接出阻塞、异步、无缓冲、QUIC、kTLS 五种用法，代价是循环写错只会停住；类型链把顺序错误变成编译错误，一次握手约 10 次状态装箱，占全部分配的 5%；连 TLS 1.2 都能关（省约 87 KB），代价是连不上只有 CBC 或 TLS 1.0 / 1.1 的服务器；可替换后端的代价是「两个都开没有默认值」；rustls-webpki 独立发版，feature 要两头转发；默认 aws-lc-rs 换来后量子和 FIPS，剥离后多 1.43 MB、构建多约 10 秒，本机只要 C 编译器不要 cmake；forbid(unsafe_code) 把 unsafe 和大量 C 代码留在了 provider 里。

flowchart TB
  goal["默认就安全"] --> sans["sans-IO"]
  goal --> typ["类型驱动"]
  goal --> old["不做旧协议"]
  goal --> prov["可换后端"]
  goal --> wp["独立 webpki"]
  goal --> nounsafe["forbid unsafe"]
  prov --> aws["默认 aws-lc-rs"]

这些取舍在实际项目里会变成具体的坑，报错原文和最小复现在 07 常见坑；本站的依赖为什么选了 ring、为什么没有撞上「两个都开」，见在本站中。