이 글은 책 ‘그림으로 배우는 HTTP & Network Basic’ 를 읽고 내용에 필자의 생각과 지식을 덧붙여 정리한 내용이다. 책 내용과 100% 일치하지 않을 수 있으며, 개인적인 견해나 경험이 들어갈 수 있다.
1대로 멀티 도메인을 가능하게 하는 가상 호스트
HTTP/1.1 에서는 하나의 HTTP 여러개의 도메인을 연결하여 서로 다른 웹사이트 여러개를 실행할 수 있다. 이를 위해 사용되는 기술이 가상 호스트이다. 가상 호스트를 사용하면 물리적으로는 서버가 한대지만 여러대의 서버인 것 처럼 운영할 수 있다.
도메인은 결국 DNS 서버를 거쳐서 IP로 변환된다. HTTP 요청이 서버에 도착한 시점에는 도메인이 아닌 IP 주소를 기준으로 서버에 액세스하게 된다. 서로 다른 도메인이라고 하더라도 같은 IP를 가리키고 있으면, 결국 같은 서버로 요청이 향하게 된다. 따라서 이를 구분하기 위해서는 호스트명과 도메인명을 완전하게 포함한 URI를 지정하거나 Host 헤더 필드에 지정해야한다고 한다.
(추가) 만약, mail.naver.com 이라는 주소가 있다고 했을 때, ‘mail’이 호스트명이 되고, ‘naver.com’이 도메인명이 된다. 이 둘을 합친 것을 Fully Qualified Domain Name(FQDN) 라고한다.
통신을 중계하는 프로그램 : 프록시, 게이트웨이, 터널
프록시, 게이트웨이, 터널 프로그램 혹은 서버는 서버와 클라이언트 사이를 중계하는 역할을 한다.
프록시
서버, 클라이언트 양쪽 역할을 하는 중계 프로그램이다. 클라이언트의 요청을 서버로 보내고, 서버의 응답을 클라이언트로 보낸다. 클라이언트의 요청 URI를 변경하지 않고 리소스를 가지고 있는 서버에 요청한다. 이때, 리소스 원본을 가지고 있는 서버를 오리진(origin) 서버라고 한다.
프록시 서버를 여러대 경유하는 것도 가능하다. 이때 아래와 같이 via 라는 응답 헤더 필드에 경유한 호스트 정보를 추가해야한다. 아래 예시는 응답이 proxy2와 proxy1을 거쳐 도달했을 때 클라이언트가 받은 HTTP 응답 헤더이다.
HTTP/1.1 200 OK
Via: proxy2, proxy1또한 조직 내부에 프록시 서버를 설치하여 특정 리소스에 액세스하는 것을 제한할 수 있다. 또한 캐시 목적으로도 사용된다.
캐싱 프록시 (Caching Proxy)
프록시 서버가 리소스의 캐시를 보관해두는 유형이다. 프록시 서버에 한번 캐싱된 요청에 대해서 다시 요청이 오게되면, 프록시 서버가 오리진 서버에 요청하는 것이 아니라 자신이 가지고 있는 캐시를 응답해주는 방식이다. 이를 통해 네트워크 대역을 효율적으로 관리할 수 있다.
투명 프록시 (Transparent Proxy)
프록시가 중계할 때 메시지를 변경하지 않은 유형을 투명 프록시라고 한다. 반대로 메시지를 변경한다면 이를 비투과 프록시라고 한다.
게이트웨이
게이트웨이는 프록시와 유사하다. 프록시는 같은 프로토콜을 사용하는 서버간 중계를 담당한다면, 게이트웨이는 서로 다른 프로토콜간 통신이 가능하도록 중계하는 역할을 담당한다. 즉, 클라이언트가 HTTP로 게이트웨이에 요청하면, 게이트웨이는 HTTP 외의 프로토콜을 통해 원 서버와 통신하여 그 응답을 클라이언트에게 HTTP로 전달한다.
또한 클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로써 통신의 안전성을 높일 수 있다.
터널
SSL 같은 암호화 통신을 위해 터널이 사용된다. 터널은 HTTP 요청을 해석하지 않고 그대로 다음 서버에 중계한다. 그리고 통신하고 있는 양쪽 끝이 끊어질 때 종료한다. 터널은 클라이언트 입장에서 투명한 존재이므로 클라이언트는 딱히 의식할 필요는 없다.
리소스를 보관하는 캐시
캐시는 클라이언트와 프록시 서버의 디스크에 저장된 리소스의 복사본을 가리킨다. 캐시를 사용해서 원 서버에 대한 요청을 줄일 수 있어서 통신시간과 통신량을 줄일 수 있어서 네트워크를 조금 더 효율적으로 사용할 수 있다.
흔히 이야기하는 캐시 서버는 프록시 서버의 일정이다.
캐시는 유효기간이 있다.
캐시에 유효기간이 없다면, 원본 리소스가 변경되어도 클라이언트는 오래된 리소스를 계속 사용하는 상황이 올 수도 있다. 따라서 캐시에 유효기간을 두어 오리진 서버에 유효성을 확인하거나, 갱신된 리소스를 획득하러 가는 경우가 있다.
클라이언트 측에도 캐시가 있다.
캐시 서버만 캐시를 가지고 있는 것이 아니라 클라이언트의 브라우저도 캐시를 가질 수 있다. 이 또한 캐시 서버와 마찬가지로 오래된 캐시라고 판단하면 오리진 서버에 유효성을 판단하러 가거나, 새로운 리소스를 획득하러 갈 수 있다.