[http 완벽 가이드] 18장 웹 호스팅

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

18장 웹 호스팅

• 콘텐츠 리소스를 저장, 중개 ,관리하는 일을 통틀어 웹 호스팅이라한다.
• 필요한 하드웨어와 소프트웨어를 직접 관리하기 어렵다면, 호스팅 서비스나 호스팅 업체가 필요할 것이다.
• 호스팅 업체는 서버와 웹 사이트 관리 프로그램을 대여해주고 다양한 등급의 보안, 리포트, 사용 편의를 제공한다.
• 보통 호스팅 업체는 경제적이면서도 믿을 수 있고 성능 좋은 웹 사이트를 제공하기 위해 잘 손상되지 않는 공용 웹 서버에 올린다.

1. 호스팅 서비스

• 웹이 빠르게 대세가 되면서, 모든 사람이 웹 사이트를 원했지만, 냉난방 장치가 있는 서버실을 짓고 도메인 이름을 등록하고 네트워크 대역폭을 구매할 기술과 시간을 가진 사람은 드물다.
• 이를 위해 전문적으로 관리하는 웹 호스팅 서비스를 제공하는 여러 신산업이 만들어졌다.

1.1 간단한 예: 전용 호스팅

• 호스팅 서비스를 제공하는 업체에서 대여할 수 있는 고성능 웹 서버들로 구성된 랙을 가지고 있다.
• 호스팅 서비스가 유지보수하면서 가지고 있는 서버를 임대해서 자신의 사이트를 만들 수 있다.

2 가상 호스팅

• 많은 사람이 트래픽이 높은 사이트는 아니더라도 웹 공간을 가지고 싶어 한다.
• 이런 사람들의 웹 공간은 대부분의 시간 동안에는 놀고 있을 것이기 때문에, 이들에게 한 달에 수백 달러라는 비용이 드는 전용 웹 서버를 제공하는 것은 낭비이다.
• 많은 웹 호스팅 업자는 컴퓨터 한 대를 여러 고객이 공유하게 해서 저렴한 웹 호스팅 서비스를 제공한다.
• 사용자는 물리적으로 다른 사이트이지만 실제론 같은 컴퓨터에서 호스팅을 한 것이다.
• 트래픽이 올라가기 전까지는 가상 호스팅을 통해 비용을 절약할 것이다.

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

• HTTP/1.0에는 가상 호스팅 업자가 골머리를 앓을 만한 설계 관련 결함이 있다.
• HTTP/1.0 명세는 공용 웹 서버가 호스팅하고 있는 가상 웹 사이트에 누가 접근하고 있는지 식별하는 기능을 제공하지 않는다.
• 웹 서버는 사용자가 어떤 웹 사이트로 접근하려고 하는지 아는데 필요한 정보가 충분하지 않다.
• 문제는 웹 사이트 호스트 정보가 요청에서 제거된다는 것

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

• 가상 호스팅에 보내는 요청이 정확하게 어느 사이트를 지칭하지 모르는 이유는 HTTP/1.0 에 가상 호스팅을 고려하지 않았기 때문이다.
  • 호스팅 명을 빼고 호스팅한 서버에 보내기 때문
• 이를 해결한 HTTP/1.1은 완전한 URL을 보내서 누구한테 보내는지 알 수 있다.
• 이 방법 전에는 다음과 같은 방법을 사용했다.
  • URL 경로를 통한 가상 호스팅
  • 포트번호를 통한 가상 호스팅
  • IP 주소를 통한 가상 호스팅
  • Host 헤더를 통한 가상 호스팅
  • URL 경로를 통한 가상 호스팅
  • 포트번호를 통한 가사 호스팅
  • IP 주소를 통한 가상 호스팅

2.3 HTTP/1.1 Host 헤더

• Host 헤더는 RFC 2068에 정의되어 있는 HTTP /1.1 요청 헤더이다.
• 가상 서버는 매우 흔하기 때문에 대부분의 HTTP 클라이언트가 HTTP / 1.1 과 호환되지 않더라고 Host헤더는 구현한다.
• Host 헤더의 누락
  • 몇몇 낡은 브라우저가 Host 헤더를 보내지 않는다면 서버는 기본 웹페이지나 다른 웹페이지를 보낸다.
• Host 헤더 해석하기
  • HTTP 요청 메시지에 전체 URL이 기술되어 있으면 Host 헤더에 있는 값은 무시하고 URL을 사용
  • HTTP 요청 메시지에 있는 URL 에 호스트 명이 기술되어 있지 않고 요청에 Host 헤더가 있으면, 호스트 명과 포트를 Host 헤더에서 가져온다.
  • 1단계나 2단계에서 호스트를 결정할 수 없으면 클라이언트에 400 응답을 반환한다.
• Host 헤더와 프락시
  • 가끔 프락시는 Host 헤더에 자신의 이름을 담아 전송한다.

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

• 웹 사이트 장애가 생기는 몇 가지 상황이 있다.
  • 서버 다운
  • 트래픽 폭증
  • 네트워크 장애나 손실

3.1 미러링 된 서버

• 서버 팜은 서로 대신할 수 있고 식별할 수 있게 설정된 웹 서버들의 집합이다.
• 서버 팜의 서버에 있는 콘텐츠들은 한 곳에 문제가 생기면 다른 한 곳에서 대신 전달할 수 있게 미러링 할 수 있다.
• 마스터 원 서버로 부터 동일한 콘텐츠를 가진 복제 서버들로 구성되어 있고 스위치를 통해 서버를 향해 요청을 보낸다.
• 클라이언트의 요청이 특정 서버로 가는 두 가지 방법이 있다.
  • HTTP 리다이렉션: 콘텐츠에 대한 URL은 마스터 서버의 IP를 가리키고 마스터 서버가 상황에 맞게 복제 서버에 리다이렉트를 한다.
  • DNS 리다이렉션: 콘텐츠의 URL 은 네 개의 IP 주소를 가리킬 수 있고 , DNS 서버는 클라이언트에게 전송할 IP 주소를 선택할 수 있다.

3.3 CDN의 대리 캐시

• 대리 캐시는 복제 원 서버를 대신해 사용될 수 있다.
• 대리서버는 리버스 프락시라고도 불리며, 웹 서버처럼 콘텐츠에 대한 요청을 받는다
• 대리 서버는 보통 수요에 따라서 동작한다
• 대리 서버는 원 서버의 전체 콘텐츠를 복사하지 않는다
• CDN이 대리 서버보다 캐시를 계층화하기 더 어렵다

3.4 CDN의 프락시 캐시

• 프락시 캐시는 어떤 웹 서버 요청이든지 다 받을 수 있다.
• 프락시 캐시의 콘텐츠는 요청이 있을 때만 저장될 것이고 원본 서버 콘텐츠를 정확히 복제한다는 보장이 없다
• 레이어2 혹은 레이어3 장비가 중간에서 웹 트래픽을 가로채 처리하기도 한다
• 가로채기 설정은, 클라이언트와 서버 사이의 모든 HTTP 요청이 물리적으로 캐시를 거치게 네트워크 설정을 할 수 있는지에 따라 달라진다.