Talk:HTTP/3

Needs improvement

The article in its current form describes the development of a standard, but does not mention clearly that no browser as yet supports HTTP/3, and does not state exactly how HTTP/3 differs from HTTP/2, other than to mention QUIC, which appears to be a transport protocol based on UDP used mostly by Google to speed up connections. Some summary and technical description of HTTP/3 features would be appropriate but is currently missing. People reading this article may be as unsatisfied as I was with it. Some of the features of QUIC are described at QUIC#QUIC. David Spector (talk) 17:27, 26 December 2019 (UTC)

 Done Article has improved significantly, see section called "Comparison with HTTP/1.1 and HTTP/2". Anton.bersh (talk) 21:42, 5 February 2022 (UTC)

Support

This: https://netty.io/news/2020/12/09/quic-0-0-1-Final.html can be referenced to prove initial QUIC support for Netty (JVM ecosystem web server). — Preceding unsigned comment added by Filip Euler (talk • contribs) 18:03, 13 December 2020 (UTC)

 Not done Netty does not appear to be notable. Anton.bersh (talk) 21:43, 5 February 2022 (UTC)

Drawbacks

The removal of the drawbacks is not justified. QUICs usage of a IDs raises similar concerns like COOKIES. This statement is backed by a paper by a reputable source. Please explain why this should not be part of the article. Instead of completely removing this piece of information lets work on wording it so no disambiguation is in there. — Preceding unsigned comment added by 46.83.121.117 (talk) 22:13, 28 January 2022 (UTC)

Hi IP, nice to see you here, I'm the user who removed comparison with HTTP Cookies earlier. Basically, this paper (and the sentence citation) appears to be written just to make a bizarre claim (comparing QUIC feature to HTTP Cookies because in public media view HTTP Cookies are scarry) without much substance.

As is, this section still does not make sense to me because:

1. What is the "discovery" of the paper? That is, what is the "drawback" of QUIC? Literally every single connection protocol which supports the concept of session has some sort of session identifier baked in. To my knowledge, UDP is the only widely used communication protocol which does not have session identifiers (and thus does not have sessions, intentionally provides only a "fire-and-forget" primitive, and does not attempt to optimize anything). For background context: sessions are used even on IP layer to compress headers for efficiency (RFC 1144, RFC 2507, etc.). Also, another basic protocol TCP (a "sibling" of UDP) used in HTTP/1.1 and HTTP/2 has sessions which are tracked with sequence numbers.

2. HTTP Cookies can contain much more data than these "QUIC Cookies". Also, HTTP Cookies can persist across sessions much more reliably than these "QUIC Cookies".

3. At the time, the "third-party tracking" described in this paper could be achieved in a far simpler and far more reliable manner via shared cache. Modern browsers (Chromium-based, WebKit/Safari, Firefox) are partitioning the network caches and other semi-persistent data, including these scarry QUIC tokens.

4. The way authors describe their "finding" about 0-RTT suggests they haven't actually read RFC 8446 which talks about reusing identifiers (sections C.4, and to smaller extent E.5, E.7, etc.)

5. Lastly, this paper might not meet Wikipedia definition of reviewed scientific paper. Normally, papers are reviewed by reputable specialists on the subject, and usually contain acknowledgement of reviewers' contribution (because this is good for both the reviewer and the paper). This paper just says:

The authors would like to thank the anonymous reviewers for their valuable feedback

Who are these "anonymous reviewers"? Do random people on reddit.com/r/privacy or 4chan count?

Anton.bersh (talk) 01:41, 29 January 2022 (UTC)

Hello Anton.bersh,

I still suggested to include the paragraph instead of completely removing it. Look: There is a paper by an actual brick-and-mortar university with real people and a real reputation and there is us that can read such a paper and have different opinions about their findings. I value the findings and suggest adding the actual work to enhance this article. You are not impressed and removed the sentence twice, instead of providing constructive criticism or rephrasing the sentence. How would you put this paper into the article? Please provide a textual example that we can work with, instead of simply erasing the sentence. How do you suggest to inform readers of the HTTP/3 article about such a paper? — Preceding unsigned comment added by 46.83.118.149 (talk) 14:51, 30 January 2022 (UTC)

Hello IP,

Editing has nothing to do with "impressing" any editor, it is about conveying factually correct information.

