01_DevTIL ✍HTTP

웹 호스팅

웹 호스팅

hosting, http
목차
  • 콘텐츠 리소스를 저장, 중개, 관리하는 일을 통틀어 웹 호스팅이라 한다.
  • 필요한 하드웨어나 소프트웨어를 직접 관리하기 어렵다면,
    호스팅 서비스나 호스팅 업체가 필요할 것이다.
  • 호스팅 업체는 서버와 웹 사이트 관리 프로그램을 대여해주고
    다양한 등급의 보안, 리포트, 사용 편의를 제공한다.

1. 호스팅 서비스

  • 웹이 빠르게 대세가 되면서,
    모든 사람이 웹 사이트를 원했지만,
    냉난방 장치가 있는 서버실을 짓고, 도메인 이름을 등록하고, 네트워크 대역폭을 구매할 기술과 시간을 가진 사람은 드물었다.
  • 그 시간을 절약하기 위해, 전문적으로 관리하는 웹 호스팅 서비스를 제공하는 여러 신사업이 만들어졌다.
    • 물리적인 장비관리 ~ 고객이 직접 콘텐츠를 제공할 수 있는 총괄적인 웹 호스팅까지
      다양한 종류의 서비스들이 있다.

1.1 예: 전용 호스팅

2. 가상 호스팅

  • 많은 웹 호스팅 업자는 컴퓨터 한 대를 여러 고객이 공유하게 해서
    저렴한 웹 호스팅 서비스를 제공한다.
    • 이를 공유호스팅 혹은 가상호스팅 이라고 부른다.
    • 각 웹사이트는 다른 서버에서 호스팅하는 것처럼 보이겠지만,
      사실은 물리적으로 같은 서버에서 호스팅되는 것이다.
      • 최종 사용자의 관점에서 가상 호스팅에 있는 웹사이트는,
        물리적으로 분리된 전용 서버에서 호스팅 하는 사이트와 구분할 수 없어야 한다.
  • 가상 호스팅은 비용, 공간, 관리에 이점이 있으므로,
    가상 호스팅을 제공하는 업체는 한 서버에 여러 개의 웹 사이트를 호스팅하려고 한다.
    • 하지만 그것이 PC한대에 웹 사이트 여러 개를 구축한다는 뜻은 아니다.
    • 호스팅 업자는 복제 서버 더미(서버 팜)를 만들고
      서버팜에 부하를 분산할 수 있다.
    • 팜에 있는 각 서버는 다른 서버를 복제한 것이며,
      수많은 가상 웹사이트를 호스팅하고 있기 때문에 관리자는 훨씬 편해진다.

2.1 호스트 정보가 없는 가상 서버 요청

  • HTTP/1.0 명세는 공용 웹 서버가 호스팅하고 있는 가상 웹사이트에
    누가 접근하고 있는지 식별하는 기능을 제공하지 않는다.
  • https://feel5ny.github.io/index.html을 요청한다면, HTTP/1.0 요청은 호스트명에 대한 별다른 언급 없이 “GET /index.html”이라는 요청을 한다.
    • 서버가 여러개의 사이트를 가상 호스팅하고 있으면, 사용자가 어떤 가상 웹 사이트로 접근하려고 하는것인지 아는 데 필요한 정보가 충분하지 않다.
  • HTTP 대리 서버와 인터셉트 프락시 또한
    어떤 사이트를 요청하는지에 관한 정보가 필요하다.

2.2 가상 호스팅 동작하게 하기 VirtualHost

  • HTTP 설계자들이 공유 서버인 가상 호스팅을 고려하지 않았다.
  • 이를 해결하기 위해서, HTTP 요청 메세지에
    완전한 URL도 포함해서 보내게 해서 간단히 해결하였다.

  1. URL경로를 통한 가상 호스팅

    • 서버가 어떤 사이트를 요청하는 것인지 알 수 있게
      URL에 특별한 경로 컴포넌트를 추가한다.
    • “GET /joy/index.html” 조이 사이트에 대한 요청이다.
      “GET /grey/index.html” 그레이 사이트에 대한 요청이다.
    • 거의 사용하지 않는다.

  2. 포트번호를 통한 가상 호스팅

    • 각 사이트에 다른 포트번호를 할당,
      분리된 웹 서버의 인스턴스가 요청을 처리한다.

  3. IP 주소를 통한 가상 호스팅

    • 각 가상 사이트에 별도의 IP 주소를 할당하고, 모든 IP 주소를 장비 하나에 연결한다.
    • 웹 서버는 IP 주소로 사이트 이름을 식별한다.
    • 각 가상 웹 사이트에 유일한 IP 주소를 한 개 이상 부여한다. 모든 가상 서버의 IP주소는 같은 공용 서버에 연결되어 있다.
    • 예
      1. 클라A는 http://feel5ny.github.io/index.html을 요청한다.
      2. 클라A는 IP 주소를 요청해 210.89.164.90를 얻는다.
      3. 클라A는 210.89.164.90에 공용 웹서버에 TCP 커넥션을 맺는다.
      4. 클라A는 “GET /index.html HTTP/1.0” 요청을 보낸다.
      5. 실제 목적지 IP 주소를(210.89.164.90) 기록하고,
        이것이 조이의 웹사이트에 대한 가상IP 주소라는 것을 판단하고 요청을 처리한다.
      • 클라B도 유사하게 처리된다.
    • 규모가 큰 호스팅 업자에게는 약간 어려운 문제점이 있다.
      • 컴퓨터 시스템이 연결할 수 있는 장비의 IP 갯수는 제한되어있다.
      • IP주소는 희소 상품이다.
      • IP주소가 부족한 문제는 호스팅 업자가 용량을 늘리려고 서버를 복제하면서 더 심각해진다.
    • 위의 문제점이 있지만 많이 사용되는 방식이다.
    • 참고

  4. Host 헤더를 통한 가상 호스팅

    • HTTP/1.1에 Host 요청 헤더를 정의했다.
    • 웹 서버는 Host 헤더로 가상 사이트를 식별할 수 있다.
    • 브라우저와 서버 개발자들은 서버가 원 호스트 명을 받아 볼 수 있게 HTTP를 확장했다.
    • 모든 요청에 호스트 명(그리고 포트)를 Host 확장 헤더에 기술해서 전달한다.

