/wiki / https

Https — Map of Content

2026-09-02T00:00:00.000Z

Map of Content for Https — 30 concepts. Start here to navigate https.

Core Concepts

ARP Protocol — concept
Browser Autocomplete — concept
Browser Rendering — concept
Compositing — concept
CSSOM — concept
CSS Parsing — concept
DNS Authoritative Server — concept
DNS Cache — concept
DNS Hierarchy — concept
DNS Lookup — concept
DNS Root Server — concept
DNS TLD Server — concept
DOM Tree — concept
GPU Rendering — concept
HSTS — concept
HTML Parsing — concept
HTTP Headers — concept
HTTP Request — concept
HTTP Response — concept
HTTPS — concept
Keyboard Interrupt — concept
Layout — concept
MAC Address — concept
OS Interrupt Handler — concept
Painting — concept
Recursive DNS — concept
Render Tree — concept
TCP Packet Drop — concept
URL Parsing — concept
url-to-rendering-flow — concept

Mechanisms & How Things Work

Auto-generated — edit to curate. Pages that explain processes/flows.

Comparisons & Tradeoffs

(No synthesis yet — create via ingest or query —save)

arp-protocol

2026-04-30T00:00:00.000Z

The Problem

You have an IP address (142.250.183.46) but need to send a packet on the local network (Ethernet). Local networks use MAC addresses, not IP addresses. Without ARP, you can’t figure out which MAC address corresponds to an IP.

Core Idea

ARP (Address Resolution Protocol) translates IP addresses to MAC addresses on local networks. It broadcasts “Who has this IP?” and the owner replies with its MAC address.

How It Works

Need MAC: System wants to send packet to IP 192.168.1.1
Check ARP Cache: Is this IP already mapped? If yes, use cached MAC
Broadcast Query: “Who has IP 192.168.1.1? Tell 192.168.1.100”
Reply: The owner replies (unicast): “I have 192.168.1.1, my MAC is aa:bb:cc:dd:ee:ff”
Cache: Store in ARP cache for future use

ARP operates at Layer 2 (Data Link) and is essential for IPv4 over Ethernet.

Visual Explanation

Key Properties

Only needed for IPv4 (IPv6 uses Neighbor Discovery)
ARP cache has TTL (typically 2-20 minutes)
Broadcast query, unicast response
Operates below IP layer (Layer 2)

Connections

Built from: IP Address — ARP translates IP to MAC
Builds into: Socket — sockets use MAC for local delivery
Related: MAC Address — what ARP resolves to
Related: Ethernet — ARP is used on Ethernet networks
Contrasts with: DNS Lookup — DNS is IP↔domain; ARP is MAC↔IP

Edge Cases & Gotchas

ARP spoofing attacks can redirect traffic (man-in-the-middle)
ARP cache poisoning is a common attack vector
Large networks can have many ARP entries (router burden)
No authentication—anyone can reply to ARP queries

browser-autocomplete

2026-04-30T00:00:00.000Z

The Problem

When users type in the address bar, they want suggestions to speed up navigation. Without autocomplete, users would have to type full URLs manually every time.

Core Idea

Browser autocomplete suggests URLs as you type, using history, bookmarks, cookies, and popular queries. It runs locally (no network needed at this stage) and updates in real-time.

How It Works

Input detected: User types character in address bar
Local search: Check against:
- Browsing history
- Bookmarks
- Cookies (visited sites)
- Popular/common URLs
Display: Show dropdown with matching suggestions
No network: This happens before any DNS/HTTP

Modern browsers also use AI/ML for smarter suggestions.

Visual Explanation

Key Properties

Runs locally—no network requests yet
Uses history, bookmarks, cookies, popular queries
Updates in real-time as user types
Can be disabled in browser settings

Connections

Built from: URL Parsing — autocomplete works on URL input
Related: Browser Rendering — happens before rendering
Related: Browser History — source for suggestions
Contrasts with: DNS Lookup — autocomplete is local, DNS is network

Edge Cases & Gotchas

Private/incognito mode limits autocomplete data
Corrupt history database can break autocomplete
Some browsers share data across devices (synced)
Autocomplete can leak visited sites (privacy concern)

browser-rendering

2026-04-30T00:00:00.000Z

The Problem

The browser has received an HTML response from the server. Now it needs to turn that raw text into pixels on the screen. Without a rendering pipeline, the user would just see a blank page or raw HTML source.

Core Idea

Browser rendering is the multi-step pipeline that converts HTML, CSS, and JavaScript into visible pixels: parsing → style calculation → layout → paint → composite. Each step transforms the content into a more rendered form.

How It Works

HTML Parsing: Build DOM tree from HTML
CSS Parsing: Build CSSOM (CSS Object Model) from stylesheets
Render Tree: Combine DOM + CSSOM (only visible elements)
Layout: Calculate position and size of each element
Paint: Fill in pixels for each element
Composite: Combine layers and send to GPU for display

Modern browsers use GPU acceleration for steps 5-6.

Visual Explanation

Key Properties

Render-blocking: CSS blocks rendering (no paint without styles)
JavaScript can block HTML parsing (unless async/defer)
Layers enable GPU-accelerated compositing
Reflow (layout recalculation) is expensive—avoid in loops

Connections

Built from: HTTP Response — HTML response triggers rendering
Builds into: DOM Tree — first step of rendering
Related: CSS Parsing — builds CSSOM
Related: GPU Rendering — accelerates painting/compositing
Related: Layout — calculates element positions

Edge Cases & Gotchas

FOUC (Flash of Unstyled Content) if CSS loads slowly
display: none removes element from render tree
visibility: hidden keeps element in render tree (takes space)
Forced synchronous layout (reading layout properties in JS) is slow

compositing

2026-04-30T00:00:00.000Z

The Problem

The browser has multiple painted layers (bitmaps), but the screen shows only one image. Without compositing, layers would overlap incorrectly or the GPU couldn’t accelerate the final display.

Core Idea

Compositing combines multiple painted layers into a single image for display. It’s handled by the GPU for smooth scrolling, animations, and transforms.

