www.google.com을 입력하면 일어나는 일 🌐

인터넷 브라우저 주소창에 'www.google.com'을 입력하고 엔터키를 누르는 순간, 눈 깜짝할 사이에 구글 홈페이지가 화면에 나타납니다. 하지만 이 짧은 순간 동안 컴퓨터와 인터넷 세계에서는 어떤 일들이 일어날까요? 마법처럼 느껴지는 이 과정을 함께 살펴봅시다! 🔍

 

1. DNS 조회: 이름을 주소로 바꾸기 🔤➡️🔢

우리가 'www.google.com'이라는 도메인 이름을 입력하면, 브라우저는 이 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환해야 합니다.

DNS 조회 과정 📚

  1. 브라우저 캐시 확인 🧠
    브라우저는 먼저 "최근에 이 주소를 방문한 적이 있나?" 확인합니다.
  2. 운영체제 캐시 확인 💻
    브라우저에 없다면, 컴퓨터의 운영체제에 저장된 DNS 캐시를 확인합니다.
  3. 라우터 캐시 확인 📶
    여기서도 못 찾으면, 집이나 사무실의 라우터에게 물어봅니다.
  4. ISP의 DNS 서버에 질의 🏢
    라우터도 모른다면, 인터넷 서비스 제공업체(KT, SKT, LG U+ 등)의 DNS 서버에 물어봅니다.
  5. 재귀적 DNS 조회 🌍
    ISP의 DNS 서버는 전 세계 DNS 서버들에게 차례로 물어보며 주소를 찾습니다.
  6. DNS 서버: "안녕, .com 서버야? google.com의 주소를 알고 있니?" .com 서버: "나는 정확한 주소는 모르지만, google.com 담당 서버를 알아!" DNS 서버: "안녕, google.com 서버야? www.google.com의 주소를 알려줄래?" google.com 서버: "응! www.google.com의 IP 주소는 142.250.196.68이야."
  7. 답변 반환 및 캐싱
    찾은 IP 주소(예: 142.250.196.68)를 브라우저에게 알려주고, 나중을 위해 캐시에 저장합니다.

 

2. TCP 연결 수립: 안전한 대화 시작하기 🤝

IP 주소를 알게 되면, 브라우저는 해당 서버와 안정적인 연결을 맺어야 합니다.

TCP 3-way 핸드셰이크 🔄

브라우저: "안녕! 나랑 대화할 준비 됐어?" (SYN)
서버: "응, 준비 됐어! 너도 준비 됐니?" (SYN-ACK)
브라우저: "응, 나도 준비 완료! 대화 시작하자!" (ACK)

이 과정은 마치 전화 통화를 시작하기 전에 서로 "여보세요?"라고 확인하는 것과 비슷합니다! 📞

 

3. HTTPS/SSL 핸드셰이크: 비밀 대화 준비하기 🔒

요즘 대부분의 웹사이트는 HTTPS를 사용합니다. 구글도 마찬가지죠! 이 과정에서는 암호화된 안전한 연결을 설정합니다.

SSL/TLS 핸드셰이크 🔐

  1. 암호화 방식 협상
    브라우저와 서버가 "어떤 암호화 방식을 사용할까?"라고 상의합니다.
  2. 인증서 검증
    서버가 "나 진짜 구글이야!"라는 디지털 인증서를 보여주고, 브라우저가 확인합니다.
  3. 비밀키 교환
    안전하게 데이터를 주고받기 위한 암호 키를 만들어 교환합니다.

이 과정은 마치 비밀 대화를 나누기 전에 서로 암호를 정하는 것과 같습니다! 🕵️‍♀️

 

4. HTTP 요청: 정보 요청하기 📝

안전한 연결이 수립되면, 브라우저는 서버에게 웹페이지를 요청합니다.

HTTP 요청 예시 📨

GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8
Connection: keep-alive

이것은 "안녕하세요, 구글! 당신의 메인 페이지를 보여주세요!"라고 말하는 것과 같습니다. 📮

 

5. 서버 처리 및 응답: 정보 받기 📥

구글 서버는 요청을 받고, 적절한 웹페이지를 만들어서 보내줍니다.

