Loading a web page rarely means downloading one object. A browser may need the HTML document, style sheets, scripts, fonts, icons, photographs, and many other resources before the finished page can appear.
Older HTTP communication could make this collection of separate requests surprisingly inefficient. Browsers developed ways to work around the limitations, including opening several connections to the same server, but the underlying protocol still imposed restrictions on how efficiently those resources could travel.
One Page Could Generate Many Separate Requests
The first HTML document gives the browser instructions about other resources it needs. As the document is examined, additional requests begin appearing for the files referenced by the page.
A relatively modest website could therefore turn one navigation into dozens of individual exchanges. More complicated pages could require considerably more.
The page looked like one document to the visitor, but the network often saw a collection of separate resources competing to reach the browser.
The challenge was not simply the amount of data. The way those requests moved through the connection also affected how quickly useful information could arrive.
HTTP/1.1 Had Developed Its Own Workarounds
Persistent connections allowed HTTP/1.1 to reuse a connection rather than creating a completely new one for every object. That was useful, but requests using an individual connection still had important ordering limitations.
Browsers commonly compensated by establishing multiple connections to the same host. Web developers also adopted techniques intended to reduce the number of requests or spread resources across different hostnames.
Combining files, joining small images into sprites, and distributing resources across hostnames were among the techniques used to work around characteristics of HTTP/1.1. Some of these practices became less important once HTTP/2 could handle many transfers more efficiently through one connection.
HTTP/2 Divided Communication Into Streams
HTTP/2 changed the structure of communication between compatible clients and servers. Instead of treating each exchange as though it needed an independent path through the connection, the protocol could divide communication into multiple streams.
Each stream carried frames belonging to a particular request or response. Frames from different streams could be interleaved while traveling through the same underlying connection.
The browser no longer needed a separate connection merely because another resource had to be requested before an earlier transfer had completely finished.
Multiplexing Changed the Traffic Pattern
Multiplexing allowed multiple active HTTP/2 streams to share one connection. A request for a style sheet could coexist with requests for scripts, images, fonts, and other resources rather than forcing all of them into one simple sequence.
Responses could also be broken into frames and interleaved. The server could send part of one response, frames belonging to another response, and then continue the first stream.
This did not make the physical network infinitely faster. The same connection still had finite bandwidth and remained subject to network latency. What changed was how efficiently several HTTP exchanges could use that connection.
The Protocol Became Binary on the Wire
HTTP/2 retained familiar web concepts such as requests, responses, methods, status codes, and headers, but its wire representation changed. Communication was organized through a binary framing layer rather than the textual message structure associated with HTTP/1.1.
HTTP/2 represents protocol communication using defined binary frames. The browser and server interpret those frames and associate them with the appropriate streams while applications continue working with familiar HTTP semantics.
This framing system made multiplexing possible because each frame could identify the stream to which it belonged.
Repeated Headers Could Consume Less Space
Web requests frequently repeat information. Several requests sent to the same site may contain many of the same header fields and values, even though the resource being requested is different.
HTTP/2 introduced HPACK header compression to reduce the amount of repeated header information transmitted between endpoints. Rather than repeatedly sending identical information in full, the connection could use a more compact representation.
The benefit depended on the traffic involved, but it addressed overhead that became increasingly noticeable as websites accumulated larger numbers of resources and requests.
IIS Could Use HTTP/2 Without Rebuilding the Website
HTTP/2 support in IIS 10.0 was integrated with the Windows HTTP networking stack. For supported configurations, an existing website did not have to be rewritten into a new kind of application simply to use the newer protocol.
The browser and server could negotiate the appropriate protocol when establishing the secure connection. A compatible client could use HTTP/2 while other clients could continue communicating through an older HTTP version.
HTML, CSS, JavaScript, images, and other website resources remained ordinary web resources. HTTP/2 changed how the requests and responses were transported between compatible endpoints.
A Faster Protocol Did Not Guarantee a Fast Website
HTTP/2 could remove important communication inefficiencies, but it could not repair every source of poor website performance. A slow application, overloaded server, enormous image, inefficient database query, or congested internet connection could still delay a page.
The protocol improved the machinery used to exchange web resources. It did not eliminate the need to build efficient pages or operate responsive servers.
What changed was a limitation that had influenced web performance for years. Several requests no longer needed to behave as though each one deserved its own road. They could travel as separate streams through the same connection, allowing the web server and browser to make much better use of the path already between them.
