httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject [users@httpd] Re: mod_ssl and Transfer-Encoding: chunked wastes ~58 bytes per chunk.
Date Thu, 20 Aug 2009 15:06:09 GMT
CC'ing dev@.

On Tue, Aug 18, 2009 at 09:26:24PM +0100, Alex Stapleton wrote:
> 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.

Interesting observation.

It would not be correct to fix this by adding buffering in the chunk 
filter.  For a plain HTTP connection, any buffering/coalescing of 
packets is already done as necessary by the core output filter.  
Typically, a (chunk-size, data, crlf) brigade can get sent using 
writev() without requiring any copying.

Translating many small buckets into many less-small SSL app-data records 
is certainly inefficient - and that's a property of SSL, so, I think it 
would be correct to fix this by adding some buffering in mod_ssl on the 
"plaintext" side of the output filter, i.e. in ssl_io_filter_output and 

Any thoughts from dev@?

Regards, Joe

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message