HTTP 응답 예시 📬

HTTP/1.1 200 OK
Date: Mon, 07 Apr 2025 12:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 45673
Connection: keep-alive

<!DOCTYPE html>
<html lang="ko">
<head>
    <title>Google</title>
    <!-- 이하 HTML 내용 -->

서버가 "여기 구글 메인 페이지가 있어요!"라고 대답하는 것과 같습니다. 📦

 

6. 브라우저 렌더링: 화면에 그리기 🎨

브라우저는 받은 HTML, CSS, JavaScript 등을 해석하여 화면에 웹페이지를 그립니다.

렌더링 파이프라인 🖌️

  1. HTML 파싱 & DOM 트리 생성 📑
    HTML 코드를 브라우저가 이해하는 구조(DOM)로 변환합니다.
  2. CSS 파싱 & CSSOM 생성 🎭
    CSS 코드를 해석하여 스타일 정보를 구성합니다.
  3. 자바스크립트 실행 ⚙️
    페이지의 동작을 담당하는 자바스크립트 코드가 실행됩니다.
  4. 렌더 트리 구성 🌳
    DOM과 CSSOM을 합쳐서 "무엇을 어떻게 그릴지"를 정합니다.
  5. 레이아웃(리플로우) 📏
    각 요소의 크기와 위치를 계산합니다.
  6. 페인트 🖼️
    실제로 화면에 픽셀을 그립니다.
  7. 컴포지팅
    여러 레이어를 합성하여 최종 화면을 만듭니다.

이 과정은 마치 건축가가 설계도(HTML)와 인테리어 계획(CSS)을 가지고 실제 건물을 짓는 것과 비슷합니다! 🏗️

 

요약: 놀라운 여정의 끝 🏁

브라우저 주소창에 'www.google.com'을 입력하고 엔터키를 누른 후, 0.5초도 안 되는 시간 동안 위의 모든 과정이 일어납니다. 이것이 현대 웹 기술의 놀라운 점이죠!

  1. DNS로 이름을 주소로 변환 🔤➡️🔢
  2. TCP로 안정적인 연결 수립 🤝
  3. HTTPS로 암호화된 보안 연결 구성 🔒
  4. HTTP 요청으로 웹페이지 요청 📝
  5. 서버가 요청을 처리하고 응답 전송 📬
  6. 브라우저가 받은 데이터를 해석하고 렌더링 🎨

인터넷이 마법처럼 느껴질 때가 있지만, 사실은 이렇게 정교하고 복잡한 과정들이 순식간에 이루어지는 것입니다. 기술의 발전과 표준화 덕분에 전 세계 어디서나 동일한 웹페이지를 볼 수 있게 되었죠! 🌍✨

 


 

인터넷 창에 www.google.com를 입력하면 무슨 일이 일어나는지 설명해주세요.

첫번째로 DNS 조회가 일어납니다. 사용자가 www.google.com을 입력하면, 브라우저는 먼저 이 도메인 이름을 IP 주소로 변환해야 합니다. 이 과정을 DNS 조회(DNS Lookup)라고 합니다. 브라우저는 캐시된 DNS 기록을 먼저 확인하고, 없으면 로컬 DNS 서버에 요청하여 www.google.com에 해당하는 IP 주소를 얻습니다.

 

두번째로 TCP 연결 수립입니다. IP 주소가 확인되면, 브라우저는 서버와 TCP 연결을 수립합니다. TCP(Transmission Control Protocol)는 데이터를 신뢰성 있게 전달하기 위한 프로토콜입니다. 이 과정에서 브라우저는 서버와 3-way handshake를 수행합니다. 즉, 브라우저가 SYN 패킷을 보내고, 서버가 SYN-ACK 패킷을 보내며, 다시 브라우저가 ACK 패킷을 보내는 과정입니다.

 

세번째로 HTTP 요청입니다. TCP 연결이 수립되면, 브라우저는 HTTP 또는 HTTPS 요청을 보냅니다. 이 요청은 "GET / HTTP/1.1" 같은 형식으로, 웹 페이지를 요청하는 메시지입니다. 만약 HTTPS를 사용할 경우, 이 단계 이전에 SSL/TLS 핸드셰이크도 수행됩니다. 이 과정에서는 브라우저와 서버가 암호화된 연결을 설정하기 위해 보안 인증서를 교환하고, 암호화 키를 협상합니다.

 

