From a5d2e71f547cd2ef1a04dba5bf72f95d9f26bc84 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Tue, 1 Sep 2026 22:50:52 +0530 Subject: [PATCH 01/16] Create what-happens-when-you-type-google.md --- .../blog/what-happens-when-you-type-google.md | 1212 +++++++++++++++++ 1 file changed, 1212 insertions(+) create mode 100644 content/blog/what-happens-when-you-type-google.md diff --git a/content/blog/what-happens-when-you-type-google.md b/content/blog/what-happens-when-you-type-google.md new file mode 100644 index 0000000..6649c54 --- /dev/null +++ b/content/blog/what-happens-when-you-type-google.md @@ -0,0 +1,1212 @@ +--- +title: "What Happens When You Type google.com?" +description: "A journey through DNS, TCP, TLS, HTTP, Google's infrastructure, and browser rendering — from a URL to the pixels on your screen." +author: "DevHub" +date: "2026-09-01" +category: "Web" +tags: + - web + - networking + - dns + - http + - tls + - browsers + - internet + - how-it-works +--- + +# What Happens When You Type `google.com`? + +You type six characters. + +`google.com` + +You press **Enter**. + +A moment later, Google's homepage appears on your screen. + +It feels instantaneous. + +But underneath that tiny interaction, your computer has just participated in an enormous chain of systems involving your browser, operating system, DNS infrastructure, network routing, encrypted connections, Google's servers, and finally the rendering engine inside your browser. + +Your browser has to answer a deceptively simple question: + +> **"Where is `google.com`, and how do I get its content?"** + +The journey looks roughly like this: + +```text +You type google.com + ↓ +Browser parses the URL + ↓ +Check local caches + ↓ +DNS resolution + ↓ +IP address discovered + ↓ +Network route + ↓ +Connection established + ↓ +TLS handshake + ↓ +HTTP request + ↓ +Google infrastructure + ↓ +HTTP response + ↓ +Browser receives bytes + ↓ +HTML parsing + ↓ +CSS + JavaScript + resources + ↓ +DOM + CSSOM + ↓ +Layout + ↓ +Paint + ↓ +Compositing + ↓ +Pixels on your screen +``` + +Let's follow that journey. + +--- + +## 1. You type `google.com` + +It begins with something incredibly ordinary. + +You open your browser and type: + +```text +google.com +``` + +Then you press Enter. + +The browser first has to determine what you actually entered. + +Is it a search query? + +Is it a URL? + +Is it a hostname? + +Is there a protocol? + +Because you entered: + +```text +google.com +``` + +the browser interprets it as a web address. + +Conceptually, it becomes something like: + +```text +https://google.com/ +``` + +The browser now knows several important pieces: + +```text +Scheme: https +Hostname: google.com +Port: 443 +Path: / +``` + +You didn't explicitly type `https://`. + +Modern browsers can infer the secure HTTP scheme for a domain. + +Now the browser needs an address. + +And `google.com` isn't an IP address. + +--- + +# 2. Computers don't route traffic using domain names + +Humans like names. + +Computers ultimately communicate using network addresses. + +You can remember: + +```text +google.com +``` + +much more easily than something like: + +```text +142.250.x.x +``` + +The system that connects those two worlds is **DNS**. + +The Domain Name System is essentially the Internet's distributed naming system. + +It translates domain names into network addresses. + +Conceptually: + +```text +google.com + ↓ +DNS + ↓ +IP address +``` + +But before your computer asks a DNS server, it may check places where the answer could already exist. + +--- + +# 3. The browser checks its caches + +Your browser doesn't want to perform a complete DNS lookup every time you visit a website. + +That would be wasteful. + +So it can cache DNS information. + +Depending on the browser and operating system, the resolution process may involve several layers of caching. + +A simplified model looks like: + +```text +Browser DNS cache + ↓ +OS DNS cache + ↓ +Configured DNS resolver + ↓ +Internet DNS infrastructure +``` + +If the browser already knows the answer and the cached record is still valid, the process can be significantly faster. + +If not, the request continues. + +--- + +# 4. DNS resolution begins + +Your computer usually communicates with a DNS resolver. + +That resolver might be operated by: + +- Your ISP +- Your organization +- Your router +- A public DNS provider +- Another network service + +The resolver needs to discover the DNS records associated with `google.com`. + +DNS is hierarchical. + +A simplified lookup can look like: + +```text +Your computer + ↓ +Recursive resolver + ↓ +Root DNS servers + ↓ +.com nameservers + ↓ +Authoritative nameservers + ↓ +google.com records +``` + +The resolver doesn't necessarily need to perform every step every time. + +It may already have the answer cached. + +But conceptually, this hierarchy is what makes the system work. + +--- + +# 5. The root servers don't know Google's IP address + +This is an important detail. + +The root DNS system doesn't contain a giant table saying: + +```text +google.com → Google's IP +``` + +Instead, root servers can direct resolvers toward the nameservers responsible for the `.com` top-level domain. + +The resolver asks: + +> Who handles `.com`? + +The `.com` infrastructure responds with information about the authoritative nameservers for `google.com`. + +The resolver then asks those authoritative nameservers: + +> What address should I use for `google.com`? + +The authoritative DNS system provides the appropriate records. + +--- + +# 6. A domain can have multiple addresses + +You shouldn't think of a domain as necessarily mapping to one permanent IP address. + +A large service can have many addresses and many locations. + +There can be: + +```text +IPv4 addresses +IPv6 addresses +regional endpoints +edge locations +load-balancing mechanisms +``` + +DNS can therefore be part of a larger traffic-management strategy. + +The exact address returned to you can depend on factors such as network topology, DNS configuration, availability, and traffic-management systems. + +The important point is: + +> **`google.com` is a name, not a single physical machine.** + +--- + +# 7. Now your computer knows where to connect + +Eventually, your system gets an address it can use. + +Conceptually: + +```text +google.com + ↓ +IP address +``` + +Now the browser has another problem. + +How does a packet get from your device to that destination? + +Your computer doesn't usually have a direct physical connection to Google's servers. + +The traffic may travel through: + +```text +Your device + ↓ +Wi-Fi / Ethernet + ↓ +Router + ↓ +ISP + ↓ +Multiple networks + ↓ +Google's network + ↓ +Destination +``` + +And the Internet needs to figure out that path. + +--- + +# 8. The Internet doesn't have one central router + +There isn't a giant machine somewhere that decides the route for every packet on Earth. + +The Internet is a network of interconnected networks. + +Organizations exchange routing information using systems such as **BGP — the Border Gateway Protocol**. + +At a high level, routing systems determine how different networks can reach one another. + +Your packet might cross multiple autonomous systems before reaching Google's infrastructure. + +You don't manually choose that path. + +Routers make forwarding decisions based on routing information. + +--- + +# 9. Your packet doesn't necessarily take the same path every time + +Internet routing is dynamic. + +The path can change because of: + +- Network failures +- Congestion +- Routing policies +- Maintenance +- Traffic engineering +- Infrastructure changes + +This is one reason the Internet is resilient. + +If one path becomes unavailable, routing systems can potentially direct traffic elsewhere. + +The Internet isn't one road. + +It's an enormous collection of interconnected roads. + +--- + +# 10. Now we need a connection + +Knowing the destination isn't enough. + +Your browser needs to communicate with the server. + +For traditional HTTPS over TCP, that means establishing a TCP connection. + +The default HTTPS port is: + +```text +443 +``` + +TCP establishes a connection using a process commonly called the **three-way handshake**. + +Conceptually: + +```text +Client Server + + SYN --------------------> + + <-------------------- SYN-ACK + + ACK --------------------> +``` + +Now both sides have established the TCP connection. + +But there's still a major problem. + +We don't want to send sensitive web traffic as plain text. + +That's where TLS comes in. + +--- + +# 11. HTTPS means HTTP over an encrypted connection + +You typed: + +```text +https://google.com +``` + +not: + +```text +http://google.com +``` + +HTTPS uses TLS to provide security properties such as encryption and server authentication. + +The browser needs to establish a secure TLS session. + +A simplified TLS 1.3 flow looks like: + +```text +Client Server + +ClientHello + ------------------------> + + ServerHello + Certificate + Key exchange + <------------------------ + +Finished + ------------------------> + + Finished + <------------------------ +``` + +The real protocol contains significantly more detail, but the important concept is: + +> Both sides negotiate cryptographic parameters and establish shared secrets used to protect the connection. + +--- + +# 12. How does the browser know it's really Google? + +Encryption alone isn't enough. + +Imagine someone intercepted your connection and pretended to be Google. + +You would have an encrypted connection... + +to the attacker. + +That's where certificates and the certificate authority ecosystem become important. + +Google's server presents a certificate. + +Your browser verifies that certificate against its trusted certificate authorities and checks properties such as: + +- The certificate's validity +- The hostname +- Its cryptographic signature +- The certificate chain +- Other certificate constraints + +If verification fails, your browser can warn you. + +If everything checks out, the browser has much stronger evidence that it's communicating with the intended service. + +--- + +# 13. HTTP finally gets involved + +Now we can actually send an HTTP request. + +At a simplified level, the request might look like: + +```http +GET / HTTP/2 +Host: google.com +User-Agent: ... +Accept: text/html +Accept-Language: ... +Accept-Encoding: gzip, br +``` + +The browser is essentially saying: + +> "Give me the resource at `/`." + +The actual request is more complex, and modern HTTP versions don't necessarily transmit it as literal text in the same way HTTP/1.1 does. + +But conceptually, that's what is happening. + +--- + +# 14. HTTP/2 and HTTP/3 change the story + +Modern web traffic isn't limited to old-school HTTP/1.1. + +HTTP/2 introduced features such as: + +- Multiplexed streams +- Header compression +- More efficient connection usage + +HTTP/3 uses QUIC, which runs over UDP rather than TCP. + +Conceptually: + +```text +HTTP/1.1 + ↓ +TCP + ↓ +IP +``` + +versus: + +```text +HTTP/2 + ↓ +TCP + ↓ +IP +``` + +and: + +```text +HTTP/3 + ↓ +QUIC + ↓ +UDP + ↓ +IP +``` + +The exact protocol negotiated depends on what the client and server support. + +The important thing is that modern browsers can use newer transport and HTTP protocols to reduce latency and improve performance. + +--- + +# 15. Your request reaches Google's infrastructure + +This is where things become very different from visiting a small website. + +`google.com` isn't sitting on one server under someone's desk. + +Large Internet services operate enormous distributed infrastructures. + +Your request can pass through multiple layers of Google's network and service architecture. + +A simplified conceptual model might look like: + +```text +Internet + ↓ +Google edge infrastructure + ↓ +Traffic management + ↓ +Frontend services + ↓ +Application systems + ↓ +Data services +``` + +The exact internal architecture is proprietary and changes over time. + +But the principle is straightforward: + +**A large service distributes work across many machines and locations.** + +--- + +# 16. The edge matters + +Large services try to handle users close to where they connect to the Internet. + +This reduces latency and allows traffic to be distributed efficiently. + +Instead of every request traveling to one central machine, traffic can be handled through distributed infrastructure. + +This is one reason large websites can serve users around the world. + +Your request from India doesn't necessarily travel to one single server in the United States before anything happens. + +Internet infrastructure is distributed. + +--- + +# 17. Load balancing decides where the request goes + +Suppose thousands or millions of requests arrive. + +One server shouldn't necessarily process all of them. + +Load-balancing systems distribute work. + +Conceptually: + +```text + ┌── Server A + │ +Request → Load Balancer ── Server B + │ + └── Server C +``` + +The real systems are considerably more sophisticated. + +They can account for factors such as: + +- Server health +- Capacity +- Location +- Traffic +- Service availability +- Routing policies + +The goal is to keep the system responsive and resilient. + +--- + +# 18. The server processes your request + +Eventually, some system needs to determine what response to send. + +For a simple static page, that might involve retrieving already-generated resources. + +For a dynamic application, the server may perform application logic, access caches, query databases, call internal services, and construct a response. + +The important thing is that: + +> **The browser doesn't know how Google internally produces its response.** + +It only knows the protocol. + +Request: + +```text +GET / +``` + +Response: + +```text +HTTP response +``` + +The complexity behind that response is hidden behind the network boundary. + +--- + +# 19. The response comes back + +The server sends an HTTP response. + +Conceptually: + +```http +HTTP/2 200 +Content-Type: text/html +Content-Encoding: br +Content-Length: ... +``` + +followed by the response body. + +A successful request might have a status such as: + +```text +200 OK +``` + +Other possibilities include: + +```text +301 Moved Permanently +302 Found +304 Not Modified +403 Forbidden +404 Not Found +429 Too Many Requests +500 Internal Server Error +503 Service Unavailable +``` + +HTTP status codes are one of the fundamental ways servers communicate the outcome of requests. + +--- + +# 20. Compression makes the response smaller + +Web pages can contain a lot of data. + +Sending everything uncompressed would waste bandwidth. + +Modern servers can compress responses using algorithms such as Brotli or gzip. + +For example: + +```text +Original: +████████████████████████████████ + +Compressed: +██████████ +``` + +The browser receives the compressed representation and decompresses it. + +Smaller payloads generally mean less data needs to cross the network. + +That can significantly matter on slower connections. + +--- + +# 21. The browser receives bytes + +Now the response has made its way back to your machine. + +But your browser doesn't immediately have a page. + +It has **bytes**. + +Those bytes need to be interpreted. + +For HTML, the browser begins parsing the document. + +Imagine the response contains: + +```html + + + + Google + + +

