Web Performance and the Impact of SPDY, HTTP/2 and QUIC: Part 4
In the second to last part of her series about web performance, Jean Tunis lays out the benefits of HTTP/2 protocol, including multiplexed streams and data flow.
Join the DZone community and get the full member experience.Join For Free
This blog is the fourth in a 5-part series on APMdigest where I discuss web application performance and how new protocols like SPDY, HTTP/2, and QUIC will hopefully improve it so we can have happy website users.
The new HTTP/2 protocol includes a number of things that did not exist at all in HTTP before:
Uses Only One TCP Connection
In HTTP/1.1, we needed many connections, but not too many due to resource constraints and latency considerations. In HTTP/2, the standard calls for only one TCP connection to be used. This will reduce the overhead of opening and closing TCP connections and reduce the round-trip time (RTT) of going to the server and back for numerous requests.
Requests Are Multiplexed
What allows the one-connection capability to occur and not impact performance is the ability of requests to be multiplexed. HTTP requests are broken up into streams, and each stream can be sent down one connection. This is what pipelining was hoping to achieve, but did not.
It's Binary, Not Text-Based to Allow for Multiplexing
The ability to multiplex the HTTP requests is enabled by the fact that the protocol is now binary. HTTP/1.1 is a text-based protocol, which make it difficult to break up HTTP data for the multiplexing capability needed.
One of the recommendations to help improve performance is to enable caching on the server. Since web browsers generally support caching, returns to the browser would not have to re-download the same data it previously downloaded. This will save a round-trip request, and users get their request almost instantaneously, depending of the performance of their PC.
The drawback of all this caching is the data in the HTTP header used to identify whether data is cached via a cookie. The size of the cookies have gotten bigger and bigger over the years. Most browsers allow a cookie to be about 4KB. With this size, an HTTP request can sometimes be mostly of cookie data in the header.
Compressing the headers helps to reduce the growth of the HTTP headers.
Has Different Frame Types: Headers and Data
At the core of the performance improvement gains expected of HTTP/2 is the new binary framing format. Each HTTP message is encoded in binary format. With this format, HTTP/2 introduces different types of frames that are part of a message. Instead of having an HTTP message with the headers and the payload in one frame, there are frames only for data and frames only for header information. There are in total ten new frame types in HTTP/2, which help allow for the new capabilities.
Prioritizes Requests Sent
HTTP/2 allows for the browser to be able to prioritize requests that are sent. Higher priority requests can go ahead of other requests via the multiplexing mechanism. This is done with the PRIORITY frame type.
Can Reset HTTP/2 Stream Instead of TCP Connection
In HTTP/1.1, when a request is complete, the connection can be reset and closed by either end. The problem is that it means if you want to use that connection again, you have to open it, and hence another trip to the server.
With HTTP/2, we can now reset a HTTP stream inside of a TCP connection. This allows for close and reusing another stream, without tearing down the TCP connection, and requiring another trip to the server when we need to send some data down that connection. This is done with the RST_STREAM frame type.
Servers Can Push Data to Browser
The server must specify to the client that it will be pushing content to it before it does so. This is done via the PUSH_PROMISE frame type.
Controls the Flow of Data
The TCP protocol has the ability to control the flow of data by opening and closing the TCP congestion window. When the receiver needs to slow down the other side, it does so by reducing its window.
With HTTP/2, we have one connection, and if that happens, everything slows down.
But with the capability of having multiplexed streams, HTTP/2 was given the ability to provide for its own flow control at the stream and connection level. This way, if a stream of data needs to be slow down, other streams are not impacted, and the TCP connection continues to operates appropriately.
This is done via the WINDOW_UPDATE frame type.
Published at DZone with permission of Jean Tunis, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.