死在/dev/random上

标签：style   blog   http   color   使用   文件   ar   问题   

FOTA差分升级的时候有个retouch_binaries操作，我这里到了这一句就卡住了，等待的圈圈能转几天也不见完。后来发觉乱捅几下居然完了。找到一个解决此问题的patch，发现是将/dev/random修改成了/dev/urandom

diff --git a/updater/install.c b/updater/install.c
index a1acdb9..2f2631a 100644
--- a/updater/install.c
+++ b/updater/install.c
@@ -450,7 +450,7 @@ Value* RetouchBinariesFn(const char* name, State* state,
     bool override_set = false;
     int32_t random_base = time(NULL) % 1024;
     // some more randomness from /dev/random
-    FILE *f_random = fopen("/dev/random", "rb");
+    FILE *f_random = fopen("/dev/urandom", "rb");
     uint16_t random_bits = 0;
     if (f_random != NULL) {
         fread(&random_bits, 2, 1, f_random);

遇到这样的事情，当然是先上网搜索/dev/random和/dev/urandom，找到一段话（http://www.linuxidc.com/Linux/2012-05/60476.htm）

Linux中的随机数可以从两个特殊的文件中产生，一个是/dev/urandom.另外一个是/dev/random。他们产生随机数的原理是利用当前系统的熵池来计算出固定一定数量的随机比特，然后将这些比特作为字节流返回。熵池就是当前系统的环境噪音，熵指的是一个系统的混乱程度，系统噪音可以通过很多参数来评估，如内存的使用，文件的使用量，不同类型的进程数量等等。如果当前环境噪音变化的不是很剧烈或者当前环境噪音很小，比如刚开机的时候，而当前需要大量的随机比特，这时产生的随机数的随机效果就不是很好了。

这就是为什么会有/dev/urandom和/dev/random这两种不同的文件，后者在不能产生新的随机数时会阻塞程序，而前者不会（ublock），当然产生的随机数效果就不太好了，这对加密解密这样的应用来说就不是一种很好的选择。/dev/random会阻塞当前的程序，直到根据熵池产生新的随机字节之后才返回，所以使用/dev/random比使用/dev/urandom产生大量随机数的速度要慢。

好吧，上面那段熵什么的我们就先不深究了，我下来再学习。不过基本上可以解释我的两个疑问了：

1. 为什么会这么慢？“/dev/random”就是慢啊，升级的时候，系统基本上动作很小的，拿来那么多的变化让它去生成随机数？即使我尝试在我电脑上执行“cat /dev/random|od -x”，然后什么也不动，就等它出字符，也是龟速。
2. 为什么捅两下会快？不管是按键还是触屏，都会导致手机系统的变化，这个变化就是产生随机数的根源，动了就有随机数了，数出来了，更新也就能继续了。这也就是为什么放这一个晚上也没有完的原因了，放着就放着了，系统基本处于静止状态了。

这哪是慢啊，简直是要命了。

引申阅读 http://zh.wikipedia.org/wiki//dev/random

死在/dev/random上,布布扣,bubuko.com

死在/dev/random上

标签：style   blog   http   color   使用   文件   ar   问题   

原文地址：http://www.cnblogs.com/sig3/p/3927046.html