Steady Study

ideveloper

Front end Developer who steadily study

Feb 1, 2020 - 7 min read

이 글은 HTTP 완벽가이드 18장을 참고해 정리한 포스팅입니다.

시작하기에 앞서

콘텐츠 리소스를 저장,중개,관리하는일을 통틀어 웹 호스팅이라고 합니다.
콘텐츠를 저장해서 제공하고 관련 로그에 접근하거나 그것을 관리하는데 서버가 필요합니다.

가상 호스팅

많은 웹 호스팅 업체들은 컴퓨터 한대를 여러 고객이 공유하게 해서 저렴한 웹 호스팅 서비스를 제공합니다.
- 이를 공유 호스팅 혹은 가상 호스팅 이라 부르게 됩니다.
각 웹 사이트는 다른 서버에서 호스팅하는 것처럼 보이겠지만, 사실은 물리적으로 같은 서버에서 호스팅되게 되는것입니다.
- 최종 사용자 관점에서는 가상 호스팅에 있는 웹 사이트는 물리적으로 분리된 전용 서버에서 호스팅하는 사이트와 구분할 수 없어야 합니다.
호스팅 업체들은 복제 서버 더미(서버 팜)를 만들고 서버팜에 부하를 분산할 수 있습니다.
- 팜에있는 각 서버는 다른 서버를 복제한 것이며, 수많은 가상 웹 사이트를 호스팅하고 있기 떄문에 관리자는 훨씬 편해집니다.

서버팜이란?

서버팜은 한곳에 집단으로 수용되어 동작되는 일련의 컴퓨터군을 말한다. 서버팜은 때로 서버 클러스터라고 불리기도 한다. 웹서버팜은 하나 이상의 서버를 가지고 있는 웹사이트 또는 다중 서버를 사용하여 웹호스팅 서비스를 제공하는 ISP를 지칭한다.

[http://www.terms.co.kr/serverfarm.htm 참고]

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

HTTP 1.0 명세는 공용 웹 서버가 호스팅하고 있는 가상 웹 사이트에 누가 접근하고 있는지 식별하는 기능을 제공하지 않습니다.
- ex) 클라이언트 A가 http://ideveloper2.dev/index.html에 접속하려고 하면 GET /index.html 요청만이 공용 웹서버에 전송 http://leeseungkyu.dev/index.html 도 마찬가지
- 따라서, 웹서버는 사용자가 어떤 웹 사이트로 접근하려고 하는지 아는데 필요한 정보가 충분하지 않게 됩니다. 두 요청이 완전히 다른 문서를(서로 다른사이트에) 요청하더라도, 요청자체는 똑같이 생기게 되기 때문입니다.

가상 호스팅 동작하게 하기

호스트 정보를 HTTP 요청 명세에 넣지 않은 것은, 각 웹서버가 정확히 한 웹 사이트만 호스팅할 것이라고 잘못 예측한 HTTP명세의 실수였다고 합니다. 따라서 HTTP 설계자들은 공유서버인 가상 호스팅을 고려하지 않게 된것이구요.
HTTP/1.1 을 지원하는 서버는 HTTP 요청 메시지에 있는 전체 URL을 처리할수 있어야 합니다. (모든 HTTP 요청메시지에 경로 컴포넌트만 보내는것이 아니라, 완전한 URL도 포함해 보내게 함)
기존 모든 애플리케이션이 위의 명세에 맞추어 업그레이드 하기까지는 오랜 시간이 걸릴것이라 판단했고 아래와 같은 네가지 기술이 나타났다고 합니다.
- URL 경로를 통한 가상 호스팅
- 포트번호를 통한 가상 호스팅
- IP 주소를 통한 가상 호스팅
- Host 헤더를 통한 가상 호스팅

url 경로를 통한 가상 호스팅

웹 사이트마다 특정 경로를 아래와 같이 붙이는 방식. 그러나 불필요한 접두어가 생기므로 좋지는 않은 방법.

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

