5, 6장 ) 웹 서버, HTTP 헤더(1)

Reference : 그림으로 배우는 Http & Network Basic

 

5. HTTP와 연계하는 웹 서버

 

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

• HTTP/1.1에서는 하나의 HTTP 서버에 여러 개의 웹 사이트를 실행할 수 있다.
• 고객마다 다른 도메인을 가지고, 다른 웹사이트를 실행 할 수 있으며, 이를 위해 가상 호스트(Virtual Host)라는 기능을 사용.
  • 가상 호스트 기능을 사용하면 물리적으로는 서버가 1대지만 가상으로 여러 대가 있는 것 처럼 설정이 가능하다.
• 같은 서버 상에 같은 IP주소에서 다른 호스트명과 도메인 명을 가진 여러 개의 웹 사이트가 실행되고 있는 가상 호스트 시스템이 있기 때문에, HTTP리퀘스트를 보내는 경우 호스트명과 도메인 명을 완전하게 포함한 URI를 지정하거나, 반드시 Host 헤더필드에서 지정해야한다.

 

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

다음에 있는 다른 서버에 리퀘스트를 중계하고, 그 서버로부터 받은 리스폰스를 클라이언트에 반환.

 

프록시 (Proxy)

 

• 서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램.
• 클라이언트로부터 리퀘스트를 서버에 전송하고, 서버로부터의 리스폰스를 클라이언트에 전송.
• 클라이언트로부터 받은 리퀘스트 URI를 변경하지 않고 그 다음의 리소스를 가지고 있는 서버에 보낸다. 리소스 본체를 가진 서버를 오리진 서버라 한다.
• 프록시 서버를 여러 대 경유하는 것도 가능하며, 중계 시 vIA 헤더필드에 경유한 호스트 정보를 추가한다.
• 프록시는 캐시를 사용해 네트워크 대역 등을 효율적으로 사용하며, 조직 내에 특정 웹 사이트에 대한 액세스를 제한하는 목적으로도 사용한다.

 

사용 방법 : 캐시 여부 / 메시지 변경 여부

• 캐싱 프록시 : 프록시로 리스폰스를 중계하는 경우는 프록시 서버 상에 리소스 캐시를 보존해 두는 타입의 프록시이다. 같은 리퀘스트가 오는 경우 캐시를 리스폰스로서 되돌려줌.
• 투명 프록시 : 프록시로 리퀘스트와 리스폰스를 중계할 때 메시지 변경을 하지 않는 타입의 프록시. (반대로 메시지 변경을 하는 프록시를 비투과 프록시라고 한다.)

 

게이트웨이 (Gateway)

• 게이트웨이의 다음에 있는 서버가 HTTP 서버 이외의 서비스를 제공하는 서버
• 클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로써 통신의 안전성을 높인다.
• Ex) 게이트웨이는 데이터베이스에 접속히 SQL 쿼리를 사용해 데이터를 얻을 수 있다.

 

터널

• 요구에 따라서 다른 서버와의 통신 경로를 확립.
• 클라이언트는 SSL 같은 암호화 통신을 통해 서버와 안전하게 통신을 하기 위해 사용한다.
• 터널 자체는 HTTP 리퀘스트를 해석하지 않고 그대로 다음 서버에 중계한다.

 

 

캐시 (Cache)

• 캐시는 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 사본을 가리킨다.
• 캐시를 사용하면 리소스를 가진 서버에의 액세스를 줄일 수 있으므로 통신량과 통신 시간을 절약 할 수 있다.
• 캐시서버는 프록시 서버의 하나로, 캐싱 프록시로 분류된다.
  • 캐시 서버를 통해 클라이언트는 네트워크에서 가까운 서버로부터 리소스를 얻게 됨.
• 캐시에는 유효기간이 있으므로, 클라이언트의 요구나 캐시의 유효 기간 등에 의해 오리진 서버에 리소스의 유효성을 확인하거나 새로운 리소스를 다시 획득해야한다.
• 인터넷 익스플로러에서 클라이언트가 보존하는 캐시를 인터넷 임시 파일이라 한다.
  • 브라우저가 유효한 캐시를 가지고 있는 경우, 같은 리소스의 액세스는 서버에 액세스하지 않고 로컬디스크로부터 불러온다.
  • 캐시 서버와 마찬가지로 리소스가 오래 된 것으로 판단되면 유효성을 확인하거나 새로운 리소스를 획득한다.

 

 

 

6. HTTP 헤더

 

HTTP 메시지 헤더

출처 : https://smjeon.dev/web/http-header/

• HTTP 프로토콜의 리퀘스트와 리스폰스에는 반드시 메시지 헤더가 포함되어 있다.
• 메시지 헤더에는 클라이언트나 서버가 리퀘스트나 리스폰스를 처리하기 위한 정보가 들어있다.
• 리퀘스트의 HTTP 메시지
  • 메소드, URI, HTTP 버전, HTTP 헤더 필드 등으로 구성되어 있다.
• 리스폰스의 HTTP 메시지
  • HTTP 메시지와 HTTP 버전, 상태코드(코드와 설명), HTTP 헤더필드 등으로 구성되어 있다.
• HTTP 헤더필드는 HTTP 메시지에 관한 정보를 가지고 있다.

 

 

HTTP 헤더 필드

• 클라이언트와 서버간의 통신에서 리퀘스트와 리스폰스에 모두 사용되며, 부가적으로 중요한 정보를 전달한다.
• 메시지 바디의 크기나 사용하고 있는 언어, 인증 정보 드을 브라우저나 서버에 제공한다.
• HTTP 헤더 필드의 구조
  

  헤더 필드 명 : 필드 값
  Ex) Content-Type:text/html​

  • 위의 경우, 메시지 바디의 오브젝트 타입을 가리키는 Content-Type이 헤더 필드 명이고, 문자열이 필드 값이 된다.
• 하나의 HTTP 헤더 필드가 여러 개의 필드 값을 가질 수 있다.

 

• 일반적 헤더 필드 (General Header Fields) : 리퀘스트 메시지와 리스폰스 메시지 둘 다 사용
• 리퀘스트 헤더 필드 : 클라이언트 측에서 서버 측으로 송신된 리퀘스트 메시지에 사용. 부가적 정보, 클라이언트 정보, 리스폰스의 콘텐츠에 관한 우선순위 등을 부가한다.
• 리스폰스 헤더 필드 : 서버측에서 클라이언트 측으로 송신한 리스폰스 메시지에 사용. 리스폰스 정보, 서버의 정보, 클라이언트의 추가 정보 요구 등을 부가한다.
• 엔티티 헤더 필드 : 리퀘스트, 리스폰스 메시지에 포함된 엔티티에 사용되는 헤더. 콘텐츠 갱신 시간 등의 엔티티에 관한 정보 부가.

 

HTTP 헤더 필드는 캐시와 비캐시 프록시의 동작을 정의하기 위해 두가지 카테고리로 분류되어 있다.

• End-to-end 헤더 : 최종 수신자에게 전송된다. 캐시에서 구축된 리스폰스 중 보존되어야 하고, 다시 전송되지 않으면 안되도록 되어 있다.
• Hop-by-hop 헤더 : 한 번 전송에 대해서만 유효하고 캐시와 프록시에 의해서 전송되지 않는 것도 있다.