##본 포스팅은 '그림으로 배우는 Http & Network Basic - 우에노 센'을 읽고 쓴 요약/정리 글입니다.
1대로 멀티 도메인을 가능하게 하는 가상 호스팅
HTTP/1.1에서는 하나의 HTTP 서버에 여러 개의 웹 사이트를 실행할 수 있다.
웹 호스팅을 제공하고 있는 사업자는 1대의 서버에 여러 고객의 웹 사이트를 넣을 수 있다.
고객마다 다른 도메인을 가지고, 다른 사이트를 실행할 수 있다.
이를 위해 가상 호스트라는 기능을 사용하고 있다.
가상 호스트 기능을 사용하면 물리적으로는 서버가 1대지만 가상으로 여러대가 있는 것처럼 설정하는 것이 가능하다.
도메인명은 DNS에 의해서 IP 주소로 변환되고 나서 액세스하게 되는데,
결국 리퀘스트가 서버에 도착한 시점에는 IP 주소를 기준으로 액세스하게 된다.
이렇게 같은 IP 주소에서 다른 호스트명과 도메인 명을 가진 여러 개의 웹 사이트가 실행되고 있기 때문에, HTTP 리퀘스트를 보내는 측에서는 호스트명과 도메인 명을 완전하게 포함한 URI를 지정하거나, 반드시 Host 헤더 필드를 통해 명시해야한다.
통신을 중계하는 프로그램
HTTP는 클라이언트와 서버 이외에 프록시, 게이트웨이, 터널과 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능하다.
1. 프록시
기본적인 동작은 클라이언트로부터 받은 리퀘스트를 다른 서버에 전송하는 것이다.
클라이언트로부터 받은 리퀘스트를 변경하지 않고 리소스를 가지고 있는 '오리진 서버'에 보낸다.
리소스 본체를 가진 '오리진 서버'는 리스폰스를 프록시에게 보내고, 리스폰스는 프록시를 경유하여 클라이언트에 돌아온다.
통신 시, 프록시 여러 대를 경유하는 것도 가능한데
중계할 때는 Via 헤더 필드에 경유한 호스트 정보를 추가해야한다.
<프록시 서버를 사용하는 이유>
- 캐시를 사용하기 위해
- 특정 웹 사이트에 대한 액세스 제한, 액세스 로그를 획득하기 위해
<프록시의 분류>
- 캐싱 프록시
프록시에 다시 같은 리소스에 리퀘스트가 온 경우, 캐시를 리스폰스 서버에서 응답 - 투명 프록시(Transparent Proxy)
중계를 할 때 메시지 변경을 하지 않는 타입의 프록시
반대로 메시지에 변경을 가하는 타입의 프록시를 비투과 프록시라고 함
2. 게이트웨이
클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로써 통신의 안전성을 높아니는 역할을 한다.
3. 터널
요구에 따라 다른 서버와의 통신 경로를 확립한다.
이 때 클라이언트는 SSL 같은 암호화 통신을 통해 서버와 안전하게 통신을 하기 위해 사용한다.
터널 자체는 HTTP 리퀘스트를 해석하려고 하지 않는다.
결국 리퀘스트를 그대로 다음 서버에 중계한다.
터널 자체는 투명한 존재이기 때문에 클라이언트는 너무 의식할 필요가 없다.
리소스를 보관하는 캐시
Cache는 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 사본을 가리킨다.
캐시를 사용하면 리소스를 가진 서버에의 액세스를 줄이는 것이 가능하기 때문에 통신량과 통신 시간을 절약할 수 있다.
캐시 서버는 프록시 서버의 하나로, '캐싱 프록시'로 분류된다.
결국 프록시가 서버로부터 리스폰스를 중계하는 때에 프록시 서버 상에 리소스의 사본을 보존한다.
클라이언트는 네트워크에서 가까운 서버로부터 리소스를 얻을 수 있게 되어 서버는 같은 리퀘스트를 매번 처리 하지 않아도 된다.
*캐시는 유효기간이 있다.
캐시 서버에 캐시가 있어도 항상 응답을 돌려준다고 할 수는 없다.
오리진 서버에 있는 원래 리소스가 갱신되는 경우가 있지만, 이 때 캐시 서버는 갱신되기 전의 옛날 리소스를 그대로 보내게 되기 때문에, 캐시의 유효기간에 의해서 오리진 서버에 리소스의 유효성을 확인하러 가게 되는 경우가 있다.
*클라이언트측에도 캐시가 있다.
클라이언트가 사용하고 있는 브라우저에서도 캐시를 가질 수 있다.
이 때의 캐시를 '인터넷 임시 파일'이라고 부른다.
브라우저가 유효한 캐시를 가지고 잇는 경우, 같은 리소스의 액세스는 서버에 액세스하지 않고 로컬 디스크로부터 불러온다.
물론 프록시 서버처럼 리소스의 유효성을 확인하러 가거나 새로운 획득을 위해 서버에 다시 획득하러 가는 일이 있다.
