base
우리는 매일 브라우저 주소창에
사용자가 브라우저 주소창에
브라우저가 내부적으로 “https://www.google.com”으로 바꿔 간주했다고 하면, 다음과 같이 구성을 쪼갭니다.
<스킴> : https
<인증> : (현재 예시에는 사용자명/암호가 없으므로 생략)
<호스트> : www.google.com
<포트> : (생략됨) → 스킴이 https이므로 기본 443번 포트를 사용
<경로> : (생략됨) → 기본으로 "/"
<쿼리> : (생략됨) → 아무 파라미터도 없으므로 빈 문자열
<프래그먼트(해시)>: (생략) → 빈 문자열세부 설명은 아래와 같습니다.
| 컴포넌트 | 실제 값 | 비고 |
|---|---|---|
| 스킴(Scheme) | https | 사용자가 생략했으나 브라우저가 자동 추가 |
| 인증(Authentication) | — | 예: user:pass@ 형태 (여기서는 없음) |
| 호스트(Hostname) | www.google.com | 도메인 네임 |
| 포트(Port) | 443 (기본값) | HTTPS 기본 포트. 명시하지 않았으므로 자동 지정 |
| 경로(Path) | / | 생략하면 루트 경로(/)로 본다 |
| 쿼리(Query) | — | 예: ?q=abc&lang=ko 형태 (여기서는 없음) |
| 프래그먼트(Hash) | — | 예: #section1 (여기서는 없음) |
URL 표준(RFC 3986)에 따르면, 스킴이 없는 경우, 브라우저는 “도메인으로 보이는 문자열”을 만나면 자동으로 스킴과 기본 포트, 기본 경로를 채워 줍니다. 따라서 사용자가 “www.google.com”만 입력해도, 브라우저는 내부에서 “https://www.google.com/”이라고 간주합니다. 해당 정보를 통해 브라우저는 서버와 연결을 시작하기 위한 준비를 마치고, IP 주소를 찾기 위한 DNS 조회 단계로 넘어갑니다.
도메인을 입력했을 때, 브라우저는 알고 있는 IP가 있는지 순차적으로 확인합니다. 각 계층에서 IP를 찾으면 그 값을 바로 사용하고, 없다면 다음 단계로 넘어갑니다.
위 네 가지 캐시 계층 모두에서 해당 도메인의 IP를 찾지 못했다면, ISP의 리졸버(DNS 서버)는 권한 있는 네임서버를 찾아가는 재귀적 질의를 수행합니다. 이때 거치는 단계는 크게 세 단계로 요약됩니다.
정리하면, 브라우저가 실제 HTTP 요청을 보내기 전, 도메인 → IP 매핑을 위해 여러 단계의 캐시(브라우저 → OS → 라우터 → ISP)를 먼저 살펴봅니다. 어느 계층에서도 캐시가 없다면, ISP의 리졸버가 루트 → TLD → 권한 네임서버 순서로 차례차례 질의하여 최종 IP를 가져온다. 최종 IP는 각 계층별 TTL에 맞춰 저장되며, TTL이 만료되면 다시 같은 과정을 거치게 됩니다.
IP 주소를 획득한 브라우저는 해당 서버와 연결을 맺기 위해 TCP 프로토콜을 사용합니다. TCP 연결은 신뢰성 있는 통신을 보장하기 위해 3단계 핸드셰이크를 수행합니다.
이 과정이 끝나면, 양쪽(클라이언트와 서버)은 데이터 전송을 위한 “TCP 연결 상태”가 되고, 이후 실제 애플리케이션(예: HTTP, FTP 등)이 TCP 세션을 통해 데이터를 주고받을 수 있게 됩니다.
TLS(Transport Layer Security, 옛 이름 SSL)는 TCP 위에서 추가로 “암호화된 통신 채널”을 만드는 단계입니다. 일반적으로 HTTPS( 스킴 )에서는 “먼저 TCP 핸드셰이크를 통해 연결을 맺고, 그 위에서 TLS 핸드셰이크를 수행”하게 됩니다. 주된 목적은 서버(혹은 클라이언트) 인증, 대칭키 교환, 암호화 방식을 협의합니다.
이 과정이 끝나면, TCP 연결 위에 암호화된 (대칭키 기반) 통신 채널이 구축됩니다. 이후 HTTP 요청/응답은 모두 이 채널 안에서 암호화되어 오가게 됩니다.
| TCP 3-way 핸드셰이크 | TLS(SSL)핸드셰이크 | |
|---|---|---|
| 계층 | 전송 계층(OSI 4계층/TCP-IP) | 전송 계층 위의 보안 계층(OSI 5~6 계층 경계) |
| 주요 목적 | 안정적인(연결형) 데이터 전송 경로 구축 | 데이터 암호화, 서버·클라이언트 인증, 세션키 교환 |
| 단계 수 | 3단계 | 일반적으로 6~8단계(사용 암호화 방식에 따라 상이) |
| 핸드셰이크 타이밍 | 애플리케이션 데이터 전송 이전에 반드시 수행됨 | TCP 연결 성립 후, 실제 애플리케이션 데이터(예: HTTP) 전송 전에 수행 |
| 메시지 종류 | SYN, SYN-ACK, ACK | ClientHello, ServerHello, Certificate, KeyExchange, ChangeCipherSpec, Finished 등 |
| 보안 여부 | 평문(암호화되지 않음) | 암호화 매개변수 협상 및 세션키 공유를 통해 이후 메시지 암호화됨 |
“TCP 핸드셰이크”와 “TLS 핸드셰이크”는 서로 다른 목적과 다른 계층에 속하며, 연속적으로 수행됩니다.
TLS 통신이 완료되면, 브라우저는 서버에 HTTP 요청을 보냅니다. 보통 기본 경로에 대한
GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml
Connection: keep-alive이 요청에는 브라우저 종류, 언어 설정, 요청 헤더 정보 등이 포함되며, 이는 서버가 적절한 콘텐츠를 반환하는 데 사용됩니다. 위에서 GET / 이라는 것은 경로(Path)가 /라는 뜻이고, 별도의 쿼리나 해시가 없으므로 기본 페이지 루트를 요청하는 형태입니다.
서버는 요청을 처리한 뒤, HTML 콘텐츠와 함께 응답을 반환합니다. 응답 예시는 다음과 같습니다:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 8912
...
<html>
<head>
<link href="style.css">
<script src="app.js"></script>
</head>
<body>Welcome to Google</body>
</html>HTML 내부에는 추가로 요청해야 할 리소스(JS, CSS, 이미지 등)가 포함되어 있으며, 브라우저는 이를 해석해 다시 요청을 보냅니다.
브라우저는 HTML을 해석하며 만나는 외부 리소스에 대해 다음과 같이 동작합니다:
브라우저는 이 리소스들을 비동기적으로 병렬 처리하며, 사용자에게 빠르게 화면을 보여주는 데 집중합니다.
리소스가 모두 수신되면 브라우저는 렌더링 파이프라인을 실행합니다.
이 렌더링 과정이 완료되면 브라우저는 최종적으로 사용자에게 완성된 웹 페이지를 보여줍니다.
실제 브라우저는 성능 최적화를 위해 다양한 기술을 적용합니다.
이러한 전략은 사용자 경험(UX)을 극적으로 향상시키는 핵심 요소입니다.