From Typing naver.com to Receiving HTML

Type naver.com into a browser's address bar, press Enter, and Naver's home page appears a moment later.

All the user did was enter ten characters. In that brief interval, however, the browser interpreted the input as a URL, found the server's address, established a secure connection, and requested a document. A single visit that feels instantaneous is the result of several layers working together in sequence.

This article follows what happens from the moment naver.com is entered until the browser receives the first HTML response. What happens afterward—turning that HTML into pixels on the screen—is a story for the next article.

naver.com Is Not Yet a Complete URL

naver.com is a domain name that identifies Naver. The URL a browser uses for an actual request contains additional information: how to access the resource and where that resource is located.

https://www.naver.com/
└─┬─┘   └────┬────┘ └┬┘
scheme       host     path

https is the scheme that specifies the communication method, www.naver.com is the host to contact, and / is the path to request. Even when the scheme and path are omitted from the address bar, the browser fills them in. It first decides whether the input is a search query or an address, then turns it into a URL that can be accessed over HTTPS.

The final URL is not necessarily identical to the original input. Depending on the server's policy, the browser may be redirected from naver.com to www.naver.com or to another path. The important point is that the browser first converts the input into a URL that can be used for a network request.

People Read Domains; Networks Use IP Addresses

Interpreting the URL is not enough to send a request to Naver. naver.com is easy for people to remember, but a network needs an IP address such as 223.130.200.104 to locate the destination.

DNS translates a domain name into an IP address. This is why DNS is often described as the phone book of the internet.

The browser does not immediately start by contacting a distant DNS server. It first checks whether an answer is already available nearby. It looks through places such as the browser and operating system DNS caches and local configuration. If no answer is available, it queries the configured DNS resolver. That resolver may be provided by a home router, an ISP, a corporate network, or a public DNS service selected by the user.

If the resolver does not already have the answer, it follows the domain hierarchy.

Root DNS
  → TLD DNS responsible for .com
    → Authoritative DNS for naver.com
      → IP address for naver.com

The root DNS points to the servers responsible for .com. The .com TLD DNS then points to the authoritative DNS for naver.com. Finally, the authoritative DNS provides the address information for the host. In practice, cached results often mean that every one of these steps does not need to be repeated.

A DNS response may contain records such as A for an IPv4 address, AAAA for an IPv6 address, or CNAME for an alias to another domain. It also includes a TTL that specifies how long the result may be cached. That is one reason a later visit to the same address may require less DNS work.

The resulting IP address should not automatically be assumed to point directly to one of Naver's application servers. Large services may place several layers in front of their applications, including CDNs, proxies, and load balancers, to serve requests from nearby locations or distribute traffic. DNS tells the browser which entry point to contact; it does not reveal the entire infrastructure behind it.

Once the Address Is Known, a Connection Is Established

Now that the destination's IP address is known, the browser needs a channel through which it can exchange data.

HTTP/1.1 and HTTP/2 generally run over TCP. A TCP connection begins with three steps commonly called the three-way handshake.

Browser  ── SYN ───────→  Server
Browser  ←─ SYN + ACK ──  Server
Browser  ── ACK ───────→  Server

The browser requests a connection. The server acknowledges that request while sending its own, and the browser acknowledges it in return. This confirms that both sides are ready to exchange data.

TCP ensures that data arrives in order and retransmits data that is lost. This makes it possible to deliver a web document reliably, but creating a new connection takes time because messages must travel back and forth between browser and server.

Not every request necessarily uses TCP. HTTP/3 uses QUIC, which is implemented over UDP. QUIC combines connection and encryption setup and reduces the chance that a loss affecting one request will hold up other requests. The protocol actually used depends on factors such as browser and server support and information learned during earlier visits.

HTTPS Verifies the Server's Identity

Establishing a connection does not mean the browser can immediately send an HTTP request. When the URL uses the https scheme, the browser and server must first prepare an encrypted connection with TLS.

TLS has three important purposes:

• It verifies that the other party is the server for the requested domain.
• It encrypts the communication so that a third party cannot read it.
• It verifies that the data was not altered in transit.

During the TLS handshake, the browser and server agree on the TLS version and cryptographic algorithms to use. The server presents a certificate containing its identity information and public key. The browser checks the domain, validity period, and chain of signatures leading to a trusted certificate authority.

