Understanding HTTPS: A Visual Journey Through Web Requests

You Type the URL

Your journey begins when you type "google.com" into your browser's address bar and press Enter. Behind this simple action, a complex series of events begins to unfold.

sequenceDiagram participant User participant Browser User->>Browser: Types "google.com" User->>Browser: Presses Enter Browser->>Browser: Parse URL Browser->>Browser: Check if HTTPS available

Key Point: Modern browsers automatically try HTTPS first for security. If you type "google.com", your browser will attempt "https://google.com" by default.

DNS Lookup: Finding the IP Address

Your browser needs to translate "google.com" into an IP address. It first checks its cache, then your operating system's cache, and finally queries DNS servers.

Key Point: DNS lookups can be cached at multiple levels to speed up future requests. The DNS system is hierarchical, starting from root servers down to authoritative name servers.

TCP Three-Way Handshake

Before any data can be exchanged, your browser establishes a TCP connection with Google's server using a three-way handshake on port 443 (HTTPS).

sequenceDiagram participant Client as Your Browser participant Server as Google Server Client->>Server: SYN (Sequence=100) Note right of Server: Server receives SYN Server->>Client: SYN-ACK (Sequence=300, Ack=101) Note left of Client: Client receives SYN-ACK Client->>Server: ACK (Ack=301) Note over Client,Server: TCP Connection Established

Key Point: The TCP handshake ensures both parties are ready to communicate. SYN stands for synchronize, and ACK stands for acknowledge. This process adds latency but guarantees reliable delivery.

TLS/SSL Handshake: Securing the Connection

Once TCP is established, the TLS handshake begins to create an encrypted channel. This involves certificate verification and cryptographic key exchange.

sequenceDiagram participant C as Your Browser participant S as Google Server C->>S: ClientHello (Supported ciphers, TLS version) S->>C: ServerHello (Chosen cipher, TLS version) S->>C: Certificate (Public key + CA signature) S->>C: ServerHelloDone Note over C: Verify Certificate Note over C: Check CA signature C->>S: ClientKeyExchange (Encrypted pre-master secret) C->>S: ChangeCipherSpec C->>S: Finished (Encrypted) S->>C: ChangeCipherSpec S->>C: Finished (Encrypted) Note over C,S: Encrypted Connection Ready

Key Point: TLS ensures three things: authentication (you're really talking to Google), encryption (no one can read the data), and integrity (data can't be modified). The certificate is signed by a trusted Certificate Authority (CA).

Sending the HTTP Request

With a secure connection established, your browser sends an HTTP GET request over the encrypted TLS channel to request the Google homepage.

graph LR A[HTTP Request] --> B[Request Line] A --> C[Headers] A --> D[Body] B --> B1["GET / HTTP/2"] C --> C1["Host: google.com"] C --> C2["User-Agent: Browser Info"] C --> C3["Accept: text/html"] C --> C4["Accept-Language: en-US"] C --> C5["Accept-Encoding: gzip"] D --> D1["(empty for GET)"] style B1 fill:#4d9fff style C1 fill:#4dff88 style C2 fill:#4dff88 style C3 fill:#4dff88 style C4 fill:#4dff88 style C5 fill:#4dff88

Key Point: HTTP/2 or HTTP/3 is typically used for modern HTTPS connections, providing better performance than HTTP/1.1 through features like multiplexing and header compression.

Server Processing

Google's server receives your request, processes it through various layers including load balancers, web servers, and application logic, then prepares a response.

graph TD A[Request Arrives] --> B[Load Balancer] B --> C[Web Server] C --> D[Application Server] D --> E{Authentication
Needed?} E -->|No| F[Generate Response] E -->|Yes| G[Check Credentials] G --> F F --> H[Prepare HTML] H --> I[Compress Response] I --> J[Add Security Headers] J --> K[Send Response] style K fill:#4dff88

Key Point: Large websites like Google use sophisticated infrastructure with load balancers, caching layers, and distributed servers across the globe to deliver content quickly and reliably.

Receiving the HTTP Response

The server sends back an HTTP response containing the status code, headers, and the actual HTML content of the Google homepage.

