2

The Yahoo Developer Best Practices recommend using multiple hosts (host1.company.com, host2.company.com, etc..) as a way of overcoming a webbrowsers built in limitation of only issuing two concurrent requests per domain.

Please gloss over this backgrounder for more information.

Before I begin, don't be confused into thinking that I am talking about "DNS performance". I'm not. I'm only talking about overcoming a browsers' built-in throttling mechanism.

So, how do I properly implement a HTTPS-only website with regard to parallel requests?

This is a logical question because every new HTTPS request will incur setup and teardown costs. This will impact performance in proportion to how many SSL/TLS connections opened.

The factors that affect the performance of a SSL/TLS connection include

So if I think further about the dependencies involved, that makes me ask these questions:

Does my certificate choice affect performance when using many DNS domains?

Does the server configuration affect performance when using many DNS domains?

example:

Suppose a web browser downloads content from 10 different subdomains, it potentially has to set up each SSL session from scratch. That would mean there could be a significant delay in getting the first page to load.

  • Would first-page load of PFS perform better or worse than AES vs RC4? What about the second page?

  • Can a wildcard certificate (or one with different Subject Alternative Names) allow me to use many domains with many domain names? Will this solve the performance problem?

makerofthings7
  • 8,911
  • 34
  • 121
  • 197
  • See also [Guidance for Implementing HTTPS-Only websites](http://security.stackexchange.com/q/7790/396) – makerofthings7 Oct 01 '11 at 16:18
  • You are mixing apples and oranges with this question. PFS is not an alternative to AES and RC4. The certificate contents have nothing to do with DNS, in fact I don't know where you think DNS is coming into play in your performance problem. And you never say what your performance problem is. Whatever it is, chances are it is not caused by SSL -- but it can be. That is why real benchmarks are needed. – President James K. Polk Oct 01 '11 at 17:18
  • @GregS You and I are talking about two different things. Read [this post and related link about how a browser can be handicapped from a performance perspective when serving content from only one domain.](http://stackoverflow.com/q/998882/328397). I want to port this best practice into the HTTPS world, but certificates and ciphers need consideration. – makerofthings7 Oct 01 '11 at 17:49
  • @GregS Regarding PFS, see [this comparison of DHE, 3DES, AES, and RSA for SSL Symmetric encryption](http://security.stackexchange.com/questions/7440/what-ciphers-should-i-use-in-my-web-server-after-i-configure-my-ssl-certificate/7621#7621) – makerofthings7 Oct 01 '11 at 18:22

3 Answers3

0

I don't think this covers all your questions but here is a link to HTTPS Performance Tuning and another for Overclocking SSL

TLDR
  • 301
  • 2
  • 9
0

Browser connection limits are more of an issue for older browsers (e.g. ie 7 and earlier) that had a limit of two connections per host name. Modern browsers use up to 6 connections per hostname.

In fact, sharding across multiple domains can end up being slower with modern browsers because of the additional overhead of setting up each connection. It would be worth running some tests on target browser versions before deciding whether to put resources on different host names.

If you do decide to use multiple host names with SSL then the easiest way to do that is to use a wild card SSL certificate as described in this blog post:

http://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/

0

With regard to parallel requests... Have you looked at the benefit that a script loader can provide? Assuming your site uses javascript and lots of images. Like most do these days!

Per the LABjs folks:

In addition to loading scripts in parallel, scripts loaded through LABjs no longer block page resource downloads (images, CSS). This will generally lead to significant decreases in page-load time (often 2x - 3x faster).

Cheers

HTTP500
  • 4,833
  • 4
  • 23
  • 31