How It Works

Layers ready: Painting has created bitmap layers
GPU composites: GPU takes layers and combines them in order
- Respect z-index and stacking context
- Apply transforms, opacity, clips
Final output: Single frame sent to display

Modern browsers promote elements to layers for:

transform, opacity animations
position: fixed
Video, canvas, iframe elements

Visual Explanation

Key Properties

GPU-accelerated (fast, off-main-thread)
Layers created for specific CSS properties
Order matters: z-index, stacking context
Enables smooth scrolling/animations without repainting

Connections

Built from: Painting — painted layers are composited
Builds into: GPU Rendering — compositing uses GPU
Related: Browser Rendering — compositing is step 7
Related: CSS Layers — promote elements to layers

Edge Cases & Gotchas

Too many layers = memory overhead
Layer promotion with will-change can backfire
Compositing doesn’t fix slow JavaScript
Not all CSS properties trigger compositing

css-parsing

2026-04-30T00:00:00.000Z

The Problem

The browser receives CSS as text (from stylesheets, <style> tags, inline styles). To apply styles, the browser needs a structured representation of all CSS rules. Raw text isn’t programmable.

Core Idea

CSS parsing converts CSS text into the CSSOM (CSS Object Model)—a tree of style rules. This is used later to compute styles for each DOM element during render tree construction.

How It Works

Tokenization: Break CSS text into tokens (selector, {, property, value, })

Parse rules: Build CSSOM tree with selectors and declarations

body { color: red; }
↓
CSSOM: selector=body, declarations=[color: red]

Style calculation: Later, match CSSOM rules to DOM elements

CSS parsing can block rendering—browser won’t paint until CSSOM is ready.

Visual Explanation

Key Properties

CSSOM is separate from DOM (different trees)
CSS parsing blocks rendering (need styles before paint)
Media queries are evaluated during CSSOM construction
Errors in CSS are silently ignored (lenient parsing)

Connections

Builds into: Render Tree — CSSOM combines with DOM
Related: DOM Tree — CSSOM is the CSS counterpart
Related: Browser Rendering — CSS parsing is step 2
Related: CSSOM — the output of CSS parsing

Edge Cases & Gotchas

CSS at top of page (best practice)—blocks rendering until parsed
@import causes additional network requests (slow)
Invalid CSS silently fails (no error thrown)
Large stylesheets = slow CSSOM construction

cssom

2026-04-30T00:00:00.000Z

The Problem

CSS is received as text, but the browser needs a structured representation to compute styles for each DOM element. Raw CSS text can’t be queried programmatically.

Core Idea

CSSOM (CSS Object Model) is the tree structure created by parsing CSS. It contains all style rules and is used to compute styles for each DOM element during render tree construction.

How It Works

CSS Received: From stylesheets, <style> tags, inline styles

Parse: Convert to CSSOM tree

body { color: red; }
↓
CSSOM: selector=body, declarations=[color: red]

Style computation: For each DOM element, find matching CSSOM rules
Cascading: Apply specificity, inheritance, !important

Visual Explanation

Key Properties

CSSOM is separate from DOM (different trees)
JavaScript can manipulate CSSOM via document.styleSheets
CSS parsing blocks rendering (need styles before paint)
Media queries evaluated during CSSOM construction

Connections

Built from: CSS Parsing — CSSOM is the output
Builds into: Render Tree — CSSOM + DOM = render tree
Related: DOM Tree — CSSOM styles are applied to DOM
Related: Browser Rendering — CSSOM is step 2

Edge Cases & Gotchas

document.write() in old browsers could break CSSOM
Large stylesheets = slow CSSOM construction
@import causes additional network requests
CSSOM errors are silently ignored

dns-authoritative-server

2026-04-30T00:00:00.000Z

The Problem

After navigating root and TLD servers, you still don’t have the IP address. Someone needs to hold the actual DNS records (A, AAAA, CNAME, etc.) for each domain—that’s the authoritative server.

Core Idea

The authoritative server is the final authority for a domain—it holds the actual DNS records (A, AAAA, MX, etc.) and returns the real IP address. This is the server operated by the domain owner or their DNS provider.

How It Works

Query from Resolver: “What is the IP for google.com?”
Lookup: Authoritative server checks its zone file
Response: Returns the A record (IPv4) or AAAA record (IPv6)
- Example: “google.com = 142.250.183.46”
Done: Resolver caches and returns IP to client

The domain owner configures records on their authoritative server (or via DNS provider like Cloudflare, AWS Route53).

Visual Explanation

Key Properties

Holds actual DNS records (A, AAAA, CNAME, MX, TXT, etc.)
Domain owners configure records via their DNS provider
Responds authoritatively—no further lookup needed
Can be primary (master) or secondary (slave) for redundancy

Connections

Built from: DNS TLD Server — TLD points to authoritative server
Builds into: DNS Lookup — authoritative gives the final answer
Related: DNS Records — authoritative servers store these
Related: DNS Zone — the configuration file holding records

Edge Cases & Gotchas

Misconfigured records cause site outages
TTL affects how long resolvers cache the answer
Secondary servers sync from primary (zone transfer)
Anycast used by large providers for global coverage

dns-cache

2026-04-30T00:00:00.000Z

The Problem

DNS lookups are slow when they have to traverse the full hierarchy (root → TLD → authoritative). Without caching, every page visit would require this full lookup, adding significant latency to every connection.

Core Idea

DNS caching stores resolved domain-to-IP mappings at multiple levels (browser, OS, router, ISP) so that subsequent requests for the same domain don’t need to repeat the full lookup process.

How It Works

Each level maintains a cache with TTL-based expiry:

Browser Cache: Chrome/Firefox cache DNS for minutes to hours
OS Cache: Windows/Linux/macOS cache via DNS client service
Router Cache: Home/office routers cache for the local network
ISP Cache: ISP recursive resolvers cache for many users

When a request comes in:

Check each cache in order
If found (cache hit), return the IP immediately
If not found (cache miss), continue to next level
TTL (Time To Live) determines how long entries remain valid

