브라우저에서 google.com 접속 시 발생하는 과정이 뭘까
브라우저 주소창에 google.com을 입력하고 엔터를 누르면 DNS 조회, TCP/IP 연결, 방화벽 검사, HTTPS/SSL 보안, 로드밸런싱, 웹서버 처리, 브라우저 렌더링 등 다양한 과정을 거쳐 최종적으로 구글 홈페이지가 화면에 표시된다.
참고 링크: google.com 접속 발생 과정
DNS 요청 및 IP 주소 조회
브라우저에 google.com을 입력하고 엔터를 누르면 가장 먼저 도메인 이름을 IP 주소로 변환하는 과정이 시작된다.
브라우저 캐시 확인
브라우저는 먼저 자체 캐시를 확인하여 이전에 방문한 도메인의 IP 주소가 저장되어 있는지 확인한다. 캐시에 정보가 없으면 다음 단계로 넘어간다.
DNS 조회 과정
브라우저는 ISP(Internet Service Provider)의 DNS 서버에 DNS 쿼리를 보내 google.com의 IP 주소를 요청한다.
DNS 재귀적 검색 과정:
1. DNS 리커서(ISP의 DNS 서버)가 루트 네임 서버에 연락
2. .com 도메인 네임 서버로 리다이렉트
3. google.com 네임 서버로 리다이렉트
4. DNS 기록에서 'www.google.com'에 매칭되는 IP 주소 찾기
5. 찾은 IP 주소를 DNS 리커서로 전송
DNS 조회는 계층적 구조로 이루어져 있어, 루트 서버부터 시작해 점차 특정 도메인의 네임 서버로 좁혀가며 IP 주소를 찾는다.
TCP/IP 연결 수립
DNS 조회를 통해 IP 주소를 얻은 후, 브라우저는 해당 IP 주소를 가진 서버와 TCP/IP 연결을 수립한다.
3-way 핸드셰이크
TCP 연결은 3-way 핸드셰이크라는 과정을 통해 이루어진다.
TCP 3-way 핸드셰이크 과정:
1. 클라이언트 → 서버: SYN 패킷 전송 (연결 요청)
2. 서버 → 클라이언트: SYN-ACK 패킷 전송 (요청 승인 및 연결 요청)
3. 클라이언트 → 서버: ACK 패킷 전송 (서버 연결 요청 승인)
이 과정을 통해 클라이언트와 서버 간에 신뢰성 있는 연결이 수립된다.
💡 TCP/IP 연결은 데이터가 올바른 순서로, 손실 없이 전송되도록 보장하는 중요한 프로토콜이다.
방화벽 검사
연결 과정에서 클라이언트나 서버 측의 방화벽이 요청을 검사한다.
방화벽은 네트워크 트래픽을 모니터링하고 보안 규칙에 따라 트래픽을 허용하거나 차단한다.
방화벽 검사 기준:
- 출발지 및 목적지 IP 주소
- 포트 번호
- 패킷 내용의 특성
방화벽이 요청을 허용하면 다음 단계로 진행되고, 차단하면 연결이 거부된다.
HTTPS/SSL 보안 연결
구글은 HTTPS를 사용하므로, 브라우저와 서버 간에 보안 연결이 수립된다.
SSL/TLS 핸드셰이크
보안 연결은 SSL/TLS 핸드셰이크를 통해 이루어진다.
SSL/TLS 핸드셰이크 과정:
1. 클라이언트 → 서버: 클라이언트 헬로 메시지 (지원하는 암호화 방식 목록 전송)
2. 서버 → 클라이언트: 서버 헬로 메시지 (선택한 암호화 방식 및 SSL 인증서 전송)
3. 클라이언트: 서버 인증서 검증
4. 클라이언트: 세션 키 생성 및 서버 공개키로 암호화하여 전송
5. 서버: 세션 키 복호화
6. 양측: 핸드셰이크 완료 메시지 교환
HTTPS는 데이터를 암호화하여 전송함으로써 중간자 공격이나 도청으로부터 사용자 정보를 보호한다.
로드 밸런싱
구글과 같은 대규모 서비스는 수많은 서버를 운영하며, 로드 밸런서를 통해 트래픽을 분산한다.
로드 밸런서는 들어오는 요청을 여러 서버에 분산하여 서버 부하를 균등하게 유지한다.
로드 밸런싱 알고리즘 예시:
- 라운드 로빈: 순차적으로 각 서버에 요청 분배
- 최소 연결: 현재 연결이 가장 적은 서버에 요청 할당
- IP 해시: 클라이언트 IP를 기반으로 항상 같은 서버로 요청 라우팅
⚡ 로드 밸런싱은 서비스의 가용성과 확장성을 높이는 핵심 기술로, 특정 서버에 과부하가 걸리지 않도록 한다.
웹 서버 및 애플리케이션 서버 처리
로드 밸런서가 요청을 특정 서버로 전달하면, 웹 서버와 애플리케이션 서버가 요청을 처리한다.
웹 서버와 WAS의 역할
웹 서버와 WAS의 차이점:
- 웹 서버: 정적 콘텐츠(HTML, CSS, 이미지 등) 처리
- WAS(Web Application Server): 동적 콘텐츠(JSP, PHP 등) 처리
웹 서버는 클라이언트의 HTTP 요청을 받아 정적 콘텐츠를 제공하거나, 동적 콘텐츠 생성이 필요한 경우 WAS에 요청을 전달한다.
WAS는 비즈니스 로직을 실행하고 필요시 데이터베이스에서 데이터를 조회하여 동적 콘텐츠를 생성한다.
HTTP 응답 및 상태 코드
서버는 처리 결과에 따라 적절한 HTTP 상태 코드와 함께 응답을 클라이언트에게 전송한다.
주요 HTTP 상태 코드:
- 200 OK: 요청 성공
- 301/302: 리다이렉션
- 404 Not Found: 리소스를 찾을 수 없음
- 500 Internal Server Error: 서버 오류
응답에는 HTML, CSS, JavaScript 파일 등 웹 페이지를 구성하는 리소스가 포함된다.
브라우저 렌더링
브라우저는 서버로부터 받은 HTML, CSS, JavaScript 파일을 해석하여 웹 페이지를 화면에 표시한다.
렌더링 과정
브라우저 렌더링 단계:
1. HTML 파싱 및 DOM 트리 구축
2. CSS 파싱 및 CSSOM 트리 구축
3. DOM과 CSSOM을 결합하여 렌더 트리 생성
4. 레이아웃 계산 (각 요소의 크기와 위치 결정)
5. 페인팅 (화면에 픽셀 그리기)
브라우저는 HTML을 파싱하면서 추가 리소스(이미지, 스크립트 등)가 필요한 경우 서버에 추가 요청을 보낸다.
브라우저 렌더링은 사용자가 최종적으로 웹 페이지를 볼 수 있게 하는 중요한 과정으로, 최적화된 렌더링은 웹 성능에 직접적인 영향을 미친다.
전체 과정 요약
google.com에 접속할 때 발생하는 전체 과정을 요약하면 다음과 같다:
- 브라우저에 URL 입력 및 엔터 키 누름
- DNS 조회를 통해 도메인 이름을 IP 주소로 변환
- TCP/IP 연결 수립 (3-way 핸드셰이크)
- 방화벽 검사 통과
- SSL/TLS 핸드셰이크를 통한 보안 연결 수립
- 로드 밸런서가 요청을 적절한 서버로 분배
- 웹 서버와 애플리케이션 서버가 요청 처리
- 서버가 HTTP 응답 생성 및 전송
- 브라우저가 응답을 받아 웹 페이지 렌더링
- 사용자에게 구글 홈페이지 표시
브라우저에서 google.com에 접속하는 간단한 행동 뒤에는 복잡한 네트워크 통신과 다양한 기술이 유기적으로 작동하고 있다. 이러한 과정을 이해하는 것은 웹 개발자로서 더 효율적인 웹 애플리케이션을 구축하는 데 도움이 된다.
댓글남기기