HTTP와 연계하는 웹 서버

1대로 멀티 도메인을 가능하게 하는 가상 호스트

HTTP/1.1에서는 하나의 HTTP서버에 여러 개의 웹사이트를 실행할 수 있습니다.

이를 위해 사용하는 것이 가상호스트라는 기능인데 가상 호스트 기능을 사용하면 물리적으로는 서버가 1대지만 가상으로는 여러대가 있는 것처럼 설정이 가능합니다. 이는 HTTP1.1 호스트 헤더를 이용해서 가상 호스트를 제공하는 기능과 동일합니다.

 

HTTP를 사용해서 클라이언트가 서버에 액세스할 때는 www.hackr.jp와 같은 호스트 명이나 도메인 명이 자주 사용됩니다.

인터넷 도메인명은 DNS에 의해서 IP주소로 변환되고나서 액세스되고,

리퀘스트가 서버에 도착한 시점에는 IP주소를 기준으로 액세스하게 됩니다.

이 때 1대의 서버 안에 두개의 도메인이 있을 경우 어느 쪽에 대한 액세스인지 알 수 없지만 같은 IP주소에서 다른 호스트명과 도메인 명을 가진 여러 개의 웹사이트가 실행되고 있는 가상 호스트의 시스템이 있기 때문에 HTTP리퀘스트를 보내는 경우에는 호스트명과 도메인명을 완전하게 포함한 URI를 지정하거나 반드시 Host 헤더 필드에서 지정해야합니다.

위 예제를 보면 실제로는 하나의 서버지만 HTTP클라이언트 입장에서는 bar, foo 두개의 서버가 존재하는 것처럼 인식됩니다. 서비스 제공자 입장에서는 동일한 /service라는 주소 패턴으로 서로 다른 서비스를 제공할 수 있습니다.

통신을 중계하는 프로그램 : 프록시, 게이트웨이, 터널

HTTP는 클라이언트와 서버 이외에 프록시(Proxy), 게이트웨이(Gateway), 터널(Tunnel)과 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능합니다.

이러한 프로그램과 서버는 그 다음에 있는 다른 서버에 리퀘스트를 중계하고 그 서버로부터 받은 리스폰스를 클라이언트에 반환하는 역할을 담당합니다.

Proxy

서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램으로 클라이언트로부터의 리퀘스트를 서버에 전송하고 서버로부터 리스폰스를 클라이언트에게 전송합니다.

클라이언트로 부터 받은 리퀘스트 URI를 변경하지 않고 서버에 보내며 리소스 본체를 가진 서버를 오리진 서버(Origin Server)라고 부릅니다.

HTTP 통신을 할 때 프록시 서버를 여러 대 경유하는 것도 가능합니다. 체인과 같이 여러 대를 경유해서 리퀘스트와 리스폰스를 중계해가고 중계할 때에는 Via 헤더필드에 경유한 호스트 정보를 추가해야합니다.

 

 

Via 헤더필드 : 브라우저로 응답을 보낸 프록시 클라이언트 정보

메시지가 지나는 각 중간 노드(프록시나 게이트웨이)의 정보 나열

이 필드는 메시지 전달을 추적하고, 메시지 루프를 진단하고, 요청과 응답 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다.

Via가 개인정보 보호와 보안에 미치는 영향

via를 통해 호스트 이름과 포트가 노출되면 이를 악의적인 집단에서 이용할 수도 있기 때문에, 보안 경계선에 존재하는 프록시는 호스트 명을 적당한 가명으로 교체해줘야한다.

또 강력한 보안 요구 사항이 있을 경우, 여러 경유지 항목들이 하나로 뭉뚱그려지기도 한다.

 

프록시를 사용하는 이유

• 캐시를 사용해서 네트워크 대역 등을 효율적으로 사용
• 조직 내에 특정 웹사이트에 대한 액세스 제한
• 액세스 로그를 획득하는 정책을 철저하게 지키는 용도 (보안)
• 콘텐츠 라우터 : 요청을 가까운 복제 캐시로 전달
• 트랜스 코더 : 프록시 서버는 콘텐츠를 클라이언트에 전달하기 전에 본문 포맷을 수정가능 (ex : 크기를 줄이기 위해 gif이미지를 jpg이미지로 변환)
• 익명화 프록시 : HTTP 메시지에서 신원을 식별할 수 있는 특성들 (클라이언트IP, From헤더, 쿠키, URI세션 아이디)제거

프록시의 사용방법은 2개의 기준으로 분류

• 캐싱 여부
• 메시지 변경여부

 

캐싱 프록시

프록시로 리스폰스 중계시에 프록시 서버상에 리소스 캐시를 보존해두는 타입의 프록시.

프록시에 같은 리소스에 리퀘스트가 온 경우 오리진 서버로 리소스를 획득하는 것이 아니라 캐시를 리스폰스로서 되돌려주는 것 등이 있음.

투명 프록시

프록시로 리퀘스트와 리스폰스를 중계할 때 메시지 변경을 하지 않는 타입.

메시지 변경하는 타입은 비투과 프록시라고 합니다.

 

클라이언트 - 포워드 프록시 - 인터넷 - 리버스 프록시 - 서버

