URL을 입력하면 무슨 일이 일어날까: DNS·TCP·TLS 연결 흐름

URL부터 분해하기

다음 주소를 예로 보겠습니다.

https://example.com:443/tasks?page=1

크게 나누면 다음과 같습니다.

scheme  https
host    example.com
port    443
path    /tasks
query   page=1

scheme은 어떤 방식으로 통신할지 나타냅니다.

host는 어느 서버를 찾을지 결정하는 핵심 정보입니다.

port는 서버 안에서 어떤 서비스에 연결할지 구분하는 번호입니다. 일반적인 HTTPS는 기본 포트 443을 사용하므로 URL에서 생략되는 경우가 많습니다.

path와 query는 서버에 연결한 뒤 어떤 자원이나 데이터를 요청할지 구분할 때 사용됩니다.

이 구분이 중요한 이유는 오류 발생 위치가 서로 다르기 때문입니다.

host를 찾지 못한 문제와 path가 잘못된 404 문제는 같은 문제가 아닙니다.

DNS로 서버 위치 찾기

사람은 example.com 같은 이름을 사용하지만 네트워크 통신에는 실제 서버의 주소를 찾아야 합니다.

DNS는 도메인 이름을 IP 주소와 연결해 주는 시스템입니다.

개념 흐름은 다음처럼 이해하면 됩니다.

example.com
↓
DNS 조회
↓
서버의 IP 주소 확인
↓
해당 서버로 연결 시도

실제 DNS는 브라우저·운영체제·공유기·DNS 리졸버의 캐시 등 여러 단계를 거칠 수 있습니다.

CS 기초에서는 모든 내부 단계를 외우기보다 DNS가 HTTP 이전에 서버 위치를 찾는 역할을 한다는 점이 핵심입니다.

Windows에서는 선택적으로 다음 명령으로 도메인 조회 결과를 확인할 수 있습니다.

nslookup example.com

출력 형식은 환경에 따라 다르지만 DNS 서버 정보와 조회된 주소를 확인할 수 있습니다.

DNS 조회가 실패하면 아직 HTTP 요청을 처리할 서버까지 도달하지 못한 상태일 수 있습니다.

따라서 이때는 404나 500 같은 HTTP Status Code가 없을 수 있습니다.

TCP로 통신 연결 준비하기

서버의 위치를 알았다면 브라우저는 서버와 통신할 연결을 준비합니다.

HTTP/1.1과 HTTP/2를 사용하는 일반적인 웹 연결에서는 TCP가 신뢰할 수 있는 바이트 전달 기반을 제공합니다.

여기서 세부 패킷 구조나 혼잡 제어까지 외울 필요는 없습니다.

프론트엔드 개발자 관점에서는 다음 정도로 이해하면 충분합니다.

DNS
→ 서버 위치 찾기

TCP
→ 서버와 통신 가능한 연결 준비

HTTP
→ 그 연결 위에서 요청과 응답 교환

서버 프로그램이 실행되지 않았거나 해당 포트에서 연결을 받지 않는다면 연결 거부 오류가 날 수 있습니다.

예를 들어 로컬 개발 서버를 실행하지 않고 localhost 주소를 열면 브라우저에서 연결 실패 메시지를 볼 수 있습니다.

이 상황은 서버에 연결한 뒤 받은 404와 다릅니다.

HTTPS와 TLS 이해하기

HTTPS는 HTTP 통신을 TLS로 보호하는 형태로 이해할 수 있습니다.

흐름을 단순화하면 다음과 같습니다.

DNS 조회
↓
서버 연결
↓
TLS 보안 연결 확인
↓
HTTP 요청·응답

TLS는 통신 내용을 암호화하고 연결 대상의 인증서를 확인하는 데 사용됩니다.

브라우저가 인증서를 신뢰할 수 없거나 인증서 이름과 접속 도메인이 맞지 않으면 HTTP 요청 이전에 보안 경고가 발생할 수 있습니다.

이 역시 404·500 같은 HTTP 오류와 구분해야 합니다.

인증서 오류
= 보안 연결 단계 문제

404
= HTTP 요청 이후 서버가 자원을 찾지 못한 문제

HTTP 요청은 그다음에 시작됩니다

1회차와 이번 회차를 연결하면 전체 흐름이 보입니다.

URL 입력
↓
URL 해석
↓
DNS 조회
↓
서버 연결
↓
HTTPS라면 TLS 연결
↓
HTTP 요청
↓
HTTP 응답
↓
브라우저 렌더링

실제 브라우저는 캐시·연결 재사용·HTTP/3 등으로 더 복잡하게 동작할 수 있습니다.

학습 초반에는 이 흐름을 논리적인 진단 순서로 사용하면 됩니다.

모든 페이지 요청마다 DNS·TCP·TLS가 처음부터 새로 실행된다고 외우면 안 됩니다. 브라우저와 운영체제는 다양한 캐시와 연결 재사용을 사용합니다.

오류를 계층별로 구분하기

DNS 문제

대표적인 증상은 도메인 이름을 찾지 못하는 형태입니다.

도메인 이름 해석 실패
↓
서버 주소를 얻지 못함
↓
HTTP 상태 코드 없음

연결 문제

서버 주소는 알지만 해당 서버나 포트에 연결하지 못할 수 있습니다.

DNS 성공
↓
연결 거부 또는 시간 초과
↓
HTTP 응답 없음

TLS 문제

HTTPS 보안 연결을 확립하지 못한 상황입니다.

DNS 성공
↓
연결 단계 진행
↓
인증서 또는 TLS 오류
↓
정상 HTTP 요청까지 진행하지 못할 수 있음

HTTP 문제

