This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Getting strange SSL record size

Hi,

We have a software where Client is used to copy file over to and from a server. The communication happens over SSL layer. I am analyzing an issue where file copying is "very" slow using our client-server software when compared with some other tools.

What I have observed is that, the packets captured follow a pattern. First there will be a packet with a payload data of 16384 bytes (reassembled from 12 assembled TCP segments) and the next one be a packet with payload data of 71 bytes only. And this pattern repeats itself. I am worried about the packet with 71 bytes, is it causing some delay?

The following is the screenshot of a reassembled packet of 16384 bytes. First Packet

The following is the screenshot of next packet of 71 bytes. Second Packet

This pattern of 16384 byte SSL record(?) and 71 byte SSL record(?) keeps on repeating itself till the whole file is uploaded. Could this be slowing down the file transfer? Moreover, why could this thing be happening? Any pointers?

Sorry if this is something very simple that I can't understand, I am very new to this thing. Thanks for taking time to go through this message.

ssl wireshark

asked 26 Dec '14, 12:02

prabhatpuros...
11●1●1●3
accept rate: 0%

edited 26 Dec '14, 12:07

One Answer:

First of all: It's hard to do troubleshooting based on screenshot, where most of the interesting parts are missing!! Would it be possible to upload an anonymized capture file (see tracewrangler.com) somewhere (google drive, dropbox, cloudshark.org) and to post the link here??

Anyway, here are some wild guesses based on the information you provided in the text and the screenshots.

The time stamps of all frames, including frame 76588 with 71 bytes, are within a few milliseconds, if the blackened pieces all belong to the same session! So, I don't believe that the frame with 71 bytes is causing the problem.
You mentioned 16384 bytes followed by 71 bytes. The first one is 16 Kbyte and sounds like the default size of a buffer, either on client or the server, either application or TCP/IP stack.
As there is no information about the rest of the transmission (ACKs, lost frames, timing), it's impossible to give any real explanation, especially as you did not specify what exactly "slow" means in your context.

So, here are some ideas:

Idea #1: Try to find the value of 16 Kbyte in your code or the config of your TCP/IP stack (send/receive buffer) and increase that value. Maybe that will increase throughput.

Idea #2: Compare a capture file created with your application to one created with another client. How do they differ?

Idea #3: draw the following I/O graphs and post them here.

Statistics -> TCP Stream Graph -> Window Scaling Graph
Statistics -> TCP Stream Graph -> Time-Squence Graph (tcptrace)

Regards
Kurt

answered 27 Dec '14, 07:30

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%