Simple comparison of HTTPS, Spdy and HTTP/2 performance

Chinese Original: HTTPS, Spdy and HTTP/2 a simple comparison of performance
Finishing from: A simple performance Comparison of HTTPS, SPDY and HTTP/2
Please respect the copyright, reproduced please indicate the source, thank you!

These days, mobile phones have been hijacked by Unicom, with the Daily news will be inserted into the spam ads, let alone in the visit to third-party websites. So attention to prevent the website is hijacked by the carrier technology, here recommended fenng before the article, in Rogue no lower limit of the operator's means below, we can do in fact not much. and HTTPS and Spdy is actually better technology, not only can guarantee not hijacked by the carrier, but also can protect the user's data security. Just see this article about HTTPS, Spdy and is about to become a reality of the HTTP/2 articles, feel more valuable, it is easy to translate over.

The following are translations:

Firefox 35 was released this week, becoming the first browser to open a default support HTTP/2 protocol. Chrome also supports it, just in the name of Spdy 4, and it has to be about://flags opened manually inside.

However, the HTTP/2 specification has not been finalized, so Firefox actually supports the draft of HTTP/2 14th, and this version of the draft may not have changed much from the final release. Google now supports HTTP/2 's 14th draft and SPDY protocol on its servers, giving us a chance to compare the performance of HTTPS, Spdy and HTTP/2 based on the same Web page.

HttpWatch is also updated so that it can monitor HTTP/2 in Firefox, and it now has a column that specifically shows the protocols used for each request:

Performance comparison

This set of performance tests is using Firefox and HttpWatch, the test page for Google UK homepage, using three kinds of protocols:

• The original HTTPS
• spdy/3.1
• Http/2

Switch between the about:config different protocols by enabling/disabling the following features in Firefox:

Each test is based on an empty cache. So even though the test is simple and based on only one website, the results are representative.

Test # #: Size of the request and response headers

Most Web sites already have compression (GZIP) enabled when downloading text content because it provides significant performance benefits. Unfortunately, http/1.1 does not support compressing each request and the corresponding HTTP header. Spdy and later HTTP/2 are designed to use different compression types to compensate for this short board.

The spdy uses a common deflate algorithm and HTTP/2 uses a hpack algorithm specifically designed for the compression header. It uses pre-defined tokens, dynamic tables, and Huffman compression.

You can also see the difference in the generated header size from an empty request. On Google UK Home page there is a beacon request (204 return code) that returns empty content. The following is HttpWatch, the ' Sent ' column shows the size of the request header, and the ' Received ' column shows the size of the response header:

Winner: HTTP/2

HTTP/2 's header size is still very obvious, it seems hpack really good.

Test # #: Response Information size

The response information includes the response header and the encoded response content. HTTP/2 provides the smallest header, then does it give the smallest response information?

The picture resource is this:

However, there is less response information for text content Spdy, although its header is larger than HTTP/2:

This is due to the optional padding bytes that can be added to the HTTP/2 data frame. HttpWatch cannot now display padding, but in debug log you can see that the Google server has added a fill to the data frame of the text content. The reasons for using padding given by the HTTP/2 specification are:

Padding can be used to confuse the actual size of the frame content and to reduce special attacks in HTTP. For example, the compressed content contains an attacker-controlled attack of plaintext and secret data (see [BREACH]).

Padding is not used for picture files because it is already a compressed format and does not contain plain text that is controlled by the attacker.

Winner: SPDY

The larger response body you see on Google servers is because the fill is used in the data frame. Although HTTP/2 produces a larger response than Spdy, its encrypted connection may be more secure. This can be a place where security and performance tradeoffs are compromised.

Test #3:tcp Connection count and SSL handshake request time

By raising the maximum number of concurrent connections per domain name from 2 to 6 or more, the browser has achieved significant performance gains in http/1.1. Increasing concurrency makes the network bandwidth more efficient to use because it reduces the block of requests.

Spdy and HTTP/2 allow multiple requests to send and receive data at once to support concurrency in a TCP and SSL connection by reusing a single connection.

After adding the ' Connect ' and ' SSL handshake ' time, SPDY:

HTTP/2:

They only create connections for different domain names, and the original HTTPS can create multiple connections for a domain name to increase concurrency:

Winning together: SPDY & HTTP/2

Increased multiplexing support in Spdy and HTTP/2 reduces the number of network connections that have to be set when downloading pages. As an added benefit, when HTTP/2 is used more broadly, the network server no longer has to maintain too many active TCP connections.

Test # #: Page load time

The ' page Load ' time in HttpWatch shows when the page is fully downloaded and available. Most of the time, this is a reasonable measure of the speed of the Web page.

The following shows the page load time for three protocols:

Winner: HTTP/2

The maximum load time for native HTTPS may be due to a lack of header compression and additional TCP connections and SSL handshake requests. For more complex pages, the benefits of Spdy and HTTP/2 may be more pronounced.

We also found that HTTP/2 is usually faster than spdy, although its response information is usually much larger. This advantage may be due to the smaller GET request information that Hpack compression reduces. Our network connection, like many people, is asymmetric-the upload speed of the network is much smaller than the download speed. This means that any saved upload data is more valuable than the equivalent amount of downloaded data saved.

Conclusion

The HTTP/2 looks to provide significant performance benefits. However, the use of padding in response information is a potential trade-off point for performance and security.

Simple comparison of HTTPS, Spdy and HTTP/2 performance