The first time you type a URL into your browser and hit Enter, something truly magical happens: your computer, which knows nothing about the internet, suddenly speaks fluent "server" and retrieves the exact webpage you asked for.
Let’s trace that journey, starting with https://www.example.com/path/to/resource.
First, your browser needs to know where www.example.com lives. It doesn’t speak domain names, it speaks IP addresses. This is where DNS (Domain Name System) comes in.
Your computer checks its local DNS cache. If it’s not there, it asks your router. If the router doesn’t have it, it asks your ISP’s DNS resolver.
Let’s say your ISP’s resolver doesn’t have it either. It then queries the root DNS servers (which know where the Top-Level Domain servers are, like .com), then the .com servers (which know where example.com’s authoritative name servers are), and finally, your ISP’s resolver asks example.com’s name server for the IP address of www.example.com.
# Example: dig command to see DNS resolution (run on your machine)
dig www.example.com
; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 300 IN A 93.184.216.34
;; Query time: 50 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Oct 26 10:00:00 UTC 2023
;; MSG SIZE rcvd: 55
In this output, 93.184.216.34 is the IP address for www.example.com. The 300 is the Time To Live (TTL) in seconds, meaning this record is cached for 5 minutes. 192.168.1.1#53 is the DNS server that answered the query.
Now that your browser has the IP address, it needs to establish a connection to the server at 93.184.216.34. This is done using TCP/IP. The browser initiates a TCP handshake.
First, it sends a SYN (synchronize) packet to the server’s IP address on the standard HTTP port (80) or HTTPS port (443). The server, if available, responds with a SYN-ACK (synchronize-acknowledge) packet. Finally, your browser sends an ACK (acknowledge) packet to complete the handshake. This three-way handshake ensures both ends are ready to communicate.
Client -> Server: SYN (Seq=X)
Server -> Client: SYN-ACK (Seq=Y, Ack=X+1)
Client -> Server: ACK (Ack=Y+1)
If the server is down or unreachable, you’ll get a "This site can’t be reached" error, often with an ERR_CONNECTION_TIMED_OUT or ERR_CONNECTION_REFUSED. This means the SYN packet either never got a response (timed out) or the server actively rejected it (refused).
Once the TCP connection is established, if the URL starts with https://, your browser initiates the TLS/SSL handshake to create a secure, encrypted connection. This involves exchanging certificates, agreeing on encryption algorithms, and generating session keys.
After the secure channel is set up (or if it was plain HTTP), your browser sends an HTTP request to the server. This request includes:
- The HTTP method (e.g.,
GETfor retrieving a page,POSTfor submitting data). - The path to the resource (
/path/to/resource). - HTTP headers, which provide additional information like the browser type (
User-Agent), acceptable content types (Accept), and cookies.
GET /path/to/resource HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
The web server (e.g., Apache, Nginx) receives this request. It parses the request, identifies the requested resource (an HTML file, an image, etc.), and processes it. This might involve running server-side code (like PHP, Python, Node.js) to dynamically generate the content.
The server then sends back an HTTP response. This includes:
- A status code (e.g.,
200 OKfor success,404 Not Found,500 Internal Server Error). - HTTP headers, like
Content-Type(e.g.,text/html),Content-Length, and caching directives. - The actual content of the resource (the HTML, CSS, JavaScript, images).
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 12345
Date: Tue, 26 Oct 2023 10:01:00 GMT
Server: Apache/2.4.52 (Ubuntu)
<!DOCTYPE html>
<html>
<head>
<title>Example Domain</title>
</head>
<body>
<h1>Example Domain</h1>
<p>This domain is for use in illustrative examples in documents. You may use this domain in literature without prior coordination or asking for permission.</p>
</body>
</html>
Your browser receives this response. It then parses the HTML, identifies any linked resources (like CSS files, JavaScript files, images), and initiates new HTTP requests for each of them, repeating the connection and request/response cycle for each.
The browser then renders the page, applying CSS for styling, executing JavaScript for interactivity, and displaying the content to you.
This entire process, from typing the URL to seeing the rendered page, happens in milliseconds for most well-connected and fast servers, a testament to the intricate choreography of numerous protocols and systems working in concert.
The next thing you’ll likely encounter is understanding how these individual HTTP requests and responses are optimized, leading you to concepts like HTTP/2, caching strategies, and content delivery networks (CDNs).