다다의 개발일지 6v6

🌐 주소창에 URL을 입력했을 때 일어나는 과정! 본문

Computer Science/네트워크

🌐 주소창에 URL을 입력했을 때 일어나는 과정!

dev6v6 2025. 3. 10. 21:02

주소창에 https://www.example.com 를 입력한다. 어떤 일이 일어날지 알아보자.

 

1. URL 해석 및 DNS 조회 (Domain Name System)

  • 사용자가 입력한 https://www.example.com브라우저가 분석함.
  • 브라우저가 example.com의 IP주소를 찾기위해 캐시에서 DNS 기록을 확인한다.
  • DNS 조회 과정 ( 먼저 캐시에서 DNS 기록을 확인하고 없으면 루트 네임서버로 ):
    1. 브라우저 캐시 확인 → 최근 방문한 사이트라면 저장된 IP 사용
    2. 운영체제(OS) 캐시 확인
    3. 로컬 네트워크(라우터) 캐시 확인
    4. ISP(internet service provider로 KT SKT 같은곳을 의미) DNS 서버 캐시 조회
    5. 최종적으로 루트 네임서버를 거쳐 실제 IP 주소 조회
  • DNS 조회 과정 5번 더 자세히 알아보기 (아래 더보기)
더보기

루트 네임서버(Root Name Server)란?

루트 네임서버는 인터넷에서 도메인 이름을 IP 주소로 변환하는 과정에서 최상위 계층에 있는 DNS 서버
인터넷에는 13개(논리적으로 13개, 물리적으로는 더 많음)의 루트 네임서버가 존재하고,
각각은 "A"부터 "M"까지 식별됨.

 

출처: https://m.blog.naver.com/wnrjsxo/221253031733

🌍 DNS 조회 과정 (IP 주소를 찾는 단계)

사용자가 https://www.naver.com을 입력하면, IP 주소를 찾기 위해 DNS 조회가 이루어진다.
DNS 조회는 캐시에 저장된 데이터가 없을 때 발생하며, 아래 단계로 진행됨.

1️⃣ DNS Resolver 조회

  • 먼저, 브라우저 → OS → 로컬 네트워크(라우터) → ISP(인터넷 제공업체)의 DNS Resolver(재귀적 DNS 서버)에서 캐시를 찾음.
  • 만약 캐시에 없다면, 다음 단계로 넘어감.

2️⃣ 루트 네임서버(Root Name Server) 조회

  • ISP의 DNS Resolver가 루트 네임서버에 "naver.com"의 IP 주소를 알고 있냐고 물어봄.
  • 루트 네임서버는 직접 IP를 주지는 않고, TLD(Top-Level Domain) 네임서버(.com .org 등을 담당하는 서버)를 알려줌.

3️⃣ TLD 네임서버 조회

  • 예를 들어, naver.com의 경우 .com을 담당하는 TLD 네임서버에서
    "naver.com"을 어디에서 관리하는지 정보를 반환해줌.

4️⃣ 권한 있는 네임서버(Authoritative Name Server) 조회

  • 마지막으로, TLD 네임서버가 알려준 권한 있는 네임서버(예: Naver가 직접 운영하는 DNS 서버)에서
    "www.naver.com"의 실제 IP 주소를 반환함.

5️⃣ 브라우저가 IP 주소를 받아서 접속

  • 이제 브라우저는 받은 IP 주소를 사용해 www.naver.com 서버와 통신을 시작함.

 

DNS 쿼리의 종류 (추가 개념)

 

