The future of NGINX

Posted Aug 25, 2022 8:30 UTC (Thu) by LtWorf (subscriber, #124958)
In reply to: The future of NGINX by bagder
Parent article: The future of NGINX

I know why browsers do multiple short lived connections. But the result is that providers tune for that. So if you make a webserver use a single connection, it will probably be slower to load overall, because of what the providers do.

Now google has the power to force providers to do things, but most other wevserver owners do not have this leverage and might be disadvantaged from switching.

The future of NGINX

Posted Aug 25, 2022 10:31 UTC (Thu) by gspr (subscriber, #91542) [Link] (8 responses)

Are you implying that Google has the power to make changes to HTTP/2 on a whim?

The future of NGINX

Posted Aug 25, 2022 10:54 UTC (Thu) by hummassa (subscriber, #307) [Link]

> Are you implying that Google has the power to make changes to HTTP/2 on a whim?

With the current adoption of chromium-based, that would not be an unreasonable statement.

The future of NGINX

Posted Aug 25, 2022 15:25 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (6 responses)

Basically yes. They can just make youtube go on this hypotetical new protocol available in chrome and throttle the old protocol. Other browsers can implement it or stay slow.

It's that easy for them.

The future of NGINX

Posted Aug 26, 2022 6:24 UTC (Fri) by jamesh (guest, #1159) [Link] (5 responses)

Are you specifically complaining specifically about youtube-dl being throttled? That seems more about the arms race between Google trying to ensure only authorised clients access video streams, and youtube-dl developers trying to reverse those protections (which currently involve interpreting some of the JavaScript on the page to determine correct URLs).

It's not an HTTP 1.1 vs HTTP 2 issue.

The future of NGINX

Posted Aug 26, 2022 7:31 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

Often it's even easier. Most video sites try to optimize their bandwidth due to clients having massive ones. If your video player downloads the video faster than you can watch, and you stop in the middle, they send too many bytes over the wire, and that bandwidth has a cost, and even causes congestion on certain links at certain hours. So it's more efficient to throttle every stream to roughly the stream's bandwidth, but that implicitly also throttles downloading tools. Now is that really an issue ?

The future of NGINX

Posted Aug 26, 2022 14:46 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (3 responses)

No it's not at all what I'm saying.

I'm saying if google wants to push http 4 they are in a position to do it and force everyone else to implement it.

The future of NGINX

Posted Aug 26, 2022 18:59 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (2 responses)

They already forced everyone to use SSL even where it makes no sense at all... When you're the entry point of the internet for the masses, you can do whatever you want. If they decide to stop indexing the sites that use a green background, they can do it and these ones will stop doing business pretty quickly.

The future of NGINX

Posted Aug 26, 2022 20:51 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> They already forced everyone to use SSL even where it makes no sense at all...

I've seen enough evil from airport and hotel "access points" that I really don't want them to muck with even `ytmnd.com` content. Forcing everything to at least *support* `https://` is a great boon IMO (forcing it via 304 redirects might be a bit much in some situations even if I do so for my own website).

The future of NGINX

Posted Aug 27, 2022 8:38 UTC (Sat) by LtWorf (subscriber, #124958) [Link]

They forced me to get 2FA on pypi! :D They can certainly force things.

The future of NGINX

Posted Aug 25, 2022 11:39 UTC (Thu) by bagder (guest, #38414) [Link] (3 responses)

Clearly you know HTTP more and better than the HTTPbis working group in the IETF and all the work done there and elsewhere that has driven the HTTP development the last decade or so. My hat is off.

The future of NGINX

Posted Aug 25, 2022 15:24 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (2 responses)

You can choose to not believe me that providers do throttle long standing connections.

What you believe will not change the fact that it does happen. If your provider doesn't… good for you. Not everyone is so lucky.

Since it does happen, a single connection will be slower overall. Yes handshake takes time… we all know that. Still redoing a handshake is faster than a connection that could go at 1MiB/s but is going at 100KiB/s because provider said so.

I understand http2 saves resources to servers, but for people connecting to those servers it will not necessarily be faster or better.

Again. Your connection is very good. Congratulations. Everyone else's connection isn't.

short pause?

Posted Aug 25, 2022 15:29 UTC (Thu) by anarcat (subscriber, #66354) [Link]

it seems this discussion is diverging significantly from the original article and from my original comment which, granted, probably wasn't great in the first place.

but maybe this has gone for long enough? or at least give you two a little pause to reconsider each other's arguments and maybe make peace with the fact you're in disagreement? :)

The future of NGINX

Posted Aug 26, 2022 7:29 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

What you're describing sounds much more like congested links with an inefficient congestion control algorithm on your side. You should play with them to see which one performs better. It is also possible that your provider is doing transparent proxying and got their implementation wrong, missing some window updates and progressively getting their windows smaller and smaller. Otherwise, there's no particular point in tracking long-lived connections, that comes with an extra processing cost, and brings no benefit.

The future of NGINX

Posted Aug 26, 2022 7:25 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

> Now google has the power to force providers to do things, but most other wevserver owners do not have this leverage and might be disadvantaged from switching.

Huh ? You apparently weren't there in 2015 when it was time to send proposals for HTTP/2, nor when SPDY was used as a starting point and heavily modified. No, HTTP/2 is not Google, it's the HTTPbis WG at the IETF, animated by a few tens of knowledgeable client, server, proxies implementers. Discussions were sometimes quite heated but that resulted in an overall good enough design for the time spent on it (yes, time was key because SPDY was going to become the next standard). HTTP/3 and QUIC also come from this group and a new one (quicwg, sharing a large part of participants) and took a long time to mature. It's not Google's anymore either (in Google's original version now called gQUIC there was no separation between the HTTP and the transport layer for example).

So please don't refrain from using protocols just for your fear that they could give someone else more power. Use them if they bring you or your users some value.