Skip to content

Latest commit

 

History

History
130 lines (103 loc) · 10.7 KB

웹 접속 과정.md

File metadata and controls

130 lines (103 loc) · 10.7 KB

브라우저에 google 을 검색했을 때 일어나는 일

  1. 브라우저창에 google.com을 치면 DNS에서 IP주소를 찾습니다.
  2. IP주소로 TCP연결을 수립합니다.(3-way-handShaking)
  3. Http Request 를 작성해 서버로 전송합니다.
    • OS의 프로토콜 스택에 메세지 전송 의뢰
    • 프로토콜 스택이 LAN에 제어정보를 붙인 패킷을 LAN 어댑터에 넘김
    • LAN 어댑터는 이것을 전기신호로 변환시켜 LAN 케이블로 송출
    • 송신한 패킷은 허브, 스위치, 라우터를 공유하여 프로바이더에 전달
    • 패킷은 수많은 액세스 회선을 통해 POP를 거쳐 인터넷 핵심부에 들어감
    • 많은 고속 라우터들 사이로 패킷이 상대방 서버까지 도달 <서버>
    • 서버측의 LAN에 도착하면 방화벽이 패킷을 검사함
    • 이상없을 경우 캐시 서버가 먼저 응답 데이터 있는 지 확인
  4. 서버는 Http Response를 작성해 보냅니다.
  5. 받은 응답으로 웹 화면을 그립니다.

Q) google 이라는 도메인명 IP주소를 조회할 때, 찾는 과정에 대해 설명해주세요.

  • DNS 내에서 Top-level -> Second-level -> Sub-level 순으로 검색합니다. image

  • 최초의 Root 네임 서버의 IP 주소에게 www.naver.com을 물어보면

  • .com을 담당하는 Top-level을 알려주고,

  • Top-level은 naver.com을 담당하는 Second-level을 알려주고,

  • Second-level은 www.naver.com을 담당하는 sub DNS Server에게 물어보며 sub가 해당 IP 주소를 알려주는 것

  • 각각의 부분들을 담당하는 독자적인 Server Computer가 존재하여, 상위 목록이 직속 하위 목록을 알고 있습니다.

    • Root는 Top-level을 담당하는 Server 목록과 IP를 알고 있으며,
    • Top-level은 Second-level의 Server 목록과 IP를 알고 있고,
    • Second-level은 sub 목록과 IP를 알고 있음.

Q-1) DNS에 찾기 전에 있는 과정에 대해 아시나요?

  • hosts 파일의 캐시를 확인합니다.
  • hosts파일은 운영체제 내부에 위치하며, 각각의 도메인네임과 이들의 IP주소를 하나하나 대응시켜서 저장해 놓은 텍스트파일입니다.
+) 이렇게 캐싱되는 이유
  • 네트워크 트레픽을 조절하고 데이터 전송 시간을 줄이기 위해

Q) 내가 사용하는 DNS서버를 어떻게 정하나요?

Hint ! DHCP

  • DHCP, 동적 호스트 설정 프로토콜(Dynamic Host Configuration Protocol) 로 찾습니다.

  • IP주소, 서브넷 마스크, 기본게이트웨이 IP주소, DNS서버 IP주소 를 자동으로 일정 시간 할당해주는 인터넷 프로토콜입니다.

  • DNS서버에 네임서버를 요청하기 전, 거리가 가까운 DNS라우터를 찾습니다. DHCP로 제일 가까운 DNS라우터를 찾아와 외부와 통신할 준비를 마치고, 정해진 DNS서버에 네임서버 요청하게 됩니다.

+) ARP를 통해 IP주소와 가장 가까운 네임서버

  • 실질적인 통신을 하기 위해서는 논리 주소인 IP주소를 물리 주소인 MAC 주소로 변환해야 합니다. 이를 위해 해당 네트워크 내에서 ARP를 브로드 캐스팅합니다. 해당 IP주소를 가지고 있는 노드는 자신의 MAC 주소를 응답합니다.