After validation, both parties securely derive the keys used to encrypt the rest of the communication. Only then can the request path, headers, cookies, and the HTML returned by the server travel in encrypted form.

One IP address may serve several domains. Early in the TLS connection, the browser can use SNI to indicate the host it intends to visit, allowing the server to select the appropriate certificate. After the connection is established, the Host header—or the :authority pseudo-header in HTTP/2 and later—helps the server determine which domain's resource was requested.

The HTTP Request Finally Travels over the Connection

DNS has located the destination, and the TLS connection is ready. The browser can now request Naver's initial document.

In simplified form, the request means something like this:

GET / HTTP/2
Host: www.naver.com
Accept: text/html
Accept-Encoding: gzip, br
User-Agent: ...
Cookie: ...

GET / asks for the resource at the root path. The headers describe information such as the content and compression formats the browser accepts and the browser making the request. If the site was visited before and valid cookies exist, those cookies may be sent as well.

With HTTPS, this request does not travel as readable plain text; it is encrypted through the TLS connection established earlier. Some network information required for delivery, such as the destination IP address, is not hidden in the same way.

The request data is divided into packets that travel across the network. Those packets pass through several devices, including a home router and routers operated by network providers. Rather than knowing the complete journey in advance, each router examines the destination IP address and decides where to forward the packet next.

The Request May Not Go Straight to a Single Server

A large web service may have several intermediary layers in front of it. An edge server near the user may receive the request first, a firewall may filter suspicious traffic, and a load balancer may choose one of several servers to process it.

Browser
  → Internet
    → Edge · Proxy
      → Load Balancer
        → Application Server

This is a general example, not a description of Naver's actual internal request path. Internal service architecture is not visible from the outside and may change with operating conditions.

From the browser's perspective, what matters is that the system receiving the request returns an appropriate response. The server may build a response using information such as the request path and cookies, or it may send a redirect instructing the browser to request another URL.

When a redirect occurs, the browser follows the new URL in the response's Location header. A new host may require another DNS lookup and connection. If the host is the same and the existing connection can be reused, some steps can be skipped.

The Server Responds with HTML

When the request is processed successfully, the server sends an HTTP response consisting of a status code, headers, and a body.

HTTP/2 200 OK
Content-Type: text/html; charset=UTF-8
Content-Encoding: br
Cache-Control: ...

<!doctype html>
<html>...</html>

200 OK means the request was handled successfully, and Content-Type tells the browser that the body is an HTML document. A Content-Encoding value indicates that the body was compressed to reduce its transfer size. Cache-related headers describe when the browser may store and reuse the response.

HTML does not have to arrive as one complete block. The browser can receive data in pieces, decompress it, and begin reading the document as it arrives. When it finds CSS, JavaScript, images, or other resources in the document, it interprets their URLs and prepares additional requests.

The browser is now ready to turn HTML into a screen: building the DOM and CSSOM, calculating layout, and painting pixels. This is the end of the network journey to naver.com and the beginning of a new journey—the rendering pipeline.

Does Every Step Repeat on the Next Visit?

The first visit and a later visit may not follow exactly the same path.

If a DNS response is still valid, the cached IP address can be reused. If an existing TCP or QUIC connection remains open, the browser may avoid creating a new one. TLS session resumption can reduce the cost of preparing another encrypted connection. If the HTML or another resource remains in the HTTP cache and meets the conditions for reuse, the browser may not need to download the full body again.

Browsers use these layers of caching and connection reuse for a simple reason: the fastest network request is the one that does not need to make the full trip.

The Process Hidden behind One Address

The entire journey can be summarized in one sequence:

Address bar input
→ URL interpretation
→ DNS lookup
→ IP address obtained
→ TCP or QUIC connection
→ TLS handshake
→ HTTP request
→ Server processing
→ HTTP response
→ HTML received

From entering naver.com to seeing it appear on screen, the domain name system, DNS, IP, transport protocols, TLS, and HTTP each perform a distinct role. Every layer solves a different problem, yet the result feels like one seamless action to the user.

Perhaps understanding the web begins by breaking this seemingly ordinary moment into separate stages. When a page loads slowly or fails only in a particular environment, examining which stage is delayed or broken can bring us closer to the cause.