HTTPS 요청 과정 완전 정복 — `DNS`, `TCP`, `TLS handshake`, 인증서 검증까지

`HTTPS` 과정, 왜 따로 알아야 하나요?

네트워크 계층 글, HTTP 버전 글, TCP vs UDP 글, TCP 4-way handshaking 글까지 읽고 나면 이런 질문이 남습니다.

브라우저 주소창에 https://example.com을 입력하면 실제로 어떤 순서로 일이 진행될까요?
HTTPS는 그냥 "암호화된 HTTP"라고만 보면 충분할까요?
인증서는 정확히 언제 확인하고, 틀리면 어디서 막힐까요?
HTTP/2, HTTP/3 이야기를 하다 보면 ALPN, SNI, TLS handshake가 같이 나오는데 각각 무슨 역할일까요?

핵심은 이것입니다.

HTTPS는 HTTP 메시지 하나만의 문제가 아니라, 이름 해석, 연결 수립, TLS 협상, 인증서 검증, 애플리케이션 프로토콜 선택이 연속해서 이어지는 과정입니다

즉:

먼저 목적지 이름을 IP로 찾고
전송 계층 연결을 만들고
그 위에서 TLS로 서버를 인증하고 키를 합의한 뒤
비로소 HTTP 요청/응답이 안전하게 오갑니다

이 글에서는 HTTPS를 "자물쇠 아이콘이 뜬다" 수준에서 끝내지 않고, 브라우저에서 https:// 요청 하나가 DNS -> TCP -> TLS -> HTTP 순서로 어떻게 흐르는지 를 기준으로 정리하겠습니다.

기준: 이 글은 일반적인 HTTPS 요청, 즉 HTTP/1.1 또는 HTTP/2 over TLS over TCP 흐름을 기준으로 설명합니다. https URI와 기본 흐름은 RFC 9110, TLS 1.3은 RFC 8446, ALPN은 RFC 7301, SNI는 RFC 6066, 브라우저 관점의 TLS 개요와 TTFB는 MDN 문서를 기준으로 설명합니다. HTTP/3는 마지막에 별도 차이점으로 짚습니다.

먼저 가장 짧은 흐름부터 보면

브라우저에서 https://example.com을 여는 과정을 아주 짧게 줄이면 이렇습니다.

단계	핵심 질문	하는 일
1	어디로 갈까?	`DNS`로 도메인을 IP 주소로 해석
2	어떻게 연결할까?	대상 IP의 `443` 포트로 `TCP handshake` 수행
3	누구와 말하는지 믿을 수 있을까?	`TLS handshake`로 서버 인증과 키 합의
4	HTTP 버전은 무엇을 쓸까?	`ALPN`으로 `http/1.1` 또는 `h2` 같은 프로토콜 선택
5	이제 실제로 무엇을 요청할까?	암호화된 채널 위에서 HTTP 요청/응답 교환

가장 짧게 줄이면 이렇습니다.

HTTPS는 HTTP over TLS over TCP입니다
HTTP 요청은 TLS handshake가 끝난 뒤에야 안전하게 보내집니다
인증서 검증에 실패하면 보통 HTTP 요청 자체로 넘어가지 못합니다

Phase 1. 브라우저는 먼저 무엇을 확인할까?

브라우저가 https://example.com을 열 때 가장 먼저 하는 일은 "이 서버와 바로 HTTP부터 얘기하자"가 아닙니다.

먼저 아래 같은 정보를 정리합니다.

스킴이 https인지
호스트가 무엇인지
포트가 명시됐는지

RFC 9110은 https URI의 기본 포트가 443이라고 설명합니다. 즉:

https://example.com

이라면 기본적으로:

호스트: example.com
포트: 443

으로 봅니다.

`HTTPS`는 보통 바로 HTTP부터 보내지 않는다

RFC 9110은 https URI에 접근할 때 클라이언트가 보통:

호스트 이름을 IP로 해석하고
그 주소의 TCP 연결을 만들고
TLS를 성공적으로 시작한 뒤
그 위로 HTTP 요청을 보낸다고 설명합니다

