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

The majority of Facebook's traffic now uses QUIC and HTTP/3

engineering.fb.com

Post reply on HN
Print view View original

111–120 of 149 posts

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#111

Post by DarkCrusader2 »

harrygeez wrote: post #45

I feel like I belong in the minority who like the new Facebook SPA. It loads shockingly fast on my computer, almost instantaneous even

I feel the same with Twitter re-design too. Everyone was hating the re-design when it was launched but my twitter use increased from once or twice a week to couple of times a day after the new design.

It is amazingly fast(on desktop at least), behaves in all the right ways you would expect, you never lose you position anywhere, using back button always works properly, gracefully handles connection loss, and again, it's so fast and pleasurable to use. Too bad can't say the same for the content on the site.

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#112

Post by tialaramex »

pabs3 wrote: post #109
mjoras wrote: post #88

Earlier quoted context omitted.

Most implementations[1] implement it in userland, but this is by no means a requirement. There is no implementation for the Linux kernel presently, but both msquic and F5's QUIC implementation can run in their respective kernels. QUIC is indeed built on top of UDP datagrams, much in the same way TCP is built (typically) on top of IP datagrams. [1] https://github.com/quicwg/base-drafts/wiki/Implementations

Could QUIC also have been built on top of IP datagrams instead of UDP datagrams? Or does our crufty Internet mean only UDP and TCP are viable Internet protocols?

It is as you say. In theory you could build this as a new IP protocol next to TCP but in practice that would be blocked by default and can't be deployed.

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#113

Post by kortilla »

codetrotter wrote: post #48
jedberg wrote: post #35

Earlier quoted context omitted.

FYI, what you wanted to say was 1 for 10, not 1 to 10. Like craps odds when betting on the don't side, where you win less than what you bet. But it's important to point out that even with 1 for 10 odds, you still get your original stake back plus the extra 1.

Thanks for clarifying. Guess it's a good thing I never tried to enter the betting industry haha

Yeah, nobody would ever place a bet if the best payout was less than what you put in...

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#114

Post by mjoras »

jdub wrote: post #102
MichaelMoser123 wrote: post #101

I guess NAS (network access storage) would really benefit from QUIC; one could treat each file transfer as a separate session, so that a lost packet will not cause all the sessions to stall. Did any of the NAS protocols adopt QUIC already? Are they working on it?

There's been some interest among the Samba hackers, including some discussion with Microsoft. They seem quite excited about SMB-on-QUIC as an Internet-capable network filesystem protocol.

Indeed. I believe the latest Windows Insiders builds have SMB over QUIC support (via msquic). I think QUIC brings a lot potential to finally run network filesystem protocols on the Internet.

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#116

Post by BatteryMountain »

Can anyone make a tidy article/post that outlines exactly how each protocol differs (v1 vs v2 vs v3) on the network level. Obviously most of us understand the high level differences but what does the mechanisms and payloads look like on lower levels. A side by side comparison would be great. Pro's & con's of each would be great. Would older hardware (say a 10 year old netgear router) be able to use v3 without pain?

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#117

Post by CppCoder »

tialaramex wrote: post #83
pvorb wrote: post #82

Earlier quoted context omitted.

Why are there two meanings of QUIC in the first place?

Some years back, Google had two experimental pieces of work to try to speed up HTTP named QUIC and SPDY (as in "Quick" and "Speedy"). The output from the experiments was new standardization efforts at the IETF. Google's SPDY, which was a binary HTTP protocol over TLS, eventually resulted in HTTP/2 which there's a fair chance you use today. The other idea, QUIC, is a much bigger lift. It replaces not just the HTTP pro…

In here and in the article it sound as if QUIC or HTTP3 use or build a new Internet Protocol, while it was my understanding it _simply_ uses UDP to create a better version of TCP.

Of course an all new IP would be great, but the issue is it would take very long for all the soft and hardware to support it and UDP is simply there.

I would prefer for a new HTTP to go an all new way, leaving behind UDP and TCP and build something new. Then support fallback over HTTP1/2 until everything else caught up.

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#118

Post by [deleted] »

Thaxll wrote: post #39
api wrote: post #31

I am really happy Google and others are pushing QUIC, but for only one main reason: networks that disallow UDP will now be considered "broken." Without something to push UDP usage its possible we could end up with a TCP-only Internet that would make P2P connectivity more or less impossible.

Who disable UDP in 2020?

[deleted]

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#119

Post by bgirard »

timc3 wrote: post #58
harrygeez wrote: post #45

I feel like I belong in the minority who like the new Facebook SPA. It loads shockingly fast on my computer, almost instantaneous even

It hangs all the time for me, video scrubbing halts the entire tab, and it uses a lot of CPU sometimes.

That's not expected. If you can send me a performance profile I'll look into it. My nick @fb.com.

Re: The majority of Facebook's traffic now uses QUIC and HTTP/3

#120

Post by sgt »

xenospn wrote: post #68
harrygeez wrote: post #62

Earlier quoted context omitted.

I've personally experienced this many times using Safari. Pages that take up a lot of memory just straight up freeze and start chugging.

I usually get the “this page is using too much memory” warning repeatedly using safari. And apparently there’s no way to make it go away, which is super annoying.

Come to think of it, even Google Calendar does this if you leave the tab open in Safari for more than a day. Is this Safari's fault or Google?
Post reply on HN