Q) 가장 가까운 주소를 찾았는데, 물리적으로 먼 서버에 어떻게 접속하는 지 설명해주세요. (한국 -> 미국 접속 과정)

  • 많은 고속 라우터들 사이를 지나 패킷이 상대방 서버까지 도달하게 됩니다.

Q-1) URI, URL, URN 차이

  • URI (Uniform Resource Identifier) : 인터넷 상의 자원을 식별하기 위한 문자열의 구성
    • URL과 URN을 포함
  • URL (Uniform Resource Locator) : 인터넷 상 자원의 위치
  • URN : 자원의 이름
    • ex) ex: urn:something:names:somehitng...

Q-2) URN을 사용하지 않고, URL을 사용할까요?

  • URN은 자원에 부여된 고유한 이름 그 자체로, 자원의 위치를 찾을 수 없습니다. 하지만, URL은 인터넷 상의 자원을 식별하고 위치를 제공할 수 있기 때문에 실용적입니다.

Q) IP주소를 찾아온 후에 TCP연결 과정에서 만약 서버의 위치가 외국인 경우, 거리가 멀수록 효율적이지 않습니다. 극복하기 위해 사용하는 방법에 대해 아시나요?

  • CDN 입니다. Content Delivery Network의 약자로 지리적인 제약 없이 전 세계 사용자에게 빠르고 안전하게 컨텐츠 전송을 할 수 있는 기술을 말합니다. 이를 통해서 컨텐츠의 병목현상을 피할 수 있습니다.
  • 서버를 분산시켜 캐싱해두고 사용자의 컨텐츠 요청이 들어오면 사용자와 가장 가까운 위치에 존재하는 서버로 매핑시켜 요청된 콘텐츠의 캐싱된 내용을 내어주는 방식으로 빠르게 데이터를 전송할 수 있습니다.
    image

왼쪽 : CDN을 사용하지 않을 경우, 오른쪽 : CDN을 사용할 경우
- 만약 서버가 파일을 찾는데 실패하는 경우 CDN 플랫폼의 다른 서버에서 컨텐츠를 찾은다음 응답을 전송

Q-1) 추가로 GSLB 에 대해 아시나요?

  • GSLB(Global Server Load Balancing)란, DNS 기반의 로드밸런싱 서비스입니다.
  • 재난 복구, 부하 분산, 성능 등의 기능이 있습니다.
  • 재난 복구 (disaster recovery)
    • 실패에 대해 대체할 수 있는 서버를 제공합니다.
  • 부하 분산 (load sharing)
    • 많은 트래픽을 여러 서버로 분산합니다.
  • 성능 (performance)
    • client의 위치나 네트워크를 기반으로 최적의 성능을 낼 서버를 선택합니다. 스크린샷 2023-05-14 오후 1.47.47.png
  • 대표적인 서비스 AWS : Route53 Google Cloud : Cloud Load Balancing Azure : Traffic Manager Naver : Global Route Manager F5 Citrix

Q) 웹 서버 주소에 IP주소를 알았을 때, HTTP request를 합니다. 이 과정에서 TCP/IP 기반이라고 할 때 어떤 과정이 일어날까요?

  • 3-way-handShaking 입니다.

