Asked out loud, answered out loud. Read the answer, then say it in your own words.
Walk me through what happens when you type a URL and press enter.
Four layers, in order. DNS turns the hostname into an IP — browser cache, OS cache, resolver, then the root, TLD and authoritative servers if nobody has it. TCP opens a connection with a three-way handshake, one round trip. TLS then negotiates a version and cipher, validates the certificate chain and derives session keys — one more round trip on 1.3, two on 1.2. Only then does the first HTTP request go out, and the response comes back to be parsed, with sub-resources fetched over the same connection.
The number that makes this answer land: before a single byte of your page moves you have already spent three or four round trips, which is why latency, not bandwidth, decides how fast a site feels.
What does a TLS certificate actually prove?
That the party you are talking to holds the private key for a name a certificate authority was willing to vouch for. That is all. It proves identity of the endpoint and gives you an encrypted channel; it says nothing about whether the site is honest, competent, or the one you meant to visit. The padlock means "nobody is reading this in the middle", not "this is safe".
The chain is what people forget: your browser trusts a small set of roots, and every certificate is valid only because it links back to one of them.
Why is DNS cached at so many levels, and what does that cost you?
Because a resolution is a network round trip to answer a question whose answer almost never changes, and the browser, the OS, the resolver and every intermediate all keep the record until its TTL expires. The cost lands the day you need to change it: a record with a 24-hour TTL is a 24-hour tail on any migration or failover, and you cannot recall the copies already handed out.
This is why you lower the TTL days before a cutover, not on the day.
