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

61–70 of 123 posts

Re: The Status of HTTP/3

#61

Post by paulddraper »

yzmtf2008 wrote: post #60
paulddraper wrote: post #59

Earlier quoted context omitted.

> 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 tha…

I didn't say "layers don't mean anything." I said names don't mean anything, especially the OSI layers which as your post points out never really became a thing.

TLS is a encryption layer that works with many protocols. Assigning some special number to it isn't the important part.

Re: The Status of HTTP/3

#62

Post by yzmtf2008 »

paulddraper wrote: post #61
yzmtf2008 wrote: post #60

Earlier quoted context omitted.

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 tha…

I didn't say "layers don't mean anything." I said names don't mean anything, especially the OSI layers which as your post points out never really became a thing. TLS is a encryption layer that works with many protocols. Assigning some special number to it isn't the important part.

> TLS is a encryption layer that works with many protocols. Assigning some special number to it isn't the important part.

Yeah but the point is TLS also doesn't work by just magically changing TCP to TLS (where would you even change that?). It works by using HTTP over TLS. The issue is also not with OSI layers, but the fact that there are dependencies between different components that are supposed to be encapsulated from each other. In this view, HTTPS (HTTP + TLS) isn't really different from HTTP/3 (HTTPS + QUIC).

Re: The Status of HTTP/3

#63

Post by 1_player »

GABeech wrote: post #48
jrumbut wrote: post #46

For the builder of small to medium (say, 10k to 1 million monthly users, some media but not the primarily focus) websites, apps, APIs, etc, is it time to begin deploying HTTP/2 or even 3? How would one make the decision, what factors would influence it? What are some of the best books/essays arguing either direction? I believe in maintaining best practices even if you can get away with sloppiness on a specific projec…

HTTP/2 absolutely there are a ton of wins with some of the work they did. Especially around content loading and ssl. HTTP/3? Meh. We've started into the realm of solving google scale problems in HTTP standards that have marginal if any benefit to the 99%

> google scale problems [...] that have marginal if any benefit to the 99%

Such as connection migration over different networks? Who ever needs that?

"Sorry, call dropped. I was leaving the house and I lost connection to the Wifi..."

Re: The Status of HTTP/3

#64

Post by manigandham »

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.

Is IP not handled by network devices and firmware? If it's just software then why don't we have IPv6 everywhere already?

Re: The Status of HTTP/3

#65

Post by wahern »

profmonocle wrote: post #47
john37386 wrote: post #22

Earlier quoted context omitted.

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.

> I am afraid that businesses that will host HTTP/3 will be less secure in terms of availavility. Presumably most HTTP/3 implementations will gracefully fall back to HTTP/2 (or 1.1) if UDP is filtered. Chrome's existing QUIC implementation already does this. Every Google property has had QUIC enabled for quite a while now (at least 4-5 years), so if UDP blocking would cause availability issues, affected businesses wo…

In 2017 Google reported that "4.4% of clients are unable to use QUIC". See sec. 7.2 of https://static.googleusercontent.com/media/research.google.c....

Re: The Status of HTTP/3

#66

Post by K0SM0S »

Slight tangent that actually shocked me when I learned about it: the OSI model that everyone keeps talking about is actually not the "official" nor "real" implementation we use. The actual protocol (and conceptual model) you really want to learn and work with is simply called "Internet Protocol Suite", commonly known as "TCP/IP".

Consider this comparison between OSI and TCP/IP models from Wikipedia[1]:

> The OSI protocol suite that was specified as part of the OSI project was considered by many as too complicated and inefficient, and to a large extent unimplementable. Taking the "forklift upgrade" approach to networking, it specified eliminating all existing networking protocols and replacing them at all layers of the stack. This made implementation difficult, and was resisted by many vendors and users with significant investments in other network technologies. In addition, the protocols included so many optional features that many vendors' implementations were not interoperable.

> Although the OSI model is often still referenced, the Internet protocol suite has become the standard for networking. TCP/IP's pragmatic approach to computer networking and to independent implementations of simplified protocols made it a practical methodology. Some protocols and specifications in the OSI stack remain in use, one example being IS-IS, which was specified for OSI as ISO/IEC 10589:2002 and adapted for Internet use with TCP/IP as RFC 1142

There's a similar discussion on the TCP/IP article as well[2], highlighting the impracticality of OSI "layers" in terms of implementation.

> The IETF protocol development effort is not concerned with strict layering. Some of its protocols may not fit cleanly into the OSI model, although RFCs sometimes refer to it and often use the old OSI layer numbers. The IETF has repeatedly stated[citation needed] that Internet protocol and architecture development is not intended to be OSI-compliant. RFC 3439, addressing Internet architecture, contains a section entitled: "Layering Considered Harmful".

In practice, a short discussion about SSL/TLS is enough to point the inadequacies of OSI, and orient one towards conforming their conceptual model closer to TCP/IP and relevant RFC's.

The advice I follow personally, given the "popularity" of OSI (people call "layer 1-7" as if it were an actual thing, 90% of the blogs and literature uses the OSI model), is to simply translate into TCP/IP lingo/concepts in your mind whenever you read/speak about it. Not everyone will get it around you, but at least you'll have a more solid implementation should you be working with low-levels of the net stack.

For reference, RFC 1122[3] defines the Internet Protocol Suite with 4 layers: application, transport, internet (or internetwork, the idea of routing) and link. Does not assume or require a physical layer in the spec itself — hence it works on 'anything' from USB to Fiber passing by Ethernet or Bluetooth and PCIe/Thunderbolt if you just follow the protocol.

[1]: https://en.wikipedia.org/wiki/OSI_model#Comparison_with_TCP/...

[2]: https://en.wikipedia.org/wiki/Internet_protocol_suite#Compar...

[3]: https://tools.ietf.org/html/rfc1122#section-1.1.3

Re: The Status of HTTP/3

#67

Post by derefr »

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.

Who cares about the WebAssembly on the web? I'm looking forward to WebAssembly because it'll mean that Electron will become the new JRE: a lightweight, portable, feature-rich "full-fat GUI" application platform. ;)

Re: The Status of HTTP/3

#68

Post by derefr »

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.

Or, a more interesting measure: how much more full will all our NAT connection-state tables be because of this?

Re: The Status of HTTP/3

#69

Post by tus88 »

manigandham wrote: post #42
kazen44 wrote: post #37

Earlier quoted context omitted.

implementing a new version of TCP would be nearly impossible because of all the equipment out in the field already. Changing transport protocol is far harder then changing IP protocol or layer 2 medium.

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

It is about the same. It is called TCP/IP for a reason. Although there are more devices that deal with TCP/IP together than just IP alone. Either way it ain't going to happen.

Re: The Status of HTTP/3

#70

Post by magicalhippo »

silisili wrote: post #57
baby wrote: post #52

Earlier quoted context omitted.

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 basicall…

> When someone tells you something relies on UDP, nobody in their right mind assumes that this person implemented TCP features on top.

AFAIK it's rather common in multiplayer games to do TCP-like features over UDP, as they usually need the UDP features but also need reliable transport for some data, and it's rather tricky to do both UDP and TCP at the same time.

See for example https://fabiensanglard.net/quakeSource/quakeSourceNetWork.ph... or https://gafferongames.com/post/reliability_ordering_and_cong...

Post reply on HN