즉, HTTPS의 핵심은:

HTTP 요청보다 먼저 연결 수립과 보안 협상이 선행된다는 점

입니다.

참고: 실제 브라우저는 캐시된 DNS, 기존 연결 재사용, HSTS, 프리커넥트 같은 최적화 때문에 이 흐름을 단축할 수 있습니다. 이 글은 기본 원리를 설명하기 위해 가장 대표적인 흐름으로 단순화합니다.

Phase 2. 먼저 `DNS`로 IP 주소를 찾는다

브라우저는 우선 example.com의 IP 주소를 알아야 합니다.

왜 `DNS`가 먼저일까?

네트워크는 결국 IP 주소 기준으로 목적지를 찾아갑니다. 그래서 도메인 이름만으로는 아직 연결을 열 수 없습니다.

즉:

example.com
  ↓
DNS 조회
  ↓
203.0.113.10 또는 2001:db8::10

처럼 이름을 주소로 바꾸는 과정이 먼저 필요합니다.

`TTFB`에도 이 시간이 들어간다

MDN의 TTFB 설명도, HTTPS 요청의 초기 지연에는:

DNS lookup
TCP handshake
TLS handshake

가 포함될 수 있다고 설명합니다.

즉, 사용자가 "페이지가 느리다"고 느낄 때 원인은:

애플리케이션 처리
DB 조회

만이 아니라, 아직 HTTP 요청을 보내기 전 단계에 있을 수도 있습니다.

Phase 3. `TCP handshake`로 연결을 만든다

대상 IP를 알게 되면, 브라우저는 보통 그 서버의 443 포트로 TCP 연결을 만듭니다.

왜 `TCP`가 먼저일까?

이 글의 기본 흐름은 HTTP/1.1 또는 HTTP/2 기준이므로, TLS는 보통 TCP 위에서 동작합니다.

따라서 순서는:

DNS
  ↓
TCP handshake
  ↓
TLS handshake
  ↓
HTTP request

가 됩니다.

여기서는 아직 암호화되지 않는다

이 시점의 TCP handshake는:

서로 연결 가능한지 확인하고
시퀀스 번호를 맞추고
전송 경로를 여는 절차

에 가깝습니다.

즉, 보안은 아직 TLS 단계 전입니다.

Phase 4. `TLS handshake`에서는 무엇이 오갈까?

이제부터가 HTTPS의 핵심입니다.

TCP 연결이 만들어지면, 그 위에서 TLS handshake가 시작됩니다.

`TLS`가 제공하는 것은 무엇일까?

MDN은 TLS가 연결을 세 가지 측면에서 보호한다고 설명합니다.

기밀성: 중간에서 내용을 읽기 어렵게 함
무결성: 중간에서 몰래 바꾸기 어렵게 함
인증: 적어도 서버가 주장하는 주체인지 확인할 수 있게 함

즉, HTTPS는 단순히 "암호화"만이 아니라 서버 인증과 무결성 보호까지 포함합니다.

`TLS 1.3` 기준으로 아주 단순화하면

실제 메시지는 더 복잡하지만, 대표 흐름을 줄이면 대체로 이렇게 볼 수 있습니다.

Client -> Server : ClientHello
Client <- Server : ServerHello
Client <- Server : EncryptedExtensions
Client <- Server : Certificate
Client <- Server : CertificateVerify
Client <- Server : Finished
Client -> Server : Finished

이걸 역할별로 보면:

클라이언트는 지원 가능한 암호 스위트, 키 교환 정보 등을 제안하고
서버는 그중 사용할 매개변수를 고르고
서버는 EncryptedExtensions로 ALPN 결과 같은 추가 협상 정보를 전달하며
서버 인증서를 보내며
자신이 그 인증서의 개인키를 실제로 가지고 있음을 증명하고
양쪽이 이후 사용할 키로 보호된 Finished를 교환합니다

