HTTP3 support.

[Moonraker]

https://www.ghacks.net/2020/07/01/how-t ... n-firefox/

Just found this.
good or bad and will pale moon implement.?

[adesh]

Eventually, we'll have to. How long, decides the "movement" by big players.

[Pentium4User]

Google implemented it so we have to implement that in future here to make Google's site accessible.
You can see what happened with WebComponents, it is also implemented on non-Google sites.

[Moonchild]

No. We don't "have to" anything. HTTP is a basic protocol on the internet that, if anything, has a very very long lifetime before a change can be enforced, no matter how much certain players might want it. See http 1.1: it isn't going away anytime soon, either.

As reasoning for http/3 is given the same reasoning they used for http/2 over using pipelining on http/1.1 "head-of-line-blocking". Wasn't http/2 supposed to solve this? Wasn't pipelining dismissed out-of-hand because of this in the reasoning given for SPDY? Isn't Google doing exactly the same thing again now, this time with QUIC (you really got to wonder if they have that little imagination...). How many more times are we going to do this dance just to have the next "standard" shoved down our throats? Wake up people.
Oh, and guess what? It's not actually a practical problem that would require a rearchitecture of this basic protocol. The reasoning given this time is that things are supposedly "held up" in case there is packet loss. Well guess what? packet loss also occurs for UDP, and using that as a flow control mechanism isn't magically going to improve your connection quality.
http/3 is also not far removed from any other version, with the exception of using UDP instead of TCP.
There's a problem with using UDP for a stateful protocol since it's stateless by design.

[Pentium4User]

No. We don't "have to" anything. HTTP is a basic protocol on the internet that, if anything, has a very very long lifetime before a change can be enforced, no matter how much certain players might want it. See http 1.1: it isn't going away anytime soon, either.

This is true, but if widely used web services like Google or YoutTube implement it and do not offer an alternative protocol, Pale Moon can't be used anymore for these sites so many users will look for browser that can.
If Firefox releases version with it enabled by default, I presume Google will serve webpages with HTTP/3.

[Moonchild]

"Fear of becoming irrelevant despite evidence to the contrary" is exactly what set Mozilla on its current path. And guess what? They are becoming irrelevant regardless.
Another issue is that UDP as a web protocol underpinning will likely not be allowed in many environments because they can't be properly controlled at the network level.

I think thinking Google will do the extreme and shutting out a large portion of their visitors (who are what makes them money...) by not offering anything but http/3 is a mistake. I really don't think that will happen; unless you are thinking solid monoculture thoughts already in which case you've already lost.

[Pentium4User]

"Fear of becoming irrelevant despite evidence to the contrary" is exactly what set Mozilla on its current path. And guess what? They are becoming irrelevant regardless.
Another issue is that UDP as a web protocol underpinning will likely not be allowed in many environments because they can't be properly controlled at the network level.

I think thinking Google will do the extreme and shutting out a large portion of their visitors (who are what makes them money...) by not offering anything but http/3 is a mistake. I really don't think that will happen; unless you are thinking solid monoculture thoughts already in which case you've already lost.

UDP is intended for things like streams or VoIP, but normally not for non-realtime things (Yes, I know that DNS also uses UDP), because UDP doesn't use handshakes and acknowledgements for reception report.
Also UDP connections outside are blocked in many company Firewalls because it is often used for games.

[adesh]

There's a problem with using UDP for a stateful protocol since it's stateless by design.

Well, to be technically accurate, HTTP is also a stateless protocol. The main difference between TCP and UDP is that packets order is not guaranteed in UDP as opposed to TCP, and that's why the performance. For this reason, online multiplayer games use UDP, as you probably already know.

[Moonchild]

There's a problem with using UDP for a stateful protocol since it's stateless by design.

