필오의 개발일지

콘텐츠 리소스를 저장, 중개, 관리하는 일을 통틀어 웹 호스팅이라 한다.
필요한 하드웨어나 소프트웨어를 직접 관리하기 어렵다면,
호스팅 서비스나 호스팅 업체가 필요할 것이다.
호스팅 업체는 서버와 웹 사이트 관리 프로그램을 대여해주고
다양한 등급의 보안, 리포트, 사용 편의를 제공한다.
1. 호스팅 서비스
웹이 빠르게 대세가 되면서,
모든 사람이 웹 사이트를 원했지만,
냉난방 장치가 있는 서버실을 짓고, 도메인 이름을 등록하고, 네트워크 대역폭을 구매할 기술과 시간을 가진 사람은 드물었다.
그 시간을 절약하기 위해, 전문적으로 관리하는 웹 호스팅 서비스를 제공하는 여러 신사업이 만들어졌다.
물리적인 장비관리 ~ 고객이 직접 콘텐츠를 제공할 수 있는 총괄적인 웹 호스팅까지
다양한 종류의 서비스들이 있다.
1.1 예: 전용 호스팅
참고 wiki
GoDaddy의 전용호스팅
2. 가상 호스팅
많은 웹 호스팅 업자는 컴퓨터 한 대를 여러 고객이 공유하게 해서
저렴한 웹 호스팅 서비스를 제공한다.
이를 공유호스팅 혹은 가상호스팅 이라고 부른다.
각 웹사이트는 다른 서버에서 호스팅하는 것처럼 보이겠지만,
사실은 물리적으로 같은 서버에서 호스팅되는 것이다.
최종 사용자의 관점에서 가상 호스팅에 있는 웹사이트는,
물리적으로 분리된 전용 서버에서 호스팅 하는 사이트와 구분할 수 없어야 한다.
가상 호스팅은 비용, 공간, 관리에 이점이 있으므로,
가상 호스팅을 제공하는 업체는 한 서버에 여러 개의 웹 사이트를 호스팅하려고 한다.
하지만 그것이 PC한대에 웹 사이트 여러 개를 구축한다는 뜻은 아니다.
호스팅 업자는 복제 서버 더미(서버 팜)를 만들고
서버팜에 부하를 분산할 수 있다.
팜에 있는 각 서버는 다른 서버를 복제한 것이며,
수많은 가상 웹사이트를 호스팅하고 있기 때문에 관리자는 훨씬 편해진다.
2.1 호스트 정보가 없는 가상 서버 요청
HTTP/1.0 명세는 공용 웹 서버가 호스팅하고 있는 가상 웹사이트에
누가 접근하고 있는지 식별하는 기능을 제공하지 않는다.
https://feel5ny.github.io/index.html을 요청한다면, HTTP/1.0 요청은 호스트명에 대한 별다른 언급 없이 “GET /index.html”이라는 요청을 한다.
서버가 여러개의 사이트를 가상 호스팅하고 있으면, 사용자가 어떤 가상 웹 사이트로 접근하려고 하는것인지 아는 데 필요한 정보가 충분하지 않다.
HTTP 대리 서버와 인터셉트 프락시 또한
어떤 사이트를 요청하는지에 관한 정보가 필요하다.
2.2 가상 호스팅 동작하게 하기 VirtualHost
HTTP 설계자들이 공유 서버인 가상 호스팅을 고려하지 않았다.
이를 해결하기 위해서, HTTP 요청 메세지에
완전한 URL도 포함해서 보내게 해서 간단히 해결하였다.
URL경로를 통한 가상 호스팅
서버가 어떤 사이트를 요청하는 것인지 알 수 있게
URL에 특별한 경로 컴포넌트를 추가한다.
“GET /joy/index.html” 조이 사이트에 대한 요청이다.
“GET /grey/index.html” 그레이 사이트에 대한 요청이다.
거의 사용하지 않는다.
포트번호를 통한 가상 호스팅
각 사이트에 다른 포트번호를 할당,
분리된 웹 서버의 인스턴스가 요청을 처리한다.
IP 주소를 통한 가상 호스팅
각 가상 사이트에 별도의 IP 주소를 할당하고, 모든 IP 주소를 장비 하나에 연결한다.
웹 서버는 IP 주소로 사이트 이름을 식별한다.
각 가상 웹 사이트에 유일한 IP 주소를 한 개 이상 부여한다. 모든 가상 서버의 IP주소는 같은 공용 서버에 연결되어 있다.
예
http://feel5ny.github.io은 210.89.164.90
http://feel5ny.me는 210.89.164.91 이라고 가정해보자
클라A는 http://feel5ny.github.io/index.html을 요청한다.
클라A는 IP 주소를 요청해 210.89.164.90를 얻는다.
클라A는 210.89.164.90에 공용 웹서버에 TCP 커넥션을 맺는다.
클라A는 “GET /index.html HTTP/1.0” 요청을 보낸다.
실제 목적지 IP 주소를(210.89.164.90) 기록하고,
이것이 조이의 웹사이트에 대한 가상IP 주소라는 것을 판단하고 요청을 처리한다.
클라B도 유사하게 처리된다.
규모가 큰 호스팅 업자에게는 약간 어려운 문제점이 있다.
컴퓨터 시스템이 연결할 수 있는 장비의 IP 갯수는 제한되어있다.
IP주소는 희소 상품이다. 
IP주소가 부족한 문제는 호스팅 업자가 용량을 늘리려고 서버를 복제하면서 더 심각해진다.
위의 문제점이 있지만 많이 사용되는 방식이다.
참고
IP 기반 가상호스팅 관련: 아파치
Host 헤더를 통한 가상 호스팅
HTTP/1.1에 Host 요청 헤더를 정의했다.
웹 서버는 Host 헤더로 가상 사이트를 식별할 수 있다.
브라우저와 서버 개발자들은 서버가 원 호스트 명을 받아 볼 수 있게 HTTP를 확장했다.
모든 요청에 호스트 명(그리고 포트)를 Host 확장 헤더에 기술해서 전달한다.
2.3 HTTP/1.1 Host 헤더
RFC 7230
문법과 사용방법
Host 헤더에 포트가 기술되어 있지 않으면, 해당 스킴의 기본 포트를 사용한다.
URL에 IP주소가 있으면, Host 헤더는 같은 주소를 포함해야 한다.
URL에 호스트 명이 기술되어 있으면,
Host 헤더는 같은 호스트 명을 포함해야 한다.
Host 헤더는 URL의 호스트명이 가리키는 IP 주소를 포함해서는 안된다.
여러개의 가상 사이트를 한개의 IP주소에 연결한 가상 호스트 서버에서 문제가 될 수 있기 때문
클라가 특정 프락시 서버를 사용한다면
Host헤더에는 origin 서버의 호스트명과 포트를 기술해야 한다.
웹 클라는 모든 요청 메세지에 Host헤더를 기술해야 한다.
웹 프락시는 요청을 전달하기 전에 요청 메세지에 Host 헤더를 추가해야 한다
HTTP/1.1 웹 서버는
Host 헤더 필드가 없는 HTTP/1.1 요청 메세지를 받으면
400 상태 코드로 응답해야 한다. 
Host 헤더 해석하기
호스트를 기준으로 리소스를 구분하는 모든 웹 서버는 HTTP/1.1을 통해 오는 리소스를 결정하려면 다음과 같은 규칙을 사용해야 한다.
HTTP 요청 메세지에 
전체 URL이 기술되어 있으면
Host 헤더에 있는 값은 무시하고
URL을 사용한다.
전체 URL이 기술되어 있지 않고
요청에 Host 헤더가 있으면, 호스트 명과 포트를 Host 헤더에서 가져온다.
전체 URL이나 Host 둘다 없을 경우
클라에게 400 Bad Request 응답을 반환한다.
Host헤더는 누가 자동 셋팅을?
Host나 Connection같이, 셋팅하는 코드를 넣지 않았는데
네트워크 탭에서 보면 종종 request 헤더에 포함되어있는 것을 보았다.
이는 브라우저 엔진 내부에서 자동으로 셋팅해준다.
예) chromium
자동 셋팅해주는 헤더는 어디서 확인 가능할까?
크롬 확장 api중 webRequest API에는 라이프사이클이 존재하는데 onBeforeSendHeaders라는 콜백으로 확인 가능하다.
참고
3. 안정적인 웹사이트 만들기
웹 사이트에 장애가 생기는 몇가지 상황
서버다운
트래픽 폭증
네트워크 장애나 손실
3.1 미러링 된 서버 팜
서버팜은 서로 대신할 수 있고 식별할 수 있게 설정된 웹 서버들의 집합이다.
서버팜의 서버에 있는 콘텐츠들은 한 곳에 문제가 생기면,
다른 한 곳에서 대신 전달할 수 있게 미러링 할 수 있다.
미러링된 서버는 계층적인 관계에 있다.
한 서버는 (원본 콘텐츠를 가지고 있는) ‘콘텐츠의 원본 제작자’ 같이 행동한다.
=> 마스터 원 서버라 부른다. Master Origin Server
마스터 원 서버로부터 콘텐츠를 받은 미러링된 서버는
=> 복제 원 서버라 부른다. Replica Origin Server
서버 팜에 배포하는 간단한 방법 하나는
네트워크 스위치를 사용해서 서버에 분산 요청을 보내는 것이다.
서버에 호스팅 되고 있는
각 웹사이트의 IP주소는
스위치의 IP주소가 된다.
마스터 원 서버는 복제 원 서버에 콘텐츠를 보낼 책임이 있다.
외부에서 볼 때, 이 콘텐츠를 가리키는 IP주소는 스위치의 IP주소다.
스위치는 서버에게 요청을 전송해야 하는 책임이 있다.
미러링된 웹 서버에는 다른 위치에 있는 콘텐츠와 정확히 같은 복제본이 있다.
위 그림의 시나리오에서는, 클라의 요청이 특정 서버로 가는 2가지 방법이 있다.
HTTP 리다이렉션
: 콘텐츠에 대한 URL은 마스터 서버의 IP를 가리키고,
 마스터 서버는 요청을 받는 즉시 복제 서버로 리다이렉트 시킨다.
