웹사이트 주소를 입력하면 무슨 일이 생길까? DNS·TCP·TLS·HTTP 흐름

브라우저 주소창에 https://www.example.com을 입력하고 엔터를 누르면 화면에 페이지가 나타납니다. 그 짧은 순간 사이에 컴퓨터는 여러 단계를 순식간에 거칩니다. 이 DNS·TCP·TLS·HTTP 흐름을 이해하면 “사이트가 안 열린다”는 막연한 문제를 단계별로 나눠 진단할 수 있고, 개발·인프라 면접에서 자주 나오는 “웹사이트 주소를 입력하면 무슨 일이 생기나요?”라는 질문에도 논리적으로 답할 수 있습니다.

1단계 — DNS: 도메인을 IP 주소로

컴퓨터는 www.example.com 같은 이름으로는 통신하지 못합니다. 실제 통신에는 IP 주소가 필요하므로, 가장 먼저 도메인 이름을 IP로 바꾸는 과정이 일어납니다. 이 변환을 담당하는 것이 DNS(Domain Name System)입니다.

브라우저는 먼저 캐시(브라우저 → 운영체제 → 라우터)를 확인하고, 없으면 통신사나 회사의 리졸버(recursive resolver)에게 묻습니다. 리졸버는 루트 → TLD(.com) → 권한 있는 네임서버 순으로 물어 내려가며 최종 IP를 찾아 돌려줍니다. 이 결과는 TTL이라는 시간 동안 캐시되어, 같은 주소를 다시 열 때는 이 과정을 건너뜁니다. 사이트가 열리지 않을 때 nslookup이나 dig로 도메인이 IP로 잘 풀리는지 확인하는 것이 진단의 첫걸음입니다.

2단계 — TCP: 연결을 만드는 3-way Handshake

IP 주소를 알아냈다면, 이제 그 서버와 연결을 만들어야 합니다. 웹은 신뢰성 있는 전송을 위해 TCP를 사용하며, 연결은 3-way handshake라는 세 번의 인사로 시작됩니다.

• SYN: 클라이언트가 “연결하고 싶다”고 요청을 보냅니다.
• SYN-ACK: 서버가 “좋다, 나도 준비됐다”고 응답합니다.
• ACK: 클라이언트가 “확인했다”고 답하며 연결이 완성됩니다.

이 세 단계가 끝나야 실제 데이터를 주고받을 수 있는 통로가 열립니다. HTTP는 보통 80번 포트, HTTPS는 443번 포트로 연결합니다. 방화벽이 해당 포트를 막고 있거나 서버가 그 포트에서 대기(listen)하고 있지 않으면 바로 이 단계에서 연결이 실패합니다.

3단계 — TLS: 통신을 암호화하는 Handshake

주소가 https://로 시작한다면, TCP 연결 직후 TLS handshake가 이어집니다. 이 과정에서 브라우저와 서버는 사용할 암호 방식을 합의하고, 서버는 인증서를 제시해 자신이 진짜임을 증명합니다. 브라우저는 인증서가 신뢰할 수 있는 기관(CA)이 발급한 것인지, 도메인과 일치하는지, 유효기간이 지나지 않았는지를 검증합니다.

검증이 끝나면 이후 통신에 쓸 대칭키를 안전하게 교환하고, 그때부터 오가는 모든 데이터가 암호화됩니다. 브라우저 주소창의 자물쇠 아이콘이 바로 이 TLS가 정상 동작하고 있다는 표시입니다. “인증서 오류”나 “연결이 비공개로 설정되어 있지 않습니다” 경고는 대부분 인증서 만료·도메인 불일치·중간 인증서 누락 같은 이 단계의 문제입니다.

4단계 — HTTP: 데이터를 요청하고 응답받기

암호화된 통로가 준비되면 드디어 HTTP 요청을 보냅니다. 브라우저는 “이 경로의 문서를 달라”는 요청(예: GET /index.html)을 헤더와 함께 전송하고, 서버는 상태 코드와 본문으로 응답합니다. 응답의 첫 줄에 담기는 상태 코드가 결과를 요약해 줍니다.

상태 코드	의미
200 OK	요청 성공, 정상 응답
301 / 302	다른 주소로 이동(리다이렉트)
404 Not Found	요청한 문서가 없음
500 Server Error	서버 내부 오류
503 Unavailable	서버가 일시적으로 응답 불가

브라우저는 받은 HTML을 해석하면서 그 안에 필요한 CSS·JavaScript·이미지를 발견하면, 각각에 대해 지금까지의 과정을 다시(대개 이미 맺어 둔 연결을 재사용해) 반복합니다. 이렇게 모든 리소스를 모아 화면을 완성하면 우리가 보는 페이지가 됩니다.

전체 흐름 한눈에 보기

지금까지의 과정을 한 문장으로 이으면 이렇습니다. DNS로 이름을 IP로 바꾸고 → TCP 3-way handshake로 연결을 만들고 → (HTTPS라면) TLS handshake로 암호화하고 → HTTP로 문서를 요청·응답받아 → 브라우저가 렌더링한다. 사이트 장애를 진단할 때 이 순서대로 “어느 단계에서 끊겼는가”를 짚으면 원인을 빠르게 좁힐 수 있습니다. 도메인이 안 풀리면 DNS, 연결이 안 되면 TCP·방화벽, 자물쇠 경고면 TLS, 페이지는 뜨는데 오류면 HTTP 계층을 의심하면 됩니다.

자주 묻는 질문 (FAQ)

Q. HTTP와 HTTPS의 가장 큰 차이는 무엇인가요?
HTTPS는 HTTP 통신에 TLS 암호화를 더한 것입니다. 중간에서 데이터를 엿보거나 변조하기 어렵게 만들고, 인증서로 서버 신원을 검증합니다. 오늘날 거의 모든 사이트가 HTTPS를 기본으로 사용합니다.

Q. DNS와 TCP 중 무엇이 먼저인가요?
DNS가 먼저입니다. 연결할 서버의 IP 주소를 알아야 TCP 연결을 시작할 수 있기 때문입니다.

Q. HTTP/2, HTTP/3는 이 흐름을 바꾸나요?
기본 개념(이름 해석 → 연결 → 암호화 → 요청·응답)은 같습니다. 다만 HTTP/3는 TCP 대신 QUIC(UDP 기반)을 사용해 연결과 암호화 과정을 더 빠르게 합치는 등, 효율을 개선한 버전입니다.

마무리

웹 요청 흐름은 인터넷을 이해하는 뼈대이자, 장애를 진단하는 지도입니다. DNS·TCP·TLS·HTTP 네 단계의 역할과 순서만 기억해 두면, 브라우저 개발자 도구의 Network 탭이나 curl -v 출력이 훨씬 잘 읽히기 시작합니다. 다음에 사이트가 느리거나 열리지 않을 때, 막연히 새로고침하기보다 어느 단계의 문제인지 짚어 보는 습관을 들여 보세요.

더 읽어보기

• 신입 인프라 엔지니어 공부 순서: 리눅스·네트워크·도커·클라우드 로드맵
• 리눅스 systemd란? 서비스를 등록하고 자동 실행하는 방법
• 프로세스와 스레드 차이: 운영체제 면접에서 자주 묻는 이유

이 글은 학습·정보 제공을 목적으로 작성되었습니다. 실제 네트워크 구성과 프로토콜 버전에 따라 세부 동작은 달라질 수 있습니다.