가상 호스트
하나의 서버에서 여러 도메인을 호스팅하는 방법을 말함
->
-> 이를 통해 하나의 물리적 서버와 IP 주소에서 여러 웹 사이트, 각각의 도메인 이름을 가진 웹 사이트를 호스팅 가능
위 경우는 Name-Based Virtual Host
-> 같은 IP주소를 가지고 여러개의 호스트 명을 가짐
반면 Ip-Based Virtual Host
-> 각 웹 사이트마다 다른 IP Address 또는 Port를 가짐
예를 들어, 웹 호스팅을 제공하는 있는 사업자는 1대의 서버에 여러 고객의 웹사이트를 넣을 수 있음
-> 가상 호스트 기능을 사용하면 물리적으론 서버가 1대지만, 가상으로 여러 대가 있는 것 처럼 설정 가능
P 주소가 192.168.0.100인 하나의 웹 서버가 있다고 가정
-> example1.com과 example2.com이라는 두 개의 웹사이트를 소유하고 있고, 이 두 웹사이트를 모두 하나의 서버에서 호스팅하고 싶다(두 주소를 클라이언트 쪽에서 입력하여 DNS 서버에서 IP주소로 변환했을때 둘의 IP 주소는 같다)
-> 가상 호스트를 구분하는 데 필요한 정보를 웹 서버에 전달하는 데는 요청 URI와 HOST 헤더 필드를 통해서 호스트명과 도메인 이름이 필요
-> 가상 호스팅을 사용하면, 서버가 example1.com과 example2.com에 대한 요청을 인식할 수 있도록 설정할 수 있고 각 도메인에 대한 적절한 웹사이트 컨텐츠를 반환할 수 있다
요약하자면
웹 서버에서 실행되는 여러 웹 사이트가 같은 IP 주소에 연결되어 있는 경우, 각 웹 사이트를 구분하기 위해 가상 호스트 기술이 사용
-> 사용자가 example1.com을 요청하면, 서버는 example1.com에 호스팅된 웹사이트에 대한 HTML, CSS, JavaScript 파일을 반환. 사용자가 example2.com을 요청하면, 서버는 example2.com에 호스팅된 웹사이트에 대한 HTML, CSS, JavaScript 파일을 반환
통신을 중계하는 프로그램(프록시, 게이트웨이, 터널)
HTTP는 클라이언트와 서버 이외에 Proxy, Gateway, Tunnel과 같은 이 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능
-> 이러한 프로그램과 서버는 그 다음에 있는 다른 서버에 리퀘스트를 중계하고, 그 서버로부터 받은 리스폰스를 클라이언트에 반환하는 역할 수행
프록시
서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램으로, 클라이언트로부터의 리퀘스트를 서버에 전송하고, 서버로부터의 리스폰스를 클라이언트에 전송
서버를 경유해서 리퀘스트와 리스폰스를 릴레이 할때마다 Via 헤더 필드에 경유한 호스트 정보를 추가해야 함
조직 내에 프록시 서버를 설치하여 특정 URI등으로 엑세스를 제한 하는 것도 가능
사용 하는 이유
캐시를 사용해서 네트워크 대역 등을 효율적으로 사용하거나, 조직 내에 특정 웹 사이트에 대한 엑세스 제한, 엑세스 로그를 획득하는 정책을 철저하게 지키려는 목적으로 사용하는 경우가 있음
사용법 2가지
-
캐싱 프록시(Caching Proxy : 캐시하는지 안하는지 여부)
리스폰스를 중계할 때,프록시 서버 상에 리소스 캐시를 보존해 두는 타입의 프록시
-> 이후 같은 리소스에 대한 리퀘스트가 온 경우, 오리진 서버로부터 리소스를 획득하는 것이 아니라 캐시를 리스폰스로서 되돌려 줌 -
투명 프록시(Transparent Proxy)
프록시로 리퀘스트나 리스폰스를 중계할때 메세지 변경을 하지 않는 타입의 프록시
-> 메세지의 변경을 가하는 타입은 비투과 프록시라고 부름
게이트웨이
동작은 프록시와 유사하지만 게이트웨이는 그 다음에 있는 서버가 HTTP 서버 이외의 서비스를 제공하는 서버
-> 클라이언트와 게이트웨이 사이를 암호화하여 안전하게 접속함으로써 통신의 안전성을 높이는 역할을 함
-> ex) 게이트웨이는 DB에 접속해 SQL 쿼리를 사용해서 데이터를 얻거나, 쇼핑 사이트에서 신용 결제 시스템 등과 연계할때 사용
터널
터널은 두 개의 네트워크 사이에서 트래픽을 전달하는 중계 서버
-> 일반적으로 터널은 보안상의 이유로 사용되어 트래픽을 암호화하거나 다른 네트워크 프로토콜을 사용하는 트래픽을 전달함
-> 예를 들어, 개인 네트워크에서 인터넷에 액세스하는 경우 터널을 통해 암호화된 트래픽을 전송
즉 SSL과 같은 암호화 통신을 통해 서버와 안전하게 통신하기 위해서 사용하며 터널 자체는 HTTP 리퀘스트를 해석하려 하지 않고 리퀘스트를 그대로 다음 서버에 중계함
리소스를 보관하는 캐시
캐시란 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 사본을 가리킴
-> 사용시 통신량과 통신시간을 절약할 수 있다
캐시 서버는 프록시 서버 중 하나로 캐싱 프록시로 분류 됨
캐시를 사용함으로써 같은 데이터를 몇번이고 오리진 서버에 전송할 피요가 없음
-> 즉 클라이언트는 네트워크에서 가까운 서버로 부터 리소스를 얻을 수 있게되어 오리진 서버는 같은 리퀘스트를 매번 처리하지 않아도 됨
캐시 서버에 캐시가 있는 경우라도 같은 리소스의 리퀘스트에 대해 항상 캐시를 돌려준다곤 볼 수 없음!
-> 캐시 되어 있는 리소스의 유효성과 관계가 있음(ex: 오리진 서버에 있는 리소스가 갱신되는 경우, 캐시 서버는 갱신되기 전의 낡은 리소스를 그대로 보냄)
-> 따라서 캐시를 가지고 있더라도 클라이언트의 요구나 캐시의 유효기간 등의 의해서 오리진 서버에 리소스의 유효성을 확인하거나 새로운 리소스를 다시 획득하러 가는 경우가 있음
캐시 서버만 캐시를 가지는 것은 아니며, 클라이언트가 사용하는 브라우저에서도 캐시를 가질 수 있음
-> 클라이언트가 보존한 캐시를 인터넷 임시파일이라 부르며, 브라우저가 유효한 캐시를 가지고 있는 경우 같은 리소스에 대한 엑세스는 서버에 엑세스 하지 않고 로컬 디스크로 부터 불러 옴
-> 이 또한 오래된 것으로 판단된다면 오리진 서버에 리소스 유효성을 확인 하러 가거나, 새로운 리소스를 다시 획득하러 가는 경우 존재