Q) DNS에서 로드밸런싱을 위해 라운드로빈 방식을 사용하는데, 왜 사용할까요?

  • 시간단위로 특정 서버에 몰아주며 균등하게 유저들을 배포합니다.

  • 웹 사이트에 접속을 원하는 사용자가 해당 도메인 주소를 브라우저에 입력하면, DNS는 도메인의 정보를 조회하는데, 이때 IP 주소를 여러 대의 서버 IP 리스트 중에서 라운드 로빈 형태로 랜덤하게 하나 혹은 여러개를 선택하여 다시 사용자에게 알려줍니다. image

  • 장점 : 중간 장비(로드밸런서 등) 없이도 서비스가 가능, 간편

  • 단점

    • 서버의 수 만큼 공인 IP 주소가 필요
    • 서버에 장애가 발생해도 감지하지 않고 부하를 분산시킴
    • 일반적인 로드밸런싱은 Health check를 수반한다. 라운드 로빈 DNS는 별도로 Health check를 하지 않음 (서버가 다운되도 확인이 불가능)
    • DNS 결과를 Caching해서 재사용하기 때문에 균등한 분산이 어려움
      • 모바일 사이트 등에서 문제가 될 수 있는데, 스마트폰의 접속은 캐리어 게이트웨이 라고 하는 프록시 서버를 경유 합니다.
      • 프록시 서버에서는 이름변환 결과가 일정 시간 동안 캐싱되므로 같은 프록시 서버를 경유 하는 접속은 항상 같은 서버로 접속됩니다.
      • 또한 PC 용 웹 브라우저도 DNS 질의 결과를 캐싱하기 때문에 균등하게 부하분산 되지 않습니다.
      • DNS 레코드의 TTL 값을 짧게 설정함으로써 어느 정도 해소가 되지만, TTL 에 따라 캐시를 해제하는 것은 아니므로 반드시 주의가 필요

Q-1) 라운드로빈의 단점을 극복하기 위한 방법은 뭐가 있을까요?

  • 다중화 구성 방식 (Synchronous Time-Division Multiplexing)

    • AP 서버에 VIP(Virtual IP)를 부여해서 다중화를 구성한다. 각 AP 서버를 Health Check후 이상이 감지되면 VIP를 정상 AP 서버로 인계하는 방식을 사용한다.
    • 즉 DNS Server Table 에 실시간으로 AP 서버의 상태를 확인할 수 있는 칼럼 및 함수를 추가하여 요청될 경우 서버 상태를 확인하여 우회루트를 제공하거나 에러를 전송하는 방식을 말합니다.

  • 가중치 편성 방식 (Weighted round robin)

    • 각각의 웹 서버에 가중치를 가미해서 분산 비율을 변경한다. 물론 가중치가 큰 서버일수록 빈번하게 선택되므로 처리능력이 높은 서버는 가중치를 높게 설정하는 것이 좋다.

또 다른 방법으로는 로드 밸런서의 도입을 통하여 다음과 같은 구성도 가능합니다.

  • 최소 연결 방식 (Least connection)
    • 접속 클라이언트 수가 가장 적은 서버를 선택한다. 로드밸런서에서 실시간으로 connection 수를 관리하거나 각 서버에서 주기적으로 알려주는 것이 필요하다.

Q) 같은 도메인 주소에 포트번호를 다르게 접속할 때, DNS는 같다고 판단하나요?

  • 아닙니다. 어떤 포트로 요청할 것인 지 분석하기 때문에, 포트가 잘못된 포트로 들어오면 다른걸로 인식합니다.
  • 명시적으로 포트를 선언하지 않았다면 브라우저에서는 설정된 기본값을 이용해 요청하게 됩니다. HTTP라면 80 포트를, HTTPS라면 443 포트를 기본 값으로 요청

Q) 443포트로 https 사용하는데, 80포트로 http 로 접근할 때 어떻게 되나요?

  • HSTS(HTTP Strict transport security), HTTP를 허용하지 않고 HTTPS를 사용하는 연결만 허용하는 기능입니다. 만약 HTTP로 요청이 왔다면 HTTP 응답 헤더에 "Strict Transport Security"라는 필드를 포함하여 응답하고 이를 확인한 브라우저는 해당 서버에 요청할 때 HTTPS만을 통해 통신하게 됩니다. 그리고 자신의 HSTS캐시에 해당 URL을 저장하는데 이를 HSTS 목록이라고 부릅니다.

  • 이를 통해 브라우저에서는 이 HSTS 목록 조회를 통해 해당 요청을 HTTPS로 보낼지 판단합니다. HSTS목록에 해당 URL이 존재한다면 명시적으로 HTTP를 통해 요청한다 해도 브라우저가 이를 HTTPS로 요청합니다.