From programming point of view, reading data from /dev/random will block while read on /dev/urandom will return immediately. This is from "man 4 random"
When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.
When read, /dev/urandom device will return as many bytes as are requested. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.
To test this, try...
$ hexdump /dev/random
$ hexdump /dev/urandom
In first case, numbers get displayed slowly depending on rate of noise on the system. This rate can be increased by moving mouse hence the read returns more quickly and you can notice change in speed of hexdump output.
But in second case, it returns immediately with as many bytes as requested.
$ cat /proc/sys/kernel/random/entropy_avail
will give you current available entropy on the system. This number drops when you read from any of these devices.