HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
👻
개발 기록/
🐿️
HTTP 완벽 가이드/
📘
18. 웹 호스팅
📘

18. 웹 호스팅

  • 콘텐츠 리소스를 저장, 중개, 관리하는 일을 통틀어 웹 호스팅이라 함.
  • 각 조직이 가지고 있는 다양한 종류의 리소스를 웹 사이트에 편하게 배포하거나, 적절한 가격에 좋은 성능을 가진 웹 서버에 배치하는 것은 매우 중요함.
 

호스팅 서비스

  • 간단한 예 : 전용 호스팅
  • 죠의 컴퓨터 가게 온라인과 메리의 골동품 경매를 크기가 큰 웹 사이트라고 가정해보자.
      1. 죠와 메리가 직접 자체 서버를 구매하고 서버 소프트웨어를 직접 유지보수하는 대신, 죠와 메리에게 대여할 수 있는 고성능 웹 서버들로 구성된 랙을 아이린의 ISP가 가지고 있음.
      1. 죠는 아이린의 ISP가 구매해 유지보수하고 있는 전용 웹 서버를 임대함. 아이린 ISP는 대량으로 서버 장비를 구매할 수 있으며 안정적이고 검증되었으며 비용이 저렴한 장비를 선택할 수 있음.
      1. 여기서의 포인트는 죠와 메리가 운영하고 있는 서버의 IP 주소는 서로 다르다는 것임.
 

가상 호스팅

  • 하지만 대부분의 웹 공간은 놀고 있는 시간이 존재함.
  • 때문에 이들에게 많은 비용이 드는 전용 웹 서버를 제공하는 것은 낭비임.
  • 많은 호스팅 업자는 컴퓨터 한 대를 여러 고객이 공유하게 해서 저렴한 웹 호스팅 서비스를 제공함.
  • 이를 공유 호스팅 또는 가상 호스팅이라 부름.
  • 각 웹 사이트는 다른 서버에서 호스팅하는 것처럼 보이겠지만, 사실은 물리적으로 같은 서버에서 호스팅 됨.
전용 호스팅
전용 호스팅
가상 호스팅
가상 호스팅
  • 안타깝게도 HTTP/1.0 명세는 공용 웹 서버가 호스팅하고 있는 가상 웹 사이트가 누가 접근하는지 식별하는 기능을 제공하지 않음.
  • 만약 http://www.joes-hardware.com/index.html을 요청하면, 브라우저는 www.joes-hardware.com/에 연결을 하지만, HTTP/1.0 요청은 호스트 명에 대해 별다른 언급없이 "GET/index.html"서버가 여러 개의 사이트를 가상 호스팅하고 있음. 이는 사용자가 어떤 가상 웹 사이트로 접근하려고 하는 것인지 아는 데 필요한 정보가 충분하지 않음.
