귀찮게하기/Infra

www.example.com을 입력하면 일어나는 일(자세히)

게임이 더 좋아 2025. 2. 16. 01:28
반응형
728x170
  • OSI 7 layer, Protocol, Cloud를 중심으로 설명
  • 해당 웹 서버가 AWS EKS 어느 파드에 떠있다고 생각하자

 

1단계: 브라우저에서 URL 입력

  • 사용자가 브라우저 주소창에 www.example.com을 입력
  • 브라우저는 HTTP/HTTPS를 통해 웹 서버에 요청을 보낼 준비를 함

 

2단계: 도메인 네임 해석 (DNS 요청, 응용 계층)

  • 브라우저는 먼저 www.example.com의 IP 주소를 알아야 하므로 DNS (Domain Name System) 조회를 수행
  • 브라우저 캐시, OS DNS 캐시, 로컬 hosts 파일을 먼저 확인
  • 캐시에 없으면 DNS 리졸버(보통 ISP의 DNS 서버)에 UDP 53 포트를 사용해 질의

 

2-1. 브라우저 및 OS 캐시 확인

브라우저 캐시 확인

  • 브라우저는 최근 방문한 사이트의 DNS 결과를 캐시(Cache) 에 저장
  • 같은 도메인을 짧은 시간 내에 다시 방문하면 DNS 서버에 요청하지 않고, 브라우저 캐시에서 직접 IP 주소를 가져옴
  • 예시: 브라우저 캐시에서 www.example.com → 203.0.113.5 (A 레코드) 검색됨

운영체제(OS) DNS 캐시 확인

  • 만약 브라우저 캐시에 없다면, OS의 로컬 DNS 캐시를 확인
  • OS별 DNS 캐시 확인 방법:
    • Windows: ipconfig /displaydns
    • Linux: systemd-resolve --statistics

로컬 hosts 파일 확인

  • OS의 /etc/hosts (Linux) 또는 C:\Windows\System32\drivers\etc\hosts (Windows) 파일을 확인
  • 만약 www.example.com이 이 파일에 등록되어 있다면, 여기에 있는 IP 주소를 사용함
  • 위 설정이 존재하면, DNS 서버에 요청하지 않고 직접 연결

2-2. 네트워크 DNS 확인

운영체제가 DNS Resolver를 통해 DNS 서버에 요청

  • OS는 로컬 네트워크의 DNS 설정을 확인하여 프라이머리(Primary) DNS 서버로 질의(Query)를 보냄
  • 설정된 DNS 확인 방법:
    • Windows: nslookup -type=A www.example.com
    • Linux: cat /etc/resolv.conf
  • 확인된 DNS 서버에 UDP 53 포트로 쿼리를 전송

 

DNS 서버가 캐시에 있는지 확인

  • ISP의 DNS 서버 또는 클라우드 DNS 서버(예: Google DNS, Cloudflare DNS, OpenDNS)가 해당 도메인의 IP를 캐시에 가지고 있다면 즉시 응답

 

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

  1. ISP의 DNS 서버가 글로벌 루트 네임서버(Root Name Server)에 질의
    • 인터넷의 DNS 시스템은 13개의 루트 네임서버 집합으로 시작됨
    • 루트 네임서버 목록 (예시):
       
      A.ROOT-SERVERS.NET (198.41.0.4) B.ROOT-SERVERS.NET (192.228.79.201) ... M.ROOT-SERVERS.NET (202.12.27.33)
       

TLD 네임서버 조회 (Top-Level Domain Name Server)

  • 루트 네임서버에서 .com을 관리하는 TLD 네임서버를 알려줌
  • .com 도메인의 TLD 네임서버 예시:
     
    a.gtld-servers.net b.gtld-servers.net ... m.gtld-servers.net

 

권한 있는 네임서버 조회 (AWS Route 53)

  • TLD 네임서버가 example.com의 권한 있는 네임서버(Authoritative Name Server) 를 반환
  • AWS Route 53이 example.com을 관리한다고 가정하면:
    ns-1234.awsdns-12.org ns-5678.awsdns-34.com
  • Route 53에 최종적으로 A 레코드를 요청하여 IP 주소를 받음

 

