This course touches on all aspects of HTTP/2, starting from explaining the need for a new version of HTTP (after more than two decades successfully using version 1.1), to understanding the inner workings of HTTP/2. Most importantly, it covers what we need to know as developers on adapting our existing applications to work with HTTP/2.
Working with HTTP/2 Libraries and Servers In this module, we're going to take a look at hosting HTTP/2 applications under what servers that are available, as well as how we can interact with client and server libraries when using HTTP/2. If we take a look at the state of the ecosystem, we can more or less divide it into three areas. From one side we have the browsers, which provide support for HTTP/2, and then we have servers, which act obviously as just HTTP/2 servers, as well as the ability to host applications that can take advantage of HTTP/2. And last but not least we also have libraries, and these libraries we can use to connect to HTTP/2 servers, as well as act as HTTP/2 servers serving requests and responses with clients. When it comes to browser support, we've already seen that the vast majority of browsers already provide support for HTTP/2. Microsoft Edge provides it. Firefox, Chrome, Safari, iOS, and Android all pretty much come already with HTTP/2 support built in. In fact, if we go to a website, which is called caniuse. com, we can type in the different technologies, in our case would be HTTP/2, and see a list of the different browsers that provide support for HTTP/2. If we come to the website we just mentioned, and I type in http2, I can see the list of browsers. It also provides me with a global percentage of adoption, as well as location-specific, which in this case is Spain. In fact, if we type spdy, we can see that already some browsers, including Microsoft Edge, no longer really provide support for SPDY. Of course you can use this website for anything, including AJAX, for instance. So it's a very good site to show you which technologies are supported by which browsers.
Adapting Existing Applications Welcome to this last module on HTTP/2. We're going to take a look at some of the things we need to do to adapt our existing web applications and APIs to take advantage of HTTP/2. For years we've been working hard on trying to optimize web applications to reduce load time, lower latency. Now the reason for this, as we saw in module 1, isn't so much HTTP, but that HTTP rests on TCP, which is the transport layer. And TCP isn't cut out for the type of interchanges that we do with HTTP, so we've had to try and address these shortcomings, and we've had optimization techniques surface up to the application level and into our applications causing us to have to deal with things that really aren't necessary in the domain aspects of the problems that we're trying to solve. Now with HTTP/2, many of the workarounds can be avoided moving forward given that the shortcomings are now addressed at the protocol layer. But this does raise a question. What about the things we've already done? Do they need to be undone? Unfortunately, to a certain point, yes. Certain things that we've optimized by use of technique, such as inlining, etc. can be counterproductive when it comes to using HTTP/2, or at the very least not provide any substantial benefit and might require undoing. So let's look at some of these in more detail.