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 ssl_filter_write. Any thoughts from dev@? Regards, Joe --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|