서버에 요청을 보내고 응답까지 받은 상황입니다.

404
401
403
500

이 경우에는 Network에서 Status Code를 확인할 수 있습니다.

이 구분만 익혀도 오류 메시지를 보고 무조건 프론트엔드 코드를 수정하는 실수를 줄일 수 있습니다.

간단한 확인 실습

1. URL 구성 분리

현재 접속 중인 페이지 주소를 보고 직접 적어봅니다.

scheme:
host:
port:
path:
query:

port가 URL에 없으면 기본 포트를 사용하는 상황일 수 있습니다.

2. DNS 확인

Windows 터미널에서 다음처럼 실행합니다.

nslookup example.com

여기서 중요한 것은 IP 주소를 외우는 것이 아니라 도메인 이름 조회가 별도 단계라는 사실을 확인하는 것입니다.

3. HTTP 응답 확인

curl을 사용할 수 있는 환경이라면 선택적으로 Header만 확인할 수 있습니다.

curl.exe -I https://example.com

이 명령은 DNS·연결·TLS를 거친 뒤 HTTP 응답 Header를 받는 흐름을 한 번에 체감하는 용도입니다.

환경에 따라 출력은 달라질 수 있습니다.

자주 하는 오해

DNS는 URL 전체를 IP로 바꿉니다

아닙니다.

DNS는 주로 host에 해당하는 도메인 이름을 주소와 연결합니다.

https://example.com/tasks

DNS 대상 핵심
→ example.com

/tasks 같은 path는 DNS가 처리하는 정보가 아닙니다.

404가 나오면 DNS가 잘못된 것입니다

일반적으로 그렇지 않습니다.

404를 받았다면 HTTP 응답을 받을 단계까지 도달한 것입니다.

HTTPS는 HTTP와 완전히 다른 요청 형식입니다

HTTPS는 HTTP 통신을 TLS로 보호하는 방식으로 이해하는 것이 좋습니다.

HTTP 요청이라는 개념은 그대로 유지됩니다.

브라우저에서 한 번 접속할 때마다 DNS와 TCP가 항상 새로 실행됩니다

그렇지 않습니다.

캐시와 연결 재사용 때문에 실제 실행은 최적화될 수 있습니다.

이번 과정에서는 장애 위치를 구분하기 위한 논리적 흐름으로 사용합니다.

독자 질문과 실전 확인

독자 질문

주소가 열리지 않을 때 DNS 문제와 HTTP 404를 어떻게 구분할까요?

웹 개발 사례

개발 서버를 켜지 않은 localhost:5173은 연결이 거부될 수 있지만, 서버가 응답한 /missing 경로의 404는 HTTP 단계까지 도달한 경우입니다. 주소의 host·port·path를 먼저 나눕니다.

직접 확인할 문제

https://example.com:443/tasks?page=1에서 host와 path를 적으세요. Windows에서 nslookup example.com의 조회 결과와 curl.exe -I https://example.com의 HTTP 응답 여부를 각각 확인한다면, 둘은 어떤 단계를 보여 줄까요?

예상 결과와 판단

host는 example.com, path는 /tasks입니다. nslookup은 이름 조회를, curl의 응답 헤더는 연결과 TLS 이후 HTTP 응답을 확인하는 단서입니다. DNS 성공만으로 특정 경로의 HTTP 성공이 보장되지는 않습니다.

검증 범위

이 명령은 독자 실습 안내입니다. 여기서 DNS 결과·인증서·HTTP 상태를 직접 실행해 확인하지 않았으며 네트워크·프록시 환경에 따라 결과가 다릅니다.

다음 학습: 3회차에서는 연결 뒤 요청에 실리는 인증 정보와 브라우저의 출처 정책을 살펴봅니다.

학습 완료 체크리스트

• URL에서 scheme·host·port·path를 구분할 수 있습니다.
• DNS가 HTTP 이전에 필요한 이유를 설명할 수 있습니다.
• TCP 연결과 HTTP 요청을 같은 단계로 보지 않습니다.
• HTTPS에서 TLS가 필요한 이유를 설명할 수 있습니다.
• DNS 실패·연결 실패·TLS 오류·404를 구분할 수 있습니다.
• HTTP 상태 코드가 없을 수 있는 오류가 있다는 것을 이해했습니다.

cs-step-01-http-basics

브라우저
→ HTTP 요청
→ HTTP 응답

URL
→ DNS
→ TCP 연결
→ TLS
→ HTTP 요청
→ HTTP 응답

host:
DNS 확인:
protocol:
HTTPS 여부:
HTTP Status 존재 여부:

HTTP 요청 실패
→ 원인을 모두 HTTP 문제로 생각

1. 도메인 이름을 찾을 수 있는가?
2. 서버에 연결할 수 있는가?
3. HTTPS 보안 연결은 정상인가?
4. HTTP 응답을 실제로 받았는가?

연결 전 오류
와
HTTP 응답 이후 오류
를 분리해서 설명 가능

✓ 1. 브라우저·HTTP 요청/응답
→ 2. DNS·TCP·TLS
○ 3. 쿠키·세션·토큰·CORS
○ 4. CSRF·XSS
○ 5. HTTP 캐시
○ 6. 프로세스·스레드·메모리
○ 7. 통합 장애 진단

cs-step-02-network-path

다음 학습

서버와 정상적으로 통신할 수 있어도 로그인 상태가 유지되지 않거나 브라우저에서 API 응답을 읽지 못하는 문제가 생길 수 있습니다.

다음 글에서는 Cookie·Session·Token의 역할과 Same-Origin Policy·CORS를 연결해서 학습합니다.

다음 글: 쿠키·세션·토큰과 CORS 기초: 로그인 정보와 출처 구분하기