The old HTTP is getting a fresher, faster look which means changes on Web servers.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Hypertext Transfer Protocol has been the dominant communication application-layer protocol for at least 15 years -- it's reliable, stable and effective. But as websites evolve and become complex with richer media and more interactive options, standards bodies like the Internet Engineering Task Force (IETF) recognized the need to reduce latency and boost performance when retrieving and displaying ever-richer content. Hypertext Transfer Protocol 2 (HTTP/2, not HTTP 2.x) is the IETF's planned update to HTTP 1.1.
The HTTP/2 draft standard, soon to be ratified, will mark an important and long-overdue step forward in website performance by deliberately reworking some aging communication processes that have become bottlenecks. HTTP/2 should be fully backward compatible with current HTTP 1.1 implementations because it doesn't add or modify any HTML or other page coding.
These key points of HTTP/2 will help IT professionals prepare to move those server and client deployments forward.
The importance of TCP
HTTP 1.1 is easily overwhelmed by complex or dynamic webpages. HTTP/2 provides four key benefits over HTTP 1.1.
1. HTTP/2 uses binary code instead of text. Binary protocols are smaller (more efficient) and less error-prone than text protocols with spaces, capitalizations and so on. HTTP 1.1 must choose one of four ways to parse a HTTP message; HTTP/2 uses only one method.
2. HTTP 1.1 has limited Transmission Control Protocol (TCP) connectivity: It allows one practical request per TCP connection. Web designers' workaround techniques, like pipelining, boost performance by fielding multiple requests, but falter because they are not fully supported from Web server to browser. Browsers can use multiple TCP connections to boost performance, but the excessive connections cause congestion, duplicate a lot of data, and choke off other applications.
HTTP/2 rectifies this performance issue with multiplexing, which formally allows multiple requests to share the same TCP connection in an orderly and organized manner. Parts of multiple messages can mix together on the wire with one TCP connection. This avoids buffer overflows, TCP traffic congestion and re-transmit requests that impair performance.
3. HTTP/2's header compression reduces the identifying and organizational data that accompanies each HTTP asset. Compressing the header data cuts down on extra requests that bog down communication speeds. The highest payoff for this technique is in mobile website access, as on smartphones.
4. A Web server under HTTP 1.1 must wait for a client browser to request each asset for a given webpage. Under version 2, it can start sending content to the client without waiting for the client to expressly request each asset. Known as server push, it can save tremendous time on the server end waiting for a long line of asset requests from the client.
Compression and encryption
Headers are critical to proper HTTP communication. But the HTTP 1.1 protocol requires a substantial number of round-trip exchanges to convey the header data for every webpage asset request -- adding latency.
HTTP/2 reduces latency without changing any of the underlying architecture of current HTTP standards. It applies data compression to every request and response message header, meaning less data exchanged and fewer exchanges per message.
GZIP compression, a standard compressor, was abandoned when attacks revealed possible vulnerabilities with cookies and authentication tokens. Instead, the IETF developed HPACK, a simple custom compression scheme that restricts susceptibility to security attacks. The HPACK format is simple and inflexible to reduce the risk of interoperability or security issues.
Developers can access the complete standard for HTTP/2 as well as a separate standard that outlines HPACK once the protocol is formally ratified.
HTTP/2 does not require encryption, but supports secure sockets layer and transport layer security (TLS) encryption, as did HTTP 1.1. HTTP/2 outlines the TLS version, cipher suite and extensions needed for implementation.
A draft standard allows TLS use for opportunistic encryption, similar to Windows' use of IPsec. Rather than deploy a costly formal encryption scheme such as HTTPS, a mechanism like TLS establishes a secure connection wherever possible on the fly.
What servers and browsers support HTTP/2?
Numerous browsers currently support HTTP/2. Mozilla Firefox 34 and later support the HTTP/2 draft 14 with header compression. However, Firefox will only support HTTP/2 over TLS (effectively supporting only HTTPS URLs).
Microsoft's Internet Explorer with Windows 10 Technical Preview only supports HTTP/2 over TLS. The latest versions of Google Chrome support HTTP/2, but users may need to start Chrome with the "-enable-spdy4" command line flag to invoke it.
An increasing number of Web servers are including HTTP/2 support for test and development purposes. The Sasazka module for Node.js supports HTTP/2 draft 14 and later. The Lucid server written in Erlang will support HTTP/2. Additional servers and clients with HTTP/2 support are available from Twitter, LiteSpeed Technologies (OpenLiteSpeed 1.4.5), MIT's Warp 18.104.22.168 lightweight Web server and others.
HTTP/2 is not designed to be an essential upgrade but rather a performance augmentation. It will not immediately displace HTTP 1.1. Still, developers and enterprise IT administrators should test any HTTP/2 Web server deployments on performance and dependency issues (such as TLS-only requirements). Verify that major browsers behave as expected before any major server-side upgrade.
About the author:
Stephen J. Bigelow is a senior technology editor at TechTarget, covering data center and virtualization technologies. He's acquired many CompTIA certifications in his more than two decades writing about the IT industry.
Secure HTTP -- What is it?
Could you benefit from file transfer protocol?