개발/기타

브라우저에 google.com을 입력하면 어떤 일이 일어날까? - 1

Ski_ 2025. 4. 14. 00:30

브라우저에 google.com을 입력하면 어떤 일이 일어나는지에 대해 작성해보겠다.

 

아래와 같은 순서로 작성할 예정이다.

1. 브라우저에 "google.com"을 입력하면 어떤 일이 일어날까?

     1) 캐시 검사

     2) DNS 조회

     3) TCP (및 TLS) 연결 설정

     4) HTTP 요청 및 응답

     5) 브라우저의 페이지 렌더링

1. 브라우저에 "google.com"을 입력하면 일어나는 일

아래와 같은 순서로 동작한다.

1. 캐시 검사

2.  DNS 조회

3. TCP (및 TLS) 연결 설정

4. HTTP 요청 및 응답

5. 브라우저의 페이지 렌더링

1) 캐시 검사 및 DNS 조회

도메인 조회 시 캐시가 존재하는지, 존재한다면 TTL이 만료되었는지 확인하고 필요한 경우 DNS 서버에 요청한다.

 

모든 사이트는 DNS 레코드에 TTL을 설정할 수 있고,  브라우저, OS 등은 이전에 수행한 DNS 조회 결과인 IP 주소를 일정 기간 동안 저장한다.

 

DNS에 변경사항이 있을 때 아래와 같은 내용을 봤던 경험이 있을 것 이다.

"DNS 변경 사항은 몇 시간 이내에 전파되지만 모든 내용이 인터넷 전체에 전파되기까지는 최대 48시간이 소요될 수 있습니다"

이 이유중 하나가 캐시를 사용하기 때문이다. 따라서 DNS에 변경사항이 생겼을 때 전파 시간은 TTL에 어느정도 의존적이다.

 

브라우저, OS, Router, ISP에서 DNS 값들을 캐시하고 있으며  DNS 레코드의 TTL길이에 따라 장단점이 있다.

 

짧은 TTL

  • 장점
    • 빠른 변경 반영 : 레코드 값이 변경되었을 때 새 정보를 빠르게 받아올 수 있음
    • 유연성: 동적 환경(예: 트래픽 분산, 장애 조치, 클라우드 환경)에서 빠른 전환이 필요한 경우 유리
  • 단점
    • 높은 부하: 캐시가 자주 갱신되면, DNS 쿼리 요청의 빈도 증가로 권한 있는 DNS 서버나 재귀적 DNS 서버에 부하가 증가
    • 응답 성능 저하: 캐시가 자주 만료되면, DNS 조회를 위한 추가 네트워크 요청이 발생으로 응답 시간이 길어짐

 

긴 TTL

  • 장점
    • 부하 감소: 캐시에 오래 남아 있기 때문에, 동일한 레코드에 대해 반복적인 DNS 조회가 줄어들어 전반적인 네트워크 트래픽 감소
    • 빠른 응답: 이미 캐시된 정보가 오랫동안 유지되므로 사용자 입장에서는 빠른 응답을 받을 수 있음
  • 단점
    • 변경 반영 지연: 레코드 정보가 변경되었음에도 불구하고, 캐시된 정보가 만료되기 전까지는 변경 사항이 반영되지 않음
    • 유연성 부족:자주 변경되는 동적 서비스에서는 긴 TTL이 오히려 문제가 될 수 있음

 

이러한 장단점이 있기에 DNS 레코드의 TTL은 아래와 같은 선택 기준을 가진다.

  • 정적 또는 거의 변경되지 않는 리소스
    회사 로고 이미지, 정적 웹페이지 등은 긴 TTL을 설정하면 서버 부하를 줄이고 안정적인 응답을 유지 가능
  • 동적 환경 및 빠른 장애 복구가 요구되는 리소스
    트래픽 분산, 로드 밸런싱, 또는 클라우드 기반 서비스의 경우 짧은 TTL로 설정하면, 변경 사항이 빠르게 반영되어 유연한 대응이 가능

개인적인 궁금증으로 DNS 레코드 TTL의 최대값을 찾아봤는데 약 136년 이라고 한다.

2) DNS 조회

만약 위 과정에서 캐시가 없다면 DNS를 통해 IP를 조회해야 한다.

먼저 DNS의 구성 요소는 아래와 같다.

 

