Packet Flow to a Website.

When you type a website address into your browser, a complex series of events unfolds behind the scenes, involving multiple layers of network protocols. This "packet flow" ensures that the website's content reaches your screen.

Visiting https://example.com (Secure Connection with TCP/TLS)

Visiting a secure website (https://) using the traditional TCP/TLS stack involves several critical steps, with an added layer of encryption to protect your data.

1. DNS Resolution (The Address Book Lookup)
   • Your computer first needs to translate example.com into an IP address (e.g., 93.184.216.34).
   • Your browser queries a DNS (Domain Name System) resolver.
   • The DNS resolver, if it doesn't have the record cached, will recursively query other DNS servers until it finds the authoritative server for example.com, which provides the correct IP address.
   • The IP address is then returned to your computer.
2. TCP Three-Way Handshake (Establishing a Reliable Connection)
   • Once your browser has the IP address, it initiates a TCP (Transmission Control Protocol) connection to the web server on port 443 (the standard port for HTTPS).
   • This involves a "three-way handshake":
     • SYN (Synchronize): Your computer sends a SYN packet to the server, proposing a connection.
     • SYN-ACK (Synchronize-Acknowledge): The server responds with a SYN-ACK packet, acknowledging your request and sending its own synchronization request.
     • ACK (Acknowledge): Your computer sends an ACK packet back, confirming the connection is established.
   • At this point, a reliable, full-duplex connection is ready.
3. TLS/SSL Handshake (Securing the Communication)
   • This is the "S" in HTTPS. Before any application data is sent, a Transport Layer Security (TLS, formerly SSL) handshake occurs:
     • Client Hello: Your browser sends a "Client Hello" message, listing its supported TLS versions, cipher suites, and a random number.
     • Server Hello: The server responds with a "Server Hello," choosing the best TLS version and cipher suite it supports from the client's list, along with its own random number and its digital certificate.
     • Certificate Exchange: Your browser verifies the server's certificate.
     • Key Exchange: The client and server exchange or derive a shared "pre-master secret" using cryptographic methods.
     • Cipher Spec & Finished: Both sides use the pre-master secret to generate symmetric session keys. They then send "Change Cipher Spec" and "Finished" messages, encrypted with these new keys, signaling that all subsequent communication will be encrypted.
4. Encrypted HTTP Request and Response (Application Data Exchange)
   • Now, securely over the established TLS tunnel, your browser sends an HTTP GET request (e.g., GET / HTTP/1.1 or GET / HTTP/2) for the website's content. This request is encrypted.
   • The server processes the request, retrieves the resource, and sends the HTTP response back. This response, containing the website's content, is also encrypted using the session keys.
   • Your browser decrypts the response and renders the webpage.

Visiting http://example.com (Unsecure Connection)

Visiting an unsecure website (http://) follows a similar flow but notably lacks the crucial encryption step.

1. DNS Resolution: Identical to HTTPS, example.com is resolved to an IP address.
2. TCP Three-Way Handshake: Your browser initiates a TCP connection to the web server on port 80 (the standard port for HTTP). The SYN, SYN-ACK, ACK process is the same.
3. Unencrypted HTTP Request and Response (Direct Data Exchange)
   • Crucially, there is no TLS/SSL handshake.
   • Your browser directly sends the HTTP GET request (e.g., GET / HTTP/1.1) to the server in plaintext.
   • The server processes the request and sends the HTTP response, containing the website's content, back to your browser in plaintext.
   • Anyone intercepting these packets can read all the information exchanged without any effort.

The Evolution to QUIC and HTTP/3: A Faster, More Resilient Future

While TCP and TLS have served the internet admirably, they have inherent limitations, especially for modern web applications that require concurrent streams of data. HTTP/2 on top of TCP/TLS tried to address some of these with multiplexing, but it still suffered from "head-of-line blocking" at the TCP layer (a lost packet for one stream would block all other streams on the same TCP connection).

Enter QUIC (Quick UDP Internet Connections) and HTTP/3. QUIC is a new transport layer network protocol designed by Google and standardized by the IETF, running on top of UDP (User Datagram Protocol) rather than TCP.