[HTTP] 24. 웹 호스팅

콘텐츠 리소스를 저장, 중개, 관리하는 일을 통틀어 웹 호스팅이라고 한다.

호스팅은 웹 서버의 가장 중요한 기능으로, 콘텐츠를 저장해서 제공하고 관련 로그에 접근하거나 관리하는 데에는 모두 서버가 필요하다.

하드웨어나 소프트웨어를 직접 관리하기 어렵다면 호스팅 서비스나 호스팅 업체가 필요할 것이다.

18.1 호스팅 서비스

각 개인이 자체 컴퓨터 하드웨어를 구매하고 망을 구축하는 비용이 크기 때문에, 전문적으로 호스팅만 해주는 사업이 생겨났다.

18.1.1 간단한 예 : 전용 호스팅 ( 생략 )

18.2 가상 호스팅

대부분의 시간동안 놀고 있을 사이트를 위해 전용 웹 서버를 가지는 것은 낭비기 때문에, 많은 웹 호스팅 업자는 컴퓨터 한 대를 여러 고객이 공유하게 해서 저렴한 호스팅 서비스를 제공한다.

이를 공유 호스팅 혹은 가상 호스팅이라고 한다. 최종적인 사용자 입장에서는 전용 서버와 호스팅 하는 사이트 사이를 구분할 수 없어야 한다.

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

HTTP/1.0 에서만 해당하는 이야기인데, 공유 호스팅을 하게 되더라도 HTTP/1.0에서는 호스트 명에 대한 별 다른 언급이 없어서 서로 다른 사이트에 가도 GET/index.html 라는 로그만 남긴다.

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

위처럼 호스트 정보를 HTTP 요청 명세에 넣지 않은 것은 웹 서버가 정확히 한 웹 사이트만 호스팅할 거라고 예측한 HTTP 명세의 실수였다.

HTTP 설계자들은 가상 호스팅을 고려하지 않았고, URL에 있는 호스트 명은 필요없는 것으로 생각해 제외하고, 단순히 경로 컴포넌트만 전송하면 된다고 여겼다.

따라서 초기 명세에서, 가상 호스팅 업자들은 필요한 차선책과 컨벤션을 직접 개발해야 했다.

그 문제는 모든 HTTP 요청 메시지에 경로 컴포넌트만 보내는 것이 아니라 완전한 URL도 포함해 보내게 해서 간단히 해결했다.

아래 4가지 방법이 나오는데, 이 중에서 1.1 프로토콜에는 마지막 방법이 표준으로 들어간다.

URL 경로를 통한 가상 호스팅

공용 서버에 있는 각 가상 사이트에 서로 다른 URL 경로를 할당해서 각각을 강제로 구분할 수 있다. ( 호스트 명을 대체할 다른 정보를 추가로 작성한다. )

• joe/index.html
• mary/index.html

이렇게 특정 사용자들을 둬서 구분하기도 했다. 하지만 이는 좋은 방법이 아니다. 게다가, 일반적인 홈페이지로 갈 때는 호환이 되지 않는다.

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

경로 명을 변경하는 것 대신에 포트 번호를 다르게 할당하여, 포트 번호에 따라 구분할 수 있다. 하지만 이것도 같은 문제가 있는데, 사용자는 URL에 비표준 포트를 쓰지 않고서도 리소스를 찾길 원한다.

IP 주소를 통한 가상 호스팅

훨씬 더 좋은 접근 방법은 가상 IP를 할당하는 것이다. 이 방식은 각 가상 웹 사이트에서 유일한 IP 주소를 한 개 이상 부여한다. 모든 가상 서버의 IP 주소는 같은 공용 서버에 연결되어 있다.

서버는 HTTP 커넥션의 목적지 IP 주소를 보고 클라이언트가 어떤 사이트에 연결하려고 하는지 알 수 있다.

문제점은 IP 개수에 제한이 있다는 점, IP 주소가 희소하다는 점.

Host 헤더를 통한 가상 호스팅

Host 확장 헤더를 기술해서 전달했다. ( 이제는 모든 브라우저가 Host 헤더를 지원한다. 1.1 버전에서는 RFC 2068에 등록된 요청 헤더이다. )

18.2.3 HTTP/1.1 Host 헤더

Host = "Host" ":" 호스트[":"포트]