네번째로 서버의 응답을 받습니다. 서버는 요청을 받고, 해당 리소스(HTML, CSS, JavaScript, 이미지 등)를 브라우저에게 응답으로 보냅니다. 이 응답은 HTTP 응답 코드(예: 200 OK)와 함께 전달됩니다.

마지막으로 받은 리소스들을 바탕으로 브라우저 렌더링 파이프라인을 진행합니다. DOM과 CSSOM을 생성하고, 렌더 트리를 구성한 뒤, 레이아웃과 페인트 단계를 통해 웹 페이지가 화면에 표시됩니다.

728x90

1. DNS란? 알기 쉽게 해설

IP 주소 = 인터넷 세계의 '주소'

인터넷에 연결된 모든 기기는 고유한 'IP 주소'를 가지고 있습니다. 이것은 마치 우리가 실제 세계에서 집이나 건물을 찾아갈 때 필요한 주소와 같습니다.

예를 들어, 네이버 서버의 IP 주소는 223.130.195.200과 같은 형태입니다. 구글의 경우 142.250.196.110 같은 숫자로 이루어진 주소를 가집니다.

IP 주소의 단점 → 숫자의 열로 "알기 어렵다"

문제는 이러한 IP 주소가 외우기 어렵다는 것입니다. 여러분이 네이버에 접속하고 싶을 때마다 223.130.195.200이라는 숫자를 입력해야 한다고 상상해 보세요. 상당히 불편하겠죠?

이것이 바로 DNS(Domain Name System)가 필요한 이유입니다. DNS는 우리가 기억하기 쉬운 도메인 이름(예: www.naver.com)을 컴퓨터가 이해할 수 있는 IP 주소로 변환해 주는 시스템입니다.

 

2. DNS의 구조를 더욱 이해하기 쉽습니다.

도메인 이름 구조

도메인 이름은 계층적 구조로 되어 있습니다. 오른쪽에서 왼쪽으로 읽으면서 점(.)으로 구분됩니다.

예를 들어, blog.example.com에서:

  • com은 최상위 도메인(TLD, Top-Level Domain)
  • example은 2차 도메인
  • blog는 서브도메인

이런 계층 구조 덕분에 도메인 이름을 효율적으로 관리할 수 있습니다.

DNS 서버 구조

DNS도 계층적 구조로 이루어져 있습니다:

  1. 루트 DNS 서버: 인터넷의 기본이 되는 13개의 서버 그룹
  2. TLD DNS 서버: .com, .org, .net 등의 최상위 도메인을 관리
  3. 권한 있는 DNS 서버: 특정 도메인(예: example.com)에 대한 정보를 가진 서버
  4. 로컬 DNS 서버: 인터넷 서비스 제공업체(ISP)가 운영하는 서버

DNS 메커니즘 - 이름 확인

웹사이트에 접속할 때 DNS 확인 과정은 다음과 같습니다

  1. 사용자가 브라우저에 www.example.com을 입력합니다.
  2. 컴퓨터는 먼저 로컬 DNS 서버에 "www.example.com의 IP 주소가 뭐야?"라고 물어봅니다.
  3. 로컬 DNS 서버가 모른다면, 루트 DNS 서버에 물어봅니다.
  4. 루트 서버는 ".com 도메인을 관리하는 서버에게 물어봐"라고 알려줍니다.
  5. 로컬 DNS 서버는 .com TLD 서버에 물어봅니다.
  6. TLD 서버는 "example.com을 관리하는 서버에게 물어봐"라고 알려줍니다.
  7. 로컬 DNS 서버는 example.com의 권한 있는 서버에 물어봅니다.
  8. 권한 있는 서버는 "www.example.com의 IP 주소는 93.184.216.34야"라고 알려줍니다.
  9. 로컬 DNS 서버는 이 정보를 사용자의 컴퓨터에 전달합니다.
  10. 브라우저는 이제 해당 IP 주소로 연결하여 웹사이트를 불러옵니다.