1. DNS 클라이언트(Stub Resolver)

- 사용자 PC나 모바일 기기 등의 운영체제에 내장되어 있는 DNS 클라이언트

 

2. 재귀적 DNS 리졸버(Recursive Resolver)

- 클라이언트의 요청을 받아 DNS 계층 구조를 따라 최종 답변을 찾는 서버

 

3. 루트 네임 서버(Root Name Servers)

- DNS 최상위 계층에 위치한 서버. 전 세계에 분산되어 있으며, 전반적인 DNS 질의의 진입점 역할

 

4. 최상위 도메인(TLD) 네임 서버

- 루트 서버가 반환한 정보를 바탕으로, 해당 TLD(예: .com, .org, .net 등)에 대해 관리하는 서버

 

5. 권한 있는(Authoritative) 네임 서버

- 특정 도메인(zone)에 대한 정식 DNS 레코드를 보유하고 있는 서버

 

6. DNS 레코드

- DNS 레코드는 각 도메인에 대해 정의된 데이터 항목으로, 도메인과 관련된 실제 정보를 가짐

위의 DNS 질의는 재귀 질의와 반복 질의가 있으며 질의 방법은 아래와 같다.

클라이언트는 최종 답변을 원하므로 재귀 질의를 통해 로컬 DNS 리졸버에 요청하고, 리졸버는 내부적으로 반복 질의를 통해 최정 결과를 찾아 클라이언트에게 반환한다.

 

그렇다면 재귀 질의와 반복 질의에 대해 알아보자

 

  • 재귀 질의(Recursive Query)
    • 개념
      • 클라이언트(ex. 웹 브라우저)는 자신의 로컬 DNS 리졸버(보통 ISP나 사내 DNS 서버)에 재귀적 질의를 보냄
      • 재귀 질의란 클라이언트가 “문제의 전체 해결을 대신해달라”는 요청으로, 로컬 리졸버가 최종 결과(ex. 도메인 IP 주소)를 찾아서 클라이언트에 반환하는 방식
      • 클라이언트는 중간 과정을 신경 쓰지 않고 최종 결과를 받기를 기대
    • 사용 상황
      • 클라이언트 → 재귀 리졸버
        • 일반적으로 클라이언트는 재귀 질의를 DNS 리졸버에 보냄
        • 이 리졸버는 내부적으로 반복 질의를 사용해 루트 서버, TLD 서버, 그리고 권한 있는 네임 서버에 차례대로 질의를 보내 최종적인 답을 찾아냄
      • 최종 답변 제공
        • 클라이언트는 DNS 리졸버로부터 최종 결과(IP 주소 or 오류 메시지)를 받음
        • 이를 통해 도메인 이름 해석
    • 장점
      • 클라이언트 입장에서 단순함
      • 복잡한 이름 해석 과정을 모두 DNS 리졸버가 처리해 주므로 설정이나 구현 부담이 줄어듬
      • 복수의 DNS 계층을 통해 캐싱된 데이터를 활용할 수 있어 전체 응답 시간 단축
  • 반복 질의(Iterative Query)
    • 개념
      • 질의를 받은 서버가 최종 답변을 가지고 있지 않을 경우, “나 대신 이 서버에 물어봐”라는 식으로 다음 대상 서버의 정보(Referral) 제공 방식
      • 질의를 받은 서버는 클라이언트에게 바로 최종 결과를 주지 않고, 답변을 위해 필요한 다음 정보를 안내
    • 사용 상황
      • 재귀 리졸버 내부에서 사용
        • 재귀적 DNS 리졸버는 클라이언트의 재귀 질의를 처리할 때, 루트 네임 서버, TLD 네임 서버, 권한 있는 네임 서버와 반복 질의 수행
        • 예를 들어, 루트 네임 서버는 해당 도메인의 TLD 네임 서버에 대한 정보를 반환하고, TLD 네임 서버는 권한 있는 네임 서버의 정보를 제공하는 식입니다.
      • 서버 간 통신
        • DNS의 상위 계층(루트 서버나 TLD 서버 등)은 자신들이 최종 답변을 가지고 있지 않기 때문에, 반복 질의를 통해 다음 단계의 서버 정보를 안내
      • 특징
        • 서버들은 요청받은 도메인의 전체 정보를 캐싱하고 있지 않으므로, “내가 알고 있는 최선의 정보를 알려줄게” 정도로 응답
        • 재귀적 리졸버가 이러한 반복 질의를 순차적으로 수행하면서 최종적인 응답을 모음
  • 결론
    • 클라이언트와의 통신에서는 재귀 질의
      • 클라이언트(사용자)는 최종 결과만 필요로 하므로, 재귀 질의를 통해 DNS 리졸버에 요청. 이는 클라이언트에서 복잡한 단계별 질의를 하지 않고도 간단하게 “나 대신 찾아줘”라고 요청
    • DNS 리졸버와 다른 DNS 서버 간의 통신에서는 반복 질의
      • 재귀 리졸버가 실제로 루트, TLD, 그리고 권한 있는 네임 서버에 대해 질의를 할 때는 반복 질의 방식 사용. 이 경우 각 서버는 최종 답을 가지고 있지 않으므로, “이 서버로 물어보라”는 식의 Referral 정보 제공
    • 결합된 동작
      • 전체 DNS 질의 과정은 클라이언트와 재귀 리졸버 간의 재귀 질의와, 재귀 리졸버와 다른 DNS 서버 간의 반복 질의가 결합되어 작동. 이렇게 함으로써 클라이언트는 단순한 인터페이스로 최종 답을 받고, 내부적으로는 효율적인 분산 처리 및 캐싱 정책 적용

 

