The SSL support in J2SE (through JSSE) has changed a lot from J2SE1.4 to J2SE1.5. So, when I got a chance this weekend, I ran my favourite ssltool (part of JSTK) to collect some performance numbers.
Now, I know the pitfalls of microbenchmarks -- but they do have some utility in some scenarios. And I consider this parituclar scenario simulated by ssltool to be one of those: a client program establishes connection with the server, sends a fixed no. of bytes and the server echoes back the same data. The client does send and receive in a loop for a fixed no. of times and reports the duration of the loop.
For the numbers given below, I executed both client and server programs on the same Athlon 900MHz machine running W2K. The buffer size was fixed at 8KB and the loopcount was 2048. Also, I measured the elapsed time for two different cipher suites: SSL_RSA_WITH_RC4_128_MD5 and SSL_RSA_WITH_3DES_EDE_CBC_SHA, as shown in the following table:
| J2SDK1.4.1_02 | J2SDK1.5.0b1 | |
|---|---|---|
| SSL_RSA_WITH_RC4_128_MD5 | 8.6 secs. | 6.5 secs. |
| SSL_RSA_WITH_3DES_EDE_CBC_SHA | 45 secs. | 64 secs. |
Now, this is really interesting!? The new JDK is better for SSL_RSA_WITH_RC4_128_MD5 but worse for SSL_RSA_WITH_3DES_EDE_CBC_SHA. How is this explained? Well, only the Sun engineers, who have the source code, can answer. I can only guess that the performance difference is because of the change in how JSSE performs cryptographic operations: JSSE now uses the default JCE provider, whereas earlier it had its own code for doing these operations.
Whatever be the reason , I only hope that Sun addresses this before their final release, for the cipher suite SSL_RSA_WITH_3DES_EDE_CBC_SHA is stronger and more widely used