웹서버에 각각 다른 포트번호를 할당하는 방식, 사용자들은 URL에 비표준 포트를 쓰지 않고서도 리소스를 찾길 원하기 때문에 좋지는 않은 방법.

IP 주소를 통한 가상 호스팅

가상 웹 사이트에 유일한 IP 주소를 한 개 이상 부여하는 방식. ex) http://ideveloper2.dev/ 에 208.172.32.3 할당

클라이언트가 http://ideveloper2.dev/index.html 를 요청
클라이언트는 ip주소를 요청해 208.172.32.3를 받음
클라이언트는 208.172.32.3에 있는 공용 웹 서버에 tcp 커넥션을 맺음
클라이언트는 GET /index.html/1.0 요청을 보냄
웹서버가 응답을 전송하기에 앞서, 실제 목적지 IP주소(208.172.32.3)를 기록하고, 이것이 죠의 웹 사이트에 대한 가상 IP주소라는 것을 판단해 /ideveloepr 하위 디렉토리에서 요청을 처리 /ideveloper/index.html을 반환

가상 IP 호스팅 방식은 잘 동작하지만, 규모가 아주 큰 호스팅 업체 에게는 약간 어려운 문제를 안겨주게 되는데 이는 아래와 같습니다. 아래와 같은 문제들이 있긴 하지만, 널리 쓰이는 방식입니다.

일반적으로 컴퓨터시스템이 연결할 수 있는 장비의 IP 개수에는 제한이 있습니다. 호스팅 업체들은 수백 혹은 수천개의 가상 사이트를 포함하는 공용서버를 제공해야 하는데, 이는 큰 문제입니다.
IP주소는 희소상품인데 복제 서버 갯수만큼 더 필요해지게 됩니다.

Host 헤더를 통한 가상 호스팅

IP 주소의 낭비와 가상 IP의 제한 문제를 피하려면, 가상 사이트들이 같은 IP를 사용하더라도 각 사이트가 어디에 속해 있는지 알수 있어야합니다. 이 문제를 해결하기 위해 서버개발자들은 서버가 원 호스트 명을 받아 볼수 있게 HTTP를 확장하였습니다. 또한,HTTP/1.1 명세를 따르려면 Host헤더를 반드시 기술해야 합니다.

HTTP/1.1 Host 헤더

문법과 사용 방법

Host 헤더에는 원본 URL에 있는 요청 리소스에 대한 인터넷 호스트와 포트번호를 기술하게 됩니다.

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

그리고 아래와 같은 규칙이 있습니다.

Host 헤더에 포트가 기술되어 있지 않으면, 해당 스킴의 기본 포트를 사용합니다.
URL에 IP 주소가 있으면, Host 헤더는 같은 주소를 포함해야 합니다.
URL에 호스트 명이 기술되어 있으면, Host 헤더는 같은 호스트 명을 포함해야 합니다.
URL에 호스트명이 기술되어 있으면, Host 헤더는 URL의 호스트 명이 가리키는 IP주소를 포함해서는 안됩니다.
- 여러개의 가상 사이트를 한개의 IP에 연결한 가상 호스트 서버에서 문제상황 발생 가능
클라이언트가 특저 프락시 서버를 사용한다면, Host 헤더에 프락시 서버가 아닌 원 서버의 호스트명과 포트를 기술해야 합니다.
웹 클라아언트는 모든 요청 메시지에 Host헤더를 기술해야 합니다.
HTTP/1.1 웹 서버는 Host 헤더 필드가 없는 HTTP/1.1 요청 메시지를 받으면 400 상태코드로 응답해야 합니다.

안정적인 웹 사이트 만들기

웹 사이트에 장애가 생기는 몇가지 상황이 있는데 아래와 같습니다.

서버 다운
트래픽 폭증
네트워크 장애나 손실

미러링된 서버 팜

