HTTP를 이용한 웹 서버 구조

 

 

* 해당 게시글은 <그림으로 배우는 Http&Network Basic>을 읽고 정리하면서 공부하기 위해 메모하듯 작성하는 글입니다.

 

 

---

 

 

가상 호스트

• HTTP/1.1에서는 하나의 HTTP 서버에 여러 개의 웹사이트 실행 가능
• 가상 호스트 기능을 통해 1개의 물리적 서버에서 가상으로 여러 대의 서버가 있는 것처럼 설정 가능

참고: HTTP 요청시 주의 사항

• 같은 IP주소에서 다른 호스트명과 도메인명을 가진 웹 사이트가 실행되는 가상 호스트의 시스템 때문에 HTTP 리퀘스트를 보낼 때 호스트명과 도메인 명을 완전히 포함한 URI를 지정하거나, 반드시 Host 헤더 필드에서 지정해줘야 함
• • 하지만 브라우저로 도메인명을 포함한 URI로 요청하기 때문에 별로 중요한 내용은 아닌 듯함

 

 

---

 

 

통신 중계 프로그램

프록시

• 클라이언트로부터 받은 리퀘스트를 다른 서버에 전송하는 중계 프로그램

작동 방식

1. 클라이언트로부터 받은 리퀘스트 URI를 변경하지 않고 리소스를 가진 서버(오리진 서버)에 전달
2. 오리진 서버로부터 돌아온 리스폰스는 프록시 서버를 경유해 클라이언트로 전달

• 프록시 서버를 경유할 때마다 Via 헤더 필드에 경유한 프록시 정보를 추가
• • 여러 프록시를 경유할 수 있음

캐싱 프록시

• 프록시로 리스폰스를 중계할 때, 서버 상에 리소스 캐시를 보존해 두는 타입의 프록시
• 프록시에 다시 같은 리소스에 리퀘스트→(오리진 서버가 아닌)프록시에서 캐시를 리스폰스로 전달

투명 프록시

• 프록시로 리퀘스트와 리스폰스를 중계할 때, 중간에서 메시지를 변경하지 않는 타입의 프록시
• • 메시지에 변경을 가하느 프록시→비투과 프록시

게이트웨이

• 프록시와 매우 유사하게 동작
• 클라이언트가 요청을 보내고픈 서버가 HTTP 이외의 서비스를 제공하는 경우 클라이언트 대신 서버와 HTTP가 아닌 프로토콜을 이용해 통신
• 데이터베이스 서버에 접속해 SQL 쿼리를 사용해 데이터를 얻거나, 쇼핑 사이트 등에서 결제 시스템과 연계할 때 게이트웨이가 사용됨

터널

• 클라이언트의 요구에 의해 다른 서버와의 통신 경로를 확립하는(터널링) 프로그램
• SSL 등의 암호화 통신을 통해 서버와 안전하게 통신하기 위해 터널 사용
• 클라이언트와 서버 사이의 통신 과정에서 터널은 통신 경로만을 제공하지 프록시나 게이트웨이처럼 요청을 직접 진행하지 않음→통신 과정에서 터널을 의식할 필요 없음

 

 

---

 

 

캐시

프록시 서버와 클라이언트의 로컬 디스크에 보관된, 리소스의 사본

• 캐시 사용시 리소스를 가진 서버에의 액세스를 줄일 수 있어 통신량과 통신 시간 절약 가능
• 캐시 서버는 캐싱 프록시로 분류됨
• • 프록시가 서버로부터의 리스폰스를 중계하는 때에 프록시 서버 상에 리소스의 사본을 보존

캐시의 유효성

• 오리진 서버의 리소스가 갱신되는 경우, 갱신 전 리소스를 복사한 캐시와 차이가 생김
• 캐시의 유효성을 확보하기 위한 방법
• • 캐시의 유효 기간을 보고 오리진 서버에 리소스의 유효성을 확인
  • 원본과 차이가 생긴 경우, 오리진 서버에서 새로운 리소스를 다시 획득하러 가야 함

클라이언트의 캐시(인터넷 임시 파일)

• 클라이언트가 사용하는 브라우저에서도 캐시를 저장할 수 있음
• 인터넷 브라우저에 저장된 캐시를 인터넷 임시 파일이라고 함
• • 사설 캐시라고도 부름

클라이언트 캐시의 작동 방식

• 브라우저가 유효한 캐시를 가진 경우→캐시와 같은 리소스의 액세스(요청)은 서버에 액세스하는 것이 아니라, 로컬 디스크로부터 불러옴
• 리소스가 오래된 것으로 판단되는 경우→오리진 서버에 리소스 유효성 확인, 새로운 리소스 획득