1. 1달 전

    18장 웹 호스팅

    HTTP 완벽 가이드 18장 정리

  2. 2달 전

    17장 내용 협상과 트랜스코딩

    HTTP 완벽 가이드 17장 정리

  3. 5달 전

    16장 국제화

    HTTP 완벽 가이드 16장 정리

  4. 5달 전

    15장 엔터티와 인코딩

    HTTP 완벽 가이드 15장 정리

  5. 6달 전

    14장 보안

    HTTP 완벽 가이드 14장 정리

  6. 7달 전

    12장 기본 인증

    HTTP 완벽 가이드 12장 정리

  7. 7달 전

    11장 클라이언트 식별과 쿠키

    HTTP 완벽 가이드 11장 정리

  8. 7달 전

    10장 HTTP 2.0

    HTTP 완벽 가이드 10장 정리

  9. 7달 전

    9장 웹 로봇

    HTTP 완벽 가이드 9장 정리

  10. 7달 전

    8장 통합점 게이트웨이, 터널, 릴레이

    HTTP 완벽 가이드 8장 정리

  11. 7달 전

    7장 캐시

    HTTP 완벽 가이드 7장 정리

  12. 7달 전

    6장 프락시

    HTTP 완벽 가이드 6장 정리

  13. 7달 전

    5장 웹서버

    HTTP 완벽 가이드 5장 정리

  14. 7달 전

    4장 HTTP 커넥션 관리

    HTTP 완벽 가이드 4장 정리

  15. 7달 전

    3장 HTTP 메시지

    HTTP 완벽 가이드 3장 정리

  16. 7달 전

    2장 URL과 리소스

    HTTP 완벽 가이드 2장 정리

  17. 7달 전

    1장 HTTP 개관

    HTTP 완벽 가이드 1장 정리

Tamm자바스크립트 웹 개발 환경을 좋아하고 사람들에게 재미를 주는 것에 관심이 많은 개발자 입니다.

18장 웹 호스팅

HTTP 완벽 가이드 18장 정리

featured image thumbnail for post 18장 웹 호스팅

콘텐츠 리소스를 저장, 중개, 관리하는 일을 통틀어 웹 호스팅이라고 한다. 물리적인 서버를 안전하게 관리하려면 꽤 노력이 필요하기 때문에 전문적으로 서버를 호스팅 해주는 IDC 회사가 생겨났다.

이번 장에서는 다음의 내용을 다룬다.

  • 여러 웹 사이트를 같은 서버에 "가상 호스팅"하는 방법. 그리고 그것이 HTTP에 끼치는 영향
  • 트래픽이 많은 상황에서 안정적인 사이트를 구축하는 방법
  • 웹 사이트 로딩을 더 빠르게 하는 방법

18.1 호스팅 서비스

웹 초기에 자체 컴퓨터 하드웨어를 구매하고 자체 망을 구축하여 직접 웹서버를 구축했다. 웹이 대세가 되면서 많은 사람들이 웹서버를 원했지만, 구축하는 비용과 관리하는 비용과 지식등이 필요해서 어려움이 있었다. 이에 전문적으로 관리하는 호스팅 서비스를 제공하는 사업이 만들어졌다.

18.1.1 간단한 예 : 전용 호스팅

ISP에서 서버를 한대 씩 임대하여 전용의 네트워크와 물리적인 서버를 사용하는 것

18.2 가상 호스팅

많은 사람들이 자신만의 웹사이트를 가지고 싶어 하는데, 전용 웹 서버를 사용하면 비용면에서 부담이 많았다. 그리고 많은 경우가 서버가 처리할 수 있는 양에 비해 적은 사용량도 적기 때문에 효율적인 면에서도 문제가 있었다.

호스팅 업체들은 효율적으로 호스팅을 하기 위해 가상 호스팅을 사용했다. 간단히 말하면 서버 한대에 여러명의 웹사이트를 동시에 호스팅하는 것이다. (실제로는 하나의 서버가 아니라 서버팜이라 불리는 서버 그룹들이 수백개, 수천개의 웹사이트를 호스팅한다.)

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

지금에야 문제가 없지만 당시에는 당장 가상 호스팅을 사용하기에는 문제가 있었다. 그 이유는 HTTP/1.0 은 HTTP 메시지가 서버에 전달하는데에 호스트 이름을 사용하지만, 메시지를 서버에 요청할 때는 단순히 GET /index.html 이라는 요청을 한다. 그러면 가상으로 호스팅한 여러 웹 서비스중 어떤 것을 원하는지 명확하지 않게 된다.

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

호스트 정보를 HTTP 요청 명세에 넣지 않은 것은, 각 웹 서버가 정확히 한 웹 사이트만 호스팅할 것이라 잘못 예측한 HTTP 명세의 실수였다. 물론 상대 경로가 아니라 완전한 URL를 사용하도록 하면 문제가 되지 않는다.

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

일반적으로, URL 기반의 가상 호스팅은 좋지 않은 방법이라 거의 사용하지 않는다.

http://test.com/joe/index.html

http://test.com/mary/index.html

GET /joe/index.html

GET /mary/index.html

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

서버당 비표준 포트를 할당하여 구분하는 방법. 사용자 입장에서 포트 번호를 주소에 입력해야 하기 때문에 별로다.

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