Visual Explanation

Key Properties

TTL (Time To Live) controls cache duration in seconds
Each level can serve the cached result to speed up lookup
Clearing cache forces a fresh lookup (useful for debugging)
Cache poisoning is a security risk—false entries redirect traffic

Connections

Built from: DNS Lookup — caching is part of the lookup process
Related: Recursive DNS — fallback when caches miss
Related: DNS Hierarchy — caches store results from hierarchical queries
Contrasts with: DNS Lookup — lookup is the full process; cache is just one optimization

Edge Cases & Gotchas

Stale cache entries point to old/incorrect IPs after server changes
TTL too long = slow propagation of DNS changes
TTL too short = unnecessary load on DNS servers
ipconfig /flushdns clears Windows DNS cache

dns-hierarchy

2026-04-30T00:00:00.000Z

The Problem

With millions of domains, a single DNS server cannot store all domain-to-IP mappings. Without a hierarchical structure, DNS would be a bottleneck and single point of failure for the entire internet.

Core Idea

DNS uses a hierarchical distributed database structured like a tree: Root servers → TLD servers → Authoritative servers. Each level is responsible for a portion of the namespace, making the system scalable and fault-tolerant.

How It Works

The DNS hierarchy has four levels:

Root Servers (13 logical servers globally): Know locations of TLD servers
- Answer: “Where is .com server?”
TLD Servers (Top-Level Domain): Manage domains under a TLD (.com, .org, .net)
- Answer: “Where is google.com server?”
Authoritative Servers: Know the actual IP for a specific domain
- Answer: “google.com = 142.250.xx.xx”
Recursive Resolvers (ISP): Do the work of querying down the hierarchy

Visual Explanation

Key Properties

Root servers are anycast (same IP, multiple physical locations)
TLD servers handle specific top-level domains
Authoritative servers are authoritative for specific domains
Distributed design prevents single point of failure

Connections

Built from: Recursive DNS — recursive resolvers navigate the hierarchy
Related: DNS Root Server — the top level of the hierarchy
Related: DNS TLD Server — intermediate level for each TLD
Related: DNS Authoritative Server — bottom level with actual records
Builds into: DNS Lookup — hierarchy is queried during DNS resolution

Edge Cases & Gotchas

Root server compromise would be catastrophic (but heavily protected)
Some countries operate their own root servers (not part of ICANN)
DNS hijacking can redirect at any hierarchy level
Anycast allows multiple servers to share the same IP address

dns-lookup

2026-04-30T00:00:00.000Z

The Problem

Humans remember domain names like google.com, but computers need IP addresses like 142.250.183.46 to route packets. Without DNS lookup, every website visit would require knowing its numeric IP address.

Core Idea

DNS lookup is the process of translating a human-readable domain name into a machine-readable IP address. It checks multiple caches and queries a hierarchical chain of DNS servers to find the IP.

How It Works

The lookup follows this priority order:

Browser Cache: Recently visited domains are cached by the browser
OS Cache: Operating system maintains its own DNS cache
Hosts File: Manual mappings (e.g., 127.0.0.1 localhost)
Router Cache: Home/office router may cache DNS responses
ISP DNS Server: Internet provider’s recursive resolver
Recursive Resolution (if not cached):
- Root server: “Where is .com server?”
- TLD server: “Where is google.com server?”
- Authoritative server: “Here is the IP”

Visual Explanation

Key Properties

Caching at every level speeds up repeated lookups
TTL (Time To Live) controls how long entries are cached
Recursive resolvers do the work so clients don’t need to query multiple servers
UDP port 53 is used for standard queries (TCP for large responses)

Connections

Built from: DNS Cache — caching is core to DNS lookup efficiency
Builds into: TCP Handshake — IP from DNS used to establish TCP connection
Related: DNS Hierarchy — the chain of servers queried
Related: ARP Protocol — after DNS gives IP, ARP finds MAC address
Contrasts with: Recursive DNS — DNS lookup includes caching, recursive is the fallback mechanism

Edge Cases & Gotchas

DNS poisoning can redirect users to malicious sites
Cache poisoning attacks exploit trust in DNS responses
Some ISPs hijack failed DNS lookups to show ads
DNS over HTTPS (DoH) encrypts DNS queries for privacy

dns-root-server

2026-04-30T00:00:00.000Z

The Problem

When a DNS resolver doesn’t know where to find a domain, it needs a starting point. Without root servers, there would be no way to begin the DNS resolution process for unknown domains.

Core Idea

DNS root servers are the top of the DNS hierarchy—13 logical servers (labeled A through M) that know the locations of all TLD servers. They are the starting point for all recursive DNS lookups.

How It Works

Query Received: Recursive resolver has a new domain to resolve
Contact Root: Resolver sends query to a root server
Response: Root server returns the TLD server for the domain’s extension
- For google.com, root returns .com TLD server address
Next Step: Resolver now queries the TLD server

Root servers don’t know the final IP—they only know which TLD server to ask next.

Visual Explanation

Key Properties

13 logical servers (A-M), hundreds of physical servers via anycast
Managed by different organizations (ICANN, Verisign, etc.)
Only return TLD server addresses, never final IPs
Root zone file contains all TLD server addresses

Connections

Built from: Recursive DNS — resolvers query root servers
Builds into: DNS TLD Server — root points to TLD servers
Related: DNS Hierarchy — root is the top level
Related: Anycast — root servers use anycast for redundancy

Edge Cases & Gotchas

Root server compromise would break the entire internet
Root servers are heavily DDoS protected
Some countries operate alternative root systems (not ICANN-recognized)
Anycast allows multiple physical servers to share one IP

dns-tld-server

2026-04-30T00:00:00.000Z

The Problem

After the root server tells you where .com is, you need to find the specific server for google.com. TLD servers bridge the gap between root servers and authoritative servers for each domain extension.

Core Idea

TLD (Top-Level Domain) servers manage all domains under a specific extension (.com, .org, .net, etc.). They know the addresses of authoritative servers for each domain registered under that TLD.