참고: 실제 TLS 1.3에는 CertificateRequest처럼 상황에 따라 추가되는 메시지도 있고, PSK나 0-RTT처럼 다른 흐름도 있습니다. 여기서는 일반적인 브라우저의 서버 인증 기반 HTTPS 흐름만 단순화해 설명합니다.

여기서 `SNI`와 `ALPN`도 같이 등장한다

ClientHello에는 실무적으로 중요한 정보가 더 들어갑니다.

`SNI`

RFC 6066의 server_name 확장은, 클라이언트가 어느 호스트 이름으로 접속하려는지 서버에 알려 주기 위한 장치입니다.

이게 왜 중요할까요?

같은 IP 주소 하나에 여러 도메인이 올라가 있을 수 있고
서버는 어떤 인증서를 보여줘야 할지 알아야 하기 때문입니다

즉, SNI는:

"나는 지금 example.com에 접속하려는 중입니다"

를 TLS handshake 초반에 알려 주는 역할에 가깝습니다.

`ALPN`

RFC 7301의 ALPN은 이 TLS 연결 위에서 어떤 애플리케이션 프로토콜을 쓸지 협상하는 확장입니다.

예를 들어 클라이언트는:

http/1.1
h2

같은 후보를 제안할 수 있고, 서버는 그중 하나를 고릅니다.

즉, 브라우저는 TLS handshake 안에서:

서버가 어떤 인증서를 제시해야 하는지(SNI)
HTTP/1.1을 쓸지 HTTP/2를 쓸지(ALPN)

까지 같이 정할 수 있습니다.

Phase 5. 인증서는 정확히 언제, 어떻게 검증할까?

많은 분이 HTTPS를 "자물쇠 아이콘이 있으면 끝"처럼 느끼지만, 실제로는 이 단계가 매우 중요합니다.

브라우저는 인증서를 그냥 보기만 하지 않는다

서버가 인증서를 보냈다고 해서 무조건 믿는 것은 아닙니다.

브라우저는 보통 아래를 확인합니다.

이 인증서 체인이 신뢰할 수 있는 루트까지 이어지는가
현재 시간 기준으로 유효 기간이 맞는가
접속하려는 호스트 이름과 인증서 이름이 맞는가
서명이 올바른가

즉, Certificate를 받는 순간 중요한 것은:

"인증서가 왔다"가 아니라 "이 인증서를 브라우저가 신뢰해도 되는가"

입니다.

여기서 틀리면 어떻게 될까?

이 검증이 실패하면 브라우저는 보통:

경고 페이지를 띄우거나
연결을 중단하고
실제 HTTP 요청 전송으로 넘어가지 않습니다

즉, HTTPS 오류는 많은 경우 애플리케이션이 응답을 못 줘서가 아니라, TLS handshake 단계에서 신뢰를 만들지 못해서 발생합니다.

Phase 6. `TLS handshake`가 끝나면 그다음은 무엇일까?

TLS handshake가 성공하면 이제 양쪽은:

서버를 인증했고
암호화 키를 합의했고
이후 데이터를 보호할 준비가 끝났습니다

그다음에야 비로소 HTTP 요청이 오갑니다.

이때부터 HTTP는 암호화된 채널 위에서 흐른다

즉, 브라우저는 이제:

GET / HTTP/1.1
Host: example.com

같은 요청을 보내지만, 이 내용이 네트워크 위에서 평문 HTTP처럼 그대로 노출되는 것은 아닙니다.

실제로는 TLS가 보호하는 기록 계층 위로 실려서 전달됩니다.

응답도 같은 방식으로 보호된다

서버 응답도 마찬가지입니다.

상태 코드
헤더
본문

모두 TLS로 보호된 채널 위에서 오갑니다.

즉, HTTPS는 "요청만 암호화"가 아니라 요청과 응답 전체를 보호하는 연결입니다.

Phase 7. 연결은 요청 하나마다 새로 만들까?

여기서도 자주 오해가 생깁니다.

항상 매 요청마다 처음부터 다시 하지는 않는다

