Antares
Antares

Reputation: 285

SSL overweight in Java

I'm using org.apache.commons.ssl to make an SSL server in Java. I'm facing a strange problem : I send 500KB of data over the SSL stream, I receive 500KB of data on client side, but the transferred data over the TCP connection is 20 times bigger. What could be the cause ? A bad configuration of SSL parameters ?

I'm using a real trusted SSL certificate for my tests. I tried to sniff and decode the SSL stream with Wireshark but it didn't work, I wasn't able to see the decoded data. Or maybe the stream was encoded in more than one pass ? The TCP packets were 1525 bytes each. Nothing abnormal as I could see.

If somebody has an idea ... Thanks ! Olivier

Upvotes: 4

Views: 452

Answers (3)

Antares
Antares

Reputation: 285

@EJP: you were right, I made a mistake in my code: I was wrapping a BufferedOuputStream around a SomeStuffOutputStream, instead of wrapping a SomeStuffOutputStream around BufferedOuputStream. The BufferedOuputStream must be at the lowest level, just above the raw socket's OutputStream.

Now it's working perfectly!

It was a misconception, and I'm just beginning to understand why I saw "normal" packet sizes, because SSL protocol stuff. I'll be more careful next time :)

Thanks to all.

Upvotes: 0

user207421
user207421

Reputation: 311023

Renegotiations won't account for your 20x explosion. Are you using BufferedOutputStreams around the SSL socket's output streams in both directions? i.e. at the server and the client? If you don't use buffered output and your code writes one byte at a time you can see a 40x explosition due to the SSL record protocol, and, geometrically, another 40x explosition due to TCP segment overhead; the latter is usually mitigated by the Nagle algorithm, but some people turn that off, a little too keenly IMHO.

Upvotes: 1

Sounds like you are only sending one byte at a time over the wire. The overhead is then the TCP/IP-packet encapsulation.

Upvotes: 3

Related Questions