And http is also stateless but AT A DIFFERENT LEVEL (it's stateless at the request level, but not the network level).
At the networking level it's stateful and has to be stateful. Things have to occur in a certain order; if not you are causing issues - just look at the whole sec problem with 0rtt where a semi-stateless sequence is attempted.

[vannilla]

I'm really out of the loop with the new HTTP features, so all I could gather is that they devised new versions of HTTP to guarantee packet order and reliance agains packet loss when using UDP.
But isn't reliance and packet ordering the purpose of TCP? Are they going to implement congestion control in HTTP too?
Please teach me, I'm ignorant.

[adesh]

Reinvent the wheel. Replace everything "old" with "new".

[Moonchild]

Are they going to implement congestion control in HTTP too?

Yes. that's what QUIC was developed as. A user space congestion control mechanism over UDP.

But isn't reliance and packet ordering the purpose of TCP?

Yes. Someone who actually understands!

So here we have HTTP/2 whose big "thing" was multiplexing and transporting many items as a compound stream to reduce the number of desired TCP connections (something HTTP/1.1-pipelining also did very well already with sane retransmission/fallback echanisms in case of packet loss or slow transmission). I'm not sure what kind of mechanisms are at play in the proposed HTTP/3 but to me it seems a step backwards by abandoning the underlying TCP protocol that has everything in place to deliver a multiplexed compound stream in a sensible and ordered way even with packet loss in play.

[VADemon]

I remember some folks testing HTTP/2 NGINX back in the day and their comments were from "no improvement" to "+25%".
The only takeaway from QUIC to me was the stateless handover for the cases when user changes IPs (mobile users on trains etc.)

HTTP1.0 / 1.1 are never going away. Only after IPv4 death and that's DECADES out.

So here we have HTTP/2 whose big "thing" was multiplexing and transporting many items as a compound stream

There's one orthogonal solution to this: Make Browsers Use Their Caches again.

[New Tobin Paradigm]

So... Make Cache Great Again?

[Pentium4User]

HTTP1.0 / 1.1 are never going away. Only after IPv4 death and that's DECADES out.

HTTP1.0/1.1 use TCP and TCP can be used via IPv4 and IPv6, so HTTP 1.0/1.1 will still be available when IPv6 is completely established.

[Moonchild]

So... Make Cache Great Again?

More like: stop using No-cache Https Everywhere™
We cache regardless of protocol used if the headers allow it.

I remember some folks testing HTTP/2 NGINX back in the day and their comments were from "no improvement" to "+25%".

What you want to bet they didn't compare it with pipelining http/1.1?

[VADemon]

HTTP1.0/1.1 use TCP and TCP can be used via IPv4 and IPv6, so HTTP 1.0/1.1 will still be available when IPv6 is completely established.

Yes, but my point is: if you look at all this as a stack, as long there are IPv4-only devices they will also be NOT compatible with HTTP/2+, so they can only start talking about retiring HTTP/1 after there is no old hardware+software. But this is unlikely to happen before the end of this century

I decided to not hide it under a spoiler, because the improvements of HTTP/2 are vital for discussion whether we need HTTP/3. TLDR: If cooked right, the only thing you'd be missing is handover of mobile clients with changing IPs. All else is not a matter of "life or death" but merely an improvement.

Off-topic:

We cache regardless of protocol used if the headers allow it.

Yeah, but it seems most websites are misconfigured in that regard either due to incompetence... or incompetence. With the dynamic™ websites and SPA everywhere it has only gotten worse over time. Hell even the IT-related site I use daily has this nonsense:
Their "CDN" for images: no cache-control flags or if-modified-since.
Then we have alike "professionals" teaching and preaching how to "optimize" their 5-7s loading time websites (yes, I have seen the table that says for every saved second in the ">7s loading time" category, the conversion increases by +3%, next they had [7;5] range and finally the numbers for conversion improvement for ≤5s. YES, they started with a commercial website of over 7 SECONDS loading time!

If it were up to me, I would like to completely override websites' cache settings, this is how bad is has become. But I feel the browsers' default caches, network timeouts etc. also changed significantly since early 00s (based on my observation with unstable EDGE-speed connection)

What you want to bet they didn't compare it with pipelining http/1.1?

No idea, consider this anecdotal evidence, but I actually came up with a few resources below.

HTTP2:


I refreshed my memory now, HTTP/2 improvements are so much case-dependant, one could write papers about it, that's how many variables there are. Throughput, Round-trip-time, packet loss, size and amount of website resources, number of distinct servers... And if the fetching of resources is just a small time of page rendering, for pages ridden with JavaScript, then HTTP2 will only be a minor improvement. It appears it can be most helpful for cases with: high RTT, low bandwidth clients (mobile), at which point you're still better off debloating the website and improving cache settings.

Translation below

Скорость загрузки выросла на 23%. Эксперты HttpWatch также отмечают, что технология пока не до конца оптимизирована, и ожидают реальное ускорение в районе 30%.
...
Специалисты Айри.рф также провели тестирование в январе-феврале 2016 года, чтобы выяснить, сколько может выиграть реальный (небольшой или средний) сайт после перевода на протокол HTTPS + HTTP/2. В среднем по нескольким сайтам, которые уже прошли предварительную оптимизацию по скорости (сжатие и объединение файлов, сетевая оптимизация), клиентская скорость загрузки выросла на 13-18% только за счет включения HTTP/2.
...
Стоит упомянуть, что не все эксперименты были столь однозначны. На Хабре уже был описан эксперимент, поставленный командой Яндекс.Почты. Тестировался протокол SPDY, но напомним, что HTTP/2 разрабатывался на основе SPDY и очень близок к нему в плане используемых методов.

Команда «Яндекс.Почты», протестировав SPDY на части своих реальных пользователей, установила, что среднее время загрузки изменилось всего лишь на 0,6% и не превысило статистической погрешности. Однако специалисты «Яндекс.Почты» обнаружили, тем не менее, положительный момент от использования SPDY. Поскольку число соединений с серверами уменьшилось (это ключевая особенность SPDY и HTTP/2), то нагрузка на серверы заметно сократилась).

The loading speed increased by 23%. HttpWatch experts note that the technology is not ultimately optimized and expect the final improvements to be around 30%
...
Experts from Айри.рф also had run tests in January-February 2016 to detetrmine how well a real (little to medium-sized) website can do after a transition to HTTPS + HTTP/2. On average over a couple sites, which already went through preliminary optimization for speed (compression and bundling of files, network optimization), the client-side loading speed increased by 13-18% just thanks to enablement of HTTP/2.
...
It's noteworthy that not all experiments are unambiguous. There was an experiment written about here on Habr conducted by the Yandex.Mail team. They tested the SPDY protocol, though remember that HTTP/2 was developed on the basis of SPDY and is closely related to it in terms of methods applied.

The Yandex.Mail team, after testing SPDY on a subset of their users, concluded that the mean loading time changed by only 0.6% and didn't exceed the margin of error. Despite this they discovered a positive effect from using SPDY. Because the number of connections to servers decreased (this is a key trait of SPDY and HTTP/2), the server load also decreased significantly.

At the same time, the user here makes a good objection for the use of RSA4096 keys: comparing OpenSSL tests, RSA4096 sign is 7 times slower (60/s) than RSA2048 and this is especially significant for mobile devices and parallel HTTP/1 connections.

Like I said, very many variables, but improvements can be had.

I will now leave the links here. You can still find tons of material there, most sources linked in articles will be in English and for the articles themselves you can use ****** Translate to find interesting excerpts for further research.
https://habr.com/ru/post/269853/ = https://www.nginx.com/blog/7-tips-for-f ... rformance/
https://habr.com/ru/company/webo/blog/300794/
https://habr.com/ru/company/yandex/blog/222951/

[Moonchild]

By the way, in case anyone missed the implication of:

A user space congestion control mechanism over UDP

Being placed in user-space also has a severe disadvantage, that I don't think any user-space software solution can properly counter:
You are bypassing all the specialized hardware-based congestion control inherent to TCP on every hop between you and the server. This is also the reason many games that use UDP suffer from severe latency issues the moment there is packet loss on the wire, because there is no congestion/error handling in transit that could minimize the impact of packet loss -- the packet loss has to be detected on the other end of the pipe by being software processed, then a request bounced back to the very start also exiting the network layer to the software layer, and not trigger retransmission before that.

[Free Bird]

HTTP/1.1 is just fine. It may not be perfect, but it performs acceptably in all reasonable use cases. HTTP/2 was created to support unreasonable use cases. HTTP/3 with its "reimplement part of the TCP/IP stack (poorly) in userland" mentality should just be shunned.

[90Obadiah]

No. We don't "have to" anything. HTTP is a basic protocol on the internet that, if anything, has a very very long lifetime before a change can be enforced, no matter how much certain players might want it. See http 1.1: it isn't going away anytime soon, either.

As reasoning for http/3 is given the same reasoning they used for http/2 over using pipelining on http/1.1 "head-of-line-blocking". Wasn't http/2 supposed to solve this? Wasn't pipelining dismissed out-of-hand because of this in the reasoning given for SPDY? Isn't Google doing exactly the same thing again now, this time with QUIC (you really got to wonder if they have that little imagination...). How many more times are we going to do this dance just to have the next "standard" shoved down our throats? Wake up people.
Oh, and guess what? It's not actually a practical problem that would require a rearchitecture of this basic protocol. The reasoning given this time is that things are supposedly "held up" in case there is packet loss. Well guess what? packet loss also occurs for UDP, and using that as a flow control mechanism isn't magically going to improve your connection quality.
http/3 is also not far removed from any other version, with the exception of using UDP instead of TCP.
There's a problem with using UDP for a stateful protocol since it's stateless by design.

More times than you can even possible imagine

How Facebook is bringing QUIC to billions
https://engineering.fb.com/networking-t ... -billions/