Slashdot Mirror


The Next Version of HTTP Won't Be Using TCP (zdnet.com)

"The HTTP-over-QUIC experimental protocol will be renamed to HTTP/3 and is expected to become the third official version of the HTTP protocol, officials at the Internet Engineering Task Force (IETF) have revealed," writes Catalin Cimpanu via ZDNet. "This will become the second Google-developed experimental technology to become an official HTTP protocol upgrade after Google's SPDY technology became the base of HTTP/2." From the report: HTTP-over-QUIC is a rewrite of the HTTP protocol that uses Google's QUIC instead of TCP (Transmission Control Protocol) as its base technology. QUIC stands for "Quick UDP Internet Connections" and is, itself, Google's attempt at rewriting the TCP protocol as an improved technology that combines HTTP/2, TCP, UDP, and TLS (for encryption), among many other things. Google wants QUIC to slowly replace both TCP and UDP as the new protocol of choice for moving binary data across the Internet, and for good reasons, as test have proven that QUIC is both faster and more secure because of its encrypted-by-default implementation (current HTTP-over-QUIC protocol draft uses the newly released TLS 1.3 protocol).

In a mailing list discussion last month, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Group, made the official request to rename HTTP-over-QUIC as HTTP/3, and pass it's development from the QUIC Working Group to the HTTP Working Group. In the subsequent discussions that followed and stretched over several days, Nottingham's proposal was accepted by fellow IETF members, who gave their official seal of approval that HTTP-over-QUIC become HTTP/3, the next major iteration of the HTTP protocol, the technology that underpins today's World Wide Web.

1 of 258 comments (clear)

  1. Re:There's More to QUIC Than You Think by fahrbot-bot · · Score: 5, Insightful

    QUIC's big win ... is that it allows your network connections to survive IP address changes, since the endpoints are identified not by an IP address/port tuple, but rather by a GUID/port tuple. Downside: You lose (some? all?) anonymity, as your GUID is long-lived.

    Hmm... I can't imagine why Google would want to develop a network protocol where devices/people could be persistently tracked by unique, persistent identifiers that would allow identification regardless of the applications used ...

    --
    It must have been something you assimilated. . . .