서버팜은 서로 대신할 수 있고, 식별할 수 있게 설정된 웹 서버들의 집합입니다. 서버 팜의 서버에 있는 콘텐츠들은 한 곳에 문제가 생기면 다른 한곳에서 대신 전달할 수 있게 미러링할수 있습니다.
보통, 미러링된 서버는 계층적인 관계에 있게 됩니다. 한서버는 콘텐츠의 원본 제작자 같이 행동하게 됩니다. 이서버를 마스터 원 서버라 부르게 됩니다. 마스터 원 서버로부터 콘텐츠를 받은 미러링 된 서버는 복제 원서버라 부르게 됩니다.
서버 팜에 배포하는 간단한 방법 하나는, 네트워크 스위치를 사용해서 서버에 분산 요청을 보내는 것입니다. 서버에 호스팅 되고 있는 각 웹 사이트의 IP 주소는 스위치의 IP주소가 됩니다.

아래 그림의 분산된 미러링 서버의 시나리오에는 클라이언트 요청이 특정 서버로 가는 두가지 방법이 있게 됩니다.

HTTP 리다이렉션

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

DNS 리다이렉션

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

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

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

CDN의 대리 캐시

리버스 프록시라고도 불리는 대리서버는 미러링 된 웹 서버처럼 콘텐츠에 대한 요청을 받게 됩니다. 또한 특정 원 서버 집합을 대신해 요청을 받게 됩니다.
대리 서버와 미러링된 서버의 차이점은 대리서버는 보통 수요에 따라서 동작한다는 점입니다. 대리서버는 원 서버의 콘텐츠 전체를 복사하지는 않고 클라이언트가 요청하는 콘텐츠만 저장하게 됩니다.
대리 서버의 캐시에 콘텐츠가 분산되는 방식은 받는 요청에 따라 달라지게 됩니다.
원서버는 대리서버의 콘텐츠를 업데이트 해줄 의무는 없고, 대리서버는 많은 요청이 있는 콘텐츠를 빠르게 제공하기 위해 동작하고, 사용자가 요청하기도 전에 콘텐츠를 가져오는 미리 가져오기 기능을 가진 대리서버도 있습니다.

CDN의 프락시 캐시

대리서버와는 다르게, 전통적인 프락시 캐시는 어떤 웹 서버 요청이든지 다 받을수 있게 됩니다. 하지만 대리 서버를 사용하면, 프락시 캐시의 콘텐츠는 요청이 있을때만 저장되게 됩니다.

프록시, 리버스 프록시에 대한 설명 https://jcdgods.tistory.com/322

웹 사이트 빠르게 만들기

서버 팜이나 분산 프록시 캐시나 대리 서버는 혼잡을 조절하고 네트워크 트래픽을 분산시킵니다. 콘텐츠를 분산 시키면, 그 콘텐츠를 사용자에게 더 가깝게 만들어 주므로 콘텐츠를 서버에서 클라이언트로의 전송하는 시간이 단축되게 됩니다.

여러가지 웹 콘텐츠 배포 기술

FrontPage

FrontPage는 "FrontPage Web" 이라는 개념을 단위로 모든 작업을 진행하게 됩니다. 물론 로컬 웹이나 각각의 파일 단위로도 작업은 가능합니다. 쉽게 말해 프로젝트단위라고 생각하면 쉬울 것 같습니다. FrontPage Web은 모든 페이지들과 그림들 그리고 웹을 구성하는 모든 파일을 포함하고 있습니다. 웹 제작자는 프런트페이지 웹을 만들고 지우며 열고 닫을 수 있습니다.

WebDAV

WebDAV(Web Distributed Authoring and Versioning, 웹 분산 저작 및 버전 관리)는 하이퍼텍스트 전송 프로토콜(HTTP)의 확장으로, 월드 와이드 웹 서버에 저장된 문서와 파일을 편집하고 관리하는 사용자들 사이에 협업을 손쉽게 만들어 줍니다.
- 출처: https://studyforus.tistory.com/40 [Study For Us]

network