Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Status of HTTP/3

infoq.com

Post reply on HN
Print view View original

51–60 of 123 posts

Re: The Status of HTTP/3

#51

Post by baby »

NilsIRL wrote: post #49
Animats wrote: post #36

All this to support more ads per page. All this is only a win mostly if you have a huge number of little assets from different sources. Ads, trackers, icon buttons, malware, etc. If it's all coming from one source, HTTP/2 is good enough. If it's mostly one big file, HTTP/1 is good enough.

> All this to support more ads per page. I'm also very afraid of the future of Web Assembly. Both of these technologies i'm afraid aren't going to make things better, faster and more lightweight. They are just going to allow the bloat of the web to become worse without noticeable symptoms.

This made me think of the problem of highways: the more lane you add, the more cars come to use your road and congestion is not reduced.

This is a problem with computers in general. For example IDEs and simple electron apps taking huge amounts of memory.

Re: The Status of HTTP/3

#52

Post by baby »

axaxs wrote: post #45
baby wrote: post #41

Earlier quoted context omitted.

It is basically TCP 2.0 implemented on top of UDP. What concerns do you have with this?

Well, I have a lot, but I don't want this to turn into a dissertation about why I don't like UDP for most things. The biggest red flag to me is that it is trivial to make the server send sizable packets to clients who didn't ask for them nor want them. Spoofing is not a solved problem, no matter how many times people scream at providers to block it before it gets out. Why isn't there a minimal ACK process up front? I…

UDP is a 4-page RFC that is pretty much a definition of IP with ports. You can easily imagine TCP as a bunch of algorithms on top of UDP. Knowing that I’m not sure what you don’t like about UDP?

Amplification attacks and spoofing are taken care of by QUIC, so these are not problems at the moment.

Re: The Status of HTTP/3

#53

Post by gsich »

baby wrote: post #51
NilsIRL wrote: post #49

Earlier quoted context omitted.

> All this to support more ads per page. I'm also very afraid of the future of Web Assembly. Both of these technologies i'm afraid aren't going to make things better, faster and more lightweight. They are just going to allow the bloat of the web to become worse without noticeable symptoms.

This made me think of the problem of highways: the more lane you add, the more cars come to use your road and congestion is not reduced. This is a problem with computers in general. For example IDEs and simple electron apps taking huge amounts of memory.

It's the reverse of Moore's law:

https://en.m.wikipedia.org/wiki/Wirth%27s_law

Re: The Status of HTTP/3

#55

Post by tracker1 »

john37386 wrote: post #22
axaxs wrote: post #16

I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. DNS has been fighting off wave after wave of attack vectors, some that realistically cannot even be fixed. Making it immune to these vectors is going to look a lot like a slapped together TCP over UDP...

Totally agree with you. Many big corporations totally block UDP at ISP level because there is no easy/magic solutions against amplified DDoS. They usually use some internal backend for DNS, Ntp, routed through other ISP. I am afraid that businesses that will host HTTP/3 will be less secure in terms of availavility.

Many corporations also block SMTP and inbound host ports... doesn't mean the protocol is bad. Hell, many corporations install horrible proxy servers and require all outbound connections go through that proxy.

Re: The Status of HTTP/3

#56

Post by tyingq »

microcolonel wrote: post #33
tyingq wrote: post #4

Because QIC is UDP based, Chrome first runs a race with TCP just in case you're sitting behind some device that blocks UDP. I wonder how much bandwidth this will waste globally.

> I wonder how much bandwidth this will waste globally. One or two packets? A handful of bytes per initial connection. The Connection ID mechanism and QPACK are likely to save a lot more data than is lost on initial TCP races.

I could have worded it better. I understand it's small in any single area.

Just interesting to contemplate the total effect when you have a userbase like Chrome's.

Re: The Status of HTTP/3

#57

Post by silisili »

baby wrote: post #52
axaxs wrote: post #45

Earlier quoted context omitted.

Well, I have a lot, but I don't want this to turn into a dissertation about why I don't like UDP for most things. The biggest red flag to me is that it is trivial to make the server send sizable packets to clients who didn't ask for them nor want them. Spoofing is not a solved problem, no matter how many times people scream at providers to block it before it gets out. Why isn't there a minimal ACK process up front? I…