How It Works

Query from Resolver: “Where is google.com?”
TLD Lookup: TLD server checks its zone file for google.com
Response: Returns the authoritative name server for that domain
- Example: “google.com is served by ns1.google.com”
Next Step: Resolver queries the authoritative server

TLDs are managed by organizations like Verisign (.com, .net), PIR (.org), etc.

Visual Explanation

Key Properties

One TLD server handles all domains under that extension
Zone files contain authoritative server mappings
Managed by registries (Verisign for .com, etc.)
Respond with NS (Name Server) records, not IP addresses

Connections

Built from: DNS Root Server — root server points to TLD server
Builds into: DNS Authoritative Server — TLD points to authoritative
Related: DNS Hierarchy — TLD is the middle layer
Related: Domain Registration — TLD servers updated via registrars

Edge Cases & Gotchas

TLD server downtime affects all domains under that TLD
Some TLDs have more stringent policies (.gov, .edu)
Country-code TLDs (.uk, .jp) have local governance
New gTLDs (.app, .dev) added regularly

dom-tree

2026-04-30T00:00:00.000Z

The Problem

The browser receives HTML as a text string. To render the page and allow JavaScript to manipulate it, the browser needs a structured representation of the document. Raw HTML text isn’t programmable.

Core Idea

The DOM (Document Object Model) tree is a tree structure built by parsing HTML, where each HTML element becomes a node. It’s the programmatic interface that JavaScript uses to read and modify the page.

How It Works

HTML Received: Browser starts receiving HTML from server
Tokenization: HTML is broken into tokens (<div>, class=, etc.)

Tree Construction: Tokens are assembled into a tree

html
├── head
│   └── title
└── body
    ├── h1
    └── p

Scripts may modify: JavaScript can add/remove nodes

The DOM is live—changes via JavaScript immediately affect the structure.

Visual Explanation

Key Properties

Tree structure mirrors HTML nesting
JavaScript can traverse and modify the DOM
document.getElementById() etc. query the DOM
DOM changes trigger re-rendering (reflow/repaint)

Connections

Built from: Browser Rendering — DOM is step 1
Builds into: Render Tree — DOM + CSSOM combine
Related: HTML Parsing — the process that builds the DOM
Related: CSSOM — CSS counterpart to DOM
Related: JavaScript — manipulates the DOM

Edge Cases & Gotchas

Malformed HTML gets corrected by parser (auto-close tags)
document.write() during parsing can break things
Large DOM = slow rendering and JS operations
DOM is not the same as HTML source (parser fixes errors)

gpu-rendering

2026-04-30T00:00:00.000Z

The Problem

The CPU can draw pixels, but it’s slow for animations, scrolling, and complex visual effects. Without GPU acceleration, web pages would feel sluggish and janky.

Core Idea

GPU rendering uses the Graphics Processing Unit (GPU) to accelerate painting and compositing. GPUs are designed for parallel pixel operations, making scrolling and animations smooth (60+ FPS).

How It Works

CPU paints: Initial painting may happen on CPU
Layers to GPU: Painted layers uploaded to GPU memory
GPU composites: GPU combines layers, applies transforms/opacity
Result: Smooth animations without CPU involvement

GPU excels at:

Transforming layers (translate, scale, rotate)
Adjusting opacity
Compositing multiple layers

Visual Explanation

Key Properties

Parallel processing: GPU has thousands of small cores
Off-main-thread: doesn’t block JavaScript
Used for: transforms, opacity, scrolling, video
Layers must be uploaded to GPU memory (costly first time)

Connections

Built from: Compositing — GPU does the compositing
Related: Painting — CPU may do initial paint
Related: Browser Rendering — GPU rendering is step 6
Contrasts with: CPU Rendering — GPU is faster for graphics

Edge Cases & Gotchas

Uploading layers to GPU has initial cost
GPU memory is limited—too many layers cause issues
Not all CSS properties are GPU-accelerated
transform and opacity are the best for animations

hsts

2026-04-30T00:00:00.000Z

The Problem

Users might accidentally visit the HTTP version of a site instead of HTTPS, exposing them to downgrade attacks. Without HSTS, a man-in-the-middle could strip TLS and force a connection to use insecure HTTP.

Core Idea

HTTP Strict Transport Security (HSTS) is a security policy that tells browsers to always use HTTPS for a domain, never allowing HTTP fallback. It prevents protocol downgrade attacks and cookie hijacking.

How It Works

First Visit: Server sends Strict-Transport-Security header with max-age value
Browser Records: Browser stores the HSTS policy for the specified duration
Subsequent Visits: Browser automatically upgrades HTTP requests to HTTPS
Preload List: Popular sites are hardcoded into browser HSTS preload lists

When a site is in the HSTS list, the browser:

Never attempts HTTP for that domain
Refuses to connect if certificate errors occur (no “proceed anyway” option)

Visual Explanation

Key Properties

Header: Strict-Transport-Security: max-age=31536000; includeSubDomains
Prevents SSL stripping man-in-the-middle attacks
Browsers refuse to bypass certificate errors for HSTS sites
includeSubDomains extends policy to all subdomains

Connections

Built from: HTTPS — HSTS enforces HTTPS usage
Contrasts with: HTTP — HSTS explicitly prevents HTTP fallback
Related: TLS Handshake — HSTS ensures TLS is always used
Related: URL Parsing — HSTS check happens after URL is parsed

Edge Cases & Gotchas

First visit before HSTS is set is still vulnerable (use preload list)
Max-age expiry requires re-visit to refresh policy
includeSubDomains can break subdomains not ready for HTTPS
Cannot be disabled by user even if site has issues (must wait for expiry)

html-parsing

2026-04-30T00:00:00.000Z

The Problem

The browser receives HTML as a text string from the server. To build the DOM and render the page, the browser needs to convert this text into a structured tree. Raw HTML isn’t programmable.

Core Idea

HTML parsing tokenizes HTML text and constructs the DOM tree. The parser is lenient—it corrects malformed HTML automatically (missing closing tags, mismatched tags, etc.).