의 방향으로 요청이 전달됩니다.

포워드 프록시 : 불필요한 헤더 제거를 역할로 사용합니다.

브라우저로 요청 보내보면 IP나 불필요한 헤더들이 많은데 지우고 싶어도 못지우는 경우가 많습니다. 브라우저가 직접 헤더들을 넣어서 보내버리기 때문

그래서 포워드 프록시를 만들면 불필요한 헤더들을 지워버릴 수 있습니다.

또 혹시나 실수로 악성 서버에 요청을 보내는 등의 실수를 포워드 프록시의 필터링을 통해 요청이 아예 안가게 할 수 있습니다.

즉 포워드 프록시는 클라이언트에서 서버로 요청이 갈 때 진짜 가도 되는지 검열, 점검, 필터링을 해준다고 보면 됩니다.

리버스 프록시 : 불필요한 요청이 온 경우 필터링

리버스 프록시로 유명한 것들은 Apache나 Nginx(비동기)가 역할을 해주거든요.

HTTPS를 적용해주는 역할도 해줍니다.

정적 파일 서빙 (Html, Css, Js, Image, Font) 이런 파일들의 요청은 진짜 서버를 거치지 않고 프록시에서 자체적으로 먼저 제공을 해줄 수 있습니다.

위의 작업을 프록시가 하는 이유는 프록시가 서버보다 더 일처리를 잘 하기 때문입니다.

프록시 사용의 가장 큰 이유는 요청에 대한 필터링

Gateway

게이트웨이는 그 다음에 있는 서버가 HTTP서버 이외의 서비스를 제공하는 서버가 됩니다.

서로 다른 프로토콜과 애플리케이션 간의 HTTP인터페이스.

클라이언트와 서버 사이를 암호화하는 등으로 안전하게 접속함으로써 통신의 안전성을 높이는 역할 등을 합니다.

클라이언트 측 게이트웨이와 서버 측 게이트웨이

• 웹 게이트웨이는 한쪽에서는 HTTP로 통신하고 다른 한쪽에서는 HTTP가 아닌 다른 프로토콜로 통신
  • 서버 측 게이트웨이는 클라이언트와 HTTP로 통신하고, 서버와는 외래 프로토콜로 통신
  • 클라이언트 측 게이트웨이는 클라이언트와 외래 프로토콜로 통신하고, 서버와는 HTTP로 통신

Tunnel

터널은 요구에 따라 다른 서버와의 통신 경로를 확립합니다. 이 때 클라이언트는 SSL같은 암호화 통신을 통해 서버와 안전하게 통신을 하기 위해 사용합니다.

터널 자체는 HTTP 리퀘스트를 해석하지 않고 그대로 다음 서버에 중계합니다.

터널 자체는 투명한 존재이기 때문에 클라이언트는 너무 의식할 필요 없습니다.

리소스를 보관하는 캐시

캐시는 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스 사본을 가리킵니다.

캐시를 사용하면 리소스를 가진 서버 액세스를 줄이기 때문에 통신량과 통신시간을 절약할 수 있습니다.

 

캐시 서버

캐시 서버는 프록시 서버중 하나로 캐싱 프록시로 분류됩니다. 프록시 서버상에 리소스의 사본을 보존합니다.

클라이언트는 네트워크에 가까운 서버로부터 리소스를 얻을 수 있고 서버는 같은 리퀘스트를 매번 처리하지 않아도 됩니다.

캐시의 장점

• 불필요한 데이터 전송을 줄여 네트워크 비용 감소
• 서버에 대한 요청을 줄여의 부하를 줄일 수 있다.
• 먼 거리로 인한 응답지연을 줄일 수 있다.

오리진 서버에 있는 리소스는 변경될 수 있기 때문에 캐시 내에 있는 사본이 유효한 값인지 알 수 있어야합니다.

그래서 재검사 요청을 보내고 서버에서 3가지 응답을 할 수 있습니다.

1. 재검사 적중 서버 객체가 캐시된 사본과 같으면 403 Not Modified 응답을 보내고 캐시 사본 반환
2. 재검사 부적중 서버 객체와 캐시된 사본이 다르다면 200 OK 응답을 보내고 캐시된 사본을 갱신
3. 객체 삭제 서버 객체가 삭제되었다면, 404 Not Found 응답을 보내며, 캐시는 사본을 삭제한다

재검사 요청을 하는건 그 헤더만 보내서 재검사 요청 속도는 서버에 직접 요청하는 것보다 빠르다.

캐시의 플로우

캐시는 유효기간이 있다.

캐시에는 유효기간이 있고 오리진 서버에 있는 원래 리소스가 갱신될 수 있습니다.

클라이언트 측에도 캐시가 있다.

브라우저가 유효한 캐시를 가지고 있는 경우, 같은 리소스의 액세스는 서버에 액세스하지 않고 로컬 디스크로부터 불러옵니다.

또한 캐시 서버와 마찬가지로 리소스가 오래된 것으로 판단된 경우 오리진 서버에 리소스의 유효성을 확인하러 가거나 새로운 리소스를 다시 획득하러 가는 일이 있습니다.