如果我在Ubuntu中运行这个命令
sudo cat /proc/sys/kernel/random/entropy_avail 它会返回一个数字，表明内核有多less“熵”可用，但这就是我所知道的。 这个熵的单位是什么？ 它是干什么用的？ 如果这个数字是“低”，我被告知这是“坏”的。 “低”有多低，如果是“坏”，会发生什么？ 它有什么好的范围？ 它是如何确定的？
您的系统通过关注不同的事件来收集一些“真实的”随机数：networking活动，硬件随机数生成器（如果可用;例如威盛处理器通常具有“真实”随机数生成器）等等。 如果将它们提供给/ dev / random使用的内核熵池。 需要一些极端安全性的应用程序倾向于使用/ dev / random作为它们的熵源，或者换句话说，随机源。
如果/ dev / random用完了可用的熵，则不能提供更多的随机性，并且等待随机性的应用程序停止，直到有更多的随机可用的东西可用。 我在职业生涯中看到的例子是，Cyrus IMAP守护进程想要使用/ dev / random作为随机性，而POP会话想要从/ dev / random生成APOP连接中的随机string。 在繁忙的环境中，有更多的login尝试，比喂食/ dev / random的stream量 – >所有的东西都停顿了。 在这种情况下，我安装了rng-tools并激活了它的rngd，在/ dev / random的情况下，将/ dev / urandom中的半随机数铲除到“真实”熵的外面。
如果您想要简单概述一下底层问题：某些应用程序（如encryption）需要随机数字。 你可以使用algorithm产生随机数 – 但是尽pipe这些在一种意义上看起来是随机的，但在另一种意义上它们是完全可预测的 例如，如果我给你的数字58209749445923078164062862089986280348253421170679，他们看起来很随机。 但是如果你意识到他们实际上是PI的数字，那么你会知道下一个将是8。
对于一些应用程序来说，这是可以的，但是对于其他应用程序（特别是与安全有关的应用程序），人们希望真正的不可预测的随机性 – 这是由algorithm（即程序）无法生成的，因为根据定义可以预测。 这是一个问题，因为你的电脑本质上是一个程序，所以它怎么可能得到真正的随机数字？ 答案是通过测量来自外部世界的真正的随机事件 – 例如你的按键之间的差距，并用它们将真正的随机性注入到另外可预测的随机数发生器中。 “熵池”可以被认为是随机性的存储，这种随机性是由随机数字的产生（由任何正在使用的）和排除而形成的。
只读文件entropy_avail给出了可用的熵。 通常，这将是4096（比特），一个完整的熵池。
你可以阅读更多： http ： //linux.die.net/man/4/random
熵是“随机性”的技术术语。 计算机并不真正生成熵，而是通过查看诸如硬盘驱动器旋转速度的变化（由于摩擦等原因而很难预测的物理现象）等东西来收集它。当计算机想要生成伪随机数据时通过测量鼠标点击，硬盘旋转变化等等来产生具有真熵的math公式。粗略地说， entropy_avail是当前可以从/dev/random读取的比特的度量
计算机需要花费时间从环境中读取熵，除非它具有象嘈杂的二极pipe之类的酷硬件。
如果你有4096位可用的熵，而你是/dev/random那么你可以期望能够在等待更多的熵之前读取512字节的熵（4096位）。
例如，如果你的“ cat /dev/random ”，你的熵会缩小到零。 起初，你会得到512字节的随机垃圾，但它会停下来，一点点你会看到更多的随机数据滴stream槽。
这不是人们应该如何操作/dev/random 。 通常开发人员将读取less量的数据，如128位，并使用它来播种某种PRNGalgorithm。 不要从/dev/random读取更多的熵，因为需要这么长时间才能build立并被认为是有价值的。 因此，如果通过不小心捕获上面的文件而使其耗尽，则会导致需要从/dev/random读取的其他应用程序被阻止。 在工作中的一个系统上，我们注意到很多encryption函数被拖延了。 我们发现一个cron工作正在调用一个python脚本，每隔几秒钟运行一次，每次运行都会初始化ramdom.random() 。 为了解决这个问题，我们重写了python脚本，使其作为一个只初始化一次的守护进程运行，cron作业将通过XMLRPC读取数据，以便在启动时不会从/dev/random读取数据。