SoylentNews is people
SoylentNews
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.
(Score: 2) by Thexalon on Tuesday November 13 2018, @03:50AM (17 children)
The problems with TCP:
1. The 3-way handshake, the SYN, SYN-ACK, ACK series of 3 packets that go back and forth before data can be sent. To close down a connection, you have 4 additional packets going back and forth. That means 7 packets that don't include any of the data being sent. If you use a persistent connection (which most browsers do), that means the server is maintaining state about all its clients. If you don't use a persistent connection, then you pay the 7-packet penalty each time you contact the server, which includes every little AJAX request.
2. TCP headers are 5 times larger than UDP headers. Again, more non-data being passed around.
If this works as promised, it will make transmitting information over HTTP noticeably lower-bandwidth. If this doesn't work as promised, then we'll all be stuck with an alternative protocol that is for all practical purposes a less-robust version of TCP without the 40+ years of use in the wild behind it.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 1, Insightful) by Anonymous Coward on Tuesday November 13 2018, @03:57AM (2 children)
5g speed and all that,and yet nickel and diiming over tcp header length? bullshit.
(Score: 1, Informative) by Anonymous Coward on Tuesday November 13 2018, @04:04AM
Sure, for any given transaction it is just very little. Now multiply that by the billions of people on the planet, and all the internet traffic they generate every single damn day.
It adds up!
(Score: 3, Informative) by Pino P on Tuesday November 13 2018, @01:49PM
As long as satellite and cellular carriers continue to nickel-and-dime their subscribers with overage fees, nickel-and-diming to reduce how much subscribers owe the carrier will continue to be valuable.
(Score: 5, Insightful) by jb on Tuesday November 13 2018, @04:21AM (11 children)
This is nonsense, up with which we ought not put ;)
TCP packets have a size limit of 65,535 bytes, although it's unusual (at least in this part of the world) to find a WAN link with an MTU over 1,500 bytes. TCP headers are 20 to 60 bytes in length. UDP headers are 8 bytes in length.
So by using shorter L4 headers we're talking an bandwidth efficiency dividend of between 0.00018% at worst and 0.03467% at best.
IP round trip times across the 'net (assuming a reasonably decent local uplink) tend to run to tens of milliseconds. So a single packet for establishment instead of three is likely to reduce connection establishment latency by between 20ms & 100ms.
Those efficiency dividends sound rather paltry.
If we want to speed up HTTP transactions, there are much simpler approaches which will yield far greater performance improvements.
For human-readable web sites --- simply design them properly, without the mountains of javascript and ridiculously oversized images that have become the fashion of late.
For machine-machine comms -- again, simply choose an API that isn't 90+% syntactic sugar or redundancy (just because storing data locally with XML can be handy, doesn't mean it's a good choice for communicating over WANs) ... [and for those extremely rare projects where 20ms extra latency really is a problem, HTTP is a poor L5 protocol choice anyway]
(Score: 5, Insightful) by choose another one on Tuesday November 13 2018, @09:11AM (1 child)
> For human-readable web sites --- simply design them properly, without the mountains of javascript and ridiculously oversized images that have become the fashion of late.
The javascript and large images is not the biggest problem, IMO. I just did a quick test (without ad blockers) for kicks:
front page of this site: 17 requests, all from one hostname.
front page of major mainstream news site (stopped after 30secs loading): 738 requests, 35 different hostnames for the top page plus dozens of iframes using other hostnames that I couldn't be bothered to expand to count
The DNS request overhead alone must be a major part of the problem, especially the latency.
(Score: 2) by Unixnut on Tuesday November 13 2018, @02:12PM
God that is awful, definitely would class that as a poorly designed web site (and insecure to boot, only one of those 35 different hostname needs to be compromised for your site to be compromised too).
So the GPPs point is still valid, even if you remove the JS crap and images.
(Score: 3, Informative) by The Mighty Buzzard on Tuesday November 13 2018, @11:20AM (5 children)
When you find yourself on the verge of ending a sentence with a preposition, simply add ", asshole" just before the terminal punctuation. Problem solved.
My rights don't end where your fear begins.
(Score: 1, Funny) by Anonymous Coward on Tuesday November 13 2018, @12:39PM (1 child)
FTFY
(Score: 3, Touché) by The Mighty Buzzard on Tuesday November 13 2018, @12:50PM
Nah, that's is too specific for general use. Stick with the wildcard synonym.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Tuesday November 13 2018, @04:51PM (2 children)
Sigh. There is nothing wrong with ending a sentence with a preposition. That nonsense rule was made up about 100 years ago by two idiots trying to make English more like Latin (where it isn't possible). It's same as the split infinitive rule. Before that, writers did it all the time.
(Score: 2) by Thexalon on Tuesday November 13 2018, @09:21PM (1 child)
We will now proceed to gleefully, playfully, nay even gloriously split infinitives with wild abandon!
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by bob_super on Wednesday November 14 2018, @08:27PM
Is that what we're now going to enthusiastically be up to, asshole ?
(Score: 0) by Anonymous Coward on Wednesday November 14 2018, @02:54AM (1 child)
"This is the type of errant pedantry up with which I will not put." - Winston Churchill
(Score: 2) by jb on Thursday November 15 2018, @05:03AM
Glad to see at least someone knew the reference.
(Score: 0) by Anonymous Coward on Thursday November 15 2018, @07:33PM
I'll just add that the next version of HTTP should be renamed to something that has nothing to to with hypertext transfer. Maybe JSTP or WebAppTP?
(Score: 1, Informative) by Anonymous Coward on Tuesday November 13 2018, @04:31AM
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.
(Score: 2) by loonycyborg on Tuesday November 13 2018, @08:52AM
Actual length of packets involved in TCP is insignificant. Though latency can matter. But it amounts to nothing more than original requester having to wait one full round trip time between endpoints before starting to send actual data. I understand you'd want to try to eliminate this somehow but most applications can live with this, including the Web. And I'm not really sure that it's possible to eliminate this delay without sacrificing other advantages of TCP.