My main concern with this section is that it is not a paragraph, but a single sentence worded to make an impression of substantial claim without providing any specifics. Essentially, I would be content with anything that addresses point 1 of my previous reply: the paragraph should describe a specific discovery (or multiple discoveries) about QUIC which actually make QUIC distinct from HTTP/1.1 or HTTP/2. (I hope it goes without saying that this paragraph should not contain known falsehoods like equivocating connection tokens and Cookies.)

Let's go back to basics and determine what piece of information you want to communicate to the reader. The latest revision of the sentence read:

Part of the protocol are IDs that are suitable to track users across networks.

This is true about any HTTP(S) revision, it is not a drawback of HTTP/3 (at least no more than it is drawback of any other HTTP revision). The core problem here is that clients can store some state information (small amounts of data) for efficiency, but malicious servers might be able to sneak into this storage some unique identifiers. These problematic places include session identifiers (like is claimed in the paper), HTTP "E-Tag" headers, HTTP redirects, etc. As far as I see, the only difference here that I see is that HTTP/3 might also add "source address token" and "server config" to that already long list. If that is what you intend to communicate, then please spell it out directly and what considerations this design choice implies. Note: all competent implementations already take this into account, it's basically a non-issue.

If that is not the information you want to convey, please write down the (factually correct) statement you want to add and I might be able to find a reliable paper which supports that statement. For reference, the specification draft (section 10.11) explicitly acknowledges the (pretty obvious) observation that reusing "single QUIC connection allows correlation of a user's activity on a site."

Anton.bersh (talk) 22:42, 30 January 2022 (UTC)

Hello Anton.bersh,

Good to hear that we now focus on the actual information that is to be conveyed. How about we take the factual correct, but short sentence:

Part of the protocol are IDs that are suitable to track users[25] across networks.

And after or into that sentence you can add the additional information that puts that first piece of information into relation. — Preceding unsigned comment added by 46.83.119.210 (talk) 07:50, 31 January 2022 (UTC)

Hi IP,

I'm still not sure what the criticism is, given all the discussion above. Any session-based protocol by design explicitly makes both parties track the state of the session. As far as I see, the paper authors were displeased that HTTP/3 sessions could last longer than HTTP/2 or HTTP/1.1 sessions, but they did not actually use the browser-provided tools to end these sessions. They never explicitly state their threat model, so we have to guess their intentions; they imply that session tracking is important in their threat model, but then they never use the built-in browsers tool to end undesirable sessions, which is incognito mode. Why? Outside of incognito mode or some other equivalent (which clears session state after session end), any session tracking becomes trivial and is explicitly out of browsers' threat model.

You are asking me to take a misleading sentence (which implies that HTTP/3 is the only protocol that tracks sessions) and develop it into a meaningful paragraph. I can't really do that without first understanding your concern about HTTP/3.

Just to clarify, HTTP/3 does have some objective disadvantages in certain cases (esp. compared to simple HTTP/1.1), but I don't think this is one of them.

Anton.bersh (talk) 12:22, 31 January 2022 (UTC)

P.S.: If you are concerned about HTTP/3 implementations in tools like Tor designed to obfuscate user's actions by proxying stuff through different IPs, then please state that is a part of your threat model. Yes, for such tools HTTP/3 affinity to re-establishing sessions across different IPs is problematic. However, that is a consideration for these tools specifically and not HTTP/3 in general. Again, the linked paper does not mention any such tools. Ideally, these tools should clear all relevant browser session state every time the IP is changed, not just HTTP/3 session state. Anton.bersh (talk) 13:40, 31 January 2022 (UTC)

P.P.S.: I noticed you have moved this problematic section verbatim to QUIC article in this edit. This sentence does not make sense even in the context of that article either. If you could elaborate, perhaps, we could actually figure out what your concern with HTTP/3 and QUIC is and write a decent paragraph. Perhaps, your concern would be more relevant in article about Tor (network) or The Tor Project? Failing that, I'll have to remove this claim from QUIC as well. Anton.bersh (talk) 09:04, 1 February 2022 (UTC)

Since that sentence was not improved in the last couple days, I had to assume you are not interesting in fixing it, so I removed it. Over the next few days, I plan to expand QUIC article with some critical content to describe tradeoffs in design of QUIC, so if you have some actual content to add you are welcome to pitch in at Talk:QUIC#Balance. Anton.bersh (talk) 00:05, 4 February 2022 (UTC)

Removal of browser table?