How It Works

Tokenization: Break HTML into tokens (<div>, class=, text content, </div>)
Tree construction: Assemble tokens into DOM tree
```
<html>
  <body>
    <h1>Hello</h1>
```
↓ DOM: html → body → h1 → “Hello”
Error recovery: Fix common HTML errors automatically

The HTML parser can be paused by <script> tags (unless async/defer).

Visual Explanation

Key Properties

Lenient parsing: fixes errors automatically
Scripts block parsing (unless async/defer)
Incremental parsing: starts before full HTML arrives
Output is the DOM tree

Connections

Builds into: DOM Tree — HTML parsing creates the DOM
Related: Browser Rendering — HTML parsing is step 1
Related: CSS Parsing — parallel but separate process
Contrasts with: XML Parsing — HTML is lenient, XML is strict

Edge Cases & Gotchas

<script> without async/defer blocks parsing
document.write() during parsing can break things
Malformed HTML gets “fixed” (may not match intent)
Table parsing is especially complex

http-headers

2026-04-30T00:00:00.000Z

The Problem

HTTP requests and responses need metadata—who is making the request? What type of content is being sent? How should the response be cached? Without headers, HTTP would only be able to send raw data with no context.

Core Idea

HTTP headers are key-value pairs sent with requests and responses that provide metadata: content type, authentication, caching instructions, cookies, and more. They’re the extension mechanism that lets HTTP evolve without changing the protocol.

How It Works

Headers appear after the request/status line, one per line:

Request Headers:

Host: google.com
User-Agent: Mozilla/5.0
Cookie: session=abc123
Authorization: Bearer token123

Response Headers:

Content-Type: text/html
Cache-Control: max-age=3600
Set-Cookie: session=abc123

Headers are case-insensitive and can appear in any order.

Visual Explanation

Key Properties

Case-insensitive names (Host = host = HOST)
Multiple values possible (e.g., multiple Accept headers)
Standard headers vs custom X- headers (deprecated but still seen)
Headers affect caching, auth, content negotiation, CORS

Connections

Built from: HTTP Request — headers are part of requests
Builds into: HTTP Response — headers are part of responses
Related: Cookies — sent via Cookie/Set-Cookie headers
Related: CORS — controlled by special headers
Related: Cache Control — caching headers

Edge Cases & Gotchas

Large headers can cause issues (proxy limits, 431 error)
Header injection attacks possible with untrusted input
Some headers are hop-by-hop (not forwarded by proxies)
Duplicate headers may be merged or cause errors

http-request

2026-04-30T00:00:00.000Z

The Problem

After establishing a TCP (and possibly TLS) connection, the browser needs to ask the server for a specific resource. Without a structured request format, servers wouldn’t understand what the client wants.

Core Idea

An HTTP request is a structured message from client to server containing: method (GET, POST, etc.), target URL path, headers (cookies, user-agent), and optional body (for POST/PUT).

How It Works

A typical HTTP request looks like:

GET / HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0
Cookie: session=abc123

Request Line: Method + path + HTTP version
Headers: Key-value pairs (Host, User-Agent, Cookie, etc.)
Body: Optional data (for POST requests with form data/JSON)

The server reads this and determines what to return.

Visual Explanation

Key Properties

Methods: GET (fetch), POST (submit), PUT (update), DELETE, etc.
Headers provide metadata (cookies, auth, content-type)
Body present only for methods that send data (POST, PUT)
HTTP/1.1 requires Host header (virtual hosting)

Connections

Built from: TCP Handshake — TCP connection must exist first
Built from: TLS Handshake — for HTTPS, TLS wraps HTTP
Builds into: HTTP Response — server replies to request
Related: HTTP Headers — headers are part of the request
Related: HTTP Methods — GET, POST, PUT, DELETE

Edge Cases & Gotchas

GET requests shouldn’t have a body (though some servers accept it)
Large headers can cause issues (proxy limits)
Missing Host header fails in HTTP/1.1
Request smuggling possible with malformed headers

http-response

2026-04-30T00:00:00.000Z

The Problem

The server has processed the request—now it needs to send back the result. Without a structured response format, the client wouldn’t know if the request succeeded, what data was returned, or how to interpret it.

Core Idea

An HTTP response is the server’s reply containing: status code (200, 404, etc.), headers (content-type, cache-control), and body (HTML, JSON, etc.).

How It Works

A typical HTTP response looks like:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

<html>...</html>

Status Line: HTTP version + status code + reason phrase
Headers: Metadata (content-type, cache settings, cookies)
Body: The actual data (HTML page, JSON, image, etc.)

The browser processes the response based on headers and status code.

Visual Explanation

Key Properties

Status codes: 2xx (success), 3xx (redirect), 4xx (client error), 5xx (server error)
Headers tell browser how to handle the response (content-type, caching)
Body contains the actual resource (HTML, CSS, JS, images)
Responses can be cached based on cache headers

Connections

Built from: HTTP Request — response is the reply to a request
Builds into: Browser Rendering — HTML response gets rendered
Related: HTTP Status Codes — 200, 404, 500, etc.
Related: HTTP Headers — headers control response behavior

Edge Cases & Gotchas

204 No Content has no body (valid response)
301/302 redirects cause browser to make a new request
304 Not Modified uses cached version (saves bandwidth)
Chunked transfer encoding streams large responses

https

2026-04-30T00:00:00.000Z

The Problem

HTTP sends data in plain text—anyone between client and server can read passwords, cookies, and private data. Without encryption, the web would be unsafe for banking, shopping, or any private communication.

Core Idea

HTTPS is HTTP over TLS/SSL encryption. It wraps HTTP inside an encrypted tunnel, protecting data from eavesdropping, tampering, and man-in-the-middle attacks.

How It Works

TCP Handshake: Establish TCP connection (3-way handshake)
TLS Handshake: Negotiate encryption, verify certificate, establish shared key
Encrypted HTTP: All HTTP requests/responses are encrypted with the shared key
Decrypt: Server decrypts request, sends encrypted response

