HTTP완벽가이드 스터디 17, 18장

http://tlog.tammolo.com/blog/17-http/

어떻게 여러 언어로 콘텐츠를 제공할 수 있을까?

배리언트(variant): 콘텐츠를 각기 다른 언어로 표현한 것

내용 협상 : 하나의 URL에서 어떤 배리언트를 사용자에게 제공할까?

17.1 내용 협상 기법

3가지가 존재, 클라이언트 주도, 서버 주도, 투명

17.2 클라이언트 주도 협상

클라이언트가 언어를 선택할 페이지를 제공

장점: 구현이 쉽다. 명확하게 선택할 수 있다.

단점: 의도한 콘텐츠를 접근하는 데 최소 두 번의 요청이 필요하다.

17.3 서버 주도 협상

클라이언트가 서버에게 선호하는 언어의 정보를 헤더를 통해 전달

• 내용 협상 헤더 (Accept 관련 헤더)
• User-Agent

17.3.1 내용 협상 헤더

17.3.2 내용 협상 헤더의 폼질값

Accept: [ text/html, application/json, image/* ... ] Accept-Language: fr-CH, fr;q=0.9, en;q=0.8 de;q=0.7, *;q=0.5 Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1 Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1

17.3.3 그 외의 헤더들에 의해 결정

User-Agent를 보고 오래된 시스템이면 별도의 처리가 필요할 수 있다.

17.3.4 아파치의 내용 협상

아래의 type-map 파일을 통해 적절한 문서를 내려준다.

URI: test.html URI: test.en.html Content-Type: text/html Content-Language: en URI: test.ko.html Content-Type: text/html; charset=utf-8 Content-Language: ko, en

17.3.5 서버 측 확장

17.4 투명한 협상

서버 주도 협상을 좀 더 확장해보면, 서버측에서 내용 협상 헤더를 통해 특정 배리언트를 응답으로 내려주었을 것이다. 그런데 캐시 서버 입장에서는 특정 URL에 응답만 가억할 것이다. 이 때 다른 내용 협상 헤더를 가지고 같은 URL로 요청을 하면 캐시 서버는 엉뚱한 언어의 응답을 내려줄 수 있다.

HTTP/1.1 명세에 투명 협상에 대한 메카니즘을 정의하지 않았지만, 캐시에 관한 Vary 헤더를 정의했다. 서버에서 User-Agent와 Accept-Language를 참조하여 응답을 내려줬다면, 응답에 다음처럼 Vary 헤더에 추가하는 것이다.

Vary: User-Agent, Accept-Language

그러면 다음에 같은 URL로 요청이 왔을 때 User-Agent와 Aceept-Laguage가 일치할 때만 캐시된 응답을 내려주게 된다.

17.5 트랜스코딩

HTML → WML

고해상도 이미지 → 저해상도 이미지

64K색 이미지 → 흑백 이미지

프레임이 복잡한 페이지 → 단순히 텍스트만 가진 페이지

광고가 있는 페이지 → 광고가 없는 페이지

 

 

http://tlog.tammolo.com/blog/18-http/

Tlog

콘텐츠 리소스를 저장, 중개, 관리하는 일을 통틀어 웹 호스팅이라고 한다. 물리적인 서버를 안전하게 관리하려면 꽤 노력이 필요하기 때문에 전문적으로 서버를 호스팅 해주는 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