之前遇到过一个Linux设备上由于随机数生成器运行过于缓慢，导致应用运行阻塞的问题，当时记录到了一篇文章JDBC Connection Reset问题分析[附]。现在这个问题有了新的进展。
针对随机数生成速度不能满足应用需要的问题，在JDBC Connection Reset问题分析中记录的解决方法[附]是不使用默认的随机数生成器/dev/random，换成/dev/urandom。依据我厂密码学专家小组的最新研究进展，这种作法并不安全，因此各产品需要进行整改。
从随机性和安全性的角度来说，Linux原生支持的/dev/random无疑是最好的选择，但这个设备最大的问题在于性能比较差，当应用对随机数的需求量比较大时，容易导致应用在获取随机数时被阻塞。而/dev/urandom则通过降低随机性和安全性，来保证性能。如下是测试数据。
# time dd if=/dev/random of=/dev/null ibs=40 count=50
记录了3+47 的读入
记录了1+1 的写出
667 bytes copied, 102.463 s, 0.0 kB/s
real 1m42.483s
user 0m0.000s
sys 0m0.000s
# time dd if=/dev/urandom of=/dev/null ibs=40 count=50
记录了50+0 的读入
记录了3+1 的写出
2000 bytes (2.0 kB, 2.0 KiB) copied, 0.000285104 s, 7.0 MB/s
real 0m0.002s
user 0m0.000s
sys 0m0.000s
从上述数据可以发现，如果单论随机数生成速度，相比于/dev/urandom，/dev/random的性能确实太差了。
整改的思路
限制随机数生成器的使用场景，仅用于生成种子，供其它随机数生成器来使用。
自行实现随机数生成器。
购买专业的随机数生成器设备，满足应用的需求。
加快随机数生成器生成随机数的速度。
关于思路一
这种思路看起来很美好，按照不同的使用场景，区别对待随机生成器的使用方法，但实际操作起来有困难。比如：
识别使用随机数生成器的代码的位置，以及关联的业务。在研产品和转维产品的代码量经过十几年的开发，代码量和复杂程度非常高，业务非常复杂，而明白人早已换过好几遍血，已经没有人可以讲清楚业务和代码。试问有谁愿意动手修改代码。
修改随机数使用方法，使用/dev/random生成的随机数作为种子，提供给其它随机数生成器使用。困难同上，另外其它随机数生成器的可靠性需要经过时间的检验，使用方法的正确性也需要时间的检验。
假如业务完成了修改，还要验证修改是否生效，是否可以满足安全的要求。考验开发、测试人员耐心的时刻来了，对于在网运行十几年的应用，构造业务场景还是很有挑战的工作。
综上，这条路其实不可行。
关于思路二
海外对随机数生成器和相关算法的要求非常高，自研的组件想要满足标准，成本非常高。不由得感叹下玩密码学研究的圈子太小众了，虽然我厂专家的文章可读性很高，但对于帮助我理解PRNG、DRBG等词汇还是没啥帮助。
当然了，根据我厂现有资料，一些大的平台软件确实提供了自研的随机数生成器。但是呢，存在各种各样的问题，比如使用不便或者性能不能满足要求等。作为产品的开发人员，抱平台的大腿是一种非常好的策略。但当平台提供的组件不能满足要求，或者抱不成大腿时，迫于安全风险的威胁和整改的压力，只能另选生路。
很不凑巧，Jakcie目前所在的产品没有大腿可抱，因而本思路不可行。
关于思路三
从专家给出的意见以及应用样例看，这个思路比较适合玩硬件的嵌入式产品，对于纯软件的业务来说，不太适合。因而本思路不可行。
关于思路四
绕了一圈，回到了原点。如何提高随机数生成器的输出速度呢？我厂密码学专家给出了另外一种思路，借助haveged - A simple entropy daemon，提高/dev/random生成随机数的性能。
根据同事在Suse 11 Sp2上测试的结果，本方法非常有效。Jackie现在使用的Ubuntu是当前最新的16.10，但很可惜没有安装这款软件，所以没法验证。
该思路的优点在于，产品的存量代码完全不需要修改，只需要启用haveged服务即可满足应用对随机数的需求，这样测试人员也不需要投入时间。当然了，这种思路在实际运行中还是有点问题，比如现网运行的Suse有很多版本比较低，没有安装haveged，那么其实无法享受haveged带来的便利。这需要让一线销售和服务想办法，尽快把操作系统的版本升级到高版本。
附：JDBC Connection Reset问题分析
半年前开始，项目组测试MM在验证功能时，经常报怨讲测试环境上的应用在启动时很慢，偶尔会报失败，遇到类似问题多数情况下重新启动一次就可以启动成功，但少数时候也有反复启动不成功的案例。当启动失败时，日志里有如下的异常，看起来似乎和网络有关。
java.sql.SQLRecoverableException: I/O Exception: Connection reset
at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:281)
at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:118)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:224)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:296)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:611)
at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:455)
at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:494)
at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:199)
at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:30)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:503)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:154)
应用使用的数据库是Oracle，版本为11g R1和R2，Oracle和应用都运行在Linux环境，JDBC驱动是从Oracle官网下载的ojdbc6.jar。
由于这类问题出现的频率比较低，出现问题的数据库环境都被做过安全加固，加上我忙于其它事情，这个问题就被搁置起来，没有去认真定位，测试MM的怀疑都被我以环境原因的理由搪塞过去。
最近两个月，应用在多个生产环境部署时也出现了类似的现象，在有些生产环境，上述问题还会导致双机切换不成功或者反复切换。做现场实施的同事对此抱怨很多，对我们的应用产生了怀疑。看来这个问题需要认真对待，并且一定要解决了。
现象分析
从测试MM和现场实施人员的描述看，这个问题有以下几个特征：
1) 应用启动时很慢，这时有很大概率会失败；
2) 应用包括很多组件，其中大部分组件在启动时都会尝试访问数据库加载一些数据，而其中一个组件在访问数据库时经常会报上述异常；
3) 当启动失败时，检查Oracle实例对应的alert日志时，发现出现有TNS错误，样例如下：
Fatal NI connect error 12170.
VERSION INFORMATION:
TNS for Linux: Version 11.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.1.0 - Production
TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.1.0 - Production
Time: 11-MAY-2014 22:23:40
Tracing not turned on.
Tns error struct:
ns main err code: 12535
TNS-12535: TNS:operation timed out
ns secondary err code: 12560
nt main err code: 505
TNS-00505: Operation timed out
nt secondary err code: 110
nt OS err code: 0
问题定位
TNS错误
由于实验室里的Oracle环境都做过安全加固，而问题现象里有发现过TNS错误，所以刚开始定位问题的思路出了点偏差，一直以为和安全加固操作有关，所以寻找的资料也和Oracle相关。
根据网上的资料，在sqlnet.ora文件中定义SQLNET.INBOUND_CONNECT_TIMEOUT变量，经过尝试，设置为0或者一个比较大的值如30，都可以消除掉前述问题。根据资料介绍，这个变量用来控制客户端通过认证的时间间隔，假如认证时间超时，则本次数据库链接创建操作就会失败，而缩短超时时间，可以有效的阻止DoS类型的攻击。根据安全加固操作指导，加固操作确实包含用于修改认证超时时间的指令。
问题定位到这里，应该说找到了规避手段，也了解引发问题的初因，但现场实施人员对于我的解释并不满意。好在我又找到一条新线索。
新线索
从Oracle官网论坛里找到一个帖子，讨论的问题和我遇到的问题类似，但提出的问题原因和解决方法比较有意思。按照帖子里的说法，问题的根因和Java的安全随机数生成器的实现原理相关。
java.security.SecureRandom is a standard API provided by sun. Among various methods offered by this class void nextBytes(byte[]) is one. This method is used for generating random bytes. Oracle 11g JDBC drivers use this API to generate random number during
login. Users using Linux have been encountering SQLException("Io exception: Connection
reset").
The problem is two fold
1. The JVM tries to list all the files in the /tmp (or alternate tmp directory set by -Djava.io.tmpdir) when SecureRandom.nextBytes(byte[]) is invoked. If the number of files is large the method takes a long time to respond and hence cause the server to timeout
2. The method void nextBytes(byte[]) uses /dev/random on Linux and on some machines which lack the random number generating hardware the operation slows down to the extent of bringing the whole login process to a halt. Ultimately the the user encounters SQLException("Io exception:
Connection reset")
Users upgrading to 11g can encounter this issue if the underlying OS is Linux which is running on a faulty hardware.
Cause
The cause of this has not yet been determined exactly. It could either be a problem in your hardware or the fact that for some reason the software cannot read from /dev/random
Solution
Change the setup for your application, so you add the next parameter to the java command:
-Djava.security.egd=file:/dev/../dev/urandom
现场实施人员对于这个帖子里的信息比较感兴趣。按照帖子里的修改方法，在测试环境和生产环境做了多次验证，惊喜的发现问题得到了解决。
随机数生成器
如果不是为了解决问题，平时也不会去刻意查阅底层实现相关的原理，这次是个好机会。网上关于/dev/random的介绍很多，只列出要点：
1) /dev/random是Linux内核提供的安全随机数生成设备；
2) /dev/random依赖系统中断信息来生成随机数，因而设备数目比较少时，产生随机数的速度比较慢，当应用对随机数的需求比较大时会供不应求；
3) /dev/random在读取时会阻塞调用线程；
4) /dev/urandom是/dev/random的改良版本，解决了随机数生成慢、阻塞调用的问题，但同时稍微降低了安全性；
5) Linux环境下man random命令可以查阅到/dev/random和/dev/urandom的介绍，比较详尽；