The Internet Engineering Task Force (IETF) completed work on the Hypertext Transfer Protocol 2 (HTTP/2) standard earlier this week. This new protocol will replace current versions of HTTP (1.0 and 1.1) and is the largest single update to the standard since it debuted more than 25 years ago. Most analysts and websites that have covered the announcement positively, but at least one major developer, Poul-Henning Kamp, has publicly spoken out against the project.

First, some uncontested background. The push to update HTTP/2 really got started after Google released its own SPDY protocol. SPDY was designed to accelerate HTTP traffic (the term is not an acronym) and Google publicly stated it was working to have its custom protocol turned into a standard back in 2012. The IETF accepted SPDY as the basis for HTTP/2, and while the two standards aren’t identical (HTTP/2 allows for multiplexing across different hosts simultaneously, whereas SPDY doesn’t), much of SPDY’s design was cut-and-pasted into the HTTP/2 standard.

According to Kamp, this was a significant mistake. He raises multiple issues with HTTP/2’s design, claiming that it doesn’t protect user privacy, does nothing to address the numerous security and privacy issues around cookies, incrementally improves performance (at best), and was driven by politics, not technical best practices. Kamp isn’t the only unhappy developer — Constantine Murenin weighed in on the IETF mailing list, noting that the standard fails to address opportunistic encryption, relying instead on mandatory encryption via HTTPS. There are a number of reasons why websites and hardware might not deploy HTTPS that have nothing to do with nefarious intent and everything to do with cost, implementation, and certification difficulties.

The HTTP/2 standard doesn’t actually require mandatory encryption, but multiple browser vendors have stated they won’t implement HTTP/2 without it, making it a de facto requirement.

Will HTTP/2 improve web performance?

Evidence on whether the new protocol will improve web performance is mixed at best. A study comparing Google’s SPDY to HTTP found that the degree of improvement depended on the precise conditions being tested. The graphs below show the time spent performing network interactions, dubbed the Time on Wire (ToW). Lower values mean faster performance.

Picture Here

Performance, in this case, was all over the map. Further testing revealed that SPDY’s ability to improve performance depended on Round Trip Time (RTT). At low latencies, the protocol’s improvement was much smaller than when RTTs rose.

Picture Here

The team also noted that SPDY took a heavier performance hit than HTTPS when packet loss was higher and that the protocol was intrinsically more likely to suffer packet loss than the protocol it ostensibly replaces. Whether these issues were fundamentally corrected in HTTP/2 is unclear — no one seems to have addressed the issue one way or another.

In aggregate, HTTP/2 does seem to offer some performance improvement, but the size and scope of that boost are going to be context-dependent. Kamp does make one excellent point — good, meaningful standard updatse tend to propogate extremely quickly through the ecosystem, while supposedly necessary changes, like the IPv4 to IPv6 shift, see positively miserable uptake. Which model HTTP/2 will follow is still uncertain.