@Akeosnhaoe: Hi, I saw you removed the table of browsers that support HTTP/3 and was curious about why you did this? I reverted the change because I actually have found this valuable here when people ask about what browsers currently support HTTP/3 by default. We're in the stage where people are implementing HTTP/3 and so this is useful to show when it is available. Why do you think we should remove the table? I'm not necessarily opposed to removing it.. I just would like us to have a discussion here before we do so. Thanks, - Dyork (talk) 01:28, 9 April 2021 (UTC)

Did you read the rest of the changes I made in the revision you reverted? The table has been wrong for close to a year, Safari still doesn't enable it be default while Chrome and Edge do and Firefox will enable it next release (Firefox 88). I thought if the table being wrong for a year hasn't bothered anyone, it must not be useful and this information is available on https://caniuse.com/http3 Akeosnhaoe (talk) 12:22, 9 April 2021 (UTC)

Akeosnhaoe - Ah, no... I did not read the rest of the changes you made. I apologize for that. It was late at night and I saw the removal of the browser table and said "hey, wait, I've been referring people to that table!" I also did NOT realize the table has been wrong for close to a year! I see that subsequently you brought the table back in an updated form. Thank you for doing that. - Dyork (talk) 16:13, 9 April 2021 (UTC)

Regarding HTTP/3 status

Hi @Comp.arch, I noticed your recent edits and I partially reverted them. Here I would like to discuss HTTP/3 status. As far as I understand, HTTP/3 did not receive an official RFC number which means it is still an Internet Draft. Typically, specification start out as an Internet Draft, then gets an RFC number and becomes Request for Comments, and then may eventually become an Internet Standard. Again, since HTTP/3 does not have an RFC number, this means HTTP/3 is still an Internet Draft.

Furthermore, I noticed that you empathized that HTTP/3 draft had expired (on 20 January 2022 to be exact). I left that information in, but I do not think this is important piece of information, because lots of drafts "expire" and then get updated and move on and become RFCs. In fact, (subjectively) the fact that HTTP/3 was implemented by many parties and draft has not been updated in a while implies that the protocol is stable and draft text is clear and detailed, basically indicating that the draft is getting closer to an RFC. If you disagree with my assessment, please feel free to comment here or edit article providing some explanation in edit summary.

Anton.bersh (talk) 00:24, 12 February 2022 (UTC)

Hi @Anton.bersh, as far as I can tell it did get a RFC number, RFC 9113. I added it to the article, feel free to revert if I misunderstood the status of that document.

Zauguin (talk) 02:17, 13 February 2022 (UTC)

Hi @Zauguin:! Is this assignment official or preliminary? IETF Datatracker URL[1] returns 404, IETF Datatracker Document Search[2] can't find anything, IETF Editor can't find anythong[3], RFC Editor[4] URL returns "HTML file does not exist". Note that URL you found, https://www.rfc-editor.org/rfc/authors/rfc9113.html is different from [4] because it has "authors/" in it. Also, the document you linked to links to status page[5] which states "RFC 9113 does not exist".

[1] https://datatracker.ietf.org/doc/html/rfc9113

[2] https://datatracker.ietf.org/doc/search?name=rfc9113

[3] https://www.rfc-editor.org/search/rfc_search_detail.php?rfc=9113&pubstatus%5B%5D=Any&pub_date_type=any

[4] https://www.rfc-editor.org/rfc/rfc9113

[5] https://www.rfc-editor.org/info/rfc9113

Anton.bersh (talk) 12:38, 13 February 2022 (UTC)

Hi, @Comp.arch: and @Zauguin: I looked into this a bit more and found the following information:

This document is in AUTH48 state as of 2022-01-17. It has not yet been published as an RFC. The RFC Editor is awaiting approvals from the author(s) as shown below (and anyone else listed) before continuing the publication process.

The table below shows that one of three authors approved the publication, pending the remaining two approvals. If you really want to, feel free to include this information in the article, but please do not torture readers with WP:CRYSTALBALL material like "seemingly completed", "apparently meant to be published in January 2022 as RFC 9113", and "(Will seemingly be published as) RFC 9113 "Hypertext Transfer Protocol Version 3 (HTTP/3)"". That kind of material is more confusing than informative.

I personally would rather remove all this extra speculation and just call HTTP/3 an "Internet draft" without words "expired" or speculation when it will be published.

Anton.bersh (talk) 21:44, 14 February 2022 (UTC)

