'Why HTTP/2 is slower than plain HTTPS?

I'm evaluating what I can get for my web site from HTTP2 in terms of performance and getting weird result - the site in Europe is loaded from US:

  • with HTTP/2 - in 6-7 seconds
  • with plain HTTPS - in 5-6 seconds (roughly 1 second quicker)

I've capture screenshots from Network monitor of Chrome and it looks like with HTTP/2 most of the resources are loaded one after another rather than in parallel like in case of plain SSL.

For testing I'm using my web application covered by Apache 2.4.17 (Win32) as proxy (to apply support for SSL & HTTP/2 protocols). Client browser is Chrome 46.0.2490.86 on Windows 7.

Captured network requests are below. Short summary: 1. Fist one - is HTML page 2. Next group - 6 requests - resources declared directly in HTML 3. The rest - resources added dynamically via script ('script' and 'link/css' tags in document/head).

Left side of the picture is HTTP/2, right side - same staff via plain SSL (http2_module is turned off).

enter image description here

Update: I've tested "something else" what supports HTTP/2 as reverse proxy. It is nginx 1.9.7.1 Kitty from http://nginx-win.ecsds.eu - fork of original nginx 'for windows'. HTTP/2 in original nginx is only available in commercial version, therefore I could not try it. And it looks like there are no other servers implementation of HTTP/2 + reverse proxy available for windows, or I just couldn't find them (list here and here).

The result I've got with Kitty is even more misleading - there is no 'sequential load' of resources like in Apache, but transfer rate is twice slower over HTTP/2 than over plain SSL. Final result is - HTTP/2 is significantly slower than plain SSL. Below are all of them side by side.

Out of all this i can only assume that performance strongly depends on implementation and currently available implementation perform weirdly to make any consistent conclusion about HTTP/2.

enter image description here

performancehttp2


Solution 1:[1]

So, finally my decision is - there is nothing wrong with HTTP/2 itself, there is something wrong with implementations currently available.

  • Apache HTTPD 2.4.17 / Win32 - has some weird 'sequential load' effect
  • nginx Kitty - provides weirdly slow transfer rate
  • official freeware nginx does not have http2 module built in

but

both show expected performance. Here is the screenshot for same test performed in 'the question', but with Apache reverse proxy hosted on linux computer of another guy here.

enter image description here

Solution 2:[2]

We are running latest nginx with http/2 

nginx version: nginx/1.9.10
built with OpenSSL 1.0.2e 3 Dec 2015
TLS SNI support enabled

We made the same observation. We are logging $request_time and $upstream_time. While upstream_time is equal regardless of protocol, the overall request_time is different: 

# grep ' 443 ' access.log|grep 'HTTP/1.1'| cut -d ' ' -f 3,4 | awk '{r+=$1; u+=$2} END {print r/NR; print u/NR}'
0.0116887   # HTTP/1.1 request_time in seconds
0.00673473  # HTTP/1.1 upstream_time in seconds

# grep ' 443 ' access.log|grep 'HTTP/2.0'| cut -d ' ' -f 3,4 | awk '{r+=$1; u+=$2} END {print r/NR; print u/NR}'
0.0363673   # HTTP/2.0 request_time in seconds
0.00695812  # HTTP/2.0 upstream_time in seconds

So the overall request time for http/1.1 is three times better! Maybe there is something not working with request_time logging and http/2 because of streams. I really don't know but the promise was that http/2 is faster than http/1.1 if both are running on TLS.

But I will further investigate this.

Solution 3:[3]

Have a look at this, it's a modified version of nginx developed from Taobao.org, and used by AliExpress and a lot of others busy sites. It supports HTTP2 out of the box, and also some other features available only in commercial nginx, like upstream control.

http://tengine.taobao.org/

Solution 4:[4]

HTTP2 is more efficient, means dropping from multiple connections to single. Its also more responsive, so request stream with more priority will be responded first.

Often times there are the limits in place on amount of bandwidth single connection can avail, so earlier HTTP protocol plays unfair though by making more connections, using most of your network stack, but if multiple connections lets says are already established, then HTTP1.1 will triumph over HTTP/2 in fetching multiple resources.

It all drills down to the bandwidth per tcp connection. Plus single TCP connection is prevailed with headline blocking issue, which is getting solved in HTTP3 so for now that is another downside to HTTP2

Note that at the same time, HTTP2 does not limit you making more than one connection also there are currently no restrictions that browser should only make a single TCP connection to the server, so HTTP2 can be optimized by going beyond its original definition.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Xtra Coder
Solution 2 Janning
Solution 3 eagle1
Solution 4 Shahid Roofi Khan

Related Questions