httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Stapleton <al...@prol.etari.at>
Subject mod_ssl and Transfer-Encoding: chunked wastes ~58 bytes per chunk.
Date Wed, 19 Aug 2009 16:53:41 GMT
(This has been cross posted to users@. I apologise if this mail isn't
relevant to the dev list.)

First some background. We use Apache HTTPD 2.0 over a high-latency,
high packet loss GPRS WAN. The cost per byte is tangible. We use SSL.
We also use Transfer-Encoding: chunked sometimes. This is a machine
monitoring application. We are using iframe streaming to push real
time data to operators browsers.

I have noticed after much faffing around with wireshark that httpd
will transmit 3 Application Data fragments for each chunk in a chunked
HTTP stream. The fragments are the HTTP chunk size, the chunk data,
and then a CRLF. All fragments in an SSL session are rounded to the
length of the ciphers block size. This results in the 4+2 bytes for
the chunk frame ending up being 64 bytes of data over TCP. A waste of
58 bytes per chunk in this case.

I'm not aware of any reason for this to behave specifically in this
way and clearly combining the entire chunk into a single SSL fragment
would provide a significant bandwidth saving for HTTP streaming
applications if not more mainstream ones.

I've done a fair amount of poking through the httpd source today to
try and isolate this but this is my first foray into the depths of
httpd so I've not got far in the direction of a solution. I have
identified that this 'problem' is due to the way the chunk_filter
function adds buckets into the brigade which end up getting turned
into their own fragments by mod_ssl. Creating a new bucket which has
the extra data wrapped around it would presumably be far too
inefficient for a general solution. I was considering using the FLUSH
bucket type but am not fully aware of how it's used by the various
filters.

I'm not sure what the ideal way is to go about fixing this, or if it's
even in fact an actual source code level problem rather than a
configuration one, hence why this is posted to users for now.

I can provide text dumps from tshark if that would be more
illuminating of the patterns I'm seeing.

Alex Stapleton

Mime
View raw message