Feel free to change. I'm not wedded to this language, yes it is CRYSTALy, or kind of backwards in time. I'm just trying to understand the situation for myself, and since I was reverting "published" it seemed sensible to explain. I wasn't even sure, maybe it was published, then retracted?! Seemingly the RFC will be published in a few days, with that RFC number I guess (so including that number and explaining as I did seemed warranted, as is done for future movies, but then it seems we need to explain why the RFC is there at all), so I guess this will be a storm in a teacup, and cleared up. If you or someone changes text you know I wrote, then I even prefer being reverted, so I know people changed (otherwise I might overlook). I do not take that as criticism, especially here, and feel it's often a quicker process than going to the talk page (I try to follow 3RR, but don't worry on my account). comp.arch (talk) 22:56, 14 February 2022 (UTC)

I see two distinct matters here: (1) understanding the status of HTTP/3 for personal/professional purposes and (2) writing informative and factually correct information in the Wikipedia article.

Regarding (1): from technology perspective, there is no difference between technology which has an RFC and one which does not (or has a draft). Also, there is plenty of RFCs which describe terrible and in some cases downright malicious technologies. Furthermore, there is plenty of RFCs which describe no standard at all and are more like "opinion" pieces. RFC is a formality and is inherently an archival format, so by the time RFC is published with all likelihood the described technology is either already in wide use or already obsolete. The only thing that matters for a technology is whether or not others support it and whether or not you can use it. And in short, you probably can (especially since HTTP/3 use does not require you to disable HTTP/1.1 and HTTP/2).

Regarding (2): I would rather not speculate. HTTP/3 draft has not been published yet and as of now I see two possible RFC numbers: 9113 and 9114. I would rather not include preliminary URLs with RFC numbers because they would only confuse people; draft URL has the same exact content anyway. This is not a significant point in the grand scheme of things.

Anton.bersh (talk) 17:03, 15 February 2022 (UTC)

Regarding HTTP/3 speed

Hi, @Comp.arch you recently edited lead to include words "much faster" without much explanation. First of all, I believe article lead should not include a simplistic assessment and instead protocol speed should to be described in a dedicated section in the article body. Secondly, I looked at the source you provided and it appeared to be just a blog written by a person who did very little testing (even omitted a measurement for no apparent reason). Instead. I found few other sources which come from more reliable sources and perform much more detailed analysis, describe the causes of observed performance differences.

My most interesting source is this: Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? It is a peer-reviewed masters thesis. It confirms that HTTP/3 actually achieves goals described in the HTTP/3 spec:

- no head-of-line blocking

- faster connection negotiation due to reduced number of RTTs

- higher sustained speed due to connection resumption

- higher resilience to dropped packets (PLR)

- more consistent speed on high-loss networks (high PLR) because lost packets are not interpreted as a sign of congestion

All this basically results in higher and more consistent throughput on wide-area networks (compared to HTTP/1.1 over TLS and HTTP/2). But the paper also describes somewhat unexpected findings:

- HTTP/3 behaves better even on high-quality networks because it has higher tolerance for packet reordering. Basically, on a very good wireless network with high speed and AP or path redundancy packets might take different paths and get reordered. TCP actually might interpret this reordering as packet loss and drop throughput, while HTTP/3 (or rather QUIC) keeps on going full speed.

There are some papers which compare plain HTTP/1.1 with HTTP/3 (for example, on local networks within data centers and loopback devices). Unsurprisingly, HTTP/1.1 comes out on top (because PLR is low and HTTP/1.1 does not waste time on crypto operations). Anton.bersh (talk) 00:53, 12 February 2022 (UTC)

So in summary, it's "much faster". :) "article lead should not include a simplistic assessment and instead [..] described in a dedicated section in the article body." It doesn't need to be either or, I agree I could have put something in the article body, but faster seemed warranted for the lead. I believe the only point of HTTP/3 (and QUIC), is to be faster, than HTTP/2 (plus TLS), and faster than HTTP/1.1 (since that was also the point of HTTP/2). I believe they achieved the objective, at least in the common case where it matters most. I googled you source, didn't find "much faster", rather "significantly faster" which I can also agree to:

"Noteworthy is also that overall QUIC’s 95th percentile is further away from its average than TCP’s 95th percentile. In other words, QUIC’s spread is larger than TCP’s. Although a majority of QUIC requests will complete significantly faster than TCPs, there are 5% of the QUIC requests that have a significantly larger delay which can be important to be aware of for time critical applications for example."

From memory, this article got a banner for readability for lay people, and I think we can explain "throughput" vs. "latency" etc. in the main text, and "faster" is what's most understandable for non-tech people for the lead. comp.arch (talk) 02:08, 12 February 2022 (UTC)