• 헤더에 포트가 기술되지 않으면 해당 스킴의 기본 포트를 사용한다.
• Host 헤더는 IP 주소와 호스트 명 둘 다 올 수 있다.
  • URL에 IP 주소가 있으면 Host 헤더는 같은 주소를 포함해야 한다.
  • URL에 호스트 명이 기술되어 있으면 Host 헤더는 같은 호스트 명을 포함해야 한다. IP 주소는 포함해서는 안 된다. 해당 IP 주소가 여러 가상 사이트를 가졌을 수도 있기 때문이다.
    • 프락시에게 혼란을 준다.
• 웹 클라이언트는 무조건 모든 요청 메시지에 Host 헤더를 기술해야 한다.
• 웹 프락시는 요청을 전달하기 전에 요청 메시지에 Host 헤더를 추가해야 한다.
• HTTP/1.1 웹 서버는 Host 헤더 필드가 없는 HTTP/1.1 요청 메시지를 받으면 400 상태 코드로 응답해야 한다.

Host 헤더의 누락

서버는 기본 웹 페이지를 보내거나 브라우저를 업그레이드하라고 제안하는 에러 페이지를 반환할 수 있다.

Host 헤더 해석하기

가상 호스팅을 지원하지 않는 원 서버는 요청 받는 호스트에 따라서 리소스가 달라지지 않기 때문에 Host 헤더 값을 무시할 것이다.

하지만 호스트를 기준으로 리소스를 구분하는 모든 웹 서버는 아래와 같은 규칙을 따른다.

1. HTTP 요청 메시지에 전체 URL이 기술되어 있으면 Host 헤더에 있는 값은 무시하고 URL을 사용한다.
2. URL에 Host 명이 기술되지 않고 요청의 Host 헤더가 있으면 호스트명과 포트를 Host 헤더에서 가져온다.
3. 위 두 단계에서 호스트를 파악할 수 없으면 400 Bad Request 응답을 반환한다.

Host 헤더와 프락시 ( 생략 )

18.3 안정적인 웹 사이트 만들기

웹 사이트에 장애가 생기는 것은, 서버 다운, 트래픽 폭증, 네트워크 장애나 손실 등의 상황이 있다.

18.3.1 미러링 된 서버 팜

서버 팜은 서로를 대신할 수 있고 식별할 수 있게 설정된 웹 서버들의 집합이다.

서버 팜의 서버에 있는 콘텐츠들은 서로에게 문제가 생기면 다른 한 곳에서 대신 전달할 수 있게 미러링되어 있다. 보통 미러링 된 서버는 계층적인 관계가 있다.

한 서버는 콘텐츠의 원본 제작자처럼 행동한다. 이 서버를 마스터 원 서버라고 부른다. 마스터 원 서버로부터 콘텐츠를 받은 미러링 서버는 복제 원 서버라고 부른다.

여러 서버를 묶는 스위치의 IP에 요청을 보내서 콘텐츠를 제공받는다.

HTTP 리다이렉션이나 DNS 리다이렉션을 통해 마스터 서버는 요청을 받는 즉시 복제 서버로 보내줄 수 있다.

18.3.2 콘텐츠 분산 네트워크

콘텐츠 분산 네트워크 ( CDN ) 은 특정 콘텐츠의 분산을 목적으로 하는 단순한 네트워크로, 네트워크의 노드는 서버, 대리 서버, 프락시 서버가 될 수 있다.

18.3.3 CDN의 대리 캐시

대리 캐시는 복제 원 서버를 대신해 사용된다. 리버스 프락시라고도 불리는 대리 서버는 미러링 된 웹 서버처럼 콘텐츠에 대한 요청을 받는다.

대리 서버와 미러링 된 서버의 차이점은, 대리 서버는 보통 수요에 따라서 동작한다는 것으로, 대리 서버는 원 서버의 전체 콘텐츠를 복사하지는 않는다.

클라이언트가 요청하는 콘텐츠만 저장할 뿐이다.

18.3.4 CDN의 프락시 캐시

대리서버와는 다르게, 전통적인 프락시 캐시는 어떤 웹 서버 요청이든 다 받을 수 있다. ( 캐시와 원 서버 간의 연동이나 IP 주소 합의가 필요 없다. )

18.4 웹 사이트 빠르게 만들기 ( 생략 )