클라이언트가 받은 DNS 응답을 캐싱

  • 클라이언트는 DNS 응답을 받아 브라우저, OS, 네트워크 장비에 캐싱

 

 

3단계: TCP 3-Way Handshake (전송 계층, 4계층)

  • 브라우저는 웹 서버와 통신하기 위해 TCP 연결을 수립
  • 3-Way Handshake 과정 (포트 443 (HTTPS) 사용)

 

AWS ALB로 요청 보내기 

  • 브라우저는 DNS 응답을 받아 ALB의 도메인 (alb-1234.us-east-1.elb.amazonaws.com)을 IP로 변환
  • IP 라우팅 과정:
    1. 클라이언트의 기본 게이트웨이(GW)로 패킷 전송
    2. ISP 백본 네트워크를 거쳐 AWS로 이동
    3. AWS 내부 네트워크에서 ALB에 도달

 

브라우저는 연결하기 위해 TCP 연결을 생성함

  • TCP 3-Way Handshake 과정:
    1. 클라이언트 → 서버: SYN (연결 요청)
    2. 서버 → 클라이언트: SYN-ACK (요청 수락)
    3. 클라이언트 → 서버: ACK (연결 확립)

*AWS 환경에서는 ELB가 앞단에서 트래픽을 받아 EKS로 전달

 

 

4단계: TLS 핸드셰이크

  • HTTPS를 사용하므로 TLS/SSL 보안 통신을 설정.
  • https://www.example.com이면, 브라우저와 서버는 TLS 핸드셰이크 수행:
    1. 클라이언트 → 서버: ClientHello (지원하는 암호화 방식 전달)
    2. 서버 → 클라이언트: ServerHello (인증서 전달, 암호화 방식 선택)
    3. 클라이언트 → 서버: 공개 키를 이용한 Key Exchange
    4. 클라이언트 & 서버: 보안 세션 키 생성 및 인증 완료

 

 

5단계: HTTP 요청 전송

  • TCP/TLS 연결이 완료되면 브라우저는 HTTP 요청을 보냄
  • 요청은 TCP 세그먼트 → IP 패킷 → 이더넷 프레임으로 변환되어 전송

 

6단계: 라우팅

HTTP Request가 라우팅 되어야 함

클라이언트 → AWS ALB로의 경로 탐색 (ARP, 라우팅 등)

6-1: 클라이언트 → 게이트웨이로 패킷 전송 (ARP 요청)

  • 앞서 조회한 DNS를 통해 받아온 IP 사용
  • 이 IP 주소로 HTTP 요청을 보낼 때 로컬 네트워크 내에서 패킷을 해당 IP 주소로 전송
  • ARP (Address Resolution Protocol) 요청이 필요
  • 패킷 구성을 위해 MAC address 필요
  • 해당 IP 주소에 대한 MAC 주소를 알아야만 실제로 패킷을 로컬 네트워크 내의 장비로 보낼 수 있기 때문

로컬 네트워크에 목적지가 있는 경우

  1. 로컬 네트워크의 게이트웨이나 라우터 IP 주소를 이용하여 ARP 요청
  2. ARP table에 존재한다면 클라이언트에 응답
  3. 존재하지 않는다면 게이트웨이나 라우터가 해당 네트워크에 ARP bradcast 하여 ARP table 업데이트 후 응답

로컬 네트워크에 목적지가 없는 경우

-> 외부로 보내야할 때는 게이트웨이로 보냄 

  1. 클라이언트는 로컬 게이트웨이의 IP 주소를 알고 있고, 로컬 네트워크의 MAC 주소를 알아야만 패킷을 전송할 수 있음
  2. 클라이언트는 ARP 요청을 보내어 게이트웨이의 MAC 주소를 알아냄
  3. 게이트웨이는 ARP 응답을 통해 자신의 MAC 주소를 클라이언트(게이트웨이)에게 반환

 이제 클라이언트는 받은 MAC 주소를 사용하여, 게이트웨이(라우터)로 HTTP 요청 패킷을 전송

 

