| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- CSS
- git flow start
- 개발일지
- git flow finish
- Mac
- 끝까지 잘 마무리하기
- 힘들었던 한주
- js
- 다시 홧팅
- HTML
- jQuery
- AJAX
- javascript30
- 바닐라JS
- 공부할 거 넘많다~
- Next.js
- TS
- JavaScript
- axios
- api 라우트
- 실무는 공식문서로
- git
- freecodecamp
- 백준
- 책으론 원리만
- 클라이언트 컴포넌트
- fetch pull 차이
- 차이점
- Main
- 서버 컴포넌트
- Today
- Total
다다의 개발일지 6v6
🌐 주소창에 URL을 입력했을 때 일어나는 과정! 본문
주소창에 https://www.example.com 를 입력한다. 어떤 일이 일어날지 알아보자.
1. URL 해석 및 DNS 조회 (Domain Name System)
- 사용자가 입력한 https://www.example.com을 브라우저가 분석함.
- 브라우저가 example.com의 IP주소를 찾기위해 캐시에서 DNS 기록을 확인한다.
- DNS 조회 과정 ( 먼저 캐시에서 DNS 기록을 확인하고 없으면 루트 네임서버로 ):
- 브라우저 캐시 확인 → 최근 방문한 사이트라면 저장된 IP 사용
- 운영체제(OS) 캐시 확인
- 로컬 네트워크(라우터) 캐시 확인
- ISP(internet service provider로 KT SKT 같은곳을 의미) DNS 서버 캐시 조회
- 최종적으로 루트 네임서버를 거쳐 실제 IP 주소 조회
- DNS 조회 과정 5번 더 자세히 알아보기 (아래 더보기)
루트 네임서버(Root Name Server)란?
루트 네임서버는 인터넷에서 도메인 이름을 IP 주소로 변환하는 과정에서 최상위 계층에 있는 DNS 서버
인터넷에는 13개(논리적으로 13개, 물리적으로는 더 많음)의 루트 네임서버가 존재하고,
각각은 "A"부터 "M"까지 식별됨.

🌍 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가지가 있다
- 재귀 쿼리(Recursive Query) - 일반적
- 클라이언트(브라우저)가 DNS Resolver에게 최종 IP 주소를 요청.
- Resolver는 스스로 직접 루트 네임서버 → TLD 네임서버 → 권한 있는 네임서버까지 모두 조회해서 최종 IP를 찾아줌.
- 사용자 입장에서는 "알아서 다 해주는" 방식.
- 일반적으로 ISP(인터넷 제공업체)의 DNS Resolver가 이렇게 동작함.
- 반복 쿼리(Iterative Query)
- DNS Resolver는 최종 IP를 직접 찾지 않고, 다음으로 물어볼 서버만 알려줌.
- 즉, 클라이언트가 루트 네임서버 → TLD 네임서버 → 권한 있는 네임서버까지 직접 조회해야 함.
- 이 방식은 일반 사용자가 직접 사용할 일은 거의 없음.
- 비재귀 쿼리(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" 과정이 일어남.
- SYN (Synchronize)
- 클라이언트(브라우저) → 서버에 연결 요청
- SYN-ACK (Synchronize-Acknowledge)
- 서버 → 클라이언트의 요청을 승인
- ACK (Acknowledge)
- 클라이언트 → 연결 완료를 확인
✅ 결과: 클라이언트(브라우저)와 서버가 연결됨!
3. TLS 핸드셰이크 (HTTPS인 경우)
만약 https:// 프로토콜을 사용했다면, TLS(SSL) 핸드셰이크 과정이 추가됨.
🔒 TLS(SSL) 핸드셰이크 과정:
- 브라우저가 서버에 보안 연결 요청
- 서버가 SSL 인증서를 제공 → 브라우저가 신뢰할 수 있는지 확인
- 공개 키 & 비밀 키를 이용해 암호화된 연결 생성
- 이후 모든 데이터가 암호화되어 전송됨
✅ 결과: 브라우저와 서버 간의 보안 연결 설정 완료! 🔐
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. 브라우저 렌더링
이제 브라우저가 응답받은 데이터를 렌더링하는 과정!
- HTML 파싱 → DOM(Document Object Model) 생성
- CSS 파싱 → 스타일 규칙 적용 (스타일링)
- JavaScript 실행 → 동적 기능 처리
- 이미지 및 추가 리소스 로드
- 최종적으로 화면에 웹 페이지 렌더링!
✅ 결과: 사용자가 웹 페이지를 볼 수 있음! 🎉
- 캐시가 있다면? → DNS 캐시 & 브라우저 캐시 활용 (속도 향상)
- HTTP와 HTTPS 차이? → HTTPS는 TLS 암호화로 더 안전함
- SPA(Single Page Application)에서는? → 초기 요청 이후 API 호출로 동적 페이지 업데이트됨
'Computer Science > 네트워크' 카테고리의 다른 글
| Axios 에 대해 알아보자! (2) | 2025.02.02 |
|---|---|
| 🔐JWT(JSON Web Token) 토큰에 대해 + vs 세션 기반 인증 (0) | 2025.02.02 |