가상 웹 사이트마다 유일한 IP 주소를 할당하는 것이다. 모든 가상 서버의 IP 주소는 같은 공용 서버에 연결되어 있다. 서버는 HTTP 커넥션의 목적지 IP 주소를 통해 클라이언트가 어떤 웹 사이트에 접근했는지 명확히 알 수 있다.

일반적으로 컴퓨터 시스템이 연결할 수 있는 장비의 IP의 개수에는 제한이 있다. 수천개의 IP주소를 관리해야 하는데 비용이 크게 든다. IP 주소는 희소 상품이므로 가상 호스팅 업체에서 사용할 수 있는 IP 주소의 개수가 제한적이다

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

브라우저 대부분이 URL의 경로 컴포넌트만 서버에 전달하므로, 중요한 가상 호스트 명 정보는 받지 못한다. 브라우저가 전체 URL을 보내더라도 서버가 경로 컴포넌트만 받아 요청을 처리할 수 있기 때문에 다른 방법을 고안했다. Host 헤더를 추가하는 것이다.

Host 헤더는 HTTP/1.0+에서 처음 소개가 되었고 HTTP/1.1 명세에 추가되었다.

18.2.3 HTTP/1.1 Host 헤더

  • Host 헤더에 포트가 기술되어 있지 않으면, 해당 스킴의 기본 포트를 사용한다.
  • URL에 IP 주소가 있으면, Host 헤더는 같은 주소를 포함해야 한다.
  • URL에 호스트 명이 기술되어 있으면, Host 헤더는 같은 호스트 명을 포함해야 한다.
  • URL에 호스트 명이 기술되어 있으면, Host 헤더는 URL의 호스트명이 가리키는 IP 주소를 포함해서는 안된다.
  • 클라이언트가 특정 프락시 서버를 사용한다면, Host 헤더에 프락시 서버가 아닌 원 서버의 호스트명과 포트를 기술해야 한다.
  • 웹 클라이언트는 모든 요청 메시지에 Host 헤더를 기술해야 한다.

HTTP 요청이 Host 헤더를 포함하지 않으면 에러를 응답으로 줄 것이다.

Host 헤더 해석하기

가상 호스팅을 사용하지 않거나 지원하지 않는 서버에서는 Host 헤더 값을 무시할 것이다. 만약 Host 헤더에 값이 있다면, 다음의 절차대로 값을 얻어낸다.

  1. HTTP 요청 메시지에 전체 URL이 기술되어 있다면, Host 헤더에 값을 무시하고 전체 URL을 사용한다.
  2. HTTP 요청 메시지에 있는 URL에 호스트명이 기술되어 있지 않다면 Host 헤더에서 가져온다.
  3. 호스트명을 가져올 수 없다면 에러를 발생.

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

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

  • 서버 다운
  • 트래픽 폭증: 갑자기 많은 사람이 몰릴 때
  • 네트워크 장애나 손실

18.3.1 미러링 된 서버 팜

서버 팜은 서로 대신할 수 있고 식별할 수 있는 설정된 웹 서버의 집합이다. 미러링 된 서버는 원본 콘텐츠를 갖는 마스터 원 서버와 마스터 원 서버로 부터 콘텐츠를 받은 미러링 된 서버인 복제 원서버로 구성된다. 네트워크 스위치를 통해 분산 요청을 보내게 된다.

부하의 분산은 HTTP 리다이렉션방식과 DNS 리다이렉션 방식이 있다.

HTTP 리다이렉션

콘텐츠에 대한 URL은 마스터 서버의 IP를 가리키고, 마스터 서버는 요청을 받은 즉시 복제 서버로 리다이렉트 한다.

DNS 리다이렉션

콘텐츠의 URL은 네 개의 IP 주소를 가리킬 수 있고, DNS 서버는 클라이언트에게 전송할 IP 주소를 선택할 수 있다.

18.3.2 콘텐츠 분산 네트워크

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

18.3.3 CDN의 대리 캐시

대리 캐시는 복제 원 서버를 대신해 사용될 수 있다. 대리 캐시는 리버스 프락시라고도 불리는데, 미러링 된 웹 서버처럼 콘텐츠에 대한 요청을 받아 처리한다. 특정 대리 캐시는 특정 원 서버와 연결이 되어 원 서버에 요청을 일부 처리하게 된다.

미러링 된 원 서버와 대리 서버의 차이점은 미러링 된 원 서버처럼 콘텐츠의 전체를 복제하지 않고, 캐싱된 일부분을 가지고 있다는 점이다. 일부 대리 캐시 서버는 요청하지도 않은 콘텐츠를 미리 가져오는 기능을 제공하기도 한다.

18.3.4 CDN의 프락시 캐시

프락시 캐시는 대리 캐시와 다르게 별도의 연동이나 IP 주소 합의등이 필요없다.

프락시 캐시는 원 서버의 최신의 콘텐츠를 가지고 있다는 확신이 없다.

프락시 서버는 레이어2 혹은 레이어3 장비 중간에서 웹 트래픽을 가로채 처리하기도 한다.

18.4 웹 사이트 빠르게 만들기

서버 팜이나 분산 프락시 캐시나 대리 서버는 혼잡을 조절하고 네트워크 트래픽을 분산시킨다. 콘텐츠를 분산시키면, 그 콘텐츠를 사용자에게 더 가깝게 만들어 주므로 더 빠른 서비스를 만들 수 있다.

또 웹 사이트의 속도를 높이는 또다른 접근은 콘텐츠를 인코딩하는 것이다. (gzip 등)

Virtual hosting