2.3 HTTP/1.1 Host 헤더

문법과 사용방법

  • Host 헤더에 포트가 기술되어 있지 않으면, 해당 스킴의 기본 포트를 사용한다.
  • URL에 IP주소가 있으면, Host 헤더는 같은 주소를 포함해야 한다.
  • URL에 호스트 명이 기술되어 있으면,
    • Host 헤더는 같은 호스트 명을 포함해야 한다.
    • Host 헤더는 URL의 호스트명이 가리키는 IP 주소를 포함해서는 안된다.
      • 여러개의 가상 사이트를 한개의 IP주소에 연결한 가상 호스트 서버에서 문제가 될 수 있기 때문
  • 클라가 특정 프락시 서버를 사용한다면
    • Host헤더에는 origin 서버의 호스트명과 포트를 기술해야 한다.
  • 웹 클라는 모든 요청 메세지에 Host헤더를 기술해야 한다.
  • 웹 프락시는 요청을 전달하기 전에 요청 메세지에 Host 헤더를 추가해야 한다
  • HTTP/1.1 웹 서버는
    Host 헤더 필드가 없는 HTTP/1.1 요청 메세지를 받으면
    400 상태 코드로 응답해야 한다.

Host 헤더 해석하기

  • 호스트를 기준으로 리소스를 구분하는 모든 웹 서버는 HTTP/1.1을 통해 오는 리소스를 결정하려면 다음과 같은 규칙을 사용해야 한다.

  • HTTP 요청 메세지에

    • 전체 URL이 기술되어 있으면
      Host 헤더에 있는 값은 무시하고
      URL을 사용한다.
    • 전체 URL이 기술되어 있지 않고
      요청에 Host 헤더가 있으면, 호스트 명과 포트를 Host 헤더에서 가져온다.

  • 전체 URL이나 Host 둘다 없을 경우
    클라에게 400 Bad Request 응답을 반환한다.

Host헤더는 누가 자동 셋팅을?

  • Host나 Connection같이, 셋팅하는 코드를 넣지 않았는데
    네트워크 탭에서 보면 종종 request 헤더에 포함되어있는 것을 보았다.
  • 이는 브라우저 엔진 내부에서 자동으로 셋팅해준다.
  • 자동 셋팅해주는 헤더는 어디서 확인 가능할까?
    • 크롬 확장 api중 webRequest API에는 라이프사이클이 존재하는데 onBeforeSendHeaders라는 콜백으로 확인 가능하다.
    • 참고

3. 안정적인 웹사이트 만들기

웹 사이트에 장애가 생기는 몇가지 상황

  1. 서버다운
  2. 트래픽 폭증
  3. 네트워크 장애나 손실

3.1 미러링 된 서버 팜

  • 서버팜은 서로 대신할 수 있고 식별할 수 있게 설정된 웹 서버들의 집합이다.
  • 서버팜의 서버에 있는 콘텐츠들은 한 곳에 문제가 생기면,
    다른 한 곳에서 대신 전달할 수 있게 미러링 할 수 있다.
  • 미러링된 서버는 계층적인 관계에 있다.
    • 한 서버는 (원본 콘텐츠를 가지고 있는) ‘콘텐츠의 원본 제작자’ 같이 행동한다.
      • => 마스터 원 서버라 부른다. Master Origin Server
    • 마스터 원 서버로부터 콘텐츠를 받은 미러링된 서버는
      • => 복제 원 서버라 부른다. Replica Origin Server
  • 서버 팜에 배포하는 간단한 방법 하나는
    네트워크 스위치를 사용해서 서버에 분산 요청을 보내는 것이다.
    • 서버에 호스팅 되고 있는
      각 웹사이트의 IP주소는
      스위치의 IP주소가 된다.
  • 마스터 원 서버는 복제 원 서버에 콘텐츠를 보낼 책임이 있다.
    • 외부에서 볼 때, 이 콘텐츠를 가리키는 IP주소는 스위치의 IP주소다.
      스위치는 서버에게 요청을 전송해야 하는 책임이 있다.
    • 미러링된 웹 서버에는 다른 위치에 있는 콘텐츠와 정확히 같은 복제본이 있다.
  • 위 그림의 시나리오에서는, 클라의 요청이 특정 서버로 가는 2가지 방법이 있다.
    1. HTTP 리다이렉션
      : 콘텐츠에 대한 URL은 마스터 서버의 IP를 가리키고,
      마스터 서버는 요청을 받는 즉시 복제 서버로 리다이렉트 시킨다.
    2. DNS 리다이렉션
      : 콘텐츠의 URL은 4개의 IP주소를 가리킬 수 있고,
      DNS 서버는 클라에게 전송할 IP주소를 선택할 수 있다.

