What Happens When You Open a Website? TCP, TLS, and HTTP Explained

You type a website address, press Enter, and a page appears. Behind that simple action, your browser and a server have to find each other, exchange data, and agree on what that data means.

Three names often appear in explanations of this process: TCP, TLS, and HTTP. They handle different parts of the same conversation. Once you separate their jobs, the whole process becomes much easier to understand.

Imagine sending an order to a shop by courier. You need a delivery service, a way to protect your message, and an order form the shop understands.

TCP is the delivery service. TLS adds protection and an identity check. HTTP is the format of the order and the reply.

The analogy is only a starting point. Let’s look at what each one actually does.

TCP stands for Transmission Control Protocol. It gives applications a reliable, ordered stream of bytes. Bytes are the small units that make up digital data.

Data travels across networks in small pieces. Some can be lost or arrive out of order. TCP tracks what has arrived, retransmits missing data, and presents the bytes to the receiving application in the correct order. A connection can still fail if the network stops working.

Before exchanging data on a normal new TCP connection, the two ends perform a three-way handshake:

This exchange synchronizes information used to track the data. It resembles confirming that both ends are ready for a delivery. TCP itself does not encrypt the contents.

TLS stands for Transport Layer Security. For a typical HTTPS connection over TCP, TLS adds a secure channel on top of that transport.

In our shop analogy, this is where you check the shop’s identity and arrange protected envelopes for the messages.

During a typical TLS handshake, the browser and server agree on cryptographic settings. The server presents a digital certificate, which the browser checks against the requested domain and trusted certificate authorities. The server also proves it has the corresponding private key.

They establish secret keys to protect the conversation. Modern key agreement lets them derive these keys without sending the secret keys openly across the network.

TLS provides encryption, so someone observing the network cannot simply read the protected content, and integrity checks, so tampering can be detected.

One important limit: a valid certificate does not prove that a shop is honest or that its content is safe. A scam website can use HTTPS too.

HTTP stands for Hypertext Transfer Protocol. It defines how a browser requests a resource and how a server responds.

The browser might send a GET request, meaning “please send me this page.” The response contains a status code, headers describing the response, and often a body containing the requested content.

For example, 200 means the request succeeded. A 404 response means the requested resource was not found.

In our analogy, HTTP is the order form and the shop’s reply. TCP carries the bytes, and TLS protects them.

HTTPS is HTTP protected with TLS. The browser is still making HTTP requests; their contents travel through a secure channel.

For a fresh HTTPS connection using HTTP/1.1 or HTTP/2, the simplified sequence looks like this:

The browser can reuse an existing connection for more requests. It does not need a new TCP and TLS handshake for every image or click.

HTTP/3 uses QUIC over UDP instead of TCP. QUIC provides reliable streams and integrates TLS 1.3 into its connection setup. So the exact TCP-then-TLS sequence above does not apply to every website connection.

The core idea remains useful: transport moves the data, security protects it, and HTTP gives the conversation its meaning.