두 요청이 서로 다른 웹 사이트에 완전히 다른 문서를 요청을 하더라도 요청 자체는 똑같이 생김. 문제는 웹 사이트 호스트 정보가 요청에서 제거된다는 것임.
두 요청이 서로 다른 웹 사이트에 완전히 다른 문서를 요청을 하더라도 요청 자체는 똑같이 생김. 문제는 웹 사이트 호스트 정보가 요청에서 제거된다는 것임.
 
  • 호스트 정보를 HTTP 요청 명세에 넣지 않은 것은, 각 웹 서버가 정확히 한 웹사이트만 호스팅할 것이라고 잘못 예측한 HTTP 명세의 실수임 (단순히 경로 컴포넌트만 전송하도록 설계).
  • 가상 호스팅을 지원하기 위해 4가지 기술이 생김.
    • URL 경로를 통한 가상 호스팅
      • 서버가 어떤 사이트를 요청하는 것인지 알 수 있게 URL에 특별한 경로 컴포넌트를 추가함.
      • ex) 죠의 컴퓨터 가게 http://www.joes-hardware.com/joe/index.html, 메리의 골동품 가게 http://www.marys-antiques.com/mary/index.html라 했을 때 요청을 GET /joe/index.html, GET /mary/index.html이라 보냄.
      • 다만 각 도메인 접두어가 불필요하게 붙어 거의 사용하지 않음.
    • 포트번호를 통한 가상 호스팅
      • 각 사이트에 다른 포트번호를 할당하여, 분리된 웹 서버의 인스턴스가 요청을 처리함.
      • ex) 80 포트 대신 죠는 82, 메리는 83으로 할 수 있음.
      • 하지만 URL에 비표준 포트를 써야 한다는 단점이 있음.
    • ip주소를 통한 가상 호스팅
      • 각 가상 사이트에 별도 IP 주소를 할당하고 모든 IP 주소를 장비 하나에 연결하고 웹 서버는 IP 주소로 사이트 이름을 식별함.
          1. 클라는 http://www.joes-hardware.com/index.html로 요청함.
          1. 클라는 www.joes-hardware.com의 IP 주소를 요청해 209.172.34.3을 얻음.
          1. 클라는 209.172.34.3에 있는 공용 웹 서버에 TCP 커넥션을 맺음.
          1. 클라는 GET /index.html HTTP/1.0 요청을 보냄.
          1. 웹 서버가 응답을 전송하기에 앞서, 실제 목적지 IP 주소를 기록하고, 이것이 죠의 웹 사이트에 대한 가상 IP 주소라는 것을 판단하고, /joe 하위디렉터리에서 요청을 처리함.
          1. /joe/index.html 페이지를 반환함.
      • 다만 규모가 아주 큰 호스팅 업자의 경우 모든 웹 사이트에 할당할 IP 주소를 얻지 못할 수 있다는 문제가 있음. 이는 호스팅 업자가 용량을 늘리려고 서버를 복제하면 각 복제된 서버에 IP 주소를 부여해야 하므로 더 심각한 문제가 발생함.
      • 가상 IP 호스팅은 위와 같은 IP 주소 부족 문제가 생길 수 있음에도 널리 쓰이는 방식임.
    • HOST 헤더를 통한 가상 호스팅
      • 브라우저와 서버 개발자들은 서버가 원 호스트명을 받아 볼수있게 HTTP를 확장함.
      • 모든 요청에 호스트명(그리고 포트)을 Host 확장 헤더에 기술해서 전달함.
      • 현재는 거의 모든 브라우저가 Host 헤더를 지원함.
       

      HTTP/1.1 Host 헤더

    • Host 헤더에는 원본 URL에 있는 요청 리소스에 대한 인터넷 호스트와 포트번호를 기술함.
      • Host = "Host" ":" 호스트[":"포트]

// 예시
GET http://www.joes-hardware.com/index.html HTTP/1.0  
Connection: Keep-Alive  
User-Agent: Mozilla/4.51 [en] (X11; U; IRIX 6.2 IP22)  
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, `*/*`  
Accept-Encoding: gzip  
Accept-Language: en  
Host: www.joes-hardware.com
    • 다음과 같은 규칙이 있음.
      • 웹 클라는 모든 요청 메시지에 Host 헤더를 기술해야 함.
      • Host 헤더에 포트가 기술되어 있지 않으면, 해당 스킴의 기본 포트를 사용함.
      • 클라가 특정 프락시 서버를 사용하더라도 Host 헤더에는 프락시 서버가 아닌 원 서버의 호스트 명과 포트를 기술해야 함.
      • Host 헤더 필드가 없는 HTTP/1.1 요청을 받으면 400으로 응답함.
       
    • 아직 사용되고 있는 몇몇 낡은 브라우저들은 Host 헤더를 보내지 않음. 이럴 경우 서버는 사용자를 기본 웹페이지로 보내거나 브라우저를 업그레이드 하라고 제안하는 여러 페이지를 반환할 수 있음.
    • 모든 웹 서버는 HTTP/1.1을 통해 오는 리소스를 결정하려면 다음과 같은 규칙을 사용해야 함.
        1. HTTP 요청 메시지에 전체 URL이 기술되어 있으면, Host 헤더에 있는 값은 무시하고 URL을 사용한다.
        1. HTTP 요청 메시지에 있는 URL 에 호스트 명이 기술되어 있지 않고 요청에 Host헤더가 있으면, 호스트 명과 포트를 Host 헤더에서 가져온다.
        1. 1단계나 2단계에서 호스트를 결정할 수 없으면 클라이언트에 400 Bad Request 응답을 반환한다.
    • 이떤 브라우저 버전은 부정확한 Host 헤더를 보내는데, 특히 프락시를 사용하게 설정했을 때 그럼. 예를 들어, 프락시를 사용하도록 구성할 때 버전이 오래된 애플이나 포인트캐스트 클라이언트는 실수로 원 서버의 이름이 아닌 프락시의 이름을 Host 헤더에 담아 전송함.
      •  