graph LR A[HTTP Response] --> B[Status Line] A --> C[Headers] A --> D[Body] B --> B1["HTTP/2 200 OK"] C --> C1["Content-Type: text/html"] C --> C2["Content-Encoding: gzip"] C --> C3["Cache-Control: private"] C --> C4["Set-Cookie: ..."] C --> C5["Strict-Transport-Security"] C --> C6["X-Frame-Options: DENY"] D --> D1["HTML Content"] D --> D2["(Compressed)"] style B1 fill:#4dff88 style C1 fill:#4d9fff style C2 fill:#4d9fff style C3 fill:#4d9fff style C5 fill:#b94dff style C6 fill:#b94dff

Key Point: Status code 200 means success. Security headers like Strict-Transport-Security (HSTS) and X-Frame-Options protect against various attacks. The response is typically compressed to reduce bandwidth.

Browser Parsing and Rendering

Your browser receives the HTML and begins parsing it, constructing the DOM tree, and requesting additional resources like CSS, JavaScript, and images.

graph TD A[Receive HTML] --> B[Parse HTML] B --> C[Build DOM Tree] B --> D[Discover Resources] D --> E[Request CSS] D --> F[Request JavaScript] D --> G[Request Images] E --> H[Parse CSS] H --> I[Build CSSOM] C --> J[Combine DOM + CSSOM] I --> J J --> K[Render Tree] K --> L[Layout/Reflow] L --> M[Paint] M --> N[Composite Layers] F --> O[Execute JavaScript] O --> P{DOM Manipulation?} P -->|Yes| L style N fill:#4dff88

Key Point: The browser rendering pipeline is complex. Each additional resource (CSS, JS, images) requires separate HTTPS requests, which is why performance optimization focuses on minimizing requests and file sizes.

Persistent Connections and Subsequent Requests

Modern HTTP keeps the connection open for multiple requests, avoiding the overhead of establishing new connections for each resource.

sequenceDiagram participant B as Browser participant S as Server Note over B,S: Initial Connection Established B->>S: GET /index.html S->>B: 200 OK (HTML) B->>S: GET /style.css S->>B: 200 OK (CSS) B->>S: GET /script.js S->>B: 200 OK (JavaScript) B->>S: GET /logo.png S->>B: 200 OK (Image) Note over B,S: Connection stays open (Keep-Alive) Note over B,S: HTTP/2 multiplexes all requests

Key Point: HTTP/2 allows multiplexing, meaning multiple requests and responses can be in flight simultaneously over a single TCP connection, dramatically improving performance compared to HTTP/1.1.

Connection Closure

Eventually, when no more data is being exchanged, either the browser or server will close the connection using the TCP termination handshake.

sequenceDiagram participant C as Your Browser participant S as Google Server Note over C,S: No more data to exchange C->>S: FIN (Finish) S->>C: ACK (Acknowledge) S->>C: FIN (Finish) C->>S: ACK (Acknowledge) Note over C,S: Connection Closed

Key Point: The four-way TCP termination ensures both sides agree to close the connection. The connection may be kept alive for a period (typically seconds to minutes) in case the user navigates to another page on the same site.

Summary: The Complete Journey

A single HTTPS request involves numerous steps across multiple protocol layers. Here's a complete overview of the entire process from start to finish.

graph TB A[User Types URL] --> B[DNS Resolution] B --> C[TCP Handshake] C --> D[TLS Handshake] D --> E[HTTP Request] E --> F[Server Processing] F --> G[HTTP Response] G --> H[Browser Rendering] H --> I[Additional Resources] I --> J[Connection Maintained] J --> K[Connection Closed] B -.->|Cache Hit| C D -.->|Session Resumption| E I -.->|Keep-Alive| J style A fill:#4d9fff style K fill:#4dff88 subgraph "Protocol Stack" L[Application: HTTP/HTTPS] M[Transport: TCP] N[Network: IP] O[Link: Ethernet/WiFi] end

Time Breakdown: For a typical HTTPS request to google.com (approximate values, actual times vary based on network conditions, geographic location, and server performance):

DNS Lookup: 20-120ms (if not cached)
TCP Handshake: 28-200ms (depending on distance)
TLS Handshake: 28-200ms
HTTP Request/Response: 20-100ms
Total: 96-620ms for the initial request