The next version of the Hypertext Transfer Protocol (HTTP)—the network protocol that defines how browsers talk to Web servers—is going to make a major break from the versions in use today.

Today’s HTTP (versions 1.0, 1.1, and 2) are all layered on top of TCP (Transmission Control Protocol). TCP, defined as part of the core set of IP (Internet Protocol) layers, provides reliable, ordered, and error-checked delivery of data over an IP network. “Reliable” means that if some data goes missing during transfer (due to a hardware failure, congestion, or a timeout), the receiving end can detect this and demand that the sending end re-send the missing data; “ordered” means that data is received in the order that it was transmitted in; “error-checked” means that any corruption during transmission can be detected.

These are all desirable properties and necessary for a protocol such as HTTP, but TCP is designed as a kind of one-size-fits-all solution, suitable for any application that needs this kind of reliability. It isn’t particularly tuned for the kinds of scenarios that HTTP is used for. TCP requires a number of round trips between client and server to establish a connection, for example; using SSL over TCP requires subsequent round trips to establish the encrypted connection. A protocol purpose-built for HTTP could combine these negotiations and reduce the number of round trips, thereby improving network latency.