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

18.1 호스팅 서비스

많은 사람이 웹 사이트를 원하지만 냉난방 장치가 있는 서버실을 짓고 도메인 이름을 등록하고 네트워크 대역폭을 구매할 기술과 시간을 가진 사람은 드물기 때문에 이를 전문적으로 관리하는 웹 호스팅 서비스들이 만들어졌다. 물리적 공간 및 냉난방 등의 장비 관리부터 고객이 직접 콘텐츠를 제공할 수 있는 총체적인 웹 호스팅까지 다양한 종류의 서비스들이 있다.

 

18.2 가상 호스팅

많은 웹 호스팅 업자는 컴퓨터 한 대를 여러 고객이 공유하게 해서 저렴한 웹 호스팅 서비스를 제공한다. 이를 공유 호스팅 혹은 가상 호스팅이라 부른다. 호스팅 업자는 서버 팜이라고 부르는 복제 서버 더미를 만들고 서버 팜에 부하를 분산할 수 있다. 가상 호스팅은 비용, 공간, 관리에 이점이 있기 때문에 만약 웹 서버를 구축해야 할 정도로 트래픽이 올라가는 것이 아니라면 비용을 절약하기 위해 가상 호스팅을 이용할 수 있다.

하지만 HTTP/1.0 명세는 공용 웹 서버가 호스팅하고 있는 가상 웹 사이트에 누가 접근하고 있는지 식별하는 기능을 제공하지 않는다. 때문에 웹 서버는 사용자가 어떤 웹 사이트로 접근하려고 하는지 아는데 필요한 정보가 충분하지 않다. 완전히 다른 문서를 요청하더라도 요청 자체가 "GET /index.html"처럼 똑같이 생긴 경우가 발생했을 때, 웹 사이트 호스트 정보가 요청에서 제거되기 때문에 어떤 사이트를 요청하는지에 관한 정보가 필요하다.

가상 호스팅 동작하게 하기

가상 호스팅을 동작하게 하기 위한 네 가지 기술이 있다.

• URL 경로를 통한 가상 호스팅 : 이 방법은 좋지 않은 방법이라 잘 사용되지는 않는다. 서버가 어떤 사이트를 요청하는지 알 수 있게 URL에 특별한 경로를 추가한다. ex. "GET /joe/index.html", "GET /mary/index.html"
• 포트번호를 통한 가상 호스팅 : 웹 서버에 각각 다른 포트번호를 할당하는 방법인데, 실제 사용자는 URL에 비표준 포트를 쓰지 않고서도 리소스를 제공받기 원하기 때문에 문제가 있다.
• IP 주소를 통한 가상 호스팅 : 가상 웹 사이트에 유일한 IP 주소를 한 개 이상 부여하는 방법이다. 모든 가상 서버의 IP 주소는 같은 공용 서버에 연결되어 있지만, 서버는 HTTP 커넥션의 목적지 IP 주소를 보고 클라이언트가 어떤 웹 사이트에 연결하려고 하는지 알 수 있다. 일반적으로는 잘 동작하지만 만약 규모가 큰 호스팅 업자라면 약간의 어려움이 있다. 일반적으로 컴퓨터 시스템이 연결할 수 있는 장비의 IP 개수에는 제한이 있고, IP 주소가 부족한 경우도 있을 수 있다.
• Host 헤더를 통한 가상 호스팅 : IP 주소의 낭비와 가상 IP의 제한 문제를 피하기 위해, 같은 IP를 사용하더라도 각 사이트가 어디에 속해 있는지 알 수 있어야 한다. 이를 해결하기 위해 서버가 원 호스트 명을 받아볼 수 있게 HTTP를 확장했다. Host 헤더는 HTTP/1.0+에서 처음 소개되었으며 HTTP/1.1 명세를 따르려면 Host 헤더를 반드시 기술해야 한다.

HTTP/1.1 Host 헤더

Host = "Host" ":" 호스트 [ ":" 포트 ]
Host: www.joes-hardware.com

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

Host 헤더 해석하기

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

 

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

웹 사이트에는 서버 다운, 트래픽 폭증, 네트워크 장애나 손실 등의 장애가 발생할 수 있다. 이를 해결하는 방법이 몇 가지 존재한다.

미러링 된 서버 팜

서버팜은 서로 대신할 수 있고 식별할 수 있게 설정된 웹 서버들의 집합이다. 한 곳에 문제가 생기면 다른 한 곳에서 대신 전달할 수 있게 미러링할 수 있다. 원본 콘텐츠를 가지고 있는 콘텐츠의 원본 제작자의 역할을 하는 서버를 마스터 원 서버라 부른다. 그리고 콘텐츠를 받은 미러링된 서버는 복제 원 서버라 부른다.

클라이언트의 요청이 특정 서버로 가는 두 가지 방법으로는 HTTP 리다이렉션과 DNS 리다이렉션이 있다.

CDN(콘텐츠 분산 네트워크)

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

• CDN의 대리 캐시 : 대리 캐시는 리버스 프락시라고도 불리며, 복제 원 서버를 대신해 사용될 수 있다. 대리 서버와 미러링 된 서버의 차이점은, 대리 서버는 수요에 따라서 동작한다는 것이며 원 서버의 전체 콘텐츠를 복사하지 않고 클라이언트가 요청하는 콘텐츠만 저장한다. 많은 요청이 있는 콘텐츠를 빠르게 제공하기 위해 사용자가 요청하기 전에 콘텐츠를 가져오는 '미리 가져오기' 기능을 가진 대리 서버도 있다.
• CDN의 프락시 캐시 : 대리 서버와는 다르게, 전통적인 프락시 캐시는 어떤 웹 서버 요청이든지 다 받을 수 있다. 하지만 대리 서버를 사용하면, 프락시 캐시의 콘텐츠는 요청이 있을 때만 저장될 것이고 원본 서버 콘텐츠를 정확히 복제한다는 보장이 없다.

 

18.4 웹 사이트 빠르게 만들기

서버 팜이나 분산 프락시 캐시나 대리 서버는 혼잡을 조절하고 네트워크 트래픽을 분산시킨다. 이를 통해 콘텐츠를 사용자에게 더 가깝게 만들어 주므로 콘텐츠를 서버에서 클라이언트로의 전송하는 시간이 단축된다. 이 외로, 콘텐츠를 인코딩하는 방법을 통해 속도를 개선할 수도 있다.