실무에서는 다음이 매우 중요합니다.

기존 TCP 연결 재사용
기존 TLS 세션 재개
HTTP/2의 연결 재사용과 다중화

즉, 첫 요청은:

DNS -> TCP -> TLS -> HTTP

가 길게 보이지만, 이후 요청은:

이미 열린 연결을 재사용하거나
HTTP/2 하나의 연결 안에서 여러 요청을 보내거나
세션 재개로 TLS 비용을 줄일 수 있습니다

그래서 실제 체감 성능은 첫 연결 비용과 이후 재사용 전략에 크게 좌우됩니다.

Phase 8. 그럼 `HTTP/3`에서는 무엇이 달라질까?

HTTP 버전 글과 연결되는 부분입니다.

이 글의 기본 흐름은 HTTP over TLS over TCP입니다. 하지만 HTTP/3는 예외가 있습니다.

`HTTP/3`는 `TCP` 대신 `QUIC` 위에서 동작한다

즉:

HTTP/1.1, HTTP/2: 보통 TCP -> TLS -> HTTP
HTTP/3: QUIC 위에서 동작하고, TLS 1.3 handshake가 그 안에 통합됩니다

그래서 HTTP/3에서는 이 글에서 설명한 "먼저 TCP handshake, 그다음 TLS handshake" 흐름이 그대로 적용되지는 않습니다.

하지만 핵심은 같습니다.

상대를 인증하고
암호화 키를 합의하고
그 위에서 HTTP를 보낸다

즉, 보안 협상과 애플리케이션 프로토콜 협상이 먼저 온다는 큰 원리는 유지됩니다.

핵심만 다시 정리하면

마지막으로 HTTPS 과정을 한 번 더 정리하면 이렇게 볼 수 있습니다.

단계	핵심 포인트
`DNS`	도메인을 IP 주소로 바꿔야 실제 연결을 열 수 있습니다
`TCP handshake`	`HTTP/1.1`/`HTTP/2` 기준으로 전송 경로를 먼저 엽니다
`TLS handshake`	서버 인증, 키 합의, 보호 채널 생성이 여기서 일어납니다
인증서 검증	신뢰 체인, 유효 기간, 호스트 이름 일치를 확인합니다
`ALPN`	`http/1.1`과 `h2` 같은 상위 프로토콜을 고릅니다
HTTP 요청/응답	모든 HTTP 메시지는 보호된 채널 위에서 오갑니다

핵심 포인트는 다섯 가지입니다.

HTTPS는 단순히 "암호화된 HTTP"가 아니라, DNS, TCP, TLS, HTTP가 이어지는 전체 연결 과정입니다.
https URI에 접근할 때는 보통 이름 해석 -> TCP 연결 -> TLS 성공 -> HTTP 요청 순서로 진행됩니다.
TLS handshake에서는 서버 인증, 키 합의, SNI, ALPN 같은 중요한 협상이 함께 일어납니다.
인증서 검증에 실패하면 보통 HTTP 요청 자체로 넘어가지 못합니다.
HTTP/3는 전송 기반이 다르지만, 보안 협상과 프로토콜 협상이 먼저 온다는 큰 원리는 같습니다.

결국 HTTPS 과정은 "자물쇠 아이콘이 뜬다" 수준의 이야기가 아니라, 브라우저가 누구와 연결하는지 확인하고, 어떤 프로토콜로 말할지 합의한 뒤, 그 위에서 HTTP를 안전하게 흘리게 만드는 단계적 절차에 가깝습니다.

HTTPS 과정, 왜 따로 알아야 하나요?

먼저 가장 짧은 흐름부터 보면

Phase 1. 브라우저는 먼저 무엇을 확인할까?

HTTPS는 보통 바로 HTTP부터 보내지 않는다

Phase 2. 먼저 DNS로 IP 주소를 찾는다

왜 DNS가 먼저일까?

TTFB에도 이 시간이 들어간다

Phase 3. TCP handshake로 연결을 만든다

왜 TCP가 먼저일까?