3.2 콘텐츠 분산 네트워크 CDN

  • Contents Delivery Network
  • 콘텐츠 분산 네트워크 CDN 은 특정 콘텐츠의 분산을 목적으로 하는 단순한 네트워크이다.
  • 네트워크의 노드는
    1. 서버
    2. 대리 서버
    3. 프락시 서버

가 될 수 있다.

기본적으로 사용자가 원격지에 있는 서버(Origin Server)로 부터 Content(예. Web Object, Video, Music, Image, Document 등)를 다운로드 받을 때 가까이 있는 서버에서 받는 것보다 시간이 오래 걸리므로, 사용자와 가까운 곳에 위치한 Cache Server에 해당 Content를 저장(캐싱)하고 Content 요청시에 Cache Server가 응답을 주는 기술입니다.
참고

3.3 CDN의 대리 캐시 ( == 리버스 프락시 )

  • Gateway 캐시: 실제 요청을 담당하는 서버에서 관리되는 캐시
  • == Reverse 프락시 : forward 프락시의 반대 방향
  • 대리 서버는 복제 원 서버를 대신해 사용될 수 있다.
  • 대리 서버는 미러링 된 웹 서버처럼, 콘텐츠에 대한 요청을 받는다.
  • 그들은 특정 원 서버 집합을 대신해 요청을 받는다.
    • 이는 콘텐츠에 대한 IP주소가 알려졌기 때문에 가능하다.
      보통 원 서버와 대리 서버가 연결되며, 대리 서버는 특정 원 서버를 가리키는 요청을 받는다.

      ??

  • 대리 서버와 미러링 된 서버의 차이점
    • 대리 서버는 수요에 따라서 동작한다.
    • 대리 서버는 원서버의 전체 콘텐츠를 복사하지 않는다.
    • 클라이언트가 요청하는 콘텐츠만 저장할 뿐이다.
    • 대리 서버의 캐시에 콘텐츠가 분산되는 방식은
      그들이 받는 요청에 따라 달라진다.
  • 원 서버는 그들의 콘텐츠를 업데이트 해 줄 의무는 없다.
  • 많은 요청이 있는 콘텐츠를 빠르게 제공하려고,
    사용자가 요청하기도 전에 콘텐츠를 가져오는 “미리 가져오기 기능“을 가진 대리 서버도 있다.

3.4 CDN의 프락시 캐시

  • 네트워크 레이어 캐시: ISP, 방화벽에 설치됨. shared cache
  • 전통적인 프락시 캐시는 어떤 웹 서버 요청이든지 다 받을 수 있다.
  • 대리 서버를 사용하면,
    프락시 캐시의 콘텐츠는 요청이 있을 때만 저장될 것이고,
    원본 서버 콘텐츠를 정확히 복제한다는 보장이 없다.
  • 어떤 프락시는 요청이 많이 받는 콘텐츠를 미리 로딩하기도 한다.
  • 요청이 있을 때만 저장하는 프락시 캐시
    • 레이어2 혹은 레이어3 장비(스위치 혹은 라우터)가 중간에 웹 트래픽을 가로채 처리하기도 한다.
    • 가로채기 설정은, 클라와 서버 사이의 모든 HTTP 요청이 물리적으로 캐시를 거치게 네트워크 설정을 할 수 있는지에 따라 달라진다.
    • 콘텐츠는 받는 요청에 따라서 캐시에 분산된다.

4. 웹 사이트 빠르게 만들기

  • 서버 팜이나 분산 크락시 캐시, 대리 서버는 혼잡을 조절하고 네트워크 트래픽을 분산시킨다.

  • 콘텐츠를 분산시키면,
    그 콘텐츠를 사용자에게 더 가깝게 만들어 주므로,
    콘텐츠를 서버에서 클라로의 전송하는 시간이 단축된다.

  • 리소스의 로딩속도를 좌우하는 요소

    1. 리다이렉션
      어떻게 요청과 응답이 클라와 서버 사이에서 연결을 맺고 인터넷을 가로질러 데이터를 전송하는 지.
    2. 인코딩 콘텐츠를 인코딩 하는 것.

참고자료

profile

author.

Joy Kim @feel5ny

웹 프론트엔드 개발자입니다. 글쓰기와 정리를 좋아합니다.

📚