이 모든 과정이 1초도 안 되는 시간에 이루어집니다!

 

3. DNS 캐시

DNS 캐시 기능

DNS 쿼리는 시간이 소요되기 때문에, 시스템은 한번 찾은 정보를 기억해 두는 '캐시' 기능을 사용합니다. 이것은 마치 자주 가는 친구의 집 주소를 메모해 두는 것과 같습니다.

DNS 캐시는 여러 레벨에서 이루어집니다

  • 브라우저 캐시
  • 운영 체제 캐시
  • 라우터 캐시
  • ISP의 DNS 서버 캐시

간단한 예시로, 윈도우에서 DNS 캐시를 확인하는 명령어입니다:

ipconfig /displaydns

DNS 캐시 업데이트

DNS 정보는 일정 시간이 지나면 만료됩니다. 이 시간을 TTL(Time To Live)이라고 합니다. TTL이 지나면 시스템은 새로운 DNS 정보를 다시 요청합니다.

만약 수동으로 DNS 캐시를 지우고 싶다면 다음 명령어를 사용할 수 있습니다:

ipconfig /flushdns

DNS 캐시의 단점

DNS 캐시는 빠른 웹 브라우징을 가능하게 하지만, 몇 가지 단점도 있습니다:

  1. 오래된 정보: 웹사이트가 IP 주소를 변경했는데 캐시가 아직 예전 주소를 저장하고 있다면, 연결 문제가 발생할 수 있습니다.
  2. 보안 위험: DNS 스푸핑이나 캐시 포이즈닝 같은 공격은 캐시에 잘못된 정보를 심어 사용자를 가짜 웹사이트로 유도할 수 있습니다.
  3. 디버깅 어려움: 웹 개발자들이 새 서버로 웹사이트를 이전했을 때, 캐시 때문에 사용자들이 여전히 옛 서버에 접속하는 문제가 발생할 수 있습니다.
728x90

'1일 1네트워크 > 제 6장: 애플리케이션 계층 프로토콜' 카테고리의 다른 글

SNMP란?  (0) 2025.04.08
DHCP와 DHCP 릴레이란?  (0) 2025.04.08
MIME와 MIME타입이란?  (0) 2025.04.04
IMAP이란?  (0) 2025.04.03
POP란?  (0) 2025.03.28

  1. URL 파싱 및 HTTP 요청 생성: 브라우저가 URL을 해석하여 HTTP 요청 메시지를 생성하고, 이를 운영체제에 전송 요청합니다.
  2. DNS 룩업: 도메인 이름을 IP 주소로 변환하기 위해 DNS 룩업을 수행합니다. 크롬 같은 브라우저는 먼저 로컬의 hosts 파일과 DNS 캐시를 확인합니다.
  3. 프로토콜 스택을 통한 패킷 처리: 운영체제 내의 프로토콜 스택이 HTTP 요청을 네트워크 패킷으로 변환하고 제어 정보를 추가합니다.
  4. LAN 어댑터를 통한 전송: LAN 어댑터가 패킷을 전기 신호로 변환하여 네트워크로 송출합니다.
  5. 인터넷 접속 경로를 통한 이동: 패킷은 스위칭 허브를 거쳐 ISP를 통해 인터넷으로 전송됩니다.
  6. 인터넷의 핵심부를 통한 전달: 패킷은 여러 고속 라우터를 거쳐 인터넷의 핵심부를 통과하여 목적지로 이동합니다.
  7. 목적지 LAN 도착 및 검사: 패킷은 목적지의 LAN에 도착하며, 방화벽에서 검사 후 필요한 경우 캐시 서버로 이동합니다.
  8. 웹 서버에서의 처리: 웹 서버는 프로토콜 스택을 통해 패킷을 추출, 메시지를 복원하고, 웹 서버 애플리케이션으로 전달합니다.
  9. 응답 데이터 작성 및 회송: 웹 서버 애플리케이션은 요청에 대한 응답 데이터를 작성하여 클라이언트로 다시 보냅니다. 이 응답도 동일한 경로를 통해 전송됩니다.
728x90

+ Recent posts