The browser shows a lock icon for HTTPS sites.

Visual Explanation

Key Properties

HTTP + TLS encryption (default port 443)
Protects against eavesdropping, tampering, MITM
Requires SSL/TLS certificate from trusted CA
Slower than HTTP (TLS handshake overhead)

Connections

Built from: HTTP — HTTPS is HTTP over TLS
Built from: TLS Handshake — HTTPS requires TLS
Built from: TCP Handshake — TCP comes first
Related: HSTS — enforces HTTPS usage
Contrasts with: HTTP — HTTP is plain text, HTTPS is encrypted

Edge Cases & Gotchas

Mixed content warnings (HTTPS page loading HTTP resources)
Certificate expiration breaks HTTPS (browser warning)
TLS 1.3 is faster (1-RTT handshake)
Some networks block HTTPS (deep packet inspection)

keyboard-interrupt

2026-04-30T00:00:00.000Z

The Problem

When you press a key, the computer needs to know about it immediately. Without interrupts, the CPU would have to constantly poll (check) the keyboard, wasting cycles.

Core Idea

A keyboard interrupt is a hardware signal sent to the CPU when a key is pressed (or released). The keyboard controller converts the physical keypress into a scan code and triggers an interrupt for the OS to handle.

How It Works

Key press: Physical switch closes in keyboard matrix
Scan code: Keyboard controller generates scan code (e.g., g = code 0x22)
Interrupt: Keyboard raises hardware interrupt (IRQ 1 on x86)
OS handler: CPU jumps to interrupt handler, reads scan code
To application: OS delivers key event to active app (browser)

USB keyboards poll at ~10ms instead of generating interrupts.

Visual Explanation

Key Properties

Scan codes are hardware-specific (not ASCII)
USB polls at ~10ms (not true interrupts)
OS converts scan codes to characters
Interrupt Vector Table maps IRQ to handler

Connections

Builds into: OS Interrupt Handler — OS handles the interrupt
Related: Keyboard Matrix — physical circuit for keys
Related: Scan Code — what keyboard controller generates
Contrasts with: Polling — interrupts vs continuous checking

Edge Cases & Gotchas

Key repeat triggers multiple interrupts (hold key down)
USB keyboards don’t use hardware interrupts (polling)
Some keys have two-byte scan codes (extended keys)
Interrupt storms can overwhelm CPU (too many fast keypresses)

layout

2026-04-30T00:00:00.000Z

The Problem

The render tree has elements with styles, but the browser doesn’t yet know where to put them on the screen. Without layout calculation, everything would overlap at position (0,0).

Core Idea

Layout (also called reflow) calculates the exact position (x,y) and size (width, height) of each element in the render tree. It runs the CSS box model algorithm to determine where pixels go.

How It Works

Start at root: Begin with <html> element
Box model: Calculate width, height, padding, border, margin per element
Flow: Block elements stack vertically, inline elements flow horizontally
Positioning: Apply position, float, flexbox, grid rules
Output: Each element gets (x, y, width, height)

Element: <div>
- x: 100px, y: 50px
- width: 500px, height: 200px

Visual Explanation

Key Properties

Also called “reflow” when triggered again after initial layout
Runs the CSS box model algorithm
Parent elements affect children (containing blocks)
Expensive operation—avoid forced synchronous layout

Connections

Built from: Render Tree — layout takes render tree as input
Builds into: Painting — layout output used for painting
Related: CSS Box Model — defines width/height calculation
Related: Browser Rendering — layout is step 4

Edge Cases & Gotchas

Reading offsetWidth/Height triggers synchronous layout (slow!)
display: none → display: block triggers full reflow
Animations with top/left cause continuous reflow (use transform instead)
Table layout is especially expensive

mac-address

2026-04-30T00:00:00.000Z

The Problem

On a local network (Ethernet, Wi-Fi), devices need unique identifiers to deliver packets to the correct machine. IP addresses can change, but hardware needs a permanent identifier for Layer 2 communication.

Core Idea

A MAC address is a 48-bit hardware identifier (e.g., aa:bb:cc:dd:ee:ff) burned into a network interface card (NIC). It’s used by Ethernet and Wi-Fi to deliver frames to the correct device on the local network.

How It Works

Structure: 6 bytes = 48 bits, typically written as hex pairs (aa:bb:cc:dd:ee:ff)
Uniqueness: First 3 bytes = OUI (Organizationally Unique Identifier, assigned to vendor)
Delivery: Network switches read destination MAC to forward frames
Resolution: ARP maps IP addresses to MAC addresses

MAC addresses operate at Layer 2 (Data Link), while IP addresses operate at Layer 3 (Network).

Visual Explanation

Key Properties

48 bits = 2^48 ≈ 281 trillion possible addresses
Burned into hardware (but can be software-overridden)
Used by switches to learn port-to-MAC mappings
First 3 bytes indicate manufacturer (OUI)

Connections

Built from: Ethernet — MAC addresses are used by Ethernet
Builds into: ARP Protocol — ARP resolves IP to MAC
Related: IP Address — IP is Layer 3; MAC is Layer 2
Related: Network Switch — switches forward based on MAC

Edge Cases & Gotchas

MAC addresses can be spoofed (changed in software)
VPNs hide your real MAC address
Wi-Fi uses MAC filtering for access control (easily bypassed)
Random MAC addresses used by some devices for privacy

os-interrupt-handler

2026-04-30T00:00:00.000Z

The Problem

When hardware interrupts arrive (keyboard, mouse, network), the CPU needs to know what to do. Without an interrupt handler, the interrupt would be ignored or crash the system.

Core Idea

The OS interrupt handler is a function that runs when a hardware interrupt fires. It reads the scan code (for keyboard) or data (for other devices) and dispatches it to the appropriate driver or application.

How It Works

Interrupt fires: Hardware raises IRQ (e.g., IRQ 1 for keyboard)
CPU jumps: Looks up handler in Interrupt Vector Table
Handler runs:
- Read data from device (scan code from keyboard)
- Convert to character (g = scan code 0x22)
- Determine target application (active window = browser)
Deliver event: Send key event to application