Google

+ + +``` + +The browser turns that markup into a structured representation. + +--- + +# 22. HTML becomes the DOM + +The browser parses HTML and constructs the **DOM — Document Object Model**. + +Conceptually: + +```text +HTML + ↓ +Parser + ↓ +DOM +``` + +The DOM is a tree. + +For example: + +```text +Document +└── html + ├── head + │ └── title + └── body + └── h1 +``` + +JavaScript can interact with this structure. + +That's how code can do things such as: + +```js +document.querySelector("h1"); +``` + +The browser isn't simply displaying raw HTML. + +It's building an internal representation of the document. + +--- + +# 23. CSS becomes the CSSOM + +HTML tells the browser what elements exist. + +CSS tells it how those elements should look. + +The browser parses CSS into another internal representation commonly referred to as the **CSSOM — CSS Object Model**. + +Conceptually: + +```text +HTML + ↓ +DOM + +CSS + ↓ +CSSOM +``` + +The browser then combines information from both. + +--- + +# 24. The browser builds the render tree + +The browser needs to determine what should actually be rendered. + +It combines relevant DOM and styling information into structures used for rendering. + +Conceptually: + +```text +DOM + CSSOM + ↓ +Render information + ↓ +Layout +``` + +Not every DOM node necessarily results in something visible. + +For example, elements that aren't rendered don't necessarily participate in visual rendering in the same way. + +--- + +# 25. Layout calculates positions + +Now the browser needs to answer: + +> Where does everything go? + +It calculates things such as: + +- Width +- Height +- Position +- Margins +- Padding +- Text layout +- Element relationships + +This stage is often called **layout**. + +Imagine: + +```text +Viewport +┌────────────────────────────┐ +│ │ +│ Google │ +│ │ +│ [ Search Box ] │ +│ │ +│ │ +└────────────────────────────┘ +``` + +The browser has to calculate the actual coordinates and dimensions of those elements. + +--- + +# 26. Then the browser paints + +Once the browser knows where things are, it needs to draw them. + +Text. + +Backgrounds. + +Borders. + +Images. + +Shadows. + +Icons. + +The browser generates visual output through a process generally referred to as **painting**. + +Conceptually: + +```text +DOM + ↓ +Style + ↓ +Layout + ↓ +Paint +``` + +But we're still not quite finished. + +--- + +# 27. Compositing puts everything together + +Modern browsers can divide visual content into layers. + +Those layers can then be composited together. + +Conceptually: + +```text +Layer 1 ─── Background +Layer 2 ─── Content +Layer 3 ─── Image +Layer 4 ─── Animation + ↓ + Compositor + ↓ + Frame +``` + +The browser and graphics stack work together to produce the final frame. + +Depending on the content, some operations can be accelerated using the GPU. + +--- + +# 28. Finally: pixels + +After all those layers of processing, your display receives a frame. + +The journey that started with: + +```text +google.com +``` + +has become: + +```text +pixels +``` + +on your screen. + +And all of this happened incredibly quickly. + +You saw a page. + +Your computer saw: + +```text +DNS +→ routing +→ transport +→ TLS +→ HTTP +→ bytes +→ parsing +→ DOM +→ CSSOM +→ layout +→ paint +→ compositing +→ pixels +``` + +--- + +# The complete journey + +Let's put everything together. + +```text +You + │ + │ Type google.com + ▼ +Browser + │ + │ Parse URL + ▼ +Local caches + │ + │ DNS lookup if needed + ▼ +DNS Resolver + │ + ├── Root + │ + ├── .com + │ + └── Authoritative DNS + │ + ▼ +IP Address + │ + │ Network routing + ▼ +Internet + │ + │ TCP / QUIC + ▼ +TLS + │ + │ Secure connection + ▼ +HTTP + │ + │ Request + ▼ +Google Infrastructure + │ + ├── Edge + ├── Traffic management + ├── Load balancing + ├── Application services + └── Data services + │ + │ Response + ▼ +Your Browser + │ + ├── Receive bytes + ├── Decompress + ├── Parse HTML + ├── Build DOM + ├── Parse CSS + ├── Build CSSOM + ├── Calculate layout + ├── Paint + └── Composite + │ + ▼ +Your Screen +``` + +And you only typed: + +```text +google.com +``` + +--- + +# What if something goes wrong? + +This entire process has many potential failure points. + +If DNS fails: + +```text +DNS_PROBE_FINISHED_NXDOMAIN +``` + +or another DNS-related error may appear. + +If the server can't be reached: + +```text +Connection failed +``` + +If TLS verification fails: + +```text +Your connection is not private +``` + +If the server returns an error: + +```text +500 Internal Server Error +``` + +If the resource doesn't exist: + +```text +404 Not Found +``` + +If the network is slow, the page may simply take longer to arrive. + +Modern web browsers hide enormous amounts of complexity behind a simple interface. + +That's one of the reasons the web feels so effortless. + +--- + +# The important lesson + +The web isn't one technology. + +It's a stack. + +When you visit a website, you're relying on many systems cooperating: + +```text +Application +HTTP +TLS +QUIC / TCP +IP +DNS +BGP +Operating System +Browser +GPU +Display +``` + +Each layer has its own responsibilities. + +Each layer abstracts complexity from the layer above it. + +And that's one of the most powerful ideas in computer science: + +> **Complex systems become manageable when responsibilities are separated into layers.** + +You don't need to understand BGP to use Google. + +You don't need to understand TLS to log into a website. + +You don't need to understand DOM construction to build a web page. + +But when something breaks, understanding the layers becomes incredibly valuable. + +If a domain doesn't resolve, investigate DNS. + +If the connection can't be established, investigate networking. + +If TLS fails, investigate certificates and encryption. + +If the server responds slowly, investigate the application or network. + +If the page loads but renders incorrectly, investigate the browser and frontend. + +Knowing **which layer is responsible** is one of the most useful skills a developer can develop. + +--- + +# One URL. An entire universe. + +The next time you type: + +```text +google.com +``` + +remember what's actually happening. + +A browser interprets your input. + +DNS turns a human-readable name into an address. + +Routing finds a path through interconnected networks. + +A secure protocol establishes encrypted communication. + +HTTP carries your request. + +Distributed infrastructure processes it. + +Bytes travel back across the Internet. + +Your browser turns those bytes into structures. + +The rendering engine calculates styles and geometry. + +The graphics pipeline turns those structures into a frame. + +And finally— + +**you see a webpage.** + +All from six characters. + +That's the web. + +And that's what happens when you type `google.com`. + +--- + +> **The Internet feels simple because billions of complicated decisions happen underneath the surface.** + +**DevHub** + +[Explore DevHub →](https://devhub.vercel.app/) + +[GitHub →](https://github.com/open-devhub/) \ No newline at end of file From 3357c16197d332b6a9da29ea7ae1d27ee4a8a9a9 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Tue, 1 Sep 2026 22:53:01 +0530 Subject: [PATCH 02/16] Update what-happens-when-you-type-google.md --- content/blog/what-happens-when-you-type-google.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/what-happens-when-you-type-google.md b/content/blog/what-happens-when-you-type-google.md index 6649c54..a6e1cb3 100644 --- a/content/blog/what-happens-when-you-type-google.md +++ b/content/blog/what-happens-when-you-type-google.md @@ -3,7 +3,7 @@ title: "What Happens When You Type google.com?" description: "A journey through DNS, TCP, TLS, HTTP, Google's infrastructure, and browser rendering — from a URL to the pixels on your screen." author: "DevHub" date: "2026-09-01" -category: "Web" +category: "WebSite" tags: - web - networking From 2cfe1f8ea9f85299b42f47653308cd8535a657d7 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Wed, 2 Sep 2026 07:50:46 +0530 Subject: [PATCH 03/16] Update what-happens-when-you-type-google.md --- content/blog/what-happens-when-you-type-google.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/what-happens-when-you-type-google.md b/content/blog/what-happens-when-you-type-google.md index a6e1cb3..6649c54 100644 --- a/content/blog/what-happens-when-you-type-google.md +++ b/content/blog/what-happens-when-you-type-google.md @@ -3,7 +3,7 @@ title: "What Happens When You Type google.com?" description: "A journey through DNS, TCP, TLS, HTTP, Google's infrastructure, and browser rendering — from a URL to the pixels on your screen." author: "DevHub" date: "2026-09-01" -category: "WebSite" +category: "Web" tags: - web - networking From a530856fe5c8e7767d603dfd70c4f5832e021986 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sat, 5 Sep 2026 20:57:43 +0530 Subject: [PATCH 04/16] Update authors.ts --- content/data/authors.ts | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/content/data/authors.ts b/content/data/authors.ts index e336aa5..415655e 100644 --- a/content/data/authors.ts +++ b/content/data/authors.ts @@ -15,4 +15,9 @@ export const authors: Author[] = [ social: "https://github.com/joshdegr8", avatar: "https://avatars.githubusercontent.com/u/237527158?s=64&v=4", }, -]; + { + name: "SpideY", + social: "https://github.com/spideythedev", + avatar: "https://avatars.githubusercontent.com/u/221688867?v=4", + }, +]; \ No newline at end of file From 03da5cc8622a582db4d79711a7a7a984c9bb9ef9 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sat, 5 Sep 2026 20:57:58 +0530 Subject: [PATCH 05/16] Update authors.ts --- content/data/authors.ts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/data/authors.ts b/content/data/authors.ts index 415655e..5080001 100644 --- a/content/data/authors.ts +++ b/content/data/authors.ts @@ -1,3 +1,5 @@ +// Here! + export type Author = { name: string; social: string; From 491231b01c23580dee6d3fc2cb73429e37b24ace Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sat, 5 Sep 2026 21:01:43 +0530 Subject: [PATCH 06/16] Update what-happens-when-you-type-google.md --- content/blog/what-happens-when-you-type-google.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/blog/what-happens-when-you-type-google.md b/content/blog/what-happens-when-you-type-google.md index 6649c54..5d03d38 100644 --- a/content/blog/what-happens-when-you-type-google.md +++ b/content/blog/what-happens-when-you-type-google.md @@ -13,6 +13,7 @@ tags: - browsers - internet - how-it-works + - featured --- # What Happens When You Type `google.com`? From 6e06d2edffc8b127a85168b516b628046503ca13 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sat, 5 Sep 2026 21:02:03 +0530 Subject: [PATCH 07/16] Update what-happens-when-you-type-google.md --- content/blog/what-happens-when-you-type-google.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/blog/what-happens-when-you-type-google.md b/content/blog/what-happens-when-you-type-google.md index 5d03d38..6649c54 100644 --- a/content/blog/what-happens-when-you-type-google.md +++ b/content/blog/what-happens-when-you-type-google.md @@ -13,7 +13,6 @@ tags: - browsers - internet - how-it-works - - featured --- # What Happens When You Type `google.com`? From 4656d9746dd985f41a7183e8bed5548b40f28be8 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sat, 5 Sep 2026 21:03:51 +0530 Subject: [PATCH 08/16] Update authors.ts --- content/data/authors.ts | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/data/authors.ts b/content/data/authors.ts index 5080001..415655e 100644 --- a/content/data/authors.ts +++ b/content/data/authors.ts @@ -1,5 +1,3 @@ -// Here! - export type Author = { name: string; social: string; From 4fa590dd94b42f14600f04ab8a148521a5ec3311 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sat, 5 Sep 2026 21:14:14 +0530 Subject: [PATCH 09/16] Update what-happens-when-you-type-google.md --- content/blog/what-happens-when-you-type-google.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/what-happens-when-you-type-google.md b/content/blog/what-happens-when-you-type-google.md index 6649c54..b027e10 100644 --- a/content/blog/what-happens-when-you-type-google.md +++ b/content/blog/what-happens-when-you-type-google.md @@ -1,7 +1,7 @@ --- title: "What Happens When You Type google.com?" description: "A journey through DNS, TCP, TLS, HTTP, Google's infrastructure, and browser rendering — from a URL to the pixels on your screen." -author: "DevHub" +author: "DevHub " date: "2026-09-01" category: "Web" tags: From 72f897ab7cba808dbdf520e41fe4d488da3aa510 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sat, 5 Sep 2026 21:14:25 +0530 Subject: [PATCH 10/16] Update what-happens-when-you-type-google.md --- content/blog/what-happens-when-you-type-google.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/what-happens-when-you-type-google.md b/content/blog/what-happens-when-you-type-google.md index b027e10..6649c54 100644 --- a/content/blog/what-happens-when-you-type-google.md +++ b/content/blog/what-happens-when-you-type-google.md @@ -1,7 +1,7 @@ --- title: "What Happens When You Type google.com?" description: "A journey through DNS, TCP, TLS, HTTP, Google's infrastructure, and browser rendering — from a URL to the pixels on your screen." -author: "DevHub " +author: "DevHub" date: "2026-09-01" category: "Web" tags: From 28600ba29d30d146098b2daa8417872987ac50a3 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sat, 5 Sep 2026 21:34:04 +0530 Subject: [PATCH 11/16] Update what-happens-when-you-type-google.md --- content/blog/what-happens-when-you-type-google.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/blog/what-happens-when-you-type-google.md b/content/blog/what-happens-when-you-type-google.md index 6649c54..9250f8c 100644 --- a/content/blog/what-happens-when-you-type-google.md +++ b/content/blog/what-happens-when-you-type-google.md @@ -13,6 +13,7 @@ tags: - browsers - internet - how-it-works + - education --- # What Happens When You Type `google.com`? From 034534d26bbae77055cb858b1afbce85e73535a7 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sat, 5 Sep 2026 21:34:29 +0530 Subject: [PATCH 12/16] Update what-happens-when-you-type-google.md --- content/blog/what-happens-when-you-type-google.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/what-happens-when-you-type-google.md b/content/blog/what-happens-when-you-type-google.md index 9250f8c..63f11e5 100644 --- a/content/blog/what-happens-when-you-type-google.md +++ b/content/blog/what-happens-when-you-type-google.md @@ -13,7 +13,7 @@ tags: - browsers - internet - how-it-works - - education + - educational --- # What Happens When You Type `google.com`? From 0dc95758ffad3ed057a868d2f05ee4086ff2b021 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sat, 5 Sep 2026 22:58:36 +0530 Subject: [PATCH 13/16] Change 'educational' tag to 'education' --- content/blog/what-happens-when-you-type-google.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/blog/what-happens-when-you-type-google.md b/content/blog/what-happens-when-you-type-google.md index 63f11e5..f896f03 100644 --- a/content/blog/what-happens-when-you-type-google.md +++ b/content/blog/what-happens-when-you-type-google.md @@ -13,7 +13,7 @@ tags: - browsers - internet - how-it-works - - educational + - education --- # What Happens When You Type `google.com`? @@ -1210,4 +1210,4 @@ And that's what happens when you type `google.com`. [Explore DevHub →](https://devhub.vercel.app/) -[GitHub →](https://github.com/open-devhub/) \ No newline at end of file +[GitHub →](https://github.com/open-devhub/) From 4ecfeadf462d3c064448c283b83be7d3e4021bcf Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sat, 5 Sep 2026 23:01:34 +0530 Subject: [PATCH 14/16] Update what-happens-when-you-type-google.md --- content/blog/what-happens-when-you-type-google.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/what-happens-when-you-type-google.md b/content/blog/what-happens-when-you-type-google.md index f896f03..253e86e 100644 --- a/content/blog/what-happens-when-you-type-google.md +++ b/content/blog/what-happens-when-you-type-google.md @@ -13,7 +13,7 @@ tags: - browsers - internet - how-it-works - - education + - educational --- # What Happens When You Type `google.com`? From b1bc7f0687f9701775d50fe57fdf7f28562e59f7 Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sat, 5 Sep 2026 23:02:21 +0530 Subject: [PATCH 15/16] Update authors.ts --- content/data/authors.ts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/data/authors.ts b/content/data/authors.ts index 415655e..c060d24 100644 --- a/content/data/authors.ts +++ b/content/data/authors.ts @@ -18,6 +18,6 @@ export const authors: Author[] = [ { name: "SpideY", social: "https://github.com/spideythedev", - avatar: "https://avatars.githubusercontent.com/u/221688867?v=4", + avatar: "https://avatars.githubusercontent.com/u/221688867?s=64&v=4", }, ]; \ No newline at end of file From 626049b64e41e4010d6d280e3154819a907183ac Mon Sep 17 00:00:00 2001 From: SpideY Dev Date: Sun, 6 Sep 2026 13:52:54 +0530 Subject: [PATCH 16/16] Revise article on the journey of typing 'google.com' Updated the article to provide a more detailed explanation of the journey from typing 'google.com' to rendering the webpage, including changes to the author, description, and tags. --- .../blog/what-happens-when-you-type-google.md | 793 ++++-------------- 1 file changed, 181 insertions(+), 612 deletions(-) diff --git a/content/blog/what-happens-when-you-type-google.md b/content/blog/what-happens-when-you-type-google.md index 253e86e..b45d15a 100644 --- a/content/blog/what-happens-when-you-type-google.md +++ b/content/blog/what-happens-when-you-type-google.md @@ -1,19 +1,9 @@ --- title: "What Happens When You Type google.com?" -description: "A journey through DNS, TCP, TLS, HTTP, Google's infrastructure, and browser rendering — from a URL to the pixels on your screen." -author: "DevHub" -date: "2026-09-01" -category: "Web" -tags: - - web - - networking - - dns - - http - - tls - - browsers - - internet - - how-it-works - - educational +description: "You type six characters and hit Enter, and DNS, routing, TLS, and your browser's rendering engine all quietly team up to turn that into a page. This is the real, layer by layer story of what happens in between." +authors: [SpideY] +date: September 1, 2026 +tags: [networking, dns, http, tls, internet] --- # What Happens When You Type `google.com`? @@ -78,8 +68,6 @@ Pixels on your screen Let's follow that journey. ---- - ## 1. You type `google.com` It begins with something incredibly ordinary. @@ -92,15 +80,12 @@ google.com Then you press Enter. -The browser first has to determine what you actually entered. - -Is it a search query? - -Is it a URL? - -Is it a hostname? +The browser first has to determine what you actually entered: -Is there a protocol? +- Is it a search query? +- Is it a URL? +- Is it a hostname? +- Is there a protocol? Because you entered: @@ -108,9 +93,7 @@ Because you entered: google.com ``` -the browser interprets it as a web address. - -Conceptually, it becomes something like: +the browser interprets it as a web address. Conceptually, it becomes something like: ```text https://google.com/ @@ -125,21 +108,13 @@ Port: 443 Path: / ``` -You didn't explicitly type `https://`. - -Modern browsers can infer the secure HTTP scheme for a domain. - -Now the browser needs an address. - -And `google.com` isn't an IP address. +You didn't explicitly type `https://`. Modern browsers can infer the secure HTTP scheme for a domain. ---- - -# 2. Computers don't route traffic using domain names +Now the browser needs an address. And `google.com` isn't an IP address. -Humans like names. +## 2. Computers don't route traffic using domain names -Computers ultimately communicate using network addresses. +Humans like names. Computers ultimately communicate using network addresses. You can remember: @@ -153,59 +128,32 @@ much more easily than something like: 142.250.x.x ``` -The system that connects those two worlds is **DNS**. - -The Domain Name System is essentially the Internet's distributed naming system. - -It translates domain names into network addresses. +The system that connects those two worlds is **DNS** (the **Domain Name System**), the Internet's distributed naming system. It translates domain names into network addresses. Conceptually: ```text -google.com - ↓ -DNS - ↓ -IP address +google.com → DNS → IP address ``` But before your computer asks a DNS server, it may check places where the answer could already exist. ---- - -# 3. The browser checks its caches - -Your browser doesn't want to perform a complete DNS lookup every time you visit a website. - -That would be wasteful. - -So it can cache DNS information. - -Depending on the browser and operating system, the resolution process may involve several layers of caching. - -A simplified model looks like: - -```text -Browser DNS cache - ↓ -OS DNS cache - ↓ -Configured DNS resolver - ↓ -Internet DNS infrastructure -``` +## 3. The browser checks its caches -If the browser already knows the answer and the cached record is still valid, the process can be significantly faster. +Your browser doesn't want to perform a complete DNS lookup every time you visit a website, since that would be wasteful. So it can cache DNS information. -If not, the request continues. +Depending on the browser and operating system, resolution may involve several layers of caching: ---- +- Browser DNS cache +- OS DNS cache +- Configured DNS resolver +- Internet DNS infrastructure -# 4. DNS resolution begins +If the browser already knows the answer and the cached record is still valid, the process can be significantly faster. If not, the request continues. -Your computer usually communicates with a DNS resolver. +## 4. DNS resolution begins -That resolver might be operated by: +Your computer usually communicates with a DNS resolver. That resolver might be operated by: - Your ISP - Your organization @@ -213,11 +161,7 @@ That resolver might be operated by: - A public DNS provider - Another network service -The resolver needs to discover the DNS records associated with `google.com`. - -DNS is hierarchical. - -A simplified lookup can look like: +The resolver needs to discover the DNS records associated with `google.com`. DNS is hierarchical. A simplified lookup can look like: ```text Your computer @@ -233,85 +177,51 @@ Authoritative nameservers google.com records ``` -The resolver doesn't necessarily need to perform every step every time. +The resolver doesn't necessarily need to perform every step every time, it may already have the answer cached. But conceptually, this hierarchy is what makes the system work. -It may already have the answer cached. +## 5. The root servers don't know Google's IP address -But conceptually, this hierarchy is what makes the system work. - ---- - -# 5. The root servers don't know Google's IP address - -This is an important detail. - -The root DNS system doesn't contain a giant table saying: +This is an important detail. The root DNS system doesn't contain a giant table saying: ```text google.com → Google's IP ``` -Instead, root servers can direct resolvers toward the nameservers responsible for the `.com` top-level domain. - -The resolver asks: +Instead, root servers can direct resolvers toward the nameservers responsible for the `.com` top-level domain. The resolver asks: > Who handles `.com`? -The `.com` infrastructure responds with information about the authoritative nameservers for `google.com`. - -The resolver then asks those authoritative nameservers: +The `.com` infrastructure responds with information about the authoritative nameservers for `google.com`. The resolver then asks those authoritative nameservers: > What address should I use for `google.com`? The authoritative DNS system provides the appropriate records. ---- - -# 6. A domain can have multiple addresses +## 6. A domain can have multiple addresses -You shouldn't think of a domain as necessarily mapping to one permanent IP address. +You shouldn't think of a domain as necessarily mapping to one permanent IP address. A large service can have many addresses and many locations, including: -A large service can have many addresses and many locations. +- IPv4 addresses +- IPv6 addresses +- Regional endpoints +- Edge locations +- Load-balancing mechanisms -There can be: - -```text -IPv4 addresses -IPv6 addresses -regional endpoints -edge locations -load-balancing mechanisms -``` - -DNS can therefore be part of a larger traffic-management strategy. - -The exact address returned to you can depend on factors such as network topology, DNS configuration, availability, and traffic-management systems. +DNS can therefore be part of a larger traffic-management strategy. The exact address returned to you can depend on factors such as network topology, DNS configuration, availability, and traffic-management systems. The important point is: > **`google.com` is a name, not a single physical machine.** ---- - -# 7. Now your computer knows where to connect - -Eventually, your system gets an address it can use. +## 7. Now your computer knows where to connect -Conceptually: +Eventually, your system gets an address it can use. Conceptually: ```text -google.com - ↓ -IP address +google.com → IP address ``` -Now the browser has another problem. - -How does a packet get from your device to that destination? - -Your computer doesn't usually have a direct physical connection to Google's servers. - -The traffic may travel through: +Now the browser has another problem: how does a packet get from your device to that destination? Your computer doesn't usually have a direct physical connection to Google's servers. The traffic may travel through: ```text Your device @@ -331,31 +241,18 @@ Destination And the Internet needs to figure out that path. ---- +## 8. The Internet doesn't have one central router -# 8. The Internet doesn't have one central router +There isn't a giant machine somewhere that decides the route for every packet on Earth. The Internet is a network of interconnected networks. -There isn't a giant machine somewhere that decides the route for every packet on Earth. +- Organizations exchange routing information using systems such as **BGP** (the Border Gateway Protocol). +- Routing systems determine how different networks can reach one another. +- Your packet might cross multiple autonomous systems before reaching Google's infrastructure. +- Routers make forwarding decisions based on routing information; you don't manually choose that path. -The Internet is a network of interconnected networks. +## 9. Your packet doesn't necessarily take the same path every time -Organizations exchange routing information using systems such as **BGP — the Border Gateway Protocol**. - -At a high level, routing systems determine how different networks can reach one another. - -Your packet might cross multiple autonomous systems before reaching Google's infrastructure. - -You don't manually choose that path. - -Routers make forwarding decisions based on routing information. - ---- - -# 9. Your packet doesn't necessarily take the same path every time - -Internet routing is dynamic. - -The path can change because of: +Internet routing is dynamic. The path can change because of: - Network failures - Congestion @@ -364,23 +261,11 @@ The path can change because of: - Traffic engineering - Infrastructure changes -This is one reason the Internet is resilient. +This is one reason the Internet is resilient. If one path becomes unavailable, routing systems can potentially direct traffic elsewhere. The Internet isn't one road; it's an enormous collection of interconnected roads. -If one path becomes unavailable, routing systems can potentially direct traffic elsewhere. +## 10. Now we need a connection -The Internet isn't one road. - -It's an enormous collection of interconnected roads. - ---- - -# 10. Now we need a connection - -Knowing the destination isn't enough. - -Your browser needs to communicate with the server. - -For traditional HTTPS over TCP, that means establishing a TCP connection. +Knowing the destination isn't enough. Your browser needs to communicate with the server. For traditional HTTPS over TCP, that means establishing a TCP connection. The default HTTPS port is: @@ -388,9 +273,7 @@ The default HTTPS port is: 443 ``` -TCP establishes a connection using a process commonly called the **three-way handshake**. - -Conceptually: +TCP establishes a connection using a process commonly called the **three-way handshake**: ```text Client Server @@ -402,17 +285,9 @@ Client Server ACK --------------------> ``` -Now both sides have established the TCP connection. - -But there's still a major problem. - -We don't want to send sensitive web traffic as plain text. +Now both sides have established the TCP connection. But there's still a major problem: we don't want to send sensitive web traffic as plain text. That's where TLS comes in. -That's where TLS comes in. - ---- - -# 11. HTTPS means HTTP over an encrypted connection +## 11. HTTPS means HTTP over an encrypted connection You typed: @@ -426,11 +301,7 @@ not: http://google.com ``` -HTTPS uses TLS to provide security properties such as encryption and server authentication. - -The browser needs to establish a secure TLS session. - -A simplified TLS 1.3 flow looks like: +HTTPS uses TLS to provide security properties such as encryption and server authentication. The browser needs to establish a secure TLS session. A simplified TLS 1.3 flow looks like: ```text Client Server @@ -441,36 +312,22 @@ ClientHello ServerHello Certificate Key exchange + Finished <------------------------ Finished ------------------------> - - Finished - <------------------------ ``` The real protocol contains significantly more detail, but the important concept is: -> Both sides negotiate cryptographic parameters and establish shared secrets used to protect the connection. - ---- - -# 12. How does the browser know it's really Google? - -Encryption alone isn't enough. - -Imagine someone intercepted your connection and pretended to be Google. - -You would have an encrypted connection... +> Both sides negotiate cryptographic parameters and establish shared secrets used to protect the connection. The server finishes its side of the handshake first (bundled with its certificate and key exchange), and the client's `Finished` message closes the handshake. After that, both sides can send encrypted application data. -to the attacker. +## 12. How does the browser know it's really Google? -That's where certificates and the certificate authority ecosystem become important. +Encryption alone isn't enough. Imagine someone intercepted your connection and pretended to be Google. You would have an encrypted connection... to the attacker. That's where certificates and the certificate authority ecosystem become important. -Google's server presents a certificate. - -Your browser verifies that certificate against its trusted certificate authorities and checks properties such as: +Google's server presents a certificate. Your browser verifies that certificate against its trusted certificate authorities and checks properties such as: - The certificate's validity - The hostname @@ -478,17 +335,11 @@ Your browser verifies that certificate against its trusted certificate authoriti - The certificate chain - Other certificate constraints -If verification fails, your browser can warn you. - -If everything checks out, the browser has much stronger evidence that it's communicating with the intended service. - ---- - -# 13. HTTP finally gets involved +If verification fails, your browser can warn you. If everything checks out, the browser has much stronger evidence that it's communicating with the intended service. -Now we can actually send an HTTP request. +## 13. HTTP finally gets involved -At a simplified level, the request might look like: +Now we can actually send an HTTP request. At a simplified level, the request might look like: ```http GET / HTTP/2 @@ -503,121 +354,57 @@ The browser is essentially saying: > "Give me the resource at `/`." -The actual request is more complex, and modern HTTP versions don't necessarily transmit it as literal text in the same way HTTP/1.1 does. +The actual request is more complex, and modern HTTP versions don't necessarily transmit it as literal text in the same way HTTP/1.1 does. But conceptually, that's what is happening. -But conceptually, that's what is happening. - ---- - -# 14. HTTP/2 and HTTP/3 change the story +## 14. HTTP/2 and HTTP/3 change the story Modern web traffic isn't limited to old-school HTTP/1.1. -HTTP/2 introduced features such as: +**HTTP/2** introduced features such as: - Multiplexed streams - Header compression - More efficient connection usage -HTTP/3 uses QUIC, which runs over UDP rather than TCP. +**HTTP/3** uses [QUIC](https://en.wikipedia.org/wiki/QUIC), which runs over UDP rather than TCP. -Conceptually: +Conceptually, the protocol stacks look like: ```text -HTTP/1.1 - ↓ -TCP - ↓ -IP +HTTP/1.1 HTTP/2 HTTP/3 + ↓ ↓ ↓ + TCP TCP QUIC + ↓ ↓ ↓ + IP IP UDP + ↓ + IP ``` -versus: +The exact protocol negotiated depends on what the client and server support. Modern browsers can use newer transport and HTTP protocols to reduce latency and improve performance. -```text -HTTP/2 - ↓ -TCP - ↓ -IP -``` +## 15. Your request reaches Google's infrastructure -and: +This is where things become very different from visiting a small website. `google.com` isn't sitting on one server under someone's desk; large Internet services operate enormous distributed infrastructures. Your request can pass through multiple layers of Google's network and service architecture: -```text -HTTP/3 - ↓ -QUIC - ↓ -UDP - ↓ -IP -``` - -The exact protocol negotiated depends on what the client and server support. +- **Google edge infrastructure**: the closest point of entry to the Internet +- **Traffic management**: deciding where the request should go +- **Frontend services**: terminating connections and routing internally +- **Application systems**: the logic that builds a response +- **Data services**: where the underlying data actually lives -The important thing is that modern browsers can use newer transport and HTTP protocols to reduce latency and improve performance. - ---- +The exact internal architecture is proprietary and changes over time. But the principle is straightforward: -# 15. Your request reaches Google's infrastructure +> **A large service distributes work across many machines and locations.** -This is where things become very different from visiting a small website. +## 16. The edge matters -`google.com` isn't sitting on one server under someone's desk. +Large services try to handle users close to where they connect to the Internet. This reduces latency and allows traffic to be distributed efficiently. Instead of every request traveling to one central machine, traffic can be handled through distributed infrastructure. -Large Internet services operate enormous distributed infrastructures. +This is one reason large websites can serve users around the world. Your request from India doesn't necessarily travel to one single server in the United States before anything happens. Internet infrastructure is distributed. -Your request can pass through multiple layers of Google's network and service architecture. +## 17. Load balancing decides where the request goes -A simplified conceptual model might look like: - -```text -Internet - ↓ -Google edge infrastructure - ↓ -Traffic management - ↓ -Frontend services - ↓ -Application systems - ↓ -Data services -``` - -The exact internal architecture is proprietary and changes over time. - -But the principle is straightforward: - -**A large service distributes work across many machines and locations.** - ---- - -# 16. The edge matters - -Large services try to handle users close to where they connect to the Internet. - -This reduces latency and allows traffic to be distributed efficiently. - -Instead of every request traveling to one central machine, traffic can be handled through distributed infrastructure. - -This is one reason large websites can serve users around the world. - -Your request from India doesn't necessarily travel to one single server in the United States before anything happens. - -Internet infrastructure is distributed. - ---- - -# 17. Load balancing decides where the request goes - -Suppose thousands or millions of requests arrive. - -One server shouldn't necessarily process all of them. - -Load-balancing systems distribute work. - -Conceptually: +Suppose thousands or millions of requests arrive. One server shouldn't necessarily process all of them; load-balancing systems distribute work. ```text ┌── Server A @@ -627,9 +414,7 @@ Request → Load Balancer ── Server B └── Server C ``` -The real systems are considerably more sophisticated. - -They can account for factors such as: +The real systems are considerably more sophisticated. They can account for factors such as: - Server health - Capacity @@ -640,21 +425,16 @@ They can account for factors such as: The goal is to keep the system responsive and resilient. ---- - -# 18. The server processes your request +## 18. The server processes your request Eventually, some system needs to determine what response to send. -For a simple static page, that might involve retrieving already-generated resources. - -For a dynamic application, the server may perform application logic, access caches, query databases, call internal services, and construct a response. +- For a simple static page, that might involve retrieving already-generated resources. +- For a dynamic application, the server may perform application logic, access caches, query databases, call internal services, and construct a response. The important thing is that: -> **The browser doesn't know how Google internally produces its response.** - -It only knows the protocol. +> **The browser doesn't know how Google internally produces its response.** It only knows the protocol. Request: @@ -670,13 +450,9 @@ HTTP response The complexity behind that response is hidden behind the network boundary. ---- +## 19. The response comes back -# 19. The response comes back - -The server sends an HTTP response. - -Conceptually: +The server sends an HTTP response. Conceptually: ```http HTTP/2 200 @@ -685,40 +461,24 @@ Content-Encoding: br Content-Length: ... ``` -followed by the response body. +followed by the response body. A successful request might have a status such as `200 OK`. Other possibilities include: -A successful request might have a status such as: - -```text -200 OK -``` - -Other possibilities include: - -```text -301 Moved Permanently -302 Found -304 Not Modified -403 Forbidden -404 Not Found -429 Too Many Requests -500 Internal Server Error -503 Service Unavailable -``` +| Status | Meaning | +| ------ | --------------------- | +| `301` | Moved Permanently | +| `302` | Found | +| `304` | Not Modified | +| `403` | Forbidden | +| `404` | Not Found | +| `429` | Too Many Requests | +| `500` | Internal Server Error | +| `503` | Service Unavailable | HTTP status codes are one of the fundamental ways servers communicate the outcome of requests. ---- - -# 20. Compression makes the response smaller - -Web pages can contain a lot of data. - -Sending everything uncompressed would waste bandwidth. +## 20. Compression makes the response smaller -Modern servers can compress responses using algorithms such as Brotli or gzip. - -For example: +Web pages can contain a lot of data. Sending everything uncompressed would waste bandwidth. Modern servers can compress responses using algorithms such as **Brotli** or **gzip**. ```text Original: @@ -728,25 +488,11 @@ Compressed: ██████████ ``` -The browser receives the compressed representation and decompresses it. - -Smaller payloads generally mean less data needs to cross the network. - -That can significantly matter on slower connections. - ---- - -# 21. The browser receives bytes - -Now the response has made its way back to your machine. - -But your browser doesn't immediately have a page. - -It has **bytes**. +The browser receives the compressed representation and decompresses it. Smaller payloads generally mean less data needs to cross the network, which can significantly matter on slower connections. -Those bytes need to be interpreted. +## 21. The browser receives bytes -For HTML, the browser begins parsing the document. +Now the response has made its way back to your machine. But your browser doesn't immediately have a page. It has **bytes**. Those bytes need to be interpreted. For HTML, the browser begins parsing the document. Imagine the response contains: @@ -764,25 +510,15 @@ Imagine the response contains: The browser turns that markup into a structured representation. ---- - -# 22. HTML becomes the DOM +## 22. HTML becomes the DOM -The browser parses HTML and constructs the **DOM — Document Object Model**. - -Conceptually: +The browser parses HTML and constructs the **DOM** (the **Document Object Model**). Conceptually: ```text -HTML - ↓ -Parser - ↓ -DOM +HTML → Parser → DOM ``` -The DOM is a tree. - -For example: +The DOM is a tree. For example: ```text Document @@ -793,86 +529,47 @@ Document └── h1 ``` -JavaScript can interact with this structure. - -That's how code can do things such as: +JavaScript can interact with this structure, that's how code can do things such as: ```js document.querySelector("h1"); ``` -The browser isn't simply displaying raw HTML. - -It's building an internal representation of the document. - ---- +The browser isn't simply displaying raw HTML. It's building an internal representation of the document. -# 23. CSS becomes the CSSOM +## 23. CSS becomes the CSSOM -HTML tells the browser what elements exist. - -CSS tells it how those elements should look. - -The browser parses CSS into another internal representation commonly referred to as the **CSSOM — CSS Object Model**. - -Conceptually: +HTML tells the browser what elements exist. CSS tells it how those elements should look. The browser parses CSS into another internal representation commonly referred to as the **CSSOM** (the **CSS Object Model**). ```text -HTML - ↓ -DOM - -CSS - ↓ -CSSOM +HTML → DOM +CSS → CSSOM ``` The browser then combines information from both. ---- - -# 24. The browser builds the render tree +## 24. The browser builds the render tree -The browser needs to determine what should actually be rendered. - -It combines relevant DOM and styling information into structures used for rendering. - -Conceptually: +The browser needs to determine what should actually be rendered. It combines relevant DOM and styling information into structures used for rendering: ```text -DOM + CSSOM - ↓ -Render information - ↓ -Layout +DOM + CSSOM → Render information → Layout ``` -Not every DOM node necessarily results in something visible. - -For example, elements that aren't rendered don't necessarily participate in visual rendering in the same way. - ---- - -# 25. Layout calculates positions +Not every DOM node necessarily results in something visible; elements that aren't rendered don't necessarily participate in visual rendering in the same way. -Now the browser needs to answer: +## 25. Layout calculates positions -> Where does everything go? +Now the browser needs to answer: where does everything go? It calculates things such as: -It calculates things such as: - -- Width -- Height +- Width and height - Position -- Margins -- Padding +- Margins and padding - Text layout - Element relationships This stage is often called **layout**. -Imagine: - ```text Viewport ┌────────────────────────────┐ @@ -887,49 +584,19 @@ Viewport The browser has to calculate the actual coordinates and dimensions of those elements. ---- - -# 26. Then the browser paints +## 26. Then the browser paints -Once the browser knows where things are, it needs to draw them. - -Text. - -Backgrounds. - -Borders. - -Images. - -Shadows. - -Icons. - -The browser generates visual output through a process generally referred to as **painting**. - -Conceptually: +Once the browser knows where things are, it needs to draw them: text, backgrounds, borders, images, shadows, icons. The browser generates visual output through a process generally referred to as **painting**. ```text -DOM - ↓ -Style - ↓ -Layout - ↓ -Paint +DOM → Style → Layout → Paint ``` But we're still not quite finished. ---- - -# 27. Compositing puts everything together +## 27. Compositing puts everything together -Modern browsers can divide visual content into layers. - -Those layers can then be composited together. - -Conceptually: +Modern browsers can divide visual content into layers. Those layers can then be composited together: ```text Layer 1 ─── Background @@ -942,17 +609,11 @@ Layer 4 ─── Animation Frame ``` -The browser and graphics stack work together to produce the final frame. +The browser and graphics stack work together to produce the final frame. Depending on the content, some operations can be accelerated using the GPU. -Depending on the content, some operations can be accelerated using the GPU. +## 28. Finally: pixels ---- - -# 28. Finally: pixels - -After all those layers of processing, your display receives a frame. - -The journey that started with: +After all those layers of processing, your display receives a frame. The journey that started with: ```text google.com @@ -964,13 +625,7 @@ has become: pixels ``` -on your screen. - -And all of this happened incredibly quickly. - -You saw a page. - -Your computer saw: +on your screen. And all of this happened incredibly quickly. You saw a page. Your computer saw: ```text DNS @@ -988,9 +643,7 @@ DNS → pixels ``` ---- - -# The complete journey +## The complete journey Let's put everything together. @@ -1010,9 +663,7 @@ Local caches DNS Resolver │ ├── Root - │ ├── .com - │ └── Authoritative DNS │ ▼ @@ -1064,105 +715,54 @@ And you only typed: google.com ``` ---- - -# What if something goes wrong? - -This entire process has many potential failure points. - -If DNS fails: - -```text -DNS_PROBE_FINISHED_NXDOMAIN -``` - -or another DNS-related error may appear. - -If the server can't be reached: - -```text -Connection failed -``` - -If TLS verification fails: - -```text -Your connection is not private -``` - -If the server returns an error: - -```text -500 Internal Server Error -``` - -If the resource doesn't exist: - -```text -404 Not Found -``` - -If the network is slow, the page may simply take longer to arrive. +## What if something goes wrong? -Modern web browsers hide enormous amounts of complexity behind a simple interface. +This entire process has many potential failure points: -That's one of the reasons the web feels so effortless. +| If this fails... | You might see... | +| ---------------------- | ------------------------------------------------------ | +| DNS resolution | `DNS_PROBE_FINISHED_NXDOMAIN` (or a similar DNS error) | +| Reaching the server | `Connection failed` | +| TLS verification | `Your connection is not private` | +| Server-side processing | `500 Internal Server Error` | +| Resource lookup | `404 Not Found` | +| Slow network | The page simply takes longer to arrive | ---- - -# The important lesson - -The web isn't one technology. - -It's a stack. - -When you visit a website, you're relying on many systems cooperating: +Modern web browsers hide enormous amounts of complexity behind a simple interface. That's one of the reasons the web feels so effortless. -```text -Application -HTTP -TLS -QUIC / TCP -IP -DNS -BGP -Operating System -Browser -GPU -Display -``` +## The important lesson -Each layer has its own responsibilities. +The web isn't one technology, it's a stack. When you visit a website, you're relying on many systems cooperating: -Each layer abstracts complexity from the layer above it. +- Application +- HTTP +- TLS +- QUIC / TCP +- IP +- DNS +- BGP +- Operating System +- Browser +- GPU +- Display -And that's one of the most powerful ideas in computer science: +Each layer has its own responsibilities. Each layer abstracts complexity from the layer above it. And that's one of the most powerful ideas in computer science: > **Complex systems become manageable when responsibilities are separated into layers.** -You don't need to understand BGP to use Google. - -You don't need to understand TLS to log into a website. - -You don't need to understand DOM construction to build a web page. - -But when something breaks, understanding the layers becomes incredibly valuable. +You don't need to understand BGP to use Google. You don't need to understand TLS to log into a website. You don't need to understand DOM construction to build a web page. -If a domain doesn't resolve, investigate DNS. +But when something breaks, understanding the layers becomes incredibly valuable: -If the connection can't be established, investigate networking. - -If TLS fails, investigate certificates and encryption. - -If the server responds slowly, investigate the application or network. - -If the page loads but renders incorrectly, investigate the browser and frontend. +- If a domain doesn't resolve, investigate **DNS**. +- If the connection can't be established, investigate **networking**. +- If TLS fails, investigate **certificates and encryption**. +- If the server responds slowly, investigate the **application or network**. +- If the page loads but renders incorrectly, investigate the **browser and frontend**. Knowing **which layer is responsible** is one of the most useful skills a developer can develop. ---- - -# One URL. An entire universe. +## One URL. An entire universe. The next time you type: @@ -1172,42 +772,11 @@ google.com remember what's actually happening. -A browser interprets your input. - -DNS turns a human-readable name into an address. - -Routing finds a path through interconnected networks. - -A secure protocol establishes encrypted communication. - -HTTP carries your request. - -Distributed infrastructure processes it. - -Bytes travel back across the Internet. - -Your browser turns those bytes into structures. - -The rendering engine calculates styles and geometry. +A browser interprets your input. DNS turns a human-readable name into an address. Routing finds a path through interconnected networks. A secure protocol establishes encrypted communication. HTTP carries your request. Distributed infrastructure processes it. Bytes travel back across the Internet. Your browser turns those bytes into structures. The rendering engine calculates styles and geometry. The graphics pipeline turns those structures into a frame. -The graphics pipeline turns those structures into a frame. +And finally, **you see a webpage.** -And finally— - -**you see a webpage.** - -All from six characters. - -That's the web. - -And that's what happens when you type `google.com`. - ---- +All from six characters. That's the web. And that's what happens when you type `google.com`. > **The Internet feels simple because billions of complicated decisions happen underneath the surface.** -**DevHub** - -[Explore DevHub →](https://devhub.vercel.app/) - -[GitHub →](https://github.com/open-devhub/)