Hypertext Transfer Protocol (HTTP) is the protocol used primarily for communication between the user’s browser and the websites that users are accessing. Introduced in 1991, with a major revision in 1999 to HTTP 1.1, HTTP protocol has many limitations. In 2009, engineers at Google redesigned the protocol in a research project called SPDY (pronounced “speedy”) to address some of HTTP 1.1 limitations.
Websites in the early 90’s when HTTP was introduced were markedly different from today’s websites. In February 2015 the Internet Engineering Task Force (IETF) introduced a new version, HTTP/2, to keep up with the evolution that internet has undergone since the early 90’s.
HTTP/2 introduces a binary layer into HTTP. No change in HTTP semantics is required, which is important to maintain compatibility. HTTP/2 also introduces a variety of enhancements to remove the limitations of HTTP 1.1 and enable it to handle it the newer types of content efficiently. A few of the major enhancements of HTTP/2 over HTTP 1.1 are listed below:
- Transaction Multiplexing: HTTP 1.1 allowed the clients to send only one request per TCP connection at a time. The subsequent request could only be sent after receiving a reply for the first one from the server. With HTTP/2 the client can now send interleaved requests on the same connection, out-of-order, without waiting for the responses for the earlier requests, thus making the communication much more efficient. This leads to much quicker page load on the client.
- Session Efficiency: When requesting web pages, the client is required to provide session information such as encoding, cache control, user and server identification, cookies, etc. This information is repeated for every HTTP transaction, adding to processing delays and increased page load time. HTTP/2 introduces a new header compression to reduce the payload. In addition, with HTTP/2, it’s enough to send the full header only once per page, and not per transaction. This results in significantly faster web page load time.
- Bi-directional Communication and Server Push: With HTTP 1.1, requests could only be initiated by the client, therefore the server could only send resources to the client, after the client had requested them. With HTTP/2, the server can initiate pushing resources to the client. This bi-directional communication can reduce the number of transactions and use the available bandwidth much more efficiently, leading to faster web application response times.
So should you adopt HTTP/2?
HTTP/2 is an important upgrade that can significantly reduce latency for users accessing web applications through transaction multiplexing and server push; reduce bandwidth required to support the same number of users accessing a website through better header compression and reduce the load on the servers due to fewer requests. This means that web applications will have faster response times and serve your users better. Any website where the user interaction is very sensitive to application latency will benefit from a move to HTTP/2.
Are you ready to move to HTTP/2?
HTTP/2 is backward compatible with HTTP 1.1, so you could ignore it completely and everything will continue to work as before, but your users surely are ready to move! Most major browsers (Chrome, Opera, Firefox, Internet Explorer 11, Safari, and Edge) added HTTP/2 support by the end of 2015. While encrypted web communication for HTTP/2 is not mandated, all browser implementation of HTTP/2 require HTTPS connection. So, even when a website uses encrypted HTTPS communication, efficiently handling SSL should be one of the key areas to focus on, before enabling HTTP/2.
Although the majority of browsers already support for HTTP/2, many web server platforms don’t offer HTTP/2 support yet. One of the capabilities that HTTP/2 added to improve performance is bi-directional communication with server push. With server push, the server pushes resources to the client, before the client requests them specifically. To take advantage of this capability, the server needs the ability to determine which resources to push. Understanding which objects to push before the user asks for them, ensuring those objects don’t already exist in the browsers’ cache (otherwise – it will make the transaction slower not faster), is a capability no web servers natively have today.
How long will it take for the adoption?
HTTP 1.1 remains the most deployed HTTP version by far, but HTTP/2 adoption is picking up steam. However, if the past is any predictor, it’ll be a very long time before all applications are modified to support HTTP/2. Unlike the past though, as the cloud-based applications proliferate, and the cloud service providers start supporting HTTP/2, the server side of HTTP/2 will gain accelerated adoption. The figure below from HTTP/2 Dashboard provides a snapshot of HTTP/2 adoption timeline thus far.
How to transition to HTTP/2?
Many Application Delivery Controllers (ADC) provide HTTP/2 gateway functionality enabling protocol translation from HTTP/2 on the client to HTTP 1.1 on the server side, and vice versa. Using such a solution ensures an interim move to support HTTP/2 on the front-end.
To support HTTP/2 Server Push without having to rewrite applications to HTTP/2, take advantage of web performance optimization (WPO) techniques and algorithms to determine which objects to push to the client – helping to enable the new server push capability the HTTP/2 protocol offers. This added value offered by the ADC gateway is something that can add significant acceleration to your website and ease your transition so your website users can start experiencing the benefits of this enhanced protocol.
For more details: Fastest Website Acceleration for New HTTP Protocol
Read “Keep It Simple; Make It Scalable: 6 Characteristics of the Futureproof Load Balancer” to learn more.
Prakash Sinha is a technology executive and evangelist for Radware and brings over 29 years of experience in strategy, product management, product marketing and engineering. Prakash has been a part of executive teams of four software and network infrastructure startups, all of which were acquired. Before Radware, Prakash led product management for Citrix NetScaler and was instrumental in introducing multi-tenant and virtualized NetScaler product lines to market. Prior to Citrix, Prakash held leadership positions in architecture, engineering, and product management at leading technology companies such as Cisco, Informatica, and Tandem Computers. Prakash holds a Bachelor in Electrical Engineering from BIT, Mesra and an MBA from Haas School of Business at UC Berkeley.