6-2: 로컬 게이트웨이 → ISP 라우터 (IP 라우팅)

  • 로컬 네트워크의 게이트웨이(라우터)는 패킷을 받아 외부 네트워크로 전송
  • 이때, 게이트웨이는 IP 라우팅을 사용하여 패킷을 ISP 라우터로 전달
    • 게이트웨이는 Destination IP 주소를 기반으로 다음 홉을 결정
    • 만약 **목적지가 외부 (인터넷)**이라면, 게이트웨이는 ISP 라우터로 패킷을 전송

 

6-3: ISP 라우터 → 인터넷 백본

  • ISP 라우터는 BGP (Border Gateway Protocol)와 같은 라우팅 프로토콜을 사용하여 패킷을 인터넷 백본으로 전달
    • 이때, BGP는 최적의 경로를 계산하고, 패킷은 다양한 백본 네트워크를 통해 최종 목적지인 AWS 데이터센터

 

6-4: AWS 데이터센터 도달

  • AWS의 데이터센터에 도달하면, 패킷은 AWS의 네트워크 장비(예: AWS 로드 밸런서, VPC 라우터 등)에 의해 처리
    • 이때 VPC  내에서 발생하는 라우팅과 NAT 도 영향
    • 패킷은 AWS의 로드 밸런서 (ALB)로 전달

 

AWS 인프라를 거쳐 요청이 라우팅됨:

  1. ALB 가 요청을 수신하고, 적절한 Target Group 로 전달
  2. Kubernetes Ingress Controller가 도메인 기반으로 적절한 Service로 라우팅
  3. Kubernetes Service가 트래픽을 받아 EKS 클러스터 내 특정 파드로 전달

 

 

AWS Load Balancer (ALB) → Kubernetes Ingress Controller

 

1. ALB에서 Target Group으로 요청 전달

  • ALB는 Listener 를 통해 요청을 수신
  • ALB의 Target Group에는 Kubernetes Ingress Controller 가 등록되어 있음
  • ALB는 요청을 Ingress Controller가 실행 중인 EKS 노드 로 전달

 

Kubernetes Ingress Controller → Kubernetes Service

 

1. Kubernetes Service 역할

  • Service는 EKS 내부에서 실행 중인 Pod들을 네트워크적으로 추상화하여 외부에서 접근할 수 있도록 함
  • Service는 여러 가지 유형이 있지만 일반적으로 EKS에서 Ingress 뒤에 배치되는 것은 ClusterIP 또는 NodePort 타입

 

 

Kubernetes Service → Kubernetes Pod

1. Endpoint Selection (Endpoint 목록에서 Pod 선택)

  • Kubernetes는 web-service의 Endpoint 목록을 조회하여 트래픽을 어떤 Pod으로 보낼지 결정

 

 

7단계: 서버에서 응답 처리

  • 웹 서버가 요청을 받아 웹페이지를 렌더링할 데이터를 생성
  • HTTP 응답 (200 OK):
     
    HTTP/2 200 OK Content-Type: text/html; charset=UTF-8 Content-Length: 10240
  • **웹 콘텐츠 (HTML, CSS, JavaScript)**가 브라우저로 전송됨

 

 

8단계: 데이터 링크 & 물리 계층 처리 (2~1계층)

  • 이더넷 프레임으로 변환되어 MAC 주소 기반으로 전송됨
  • Wi-Fi, 광섬유, UTP 케이블을 통해 물리적 신호 전송

 

 

9단계: 브라우저가 웹페이지 렌더링

  • HTML 파싱, DOM 트리 및 CSSOM 생성
  • JavaScript 실행 및 레이아웃 엔진이 페이지 표시

 

 

참고

728x90
반응형
그리드형
저작자표시 비영리 변경금지

'귀찮게하기 > Infra' 카테고리의 다른 글

IaC, 인프라의 자동화  (0) 2024.11.12
인프라팀 귀찮게 안하기 - Network(4)  (1) 2024.11.06
인프라팀 귀찮게 안하기 - LoadBalancer 및 세션 유지  (0) 2024.11.06
인프라팀 귀찮게 안하기 - Network(3)  (0) 2024.11.06
인프라팀 귀찮게 안하기 - SSH  (0) 2024.11.05

'귀찮게하기/Infra'의 다른글

  • 현재글www.example.com을 입력하면 일어나는 일(자세히)

관련글

댓글

티스토리툴바