5 ms·
Netty and the JVM meet OpenSSL to speed up connections
- vikrum 14y agoI put this blog post together in the hopes that someone can benefit from the niche optimization that we undertook. Finding anything relating to "java", "ssl", and "optimizations" on a search engine along this vein is difficult to say the least.
- kelnos 14y agoThanks so much for writing this up! I've been looking for a Java implementation of DTLS, and haven't found one. Since OpenSSL supports DTLS, I might be able to abuse this into doing what I need. I'll probably want to strip down the tomcat-native dependency, but this puts me a lot closer to my goal than I was previously.
- timdoug 14y agoWhat's the benefit of doing SSL/TLS in the application instead of using a dedicated terminator like stud?
- vikrum 14y agoWe did use stud for a short time but have recently moved back to this approach for a couple of reasons: + Currently out SSL connections need to be pinned to a specific server, so we wound up running the terminator on the same box. We then ran into a problem of having more than 65k connections (src ip/port <-> dest ip/port) on loopback, which introduced a bit more complexity in our deployment (either have stud use 127.0.0.2, 127.0.0.3, etc or have stud point to a different port.) + The memory consumption also goes up across the board since we are on the same box (2x the connections per actual connection). stud uses an additional ~200k per connection and on some of our boxes that have 100k+ connections, this is something north of 18GB. This was the biggest driver for the change.