101–110 of 123 posts
Earlier quoted context omitted.
In the age of evergreen browsers, it's possible to go from 0% to 85% in just a few weeks time. Upgrading web servers will be the real bottleneck.
nginx will get H3 this year, so I think we'll see a massive uptick in adoption.
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.
[0]: https://news.ycombinator.com/item?id=22040780
I enjoy discovering my misconceptions on this topic, as I am no longer building computer networks. Mostly harmless.
Earlier quoted context omitted.
With HTTP/1.1 pipelining, you can't reliably start sending the second request until the first response is complete. As such, you can't have multiple requests out at the same time. It's also very much linear.
"With HTTP/1.1 pipelining, you can't reliably start sending the second request until the first response is complete." In the example, all 30 requests were sent at the same time. openssl did not wait for any responses. This example can be repeated again and again and every time, all the responses are received, in order. It is reliable. Not sure who "you" refers to in the above statement, however if it applies to me th…
> A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response).
Maybe this was just yet another case where plenty of intermediaries are broken and mass-deployment has always been difficult?
I see that the WG charter has one milestone in May 2020, and Daniel Stenberg of curl has mentioned early 2020 before. In addition, AFAIU, both Chrome and Firefox have implementations ready, though still behind flags.
Is it likely that we'll see actual deployments and a wider rollout already in 2020?
Earlier quoted context omitted.
"With HTTP/1.1 pipelining, you can't reliably start sending the second request until the first response is complete." In the example, all 30 requests were sent at the same time. openssl did not wait for any responses. This example can be repeated again and again and every time, all the responses are received, in order. It is reliable. Not sure who "you" refers to in the above statement, however if it applies to me th…
Ah, I seem to have misremembered; from RFC 7230: > A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). Maybe this was just yet another case where plenty of intermediaries are broken and mass-deployment has always been difficult?
Earlier quoted context omitted.
It's fun to see how we kind of reinvented goold old DNS as soon as we use HTTP/3 for DoH. It runs on UDP, but with HTTP in between (and encrypted, of course). We could have done that with DNS itself, but somehow this never gained traction.
The difference DoH started with something nearly every network was guaranteed to have allowed: HTTPS traffic on TCP 443. Trying to wait for every network to allow DNS on 31218 or whatever wouldn't have worked. Even with a massive amount of the web guaranteed to move to HTTP/3 there will be places that still don't allow UDP 443 five years from now. If ever something seems dumb in network protocol design the answer pro…
You can use most ports just fine. Multiplayer games show this every day. If those don't work in corporate networks (I include "public" wlan in this) that's fine too. It's not up to you what should be allowed or not in a company setting. ISPs don't block ports just for fun.
And if you are big enough like Google or Facebook, just offer a service only on that port. If it doesn't work, show a warning that the customer should complain to the network owner.
Can anyone now give a reasonable ETA for the HTTP/3 RFC:s? I see that the WG charter has one milestone in May 2020, and Daniel Stenberg of curl has mentioned early 2020 before. In addition, AFAIU, both Chrome and Firefox have implementations ready, though still behind flags. Is it likely that we'll see actual deployments and a wider rollout already in 2020?
Earlier quoted context omitted.
“A new version of TCP” is pretty much what QUIC (basis of HTTP/3) is. It’s just tunneled over UDP because existing Internet infrastructure likes to drop anything that’s not TCP or UDP.
That's the problem being cited. The best option is to do a real update of TCP at layer 4, but nobody wants to put in the work and investment to do so.
In exchange... among other things, it would break all existing NAT implementations, since NAT is based on port numbers and existing devices wouldn't know where to find the port number in the new protocol. So everyone behind a home router would be unable to use the new protocol until they upgraded their router firmware – which of course most 'normal people' never do, so realistically you're waiting years until they get a new router.
Not only is that a gigantic practical disadvantage, it also feels rather inelegant itself. After all, routers shouldn't need to know the details of the transport protocol just to route packets. If it weren't for NAT they wouldn't have to, which is probably why port numbers aren't part of IP itself. NAT sucks. But NAT isn't going away; even on IPv6 some people insist on using it. By tunneling QUIC inside UDP, we at least regain the elegance of separating what routers need to know (IP + UDP) from the real "transport protocol" (QUIC).
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%
Compared with HTTP/1.1, HTTP/2 has known regressions which can be catastrophic on poor-quality connections, mostly due to TCP head-of-line blocking. At Fastmail we found concrete performance problems for some users from deploying HTTP/2 so that we rolled it back for a while and tried again later after shuffling a couple of things around to mitigate the worst such problems (can’t remember what we actually did). But even so, a small fraction of our users will get a worse experience from HTTP/2 than from HTTP/1.1. (Don’t think I’m speaking against HTTP/2; overall it’s an improvement for performance over HTTP/1.1, often a big improvement. But for developing things like interactive apps, it’s helpful to understand the differences and their effects.)
HTTP/3, meanwhile, does not suffer from such problems (which is most of why they made it). The main risk is that it’s less likely to work at all—but browsers take that into consideration and fall back to HTTP over TCP (HTTP/1.1 or HTTP/2) smoothly.
Presuming you have capable server software, I’d honestly consider deploying HTTP/3 to be lower risk than deploying HTTP/2.
One should also consider the robustness of the HTTP/2 or HTTP/3 implementation. Consider such things as this variety of DoS attacks against HTTP/2 from the last six months: https://github.com/Netflix/security-bulletins/blob/master/ad.... It’s improbable that these are are only major attack vectors in HTTP/2 and HTTP/3 implementations.
Earlier quoted context omitted.
That's the problem being cited. The best option is to do a real update of TCP at layer 4, but nobody wants to put in the work and investment to do so.
Except we already have those layer 4 replacements (i.e. SCTP covers a lot of the same ground), and they've never managed to get out of the niches they are in. How would you suggest "a major internet company" motivate their support better?