안정적인 웹 사이트 만들기

  • 웹 사이트에 장애가 생기는 경우는 서버 다운, 트래픽 폭증, 네트워크 장애 또는 손실 등이 있음.
 
💡
이런 문제를 예측하고 대응하는 방법을 알아보자.
 
  • 미러링 된 서버 팜
    • 호스팅 업자는 복제 서버 더비(서버 팜)를 만들고 서버 팜에 부하를 분산할 수 있음.
      • notion image
    • 서버 팜은 서로 대신할 수 있고 식별할 수 있게 설정된 웹 서버들의 집합임. 서버팜의 서버에 있는 콘텐츠들은 한 곳에 문제가 생기면 다른 한 곳에서 대신 전달할 수 있게 미러링할 수 있음.
    • 미러링된 서버 팜에서, 마스터 원 서버는 복제 원 서버에 콘텐츠를 보낼 책임이 있음.
    • 미러링 된 웹 서버에는 다른 위치에 있는 콘텐츠와 정확히 같은 복제본이 있음.
    • 마스터 서버는 클라이언트에게 콘텐츠를 제공하면서 복제 서버들에게 콘텐츠를 퍼트리는 일을 함.
    • 클라이언트의 요청이 특정 서버로 가는 두 가지 방법
        1. HTTP 리다이렉션 - 콘텐츠에 대한 URL은 마스터 서버의 IP를 가리키고, 마스터 서버는 요청을 받는 즉시 복제 서버로 리다이렉트 시킴.
        1. DNS 리다이렉션 - 콘텐츠의 URL은 네 개의 IP주소를 가리킬 수 있고, DNS 서버는 클라이언트에게 전송할 IP주소를 선택할 수 있음.
  • 콘텐츠 분산 네트워크(CDN)
    • 콘텐츠 분산 네트워크는 특정 콘텐츠의 분산을 목적으로 하는 단순한 네트워크임.
    • 네트워크의 노드는 서버, 대리서버, 혹은 프락시 서버가 될 수 있음.
  • CDN의 대리 캐시
    • 대리 캐시는 복제 원 서버를 대신해 사용될 수 있음.
    • 대리서버는 리버스 프락시라고도 불리며, 웹 서버처럼 콘텐츠에 대한 요청을 받음.
    • 대리 서버는 보통 수요에 따라서 동작함.
    • 대리 서버는 원 서버의 전체 콘텐츠를 복사하지 않음.
    • CDN이 대리 서버보다 캐시를 계층화하기 더 어려움.
  • CDN의 프락시 캐시
    • 프락시 캐시는 어떤 웹 서버 요청이든지 다 받을 수 있음.
    • 프락시 캐시의 콘텐츠는 요청이 있을 때만 저장될 것이고 원본 서버 콘텐츠를 정확히 복제한다는 보장이 없음.
    • 레이어2 혹은 레이어3 장비가 중간에서 웹 트래픽을 가로채 처리하기도 함.
        • notion image
    • 가로채기 설정은, 클라이언트와 서버 사이의 모든 HTTP 요청이 물리적으로 캐시를 거치게 네트워크 설정을 할 수 있는지에 따라 달라짐.
 

웹 사이트 빠르게 만들기

  • 앞서 언급한 내용들은 웹 사이트를 더 빠르게 하는 데 도움 됨.
  • 서버 팜이나 분산 캐시 프락시 캐시나 대리 서버는 혼잡을 조절하고 네트워크 트래픽을 분산시킴.
  • 콘텐츠를 분산시키면, 그 콘텐츠를 사용자에게 더 가깝게 만들어 주므로 콘텐츠를 서버에서 클라로 전송하는 시간이 단축됨.
  • 리소스 로딩 속도를 좌우하는 핵심 요소는, 어떻게 요청과 응답이 클라와 서버 사이에서 연결을 맺고 인터넷을 가로질러 데이터를 전송하는지임.
  • 또 다른 방법은 콘텐츠를 인코딩하는 것임.