The speed of light in a fiber optic cable is slower than light in a vacuum, about 2.14e8 m/s.
If you feel latency, it's probably not the one-direction or round-trip latency, but rather the MANY round trips that are typically required for an HTTP request. DNS is probably 2 round trips (CNAME then A), and that has to cross the ocean via your resolver of choice (8.8.8.8 or whatever) to get to the authoritative server if it's not already cached (or distributed; big DNS providers will serve your zone in many regions). Then you have to set up a TCP session, which is 1.5 round trips. Then you have to set up TLS, which varies, and make an HTTP request, and wait for the response. (I counted 5 total round trips until you see the response.)
So basically if you calculate the speed of light between two points, multiply that by 2*(2+5) = 14 in the worst case to see your time to first byte. Doing something 14 times is always going to be slow.
The underlying issue here is not so much the distance, but rather that TCP, TLS, and HTTP don't care about latency at all. (I'll ignore the application layer, which probably wants to redirect you to /verify-session-cookie and then /hey-you-logged-in for some reason. And yes, TLS1.3 has 0RTT handshakes now too, eliminating some trips.)
This is the problem that HTTP/3 aims to fix; one round trip replaces the TCP handshake, TLS handshake, and HTTP request. You shoot out a packet, you get back an HTTP response. (You still have to do the DNS lookup, so we'll call this 3 round trips total.)
Your post is a good read for everyone trying to calculate number of RTT solely on the HTTP layer, which is done so often, but always wrong.
To add to your post, don't forget TCP congestion window scaling, which will add some more roundtrips - this mostly depends on the size and bandwidth of the ressources, so smaller sites like HN have an advantage here. Especially if the initial ressources fit within the initcwnd (10*MSS, usually around 15kb). But this, like many of the parameters you mentioned, are highly flow- and also software specific, it becomes so hard to make meaningfull predictions.
People should use their ISP's DNS as well which is often <5ms. I've never bothered using an off-net DNS provider for this reason given how much faster is it to use an on-net caching DNS resolver provided by my ISP.
It depends on the competency of your ISP and how aggressive they are about so-called features. In several cases, the ISP provided DNS decided not to return NX results and instead returned a page of ads which was great for email servers, back in the day. The other failure mode I've seen is that the ISP's DNS servers are overloaded and take several seconds to respond.
There's also the reality that using your ISP's DNS almost entirely moots any VPN you use. The main reason to use a VPN is to hide your browsing from your ISP and anyone your ISP might be reporting to (in the US for example we've seen several programs where the government intercepts ISP data at special places in interconnects, so even if your ISP publicly says your DNS is safe, it could actually be logged to a spy database associated to you)
When you use a VPN and then immediately send all your DNS lookups right back to your ISP... Hey I wonder where this person is actually from! Maybe the geographical area of the regional ISP that all their DNS lookups are coming from...
>People should use their ISP's DNS as well which is often <5ms. I've never bothered using an off-net DNS provider for this reason given how much faster is it to use an on-net caching DNS resolver provided by my ISP.
I've been using a local recursive resolver for the past 2-3 years and haven't seen a noticeable difference in resolution times as compared with using my ISP's resolver.
I would guess that using a local recursive resolver (although it caches as well, so that's less of an issue with items in-cache) increases resolution times, but only on the order of tens of milliseconds.
Which is peanuts compared to client/server query response times, especially if requests return data and/or javascript heavy results.
And given that many ISPs mine their customers' DNS queries and sometimes return incorrect (from the perspective of the customer) results, I'd rather not use my ISP's resolvers -- and that hasn't had any noticeable impact on responses to browser requests.
In fact, uMatrix tends to slow things down much more for me as I often have to choose which scripts/3rd party assets/etc. to allow in order to browse a particular site -- or just to abandon the attempt if there's too much cruft.
That especially annoys me when I need to load scripts from several different sites just to view text. In those cases, I usually just close the tab.
In my experience, ISPs DNS servers are slower compared to 8.8.8.8 or 1.1.1.1, especially for "complex" lookups where there are as many as 6 CNAMEs in the DNS chain.
Also, they often run a single instance of bind, with little to no load-balancing.
DNS is typically a single round-trip for CNAME + A. And if you're using a resolver such as 8.8.8.8 or 1.1.1.1, it will route to a resolver close to you in most cases, and already have the results cached for any major site.
If you feel latency, it's probably not the one-direction or round-trip latency, but rather the MANY round trips that are typically required for an HTTP request. DNS is probably 2 round trips (CNAME then A), and that has to cross the ocean via your resolver of choice (8.8.8.8 or whatever) to get to the authoritative server if it's not already cached (or distributed; big DNS providers will serve your zone in many regions). Then you have to set up a TCP session, which is 1.5 round trips. Then you have to set up TLS, which varies, and make an HTTP request, and wait for the response. (I counted 5 total round trips until you see the response.)
So basically if you calculate the speed of light between two points, multiply that by 2*(2+5) = 14 in the worst case to see your time to first byte. Doing something 14 times is always going to be slow.
The underlying issue here is not so much the distance, but rather that TCP, TLS, and HTTP don't care about latency at all. (I'll ignore the application layer, which probably wants to redirect you to /verify-session-cookie and then /hey-you-logged-in for some reason. And yes, TLS1.3 has 0RTT handshakes now too, eliminating some trips.)
This is the problem that HTTP/3 aims to fix; one round trip replaces the TCP handshake, TLS handshake, and HTTP request. You shoot out a packet, you get back an HTTP response. (You still have to do the DNS lookup, so we'll call this 3 round trips total.)