3 ms·
This test 'cheats' in favor of HTTP 2.0. The problem is that there are ways around the HTTP 1.1 limitation of 'one connection, one thing,' and this test uses a
by chucky_z 11y ago
This test 'cheats' in favor of HTTP 2.0. The problem is that there are ways around the HTTP 1.1 limitation of 'one connection, one thing,' and this test uses absolutely none of those ways. It makes a connection, receives an image, closes a connection, opens a connection, receives an image,... 200 times.
The HTTP/2 test does exactly what it's designed to do: opens a lot of connections and receives the images pretty much all at once.
This isn't to downplay HTTP/2, but it's something that should be noted for _this_ test.
- stdbrouw 11y agoAlternatively you could say that using all of the various tricks to speed up HTTP 1.1 would be cheating in favor of 1.1. Personally, I prefer not to have to think about how to optimize my websites; just let the protocol figure it out for me.
- Steltek 11y agoElsewhere in the comments here, it's mentioned that nginx doesn't yet have server push so maybe it's fair to call these naive test setups then? I'd certainly buy that HTTP/2 has more head room for acceleration and optimization but I'm curious what the difference there would be. However, it starts to sound like programming language benchmarks where the test servers aren't setup in an "idiomatic" manner. I believe that HTTP/2 isn't opening many connections. It's opening one TCP connection and multiplexing many requests through that. This would allow for exploiting a pre-warmed TCP connection in subsequent requests. I've always felt that was a flaw in HTTP/2: with minor modifications, that multiplexing protocol could have been split out. I'm interested to see how HTTP/2 could accelerate your modern jumbo media websites. The ones with a dozen or so tracking bugs, ads, etc. All splattered across multiple domains with ad servers that aren't quite as zippy as one would wish.