Reputation: 285
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
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
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
Reputation: 75416
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