Visual Explanation

Key Properties

Interrupt Vector Table maps IRQ numbers to handler functions
Handlers run in kernel mode (privileged)
Must be fast—blocking handler blocks entire system
After handler, CPU resumes previous task

Connections

Built from: Keyboard Interrupt — handler processes keyboard IRQs
Builds into: Browser Autocomplete — key events go to browser
Related: Interrupt Vector Table — lookup table for handlers
Related: Kernel Mode — handlers run with full privileges

Edge Cases & Gotchas

Slow handlers cause system lag (handler blocks everything)
Nested interrupts require careful handling
Missing handler = interrupt ignored (or panic)
Shared IRQs (multiple devices on one IRQ) need demultiplexing

painting

2026-04-30T00:00:00.000Z

The Problem

The browser knows where each element goes (layout), but the screen is still blank. The pixels haven’t been drawn yet. Without painting, the user would see nothing.

Core Idea

Painting (rasterization) converts the layout output into actual pixels. Each element is drawn into layers (bitmaps) that will later be composited together.

How It Works

Input: Layout gives (x, y, width, height) for each element
Fill pixels: Draw text, backgrounds, borders, shadows
Create layers: Elements may be promoted to separate layers
Output: Bitmap layers ready for compositing

Painting is done by the browser’s rendering engine (Blink, Gecko, WebKit).

Visual Explanation

Key Properties

Converts vectors (layout) to rasters (pixels)
Each element can be in a different layer
will-change hints browser to create a layer
CPU-intensive for complex styles (shadows, gradients)

Connections

Built from: Layout — painting uses layout output
Builds into: Compositing — layers get combined
Related: GPU Rendering — can accelerate painting
Related: Browser Rendering — painting is step 5

Edge Cases & Gotchas

Large repaints are expensive (full-screen redraw)
box-shadow and border-radius slow down painting
Layers help—only repaint changed elements
Forced repaint (reading getComputedStyle) is slow

recursive-dns

2026-04-30T00:00:00.000Z

The Problem

Clients (browsers) don’t want to query root, TLD, and authoritative servers themselves—that’s too complex and slow. Recursive DNS resolvers do all the work so clients just get the final answer.

Core Idea

A recursive DNS resolver is a server (usually your ISP’s or a public one like 8.8.8.8) that performs the full DNS lookup on behalf of clients. It queries root → TLD → authoritative servers and returns only the final IP.

How It Works

Client Query: “What is google.com’s IP?”
Cache Check: Resolver checks its cache first
Recursive Lookup (if not cached):
- Query root server → get TLD server
- Query TLD server → get authoritative server
- Query authoritative server → get IP
Cache & Return: Store in cache (per TTL), return IP to client

Public recursive resolvers: Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9).

Visual Explanation

Key Properties

Does the heavy lifting so clients don’t have to
Caches results for many clients (improves performance)
Can be ISP-provided or public (Google, Cloudflare)
Recursive = will query until it gets the final answer

Connections

Built from: DNS Hierarchy — navigates the full hierarchy
Builds into: DNS Lookup — recursive is the fallback when caches miss
Related: DNS Cache — resolvers cache aggressively
Related: Public DNS — Google DNS, Cloudflare, Quad9

Edge Cases & Gotchas

ISP resolvers may hijack failed lookups to show ads
DNS over HTTPS (DoH) encrypts queries to recursive resolver
Some resolvers filter malicious domains (Quad9)
Recursion can be disabled (authoritative-only servers)

render-tree

2026-04-30T00:00:00.000Z

The Problem

The DOM tree has all HTML elements, but not all are visible (e.g., <head>, display: none). The CSSOM has all styles, but not all apply to every element. We need a combined tree of only visible elements with their styles attached.

Core Idea

The render tree combines the DOM tree and CSSOM, keeping only visible elements and attaching their computed styles. This is the tree used for layout and painting—invisible elements are excluded.

How It Works

Start with DOM: Traverse the DOM tree
Check visibility: Skip elements that are display: none or in <head>
Attach styles: For each visible element, compute its styles from CSSOM
Build render tree: New tree with visible elements + computed styles

DOM: <div style="display:none"> (skipped)
DOM: <h1> (included, with styles attached)

Visual Explanation

Key Properties

Only visible elements included (display: none excluded)
Each node has computed styles (inherited + specified + default)
Render tree nodes are called “render objects” or “frames”
Changes to DOM or CSS can trigger render tree reconstruction

Connections

Built from: DOM Tree — provides the structure
Built from: CSSOM — provides the styles
Builds into: Layout — render tree is input to layout
Related: Browser Rendering — render tree is step 3
Contrasts with: DOM Tree — DOM has everything; render tree has only visible

Edge Cases & Gotchas

visibility: hidden elements ARE in render tree (take space, just invisible)
display: none elements are NOT in render tree
Pseudo-elements (::before) are in render tree but not DOM
Rebuilding render tree is expensive (triggers layout + paint)

tcp-packet-drop

2026-04-30T00:00:00.000Z

The Problem

Packets can get lost in the network (router congestion, cable issues, buffer overflow). Without handling packet loss, data transfers would fail randomly and unpredictably.

Core Idea

When a TCP packet is dropped (lost in network), TCP detects the loss (via timeout or duplicate ACKs) and retransmits the packet. This ensures reliable delivery despite unreliable underlying networks.

How It Works

Packet sent: TCP sends packet with sequence number
Packet lost: Router drops packet (congestion, error)
Timeout: Sender doesn’t receive ACK within timeout
Retransmit: Sender resends the packet
Congestion control: TCP reduces sending rate (slow start, congestion avoidance)

TCP treats packet drops as a signal of network congestion.

Visual Explanation

Key Properties

Detected via timeout or 3 duplicate ACKs
Triggers retransmission automatically
Reduces congestion window (slows down sending)
Part of TCP’s reliability guarantees

Connections

