Stories
Slash Boxes
Comments

SoylentNews is people

posted by chromas on Tuesday November 13 2018, @03:12AM   Printer-friendly
from the with-blackjack-and-hookers dept.

The next version of HTTP won’t be using TCP

In its continued efforts to make Web networking faster, Google has been working on an experimental network protocol named QUIC: "Quick UDP Internet Connections." QUIC abandons TCP, instead using its sibling protocol UDP (User Datagram Protocol). UDP is the "opposite" of TCP; it's unreliable (data that is sent from one end may never be received by the other end, and the other end has no way of knowing that something has gone missing), and it is unordered (data sent later can overtake data sent earlier, arriving jumbled up). UDP is, however, very simple, and new protocols are often built on top of UDP.

QUIC reinstates the reliability and ordering that TCP has but without introducing the same number of round trips and latency. For example, if a client is reconnecting to a server, the client can send important encryption data with the very first packet, enabling the server to resurrect the old connection, using the same encryption as previously negotiated, without requiring any additional round trips.

The Internet Engineering Task Force (IETF—the industry group that collaboratively designs network protocols) has been working to create a standardized version of QUIC, which currently deviates significantly from Google's original proposal. The IETF also wants to create a version of HTTP that uses QUIC, previously referred to as HTTP-over-QUIC or HTTP/QUIC. HTTP-over-QUIC isn't, however, HTTP/2 over QUIC; it's a new, updated version of HTTP built for QUIC.

Accordingly, Mark Nottingham, chair of both the HTTP working group and the QUIC working group for IETF, proposed to rename HTTP-over-QUIC to HTTP/3, and the proposal seems to have been broadly accepted. The next version of HTTP will have QUIC as an essential, integral feature, such that HTTP/3 will always use QUIC as its network protocol.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Informative) by Anonymous Coward on Tuesday November 13 2018, @04:31AM

    by Anonymous Coward on Tuesday November 13 2018, @04:31AM (#761155)

    The three-way handshake is annoying, as is the TLS handshake, if you are doing a number of short requests, sure. But removing it only reduces the initial connection anyway, as you can pipeline and stream numerous responses on a single connection. It also doesn't remove that much, as you would have to implement some sort of handshake in your own protocol. Plus, session resumption on later connections has its own security and performance problems.

    As for the headers, UDP headers consist of 16-bit source, 16-bit destination, 16-bit length and 16-bit checksum. TCP adds a 32-bit sequence number, 32-bit ACK number, 4-bit header size, 12-bit of flags, 16-bit window size, 16-bit urgent pointer, and then various options, followed by enough padding to make the header length a multiple of 32. Of the added data, you could remove some of the flags, the urgent pointer, some of the flags, and condense a couple of standard options and the window size. The reason why you can't really get rid of the others is that your application will have to re-implement them in order to make the same reliability, connection-oriented, flow-controlled, congestion-avoiding guarantees as TCP.

    Really, as the other poster put it, SCTP seems to be better and with more history than hacking your own application protocol over UDP.

    Starting Score:    0  points
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  

    Total Score:   1