DNS 요청(쿼리) 방식에는 3가지가 있다

  1. 재귀 쿼리(Recursive Query) - 일반적
    • 클라이언트(브라우저)가 DNS Resolver에게 최종 IP 주소를 요청.
    • Resolver는 스스로 직접 루트 네임서버 → TLD 네임서버 → 권한 있는 네임서버까지 모두 조회해서 최종 IP를 찾아줌.
    • 사용자 입장에서는 "알아서 다 해주는" 방식.
    • 일반적으로 ISP(인터넷 제공업체)의 DNS Resolver가 이렇게 동작함.
  2. 반복 쿼리(Iterative Query)
    • DNS Resolver는 최종 IP를 직접 찾지 않고, 다음으로 물어볼 서버만 알려줌.
    • 즉, 클라이언트가 루트 네임서버 → TLD 네임서버 → 권한 있는 네임서버까지 직접 조회해야 함.
    • 이 방식은 일반 사용자가 직접 사용할 일은 거의 없음.
  3. 비재귀 쿼리(Non-Recursive Query)
    • 만약 DNS Resolver가 캐시에 해당 IP 주소를 가지고 있다면, 바로 응답해줌.
    • 즉, 이미 알고 있는 정보를 빠르게 반환하는 방식.

🔎 예시:

  • www.example.com → 192.168.1.100 (IP 주소 변환됨)

 

2. TCP 연결 (3-Way Handshake)

브라우저는 서버와 연결을 맺기 위해 TCP(Transmission Control Protocol) 연결을 수행해.
"3-Way Handshake" 과정이 일어남.

  1. SYN (Synchronize)
    • 클라이언트(브라우저) → 서버에 연결 요청
  2. SYN-ACK (Synchronize-Acknowledge)
    • 서버 → 클라이언트의 요청을 승인
  3. ACK (Acknowledge)
    • 클라이언트 → 연결 완료를 확인

결과: 클라이언트(브라우저)와 서버가 연결됨!

 

 

3. TLS 핸드셰이크 (HTTPS인 경우)

만약 https:// 프로토콜을 사용했다면, TLS(SSL) 핸드셰이크 과정이 추가됨.
🔒 TLS(SSL) 핸드셰이크 과정:

  1. 브라우저가 서버에 보안 연결 요청
  2. 서버가 SSL 인증서를 제공 → 브라우저가 신뢰할 수 있는지 확인
  3. 공개 키 & 비밀 키를 이용해 암호화된 연결 생성
  4. 이후 모든 데이터가 암호화되어 전송됨

결과: 브라우저와 서버 간의 보안 연결 설정 완료! 🔐

 

 

4. HTTP 요청 전송

이제 브라우저는 서버에 HTTP 요청을 보냄!
예를 들어, https://www.example.com을 입력하면 아래와 같은 요청이 발생함:

GET / HTTP/1.1
Host: www.example.com
User-Agent: Chrome/120.0
Accept: text/html
  • GET / → 서버의 루트 페이지(/) 요청
  • Host: www.example.com → 어떤 사이트를 요청하는지 명시
  • User-Agent → 사용자의 브라우저 정보 전달

결과: 서버가 요청을 받음!

 

5. 서버에서 응답 (HTTP Response)

  • 서버는 클라이언트의 요청을 받고 처리 후 응답을 반환함.
  • 예를 들어, 웹 페이지를 요청했다면, 서버는 HTML, CSS, JavaScript 파일을 반환할 것임.

예시 응답:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 3421

<html>
  <head>...</head>
  <body>...</body>
</html>

 

HTTP 응답 코드

  • 200 OK → 정상 응답
  • 404 Not Found → 페이지 없음
  • 500 Internal Server Error → 서버 오류

결과: 브라우저가 HTML 데이터를 받음!

 

6. 브라우저 렌더링

이제 브라우저가 응답받은 데이터를 렌더링하는 과정!

  1. HTML 파싱 → DOM(Document Object Model) 생성
  2. CSS 파싱 → 스타일 규칙 적용 (스타일링)
  3. JavaScript 실행 → 동적 기능 처리
  4. 이미지 및 추가 리소스 로드
  5. 최종적으로 화면에 웹 페이지 렌더링!

결과: 사용자가 웹 페이지를 볼 수 있음! 🎉

 

  • 캐시가 있다면? → DNS 캐시 & 브라우저 캐시 활용 (속도 향상)
  • HTTP와 HTTPS 차이? → HTTPS는 TLS 암호화로 더 안전함
  • SPA(Single Page Application)에서는? → 초기 요청 이후 API 호출로 동적 페이지 업데이트