DNS 리다이렉션
: 콘텐츠의 URL은 4개의 IP주소를 가리킬 수 있고,
 DNS 서버는 클라에게 전송할 IP주소를 선택할 수 있다.
3.2 콘텐츠 분산 네트워크 CDN
Contents Delivery Network
콘텐츠 분산 네트워크 CDN 은 특정 콘텐츠의 분산을 목적으로 하는 단순한 네트워크이다.
네트워크의 노드는 
서버 
대리 서버 
프락시 서버
가 될 수 있다.
기본적으로 사용자가 원격지에 있는 서버(Origin Server)로 부터 Content(예. Web Object, Video, Music, Image, Document 등)를 다운로드 받을 때 가까이 있는 서버에서 받는 것보다 시간이 오래 걸리므로, 사용자와 가까운 곳에 위치한 Cache Server에 해당 Content를 저장(캐싱)하고 Content 요청시에 Cache Server가 응답을 주는 기술입니다.
참고
3.3 CDN의 대리 캐시 ( == 리버스 프락시 )
Gateway 캐시: 실제 요청을 담당하는 서버에서 관리되는 캐시
== Reverse 프락시 : forward 프락시의 반대 방향
대리 서버는 복제 원 서버를 대신해 사용될 수 있다.
대리 서버는 미러링 된 웹 서버처럼, 콘텐츠에 대한 요청을 받는다.
그들은 특정 원 서버 집합을 대신해 요청을 받는다.
이는 콘텐츠에 대한 IP주소가 알려졌기 때문에 가능하다.
보통 원 서버와 대리 서버가 연결되며, 대리 서버는 특정 원 서버를 가리키는 요청을 받는다.
??
대리 서버와 미러링 된 서버의 차이점
대리 서버는 수요에 따라서 동작한다.
대리 서버는 원서버의 전체 콘텐츠를 복사하지 않는다.
클라이언트가 요청하는 콘텐츠만 저장할 뿐이다.
대리 서버의 캐시에 콘텐츠가 분산되는 방식은
그들이 받는 요청에 따라 달라진다.
원 서버는 그들의 콘텐츠를 업데이트 해 줄 의무는 없다. 
많은 요청이 있는 콘텐츠를 빠르게 제공하려고,
사용자가 요청하기도 전에 콘텐츠를 가져오는 “미리 가져오기 기능“을 가진 대리 서버도 있다.
3.4 CDN의 프락시 캐시
네트워크 레이어 캐시: ISP, 방화벽에 설치됨. shared cache
전통적인 프락시 캐시는 어떤 웹 서버 요청이든지 다 받을 수 있다.
대리 서버를 사용하면,
프락시 캐시의 콘텐츠는 요청이 있을 때만 저장될 것이고,
원본 서버 콘텐츠를 정확히 복제한다는 보장이 없다.
어떤 프락시는 요청이 많이 받는 콘텐츠를 미리 로딩하기도 한다.
요청이 있을 때만 저장하는 프락시 캐시
레이어2 혹은 레이어3 장비(스위치 혹은 라우터)가 중간에 웹 트래픽을 가로채 처리하기도 한다.
가로채기 설정은, 클라와 서버 사이의 모든 HTTP 요청이 물리적으로 캐시를 거치게 네트워크 설정을 할 수 있는지에 따라 달라진다.
콘텐츠는 받는 요청에 따라서 캐시에 분산된다.
4. 웹 사이트 빠르게 만들기
서버 팜이나 분산 크락시 캐시, 대리 서버는 혼잡을 조절하고 네트워크 트래픽을 분산시킨다.
콘텐츠를 분산시키면,
그 콘텐츠를 사용자에게 더 가깝게 만들어 주므로,
콘텐츠를 서버에서 클라로의 전송하는 시간이 단축된다.
리소스의 로딩속도를 좌우하는 요소
리다이렉션
어떻게 요청과 응답이 클라와 서버 사이에서 연결을 맺고 인터넷을 가로질러 데이터를 전송하는 지.
인코딩 콘텐츠를 인코딩 하는 것.
HTTP 완벽가이드 책을 보고 이해한 내용을 정리 한 글입니다.
참고자료
Reverse 프록시 관련
캐시 관련

웹 호스팅

댓글