2025年5月

python Async Sync 函数

这篇是比较好的一篇文章: https://docs.chainlit.io/guides/sync-async

  1. sync -> sync -> ok
  2. sync -> async -> asyncio.run() | asyncio.get_event_loop().run_until_complete(async_func())
  3. async -> sync -> ok | await asyncio.to_thread(sync_task)
  4. async -> async -> await
  5. Python 的 asyncio 库是标准库中用于编写异步 I/O 代码的核心框架，自 Python 3.4 引入后成为构建高性能网络应用和并发程序的重要工具. asyncio 是 Python 异步编程的基石，适合需要高效处理 I/O 并发的场景。通过事件循环和协程机制，开发者能以同步风格编写异步代码，显著提升程序性能.
  6. Asyncer 是一个用于简化 Python 异步编程的第三方库，它通过更优雅的语法和高级功能让异步代码更易编写和维护. 相比标准库 asyncio，Asyncer 通过更高层次的抽象降低了异步编程门槛，适合需要快速开发高并发应用的场景.
  7. Python 的 anyio 库是一个​​跨异步框架的统一接口库​​，旨在简化异步编程的复杂性，同时兼容主流异步模型（如 asyncio 和 trio）。

操作系统获取随机数的进化

最近重新阅读 一书. 之前都是从前往后看, 这次选择从后往前看. 最后一章有一节专门讲 Java 获取随机数的相关类和这些类的对比和使用. 其实内容不仅仅局限于 Java, 而是从整个操作系统层面来看这个问题.

一边阅读, 一边查阅相关资料. 以我的理解它的进化大概有下面几个过程:

  1. 最早想, 无非就是一个随机数吗, 于是就有了一个随机函数, 随机函数怎么增加随机性呢? 那就加一个种子, 种子的值不确定.
  2. 接着发现代码别人是知道的, 所以随机函数就是公开的, 那么唯一的就剩下种子. 但是连续获得多个随机数后, 种子也是可猜测的. 需要找真正的随机数.
  3. 于是发现机器本身能获得一些随机值. 比如: 移动鼠标的性质, 磁盘转动的性质, 网络的性质等. 但是获得这些需要时间, 有时候很慢, 就是要block 的.
  4. 然后发现可以结合真随机值和伪随机数, 两者结合可以就可以做到别人猜测不到. 唯一的问题是有时候要等系统的真随机数还是需要点时间.
  5. 于是就有了获得真随机数的后台持续运行的 deamon 线程, 它可以做到持续的获得, 等到用的时候, 随时给.
  6. 到后来又进化到某些硬件支持.

具体到 Linux 操作系统上面, 就是 /dev/urandom 和 /dev/random 设备和 rngd 守护进程.

为了让理解这个进化更细致, 下面是 Deepseek 的联网回答. 结构很好, 也很有逻辑关系. 唯一的不足感觉就是有点浅.

Linux随机数生成机制的演化与优化历程

在Linux系统中，随机数生成机制经历了从简单伪随机算法到复杂熵源管理、硬件加速的漫长优化过程。这一过程的核心矛盾在于随机性质量与性能效率之间的平衡，同时需满足密码学安全的高标准要求。以下是其关键发展阶段及技术动因分析：

一、早期阶段：伪随机数生成器（PRNG）的局限性

技术背景

早期Linux系统依赖伪随机数生成算法（如线性同余法），其核心问题在于种子可预测性。若攻击者获取初始种子，即可推导出完整随机序列。例如，系统时间常被用作默认种子，但时间戳的有限精度（如秒级）导致种子空间狭小，易被暴力破解。

缺陷暴露

  • 安全性不足：SSH、TLS等安全协议依赖随机数生成密钥，伪随机数的可预测性直接威胁加密强度。
  • 确定性缺陷：相同种子生成相同序列，导致测试环境复现问题，但生产环境无法接受此类漏洞。

二、熵源驱动的随机数生成：从理论到实践

熵源的引入

Linux内核通过收集系统事件（如键盘敲击、磁盘I/O延迟、硬件中断）的物理随机性构建熵池（Entropy Pool）。例如：

  • 鼠标移动：用户操作的时间戳和坐标变化具有不可预测性。
  • 磁盘寻道时间：物理磁盘的机械延迟受环境因素影响，产生微小随机波动。
  • 中断计时：硬件中断的到达时间间隔因电路噪声而呈现随机性。

熵池管理机制

  • 熵值计量：内核通过熵估算算法（如Linux内核的rng-core模块）量化熵池的随机性强度，熵值越高，随机数质量越优。

  • 阻塞与非阻塞模式：

    • /dev/random：严格依赖熵池，熵不足时阻塞，确保高安全性（如密钥生成）。
    • /dev/urandom：熵不足时切换为伪随机算法（如SHA-256），牺牲部分安全性以提升性能，适用于非安全敏感场景。

技术瓶颈

  • 熵源竞争：多进程并发读取熵池时，可能导致熵值快速耗尽，引发阻塞问题。
  • 启动阶段熵饥饿：系统冷启动时熵源未激活，早期加密操作可能面临低熵风险。

三、算法与架构的优化：从被动收集到主动预测

算法升级

  • Yarrow算法：Linux内核早期采用Yarrow架构，结合熵池与密码学算法（如HMAC-SHA1）生成随机数，平衡安全性与性能。
  • ChaCha20替代：为应对SHA-1碰撞攻击，Linux内核逐步迁移到ChaCha20算法，提升抗侧信道攻击能力。

熵池结构优化

内核将熵池细分为多个子池（如input_pool、blocking_pool），分别处理不同类型熵源，并通过动态权重分配优化熵混合效率。

硬件随机数生成器（TRNG）支持

现代CPU和主板集成硬件熵源（如Intel RDRAND指令、TPM芯片），Linux通过/dev/hwrng直接接入硬件随机数，显著提升生成速度与质量。

四、系统级抽象与守护进程的引入

统一接口：getrandom()系统调用

2014年Linux 3.17引入getrandom()，统一用户态接口：

  • 自动选择最优熵源（优先硬件TRNG，其次熵池）。
  • 阻塞行为可控：通过标志位选择是否等待熵池初始化完成。

守护进程优化

  • rngd后台服务：持续监控熵池状态，通过混合熵源（如网络抖动、环境传感器数据）维持熵池活跃度，避免低熵场景。
  • 自适应速率控制：根据熵池负载动态调整伪随机算法的调用频率，平衡性能与随机性质量。

五、现代挑战与前沿方向

量子计算威胁

传统随机数生成算法可能被量子计算机高效破解，Linux社区正探索抗量子算法（如基于格的随机数生成方案）。

容器化环境适配

容器共享宿主机熵池导致随机性竞争，解决方案包括：

  • 容器内嵌轻量级熵源（如基于CPU时间戳抖动）。
  • 增强宿主机熵源分发机制，通过cgroup隔离熵资源。

标准化与审计

Linux内核引入随机数生成器的形式化验证（如FIPS 140-2认证），并定期公开熵源统计报告，增强透明度和可信度。

总结：从“伪随机”到“真随机”的演进逻辑

Linux随机数生成机制的迭代本质上是安全性需求驱动下的工程妥协：

  1. 早期：以性能优先的伪随机算法为主，牺牲部分安全性。
  2. 中期：引入熵池和硬件熵源，构建混合生成模式。
  3. 现代：通过算法优化、守护进程和硬件加速，实现安全与性能的动态平衡。

未来，随着量子计算和容器技术的普及，Linux随机数生成机制将更注重抗量子攻击、轻量化与跨平台兼容性。