SSL Latency/Handshake Speedup: Set TLS Record Size at 1400

[Xing]

Sorry to bombard the list with posts today. 

I'm trying to reduce the latency of SSL handshakes right and read up on this:

http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#_certificate_chain_length

Which is referenced by this 

http://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/

The author of the book and result verified by the blogger that part of the SSL latency especially during handshake can be reduced/fixed by making sure every single TCP packet contains exactly 1 TLS record. By default openssl uses 16KB record size which is much too high for high latency https connections and recommend 1400 value which in their view is the best size for both IPV4 and IPV6 assuming MTU = 1500.

Would love to see if the litespeed team can cook up this. I read the implementation of haproxy and nginx and both are different in implementation and I could not find a way to change this on my own digging through the current code. 

[Xing]

Forgot to mention the above blogger is from Google and they are using this 1400 TLS record size on all their servers, at least when it comes to accept/handshake stage. 

[Xing]

To correct my emails.

What the google engineer did was actually change the OpenSSL handshake buffer from default of 4K to 16K, since his cert is larger than 4k and openssl handshake default buffer,  and for the reset of ssl_writes() using 1400 chunks. 

[George Wang]

For OLS, you can patch

SSLConnection::write( const char * pBuf, int len )

call SSL_write() in a loop when len > 1400 or what ever chunk size.

To me, it may not be a good idea to send data in that small pieces.
Each SSL_write() will flush data out, which adds about 40-50 bytes SSL
protocol overhead per chunk. the overhead at network level is higher
with smaller chunk. and may cause too many write() system calls.

Internally, OpenSSL uses 16KB buffer, LSWS uses 8K or 4K buffer.

To reduce the memory allocation per connection, you may need to patch
OpenSSL code to use smaller buffer.

The goal of using smaller chunk is to reduce the memory cost per SSL
connection with sacrificed throughput (maybe not significant), I can
understand why google doing that as they want to maximize SSL
connections per server due to the amount of traffic to their service, it
may not apply to average users.

Chrome SPDY implementation send DATA frame in 2852 bytes to fit into 2 *
MTU.

Best regards,
George

> --
> You received this message because you are subscribed to the Google
> Groups "OpenLiteSpeed Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openlitespeed-deve...@googlegroups.com.
> To post to this group, send email to
> openlitespee...@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/openlitespeed-development.
> For more options, visit https://groups.google.com/groups/opt_out.

[Pedram Soltani]

I have a slow SSL handshake on litespeed based website ( r9host.eu ). I see some websites with only 23ms SSL handshakes but mine about 250ms or more. What configurations can I use to resolve this issue ? Thanks