Hacker News Reader

Comment by CyberRabbi | Hacker News Reader

As has been demonstrated by my original post, clearly saving a few rtt is irrelevant here. Anyway your point is halfway-irrelevant since if you initiate all connections in parallel you only suffer the rtt latency of a single connection.

The only people saving here are the people running servers that serve world-scale numbers of requests. The average user notices nearly no difference.

View on HN

Those connections will all go though TCP startup phase where throughput is limited by the congestion window size.

And because they're unaware of each other it's likely they'll eventually start competing with each other and cause packet loss

In the vast majority of cases, neither of those things practically matter. The multiple connections are for intended for concurrency, not parallelism. Web assets are not large enough for slow start to impact overall download speed by any large margin, nor sustain downloads long enough that the connections start to compete. Requests are bursty.

It's quite a few years old –https://web.archive.org/web/20170724120441/https://insoucian... – but I still see this in some packet captures

Yea technically there is a potential benefit but the point is that it’s so marginal that the majority of users won’t ever notice it. You’re saving 1-5ms off of a page load.

...but multiple TCP connections (within reason: too many causes a problem, but not just a handful) actually almost always out-perform a single one for numerous reasons (including the congestion controller having more leverage from looking like multiple users, being able to hit multiple backend machines from dns load balancing, and working around various per-connection bottlenecks); this is in fact the primary trick of "download helpers": they download multiple independent segments of the file on parallel connections.

What if you're not running requests in parallel and instead want a pre-warmed tls connection?

Something like gRPC could be implemented as a websocket protocol but you lose all the http semantics for each internal request. You can't expect a load balancer to handle your custom socket protocol but with a standard like http/2 nginx is able to do it.

That sounds like a TLS problem and not an http problem. Fortunately TLS has already solved that problem: https://blog.cloudflare.com/introducing-0-rtt/

Though http keepalive seems to already solve your use-case, without TLS 1.3’s connection rtt optimizations, if you indeed aren’t running requests in parallel.

>Specifically, only GET requests with no query parameters are answered over 0-RTT.

Sorry but no. Not solved.

They also have a newer post about 0-RTT and how QUIC makes it even faster.

https://blog.cloudflare.com/even-faster-connection-establish...

>Specifically, only GET requests with no query parameters are answered over 0-RTT.

That only applies to cloudflare’s implementation of 0-rtt. That isn’t a general restriction.

Additionally 0-rtt isn’t the only rtt optimization in tls 1.3.

Either way your original point was moot since http keepalive is sufficient to avoid tls connection costs for serial requests.

The world-scale companies are also the companies writing the standards.

Funny that

I'm not sure I fully follow here, but I would like to be able to. Created a video response:

https://www.loom.com/share/4539869f41cf47c5a154a342308584de

Hehe I engage with people like that all the time and I think I’ve learned a lot. In my humble opinion the people who are easily offended aren’t really worth discussing difficult problems with. Actually I find that I learn a lot more from people who don’t get hung up when their ego happens to unintentionally get bruised.

I think you need to reread my initial post in this thread. The importance of minimizing rtt blocking is acknowledged in my questioning of chrome’s decision to not implement http push.

My ego is not bruised. As I said:

> I'm not sure I fully follow here, but I would like to be able to

What I'm calling out is that you may have fallen into the trap (as I did years back) that you need to be an asshole to drive towards solving hard problems. You don't, and it actually blocked me from creating the psychological safety necessary to get good ideas out of people who otherwise wouldn't feel comfortable speaking up. Genuinely good/supporting vibes from my direction to you - do with it what you will, but I do believe your ego is showing here more than mine. We can agree to disagree since I believe each of us will over-index on our past life experiences vs. those of some random person on Hacker News.

> I think you need to reread my initial post in this thread. The importance of minimizing rtt blocking is acknowledged in my questioning of chrome’s decision to not implement http push.

I think I get what you're saying, but honestly the way you're wording your points is a bit confusing. I am going to chalk this up to "I'm just too dumb" for sake of laziness at this point.

I don’t believe that you need to be an asshole to drive towards solving hard problems. Not in the least. That is your projection. Calling your point irrelevant is not a personal attack on you, it was intended to be a neutral objective statement. Smart people often make irrelevant points, in fact the smartest people often make the most irrelevant points when trying to drive at the truth. I don’t believe you are dumb but I do have reason to believe you can interpret a personal attack where there is none.

This is a fair assessment.

Reply on news.ycombinator.com