여기까지가 DNS 서버에 원하는 정보를 요청하는 방법이고, 이 과정으로 IP주소를 얻게 되었다.

그럼 이제 IP주소를 활용해 연결하는 방법에 대해 알아보자.

 

3) TCP (+TLS) 연결 설정

브라우저는 DNS를 통해 얻은 IP 주소로 TCP 연결을 시도한다. HTTP - 80, HTTPS - 443 포트를 사용한다.

이후 HTTPS인 경우 TLS 핸드쉐이크를 추가적으로 진행한다.

 

1. TCP 연결 설정

TCP(Transmission Control Protocol)는 신뢰성 있는 연결 기반 통신을 위해 사용되며, 3-way handshake 과정을 통해 연결된다.

 

3-Way 핸드쉐이크 단계

  1. SYN (Synchronize) 패킷 전송
    • 클라이언트는 서버에 연결 요청을 의미하는 SYN 패킷을 보낸다.
    • 이 패킷에는 클라이언트의 초기 시퀀스 번호 포함
    • 서버와의 데이터 전송 순서를 맞추기 위한 첫 번째 단계
  2. SYN-ACK (Synchronize-Acknowledge) 패킷 수신
    • 서버는 클라이언트의 SYN 패킷을 받으면, 자신의 초기 시퀀스 번호와 함께 클라이언트의 시퀀스 번호에 대한 응답(Acknowledgment)을 포함하는 SYN-ACK 패킷으로 응답
    • 이 단계에서 서버는 "내 시퀀스 번호는 이것이고, 네가 보낸 SYN을 받았으니 준비 완료"라는 의미로 응답
  3. ACK (Acknowledge) 패킷 전송
    • 클라이언트는 서버로부터 받은 SYN-ACK 패킷을 확인하고, ACK 패킷 전송
    • 양쪽 모두 연결을 확립했음을 확인하며 데이터 통신 시작 준비 완료

TCP 연결의 특징

  • 신뢰성 보장: 시퀀스 번호와 ACK를 사용하여 데이터 패킷의 손실 및 순서 오류를 감지 및 재전송
  • 흐름 제어: 클라이언트와 서버 간의 데이터 전송 속도를 조절하여 네트워크 혼잡 완화
  • 혼잡 제어: 네트워크의 상태에 따라 전송 속도를 동적으로 조절하는 메커니즘을 포함하여 전체 네트워크 효율 향상

 

2. TLS 연결 설정

TLS(Transport Layer Security)는 TCP 연결 위에서 작동하는 보안 프로토콜로, 데이터 암호화와 인증을 통해 클라이언트와 서버 간의 통신을 보호. TLS 연결 설정(handshake)은 TCP 연결이 확립된 이후에 진행.

 