UDP is a 4-page RFC that is pretty much a definition of IP with ports. You can easily imagine TCP as a bunch of algorithms on top of UDP. Knowing that I’m not sure what you don’t like about UDP? Amplification attacks and spoofing are taken care of by QUIC, so these are not problems at the moment.

That's a little unfair. When someone tells you something relies on UDP, nobody in their right mind assumes that this person implemented TCP features on top. UDP is simple and quick, and the assumption is that there was a reason they chose that route.

AFAICT, QUIC loosely defines a way to do client address validation, but it isn't required! It's worded as 'CAN' and 'MAY' in places, and places outside the spec basically hint that 'oh no! it adds another round trip'. This makes it feel totally bolted on. Why wasn't it required up front? If someone came up to me with this idea of QUIC, the -first- thing I'd tell them is to solve this problem definitively first. The idea seems sound to me, but not if you let everyone turn it off...

Re: The Status of HTTP/3

#58

Post by lizknope »

watersb wrote: post #44
manigandham wrote: post #42

Earlier quoted context omitted.

Why doesn't the IP protocol require new hardware if it's a lower layer?

IP doesn't require new hardware because it's a lower layer. Transmission Control Protocol - TCP - is baked into the firmware of every client network interface card, and I would suppose in almost all of the switches and routers of business infrastructure. I have no idea what data centers use. Infiniband and similar things aren't TCP, I think.

Infiniband is a lower level than TCP. Infiniband is often used as a replacement for ethernet in a supercomputing cluster.

If you wish you can run IP over Infiniband (IPoIB) but I think most people using Infiniband are running a lower latency protocol like RDMA

https://wiki.archlinux.org/index.php/InfiniBand#TCP/IP_(IPoI...

Re: The Status of HTTP/3

#59

Post by paulddraper »

yzmtf2008 wrote: post #40
paulddraper wrote: post #30

Earlier quoted context omitted.

Forget the narrow waist of the internet; this is the spaghetti ball of the internet. It violates all of the encapsulation and decoupling principles you learned about as a CS undergrad. If you have a better transport layer, fine. Make a better transport layer. But rolling the whole thing is the best way to ensure nothing will ever get done. HTTP/3 is the new IPv6.

> It violates all of the encapsulation and decoupling principles you learned about as a CS undergrad. I mean, it's not like encapsulation and decoupling ever worked with the networking stack. For example, let's pause a minute and think about which layer does TLS or NAT sit in. To quote @tptacek[0]: There is no such thing as a layering violation. You should be immediately suspicious of anyone who claims that there are…

> which layer does TLS

Transport Layer Security? Transport layer.

> which layer does NAT

Network Address Translation? Network layer.

---

That said, the names aren't as important as the layer and independence. E.g. TLS can be used to secure any TCP traffic: STMP, HTTP, etc.

Re: The Status of HTTP/3

#60

Post by yzmtf2008 »

paulddraper wrote: post #59
yzmtf2008 wrote: post #40

Earlier quoted context omitted.

> It violates all of the encapsulation and decoupling principles you learned about as a CS undergrad. I mean, it's not like encapsulation and decoupling ever worked with the networking stack. For example, let's pause a minute and think about which layer does TLS or NAT sit in. To quote @tptacek[0]: There is no such thing as a layering violation. You should be immediately suspicious of anyone who claims that there are…

> which layer does TLS Transport Layer Security? Transport layer. > which layer does NAT Network Address Translation? Network layer. --- That said, the names aren't as important as the layer and independence. E.g. TLS can be used to secure any TCP traffic: STMP, HTTP, etc.

Some might argue that TLS is on Layer 6, 7 and 4 at the same time: https://security.stackexchange.com/a/93338

Same for NAT: https://networkengineering.stackexchange.com/questions/3145/...

> the names aren't as important as the layer and independence

That's the point. Layers don't mean anything in the real world where ossifications are a thing and replacing infrastructures has a cost. There are plenty of protocols that require cross-layer coupling (aka "layering violations") and asking for layering compliance really doesn't make anyone except layering lawyers' life better.

Post reply on HN