Built from: TCP Handshake — TCP connection must exist
Related: Congestion Control — packet drop triggers slowdown
Related: Timeout — mechanism to detect lost packets
Contrasts with: UDP — UDP doesn’t handle packet loss

Edge Cases & Gotchas

Too-short timeout = unnecessary retransmissions
Too-long timeout = slow recovery
Congestion collapse if many TCP flows don’t back off
Some networks drop packets intentionally (policing)

url-parsing

2026-04-30T00:00:00.000Z

The Problem

When you type a URL into a browser, the browser needs to understand what resource you’re requesting and how to reach it. Without parsing, the browser wouldn’t know which protocol to use, which server to contact, or which resource to fetch.

Core Idea

URL parsing is the process of breaking a URL string into its component parts: protocol, domain, path, query parameters, and fragments. This allows the browser to understand the request and route it correctly.

How It Works

Extract Protocol: Browser identifies the scheme (e.g., https://) to determine the protocol
Extract Domain: The hostname (e.g., google.com) is separated for DNS resolution
Extract Path: The resource path (e.g., /search) tells the server which resource to return
Extract Query: Query parameters (e.g., ?q=hello) provide additional request data
Extract Fragment: The fragment (e.g., #section) identifies a specific part of the page

Example: https://google.com/search?q=hello

Protocol: https
Domain: google.com
Path: /search
Query: q=hello

Visual Explanation

Key Properties

Browser first checks if input is a URL or search term
Non-ASCII Unicode characters in hostname get converted/encoded
Missing protocol defaults to https (or http for some browsers)
Malformed URLs trigger error pages or search fallback

Connections

Built from: HTTP — URL specifies which HTTP resource to fetch
Builds into: DNS Lookup — domain from URL needs DNS resolution
Related: HSTS — security check happens after URL parsing
Related: Browser Autocomplete — operates on URL input during typing

Edge Cases & Gotchas

google alone might be treated as search term, not URL
URLs with non-ASCII characters need percent-encoding
Trailing slashes can sometimes change server behavior
Browser address bar “pretty prints” URLs (hides protocol, simplifies display)

URL to Rendering — Full Flow Analysis

2026-04-30T00:00:00.000Z

Framing

This synthesis traces the complete path from pressing a key to seeing pixels on screen. It integrates hardware, OS, network, and browser concepts into one coherent flow.

The Complete Flow

Key Press → OS Interrupt → Browser Input
    ↓
URL Parsing → HSTS Check
    ↓
DNS Lookup (Browser → OS → Router → ISP → Root → TLD → Auth)
    ↓
ARP (IP → MAC)
    ↓
TCP Handshake (SYN → SYN-ACK → ACK)
    ↓
TLS Handshake (ClientHello → ServerHello → Key Exchange)
    ↓
HTTP Request (GET / HTTP/1.1 + Headers)
    ↓
HTTP Response (200 OK + HTML)
    ↓
Browser Rendering:
  HTML Parsing → DOM Tree
  CSS Parsing → CSSOM
  DOM + CSSOM → Render Tree
  Layout (position/size)
  Painting (pixels)
  Compositing (layers)
  GPU Rendering (screen)

Layer-by-Layer Analysis

Layer 1: Hardware (Keyboard)

Keyboard Interrupt: Physical key press → scan code
OS Interrupt Handler: Converts scan code to character
Browser Autocomplete: Local suggestions (no network)

Layer 2: Browser (URL Processing)

URL Parsing: Break into protocol, domain, path
HSTS: Security check—force HTTPS if required

Layer 3: Network (DNS + Connection)

DNS Lookup: Domain → IP resolution
- DNS Cache: Browser → OS → Router → ISP caches
- Recursive DNS: Full hierarchy traversal
- DNS Hierarchy: Root → TLD → Authoritative
ARP Protocol: IP → MAC for local delivery
TCP Handshake: Reliable connection (3-way)
TLS Handshake: Encrypted tunnel (for HTTPS)

Layer 4: Application (HTTP)

HTTP Request: GET/POST + headers + body
HTTP Response: Status + headers + body (HTML)

Layer 5: Rendering (Browser Engine)

HTML Parsing → DOM Tree
CSS Parsing → CSSOM
Render Tree: DOM + CSSOM (visible only)
Layout: Calculate positions and sizes
Painting: Rasterize to pixels
Compositing: Combine layers
GPU Rendering: Hardware acceleration

Key Insights

Each layer is independent: Keyboard works without network; DNS works without HTTP; Rendering works without network
Caching everywhere: DNS caches at 4+ levels; browser caches HTML/CSS/JS
Security is layered: HSTS (app) + TLS (transport) + HTTPS (protocol)
Rendering is parallel: HTML parsing + CSS parsing happen somewhat independently
GPU acceleration: Only the final stages (compositing, paint) use GPU

Contrasts

Aspect	HTTP	HTTPS
Encryption	None	TLS (all data encrypted)
Port	80	443
Security	Vulnerable to MITM	Protects against eavesdropping
Performance	Faster (no handshake)	Slower (TLS handshake overhead)

Connections

This synthesis connects to ALL 29 concept pages in this ingestion, plus existing pages:

DNS (existing, updated)
TLS Handshake (existing, updated)
TCP Handshake (existing, updated)
Socket (existing, updated)
HTTPS (new concept page)

Edge Cases

Packet loss: TCP Packet Drop triggers retransmission
DNS failure: Browser shows error page (DNS_PROBE_FINISHED_NXDOMAIN)
TLS error: Certificate warnings, HSTS blocks override
HTML errors: Parser auto-corrects malformed HTML
CSS errors: Silently ignored (lenient parsing)

/wiki / https

Https — Map of Content

Core Concepts

Mechanisms & How Things Work

Comparisons & Tradeoffs

Suggested Reading Order

arp-protocol

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

browser-autocomplete

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

browser-rendering

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

compositing

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

css-parsing

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

cssom

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

dns-authoritative-server

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

dns-cache

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

dns-hierarchy

The Problem

Core Idea

How It Works

Visual Explanation

Key Properties

Connections

Edge Cases & Gotchas

dns-lookup

The Problem