TLS 핸드쉐이크 단계

  1. Client Hello
    • 클라이언트는 자신이 지원하는 암호화 알고리즘, TLS 버전, 난수 값을 포함하는 Client Hello 메시지를 서버에 보냄
    • 이 메시지를 통해 클라이언트는 보안 연결의 기본 조건을 제시
  2. Server Hello
    • 서버는 Client Hello 메시지를 검토한 후, 사용 가능한 암호화 스위트와 TLS 버전을 선택하여 Server Hello 메시지로 응답
    • 서버는 또한 자신의 난수 값을 포함하여, 클라이언트와 이후에 생성할 암호화 키의 기초 정보를 제공
  3. 인증 및 키 교환
    • 서버 인증
      • 서버는 자신의 인증서를 클라이언트에게 전송하여 신뢰할 수 있는 인증 기관(CA)이 발행한 것임을 증명
      • 클라이언트는 이를 검증하여 중간자 공격(man-in-the-middle attack) 방지
    • 키 교환
      • 클라이언트와 서버는 사전 정의된 알고리즘을 통해 세션 키 생성
      • RSA, Diffie-Hellman 등 다양한 방식으로 이루어질 수 있으며, 이를 통해 양쪽에서 사용될 대칭 암호화 키가 생성
  4. Change Cipher Spec & Finished
    • 클라이언트와 서버는 “이제부터 교환될 모든 메시지는 새로 협상된 암호화 키를 사용하여 암호화된다”는 메시지를 주고받으며 핸드쉐이크 과정 종료
    • 양측은 Finished 메시지를 교환함으로써, 핸드쉐이크 동안 주고받은 모든 정보가 올바르고 동일하게 처리되었음을 확인

TLS 연결 특징

  • 데이터 암호화: 전송되는 모든 데이터는 협상된 대칭 암호화 키를 통해 암호화되어 중간에 도청되더라도 내용을 알아볼 수 없음
  • 데이터 무결성: 해시 기반 메시지 인증 코드(HMAC) 등을 이용하여 데이터가 전송 중 변경되지 않았음을 확인할 수 있음
  • 서버(및 선택적으로 클라이언트) 인증: 인증서를 통해 상대방의 신원을 확인하여 보안 강화

TCP와 TLS 연결의 상호작용

  • 순차적 연결
    • TLS 핸드쉐이크는 반드시 TCP 연결이 완전히 확립된 이후에 시작
    • TCP는 안정적인 연결을 보장하고, TLS는 이 위에 보안 계층 추가
  • 통합 역할
    • TCP는 데이터 전송의 신뢰성과 순서를 보장하고, TLS는 데이터의 기밀성, 무결성 및 인증 제공
    • 이 둘이 결합되어 사용자와 서버 간의 안전한 통신을 수행

 

DNS에게 질의를 보내 IP주소를 얻었고, 이를 활용해 TCP(+TLS) 연결까지 완료되었다.

이제는 HTTP로 요청을 보내고 받는 방법에 대해 알아보자.

4) HTTP 요청 및 응답

HTTP/HTTPS 요청 전송

  • 연결이 성립되면 브라우저는 HTTP GET 요청을 보내어 서버에 "google.com"의 기본 페이지(보통 "/")를 요청
    • 요청에는 User-Agent, Accept, Cookie 등 다양한 헤더 정보 포함

서버 처리

  • Google의 웹 서버는 요청을 수신하고, 이를 처리하여 적절한 웹 페이지(HTML, CSS, JavaScript, 이미지 등) 또는 리다이렉션 정보 반환

응답 전송

  • 서버는 HTTP 응답을 통해 요청한 리소스와 함께 상태 코드(예: 200 OK, 301 Moved Permanently 등) 전송

5) 브라우저의 페이지 렌더링

  • HTML 파싱: 브라우저는 받은 HTML 문서를 파싱하여 DOM(Document Object Model)을 생성
  • 리소스 요청:  HTML 내에 포함된 링크(스타일시트, 스크립트, 이미지 등)를 추가로 요청하여, 필요한 리소스를 다운로드
  • 렌더 트리 구성 및 화면 출력: 최종적으로 파싱된 내용과 추가로 다운로드한 리소스를 조합해 렌더 트리를 만들고, 이를 바탕으로 웹 페이지가 화면에 렌더링

여기까지 브라우저에 "google.com"을 입력하면 일어나는 일 이었다.

작성하고 나서 다른 글들을 찾아보니 4~5번 내용이 조금 부실해보여서 다음 글에서 해당 내용에 대해 더 자세히 작성해보겠다.

 

반응형