Way back in the days of telephone modems, pagers, and mainframes, Hypertext Transfer Protocol sprang into existence. Development of HTTP was initiated by Tim Berners-Lee at CERN in 1989. The first documented version of HTTP was released in 1991 as HTTP0.9, HTTP1.0 was introduced and recognized in 1996. HTTP1.1 followed in 1997 and has been the gold standard for HTTP web pages for the last 20 years.
The problem with the protocol not changing is that computing and networking technology has continued to improve and iterate over those 20 years. We are no longer browsing the web on a Mosaic web browser running on a SPARCstation 1 like I was in 1994. High speed networking, mobile browsers on cell phones, and even Application Delivery Controllers (ADC) were not in existence of in the days when HTTP was conceived.
One of the major drawbacks of HTTP1.1 is that you are limited to processing one request per TCP connection, which browsers and developers got around that problem by spawning multiple TCP connections simultaneously for each session. Developers may think “problem solved!”, while the network engineer sees his networks clogged and congested. Over the years, many different solutions were hacked into being like concatenation, domain sharding, data inlining, and the like to try to get around these types of issues.
When HTTP/2 was adopted in 2015 (RFC 7540), existing HTTP 1.1 web pages worked the same. The same methods, status codes, headers, and URIs remain. What is vastly different is data transmission and framing between the client and server (or in our case, between the client and the ADC). Even though the HTTP/2 standard does not require encryption, the major web browser consortium of Firefox, Chrome, Safari, IE, and Edge that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory.
For more details, refer to this article about the introduction of HTTP/2.
Why on earth would I want to run HTTP/2 when HTTP1.1 works just fine? Well, if your web page is just a pile of cobwebs, dust, and static text, then you’re probably not reading this blog anyway.
However, if you have a dynamic webpage that hosts a multitude of media, and you have a business that wants to succeed and make more profits, then chances are, you want to host more content, and drive more usage of your website. So, you might ask, “Can HTTP/2 really drive more traffic to my company site?” The answer is yes possibly. Let me explain why.
HTTP/2 loads most web pages quicker than HTTP1.1 on almost any device. This is a big benefit for your web site. All the major web search engines rank faster pages higher for search engine optimization (SEO). Significantly lower your page load times results in search engines sending you more traffic. HTTP/2 can take your website from the mom and pop store on the corner to the best location right off the interstate.
Another thing to consider is that fast pages make happy shoppers. Kissmetrics, an expert on customer engagement has estimated that a one second delay in a page load or response can result in a 7% reduction in conversions. In other words, if your ecommerce site averages $100,000 a day, that one second delay could cost you over $2.5 million a year.
The good news is that if you are an A10 customer, and are running ACOS version 4.1.4 or above, you can take advantage of the performance gains that you will see with HTTP/2.
The A10 Thunder ADC supports end-to-end HTTP/2 communication with ACOS 4.1.4-GR1. ACOS device operation for supported HTTP/1.1 and HTTP/2 features is transparent to the user. HTTP/2 support for a virtual port is enabled through the support-http command that is available in virtual port mode for HTTP or HTTPS ports.
On the command line, you simply configure the virtual port to process HTTP/2 traffic.
ACOS(config)# slb virtual-server vip1 10.10.10.99 ACOS(config-slb vserver)# port 80 http ACOS(config-slb vserver-vport)# support-http2
In the GUI, HTTP/2 support is just a checkbox, as seen below.
You can view HTTP/2 statistics by using the following on the command line:
ACOS(config)# show slb http2 ACOS(config)# show slb session http2
Good luck, and happy Application Delivery Controlling!