히포

• Keep-Alive 헤더는 송신자가 연결에 대한 타임아웃(time-out)과 요청 최대 개수를 결정
• Keep-Alive 헤더를 사용하기 위해서는 Connection 헤더를 "keep-alive"로 설정
• Connection과 Keep-Alive는 HTTP/2에서 무시 → HTTP/2 연결 관리는 다른 메커니즘에 의해 처리
• TCP가 전송이 끝나면 연결이 끊어지듯이 HTTP도 서로 전송이 끝나면 끊어짐 →TCP는 Layer4, HTTP는 Layer7
• 매번 똑같은 주소로 요청을 할 때마다 새로운 연결을 설정하고 끊어야 함 → 자원이 낭비
• 자원 낭비를 막기 위해 Keep-Alive가 생성 → '연결을 계속 유지해라'라는 의미
• Keep-Alive 헤더를 통해 최소 특정 시간동안(timeout) 최대 요청 request(max)의 수를 지정

• 최소 5초동안 최대 1000번의 요청을 할 경우에는 http connection이 끊어지지 않음

  Keep-Alive: timeout=5, max=1000

  
  
• HTTP/1.0과 HTTP/1.1에서의 영속성
  • HTTP/1.0 커넥션은 기본적으로 영속적이지 않음.
  • Connection을 close가 아닌 retry-after로 설정하면 영속적으로 동작 -> HTTP/1.0으로 동작하는 경우(fallback)에 대비해 종종 추가
  • HTTP/1.1는 영속적이며 헤더도 필요 X
    
    
    

Connect: keep-alive 헤더와 Keep-Alive 헤더를 활용하여 설정

1. Multiple Connections 기본적인 구조

• connection을 생성하고, 하나의 호출, 응답을 받은뒤 connection을 끊고, 다시 생성하는 방식
  
  
  

2. Persistent Connection의 Keep-Alive를 사용하는 구조

• 처음 connection을 생성하고, Keep-Alive time out 내에 client가 요청을 하면 port를 새로 여는 것이 아니라 이미 열려 있는 socket에 전송 방식
• time-out 내에 요청이 안들어오게 되면 port를 끊는 방식
  

  

  
  

Keep-Alive를 사용하지 않아야하는 환경

• 서버에 연결된 모든 클라이언트의 연결이 계속 증가하여 서버의 자원이 고갈되면, 많은 클라이언트의 접속에 대처할 수 없음
• 클라이언트의 접속이 제일 잦은 메인 페이지와 같은 URL 에서는 서버의 가용성을 고려하여 Keep-Alive 사용 유무 결정
• 개인 블로그가 아닌 접속자가 많은 사이트를 운영할 경우에는 관리상 웹 어플리케이션 서버와 이미지 서버를 분리해 운영하는 것이 좋음
• 웹 어플리케이션 서버의 경우에는 Keep-Alive Off 설정
• 이미지 서버는 연결 유지를 위해 KeepAlive On 설정
  
  
  

Keep-Alive 설정 → Keep-Alive: timeout=5, max=1000

1. KeepAlive ( default : off)

• KeepAlive는 한 프로세스가 특정 사용자의 요청을 지속적으로 허용하며 처리할지 여부를 결정
• 운영하는 서버의 메모리 상태나 접속자의 수를 확인하면서 KeepAlive 활용을 조정 필요

• KeepAlive를 On으로 설정 → Connection: Keep-Alive 설정
  • 메모리 사용의 부담이 많아지게 되지만 성능은 좋아짐 → 접속자의 수 상관없이 메모리가 충분해야함
  • 단발성 요청이 많은 대민 서비스의 경우 Off 가 적절
  • 안정적인 KeepAlive를 활용하기 위해서는 접속자가 maxclient 값에 도달했을 경우에도 swap 메모리를 사용하지 않아야함

• KeepAlive를 Off으로 설정
  • 동시 접속자 수가 많고, 메모리가 충분하지 못한 경우 활용
    
    
    

2. KeepAliveTimeout ( default 15 초) → timeout 값

• KeepAlive가 On 일 경우에 유효한 값
• 연결된 사용자로부터 새로운 오쳥을 받기까지 서버가 얼마나 기다릴 것인가를 설정
• 1~5초 사이로 설정하는 것이 요청을 기다리는 동안 프로세스를 물고있는 RAM 의 낭비를 줄일 수 있음
• 10초 이상은 메모리 점유로 동시접속자가 크게 감소 할 수 있음
  
  
  

3. MaxKeepAliveRequests ( default 100 회) → max 값

• KeepAlive가 On 일 경우에 유효한 값
• 하나의 지속적인 연결에서 서비스를 제공할 요청의 최대 값을 설정
• 50 ~ 75 사이 정도가 충분
  
  
  

문법

Keep-Alive: parameters

Keep-Alive의 파라메터(parameters)

• 쉼표로 구분된 파라메터 목록으로, 각각 등호('=')로 구분되는 식별자와 값으로 구성

1. timeout

• 유휴 연결이 계속 열려 있어야 하는 최소한의 시간(초 단위)을 표시
• keep-alive TCP 메시지가 전송 계층(Transport layer)에 설정되지 않는다면 TCP 타임아웃 이상의 타임아웃은 무시됨
  
  
  

2. max

• 연결이 닫히기 이전에 전송될 수 있는 최대 요청 수를 표시
• 만약 0이 아니라면, 해당 값은 다음 응답 내에서 다른 요청이 전송될 것이므로 비-파이프라인 연결의 경우 무시
• HTTP 파이프라인은 파이프라이닝을 제한하는 용도로 해당 값을 사용 가능
  
  
  

3. Keep-Alive 헤더를 포함하는 응답 예제

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Thu, 11 Aug 2016 15:23:13 GMT
Keep-Alive: timeout=5, max=1000
Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT
Server: Apache
(body)

• 헤더 이름에서 알수 있듯이 If-Modified-Since 헤더의 반대

• If-Modified-Since 헤더는 변경되었는지를 체크하는 것이고, If-Unmodified-Since 헤더는 변경되지 않았는지를 체크

• If-Unmodified-Since 헤더는 PUT 메소드를 이용해서 웹서버의 컨텐츠를 수정하려 할때 사용하면 좋은 것

• 변경되지 않은 올드한 컨텐츠의 내용을 바꾸려고 할때 올드한 컨텐츠인지 아닌지를 체크하는 과정에서 활용

• If-Unmodified-Since 요청 헤더 필드는 조건부로 만드는 방법과 함께 사용 → 요청된 리소스가 필드에 지정된 시간 이후 수정되지 않은 경우 서버는 If-Unmodified-Since 헤더가 없는 것처럼 요청된 작업을 수행

• 요청된 변형이 지정된 시간 이후에 수정된 경우 서버는 요청된 작업을 수행해서는 안됨 → 412 응답 코드 반환

• 412 응답 코드는 Precondition Failed 에러 메시지로 선결 조건이 실패하였다는 의미

  # If-Unmodified-Since 형식
  "If-Unmodified-Since" ":" HTTP-날짜
  
  # 예시
  If-Unmodified-Since: 1994년 10월 29일 토요일 19:43:31 GMT

  
  

• 요청이 정상적으로(즉, If-Unmodified-Since 헤더 없이) 2xx 상태가 아닌 다른 결과를 초래하는 경우 If-Unmodified-Since 헤더는 무시되어야 함

• 지정된 날짜가 유효하지 않으면 헤더가 무시됨
  
  
  

If-Unmodified-Since 헤더를 사용 설명

1. 컨텐츠 변경 시 : 412 Precondition Failed 에러 메시지 전달
2. 컨텐츠 미 변경 시 : 200 OK 와 함께 전체 데이터 전송
   

   

   
   

• If-Range 헤더를 포함한 HTTP 요청 헤더는 범위 요청을 조건적으로 만듬
  • 조건이 만족된다면, 서버에서 206 Partial Content 응답과 범위 요청의 데이터를 HTTP 바디(body) 포함하여 전송
  • 조건을 만족하지 못한다면, 200 OK 상태 코드가 전체 리소스와 함께 반송됨

• 다운로드를 재시작하거나, 저장된 리소스가 마지막 조각을 다운받은 후 수정되었는지 확인하는 경우 많이 사용
• ETag 정보를 활용하기 때문에 If-Range 헤더는 캐시관련 헤더임
• 캐시라는 동작은 항상 웹서버에서 제공하는 컨텐츠의 유효성을 체크해야 함 → 저장하고 있는 컨텐츠가 지금도 웹서버에서 제공하는 컨텐츠와 같은지 체크 필요
• If-Range 헤더는 Last-Modified 유효 검사자, 또는 ETag와 함께 사용될 수 있지만, 동시에 사용은 불가
• 웹서버에서 ETag를 지원하지 않는 경우도 있음
• ETag를 지원하지 않는 경우에 If-Range 헤더의 값으로 클라이언트는 If-Modified-Since 헤더와 같이 Last-Modified 시간 정보를 기재 → ETag를 사용하지 못하지만, 기능에는 차이가 없음
  
  
  

If-Range 헤더가 사용되는 예시 상황

1. 웹서버에서 어떤 프로그램 설치 파일을 다운로드 받고 있었는데, 알 수 없는 이유로 다운로드가 중간에 중단됨
2. 당장 다운받을 수 없는 환경이라, 몇시간 뒤 다운 받아야하는 상황이 발생함
3. 시간이 지나고 나서 다시 다운로드를 받으려고 하니 웹서버에서 제공하는 동일한 이름의 프로그램이 이전에 다운받는 것과 같은것인지 확인할 필요가 있음
4. 멈춰있는 동안 프로그램의 버전이 업그레이드된 경우에는 이름이 같아도 내용이 다름
5. 웹서버에게 중간에 다운로드가 끊어졌던 프로그램에 관련한 정보를 웹 서버에 전달해 주면, 웹 서버가 같은지 다른지 판단하여 프로그램을 전달
6. 동일한 프로그램이 존재하는 경우에는 계속 다운받을 수 있는 것이고, 다른 프로그램이라면 프로그램이 변경되었기에 새로운 프로그램을 다운받아야함
   
   
   

If-Range 헤더가 없는 경우, If-Match 헤더를 사용해서 동일한 컨텐츠인지 확인하고 프로그램 다운로드 진행

• 웹서버에 컨텐츠 변경이 없는 경우에는 If-Match 헤더를 사용하여도 큰 이상은 없음 -> 같은 컨텐츠기에 프로그램을 연속해서 다운 가능
• 웹 서버에 컨텐츠 변경이 있는 경우는 복잡해짐 → 하나의 컨텐츠를 전달받기 위해서 총 2번의 요청, 2번의 응답이 상호 교환 필요
  

  

  
  

If-Match 헤더의 문제를 개선하기 위해 If-Range 헤더 사용

• If-Range 헤더를 사용하게 되면 한번의 요청으로 모든 처리가 가능
• 웹서버는 If-Range 헤더를 받게 되면, 컨텐츠가 변경된 경우는 새로운 컨텐츠 전체를 전달
• 웹서버는 If-Range 헤더를 받게 되면, 컨텐츠가 변경되지 않은경우는 Range 헤더의 값에 해당되는 데이터만 전달
• 컨텐츠 변경이 없는 경우는 If-Range 헤더는 If-Match 헤더를 사용했을 때와 같으나, 컨텐츠가 변경된 경우에 If-Range 헤더는 If-Match 헤더보다 처리 과정이 절반으로 줄어듬
  

  

  
  

If-Range 헤더 참고 사진

문법

If-Range: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
If-Range: <etag>

지시자

1. <etag>

• 개체 태그는 요청한 리소스가 유일한 것을 표현
• ASCII 문자열로 쌍따옴표("675af34563dc-tr34"처럼)로 묶여있음
• 접두사로 W/가 있어 약한 비교 알고리즘을 사용되어야 하는 것을 표시
• If-Range 헤더 사용 예제

  If-Range: Wed, 21 Oct 2015 07:28:00 GMT

2. <day-name>

• "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", 또는 "Sun" 중 하나가 표시
• 대소문자 구분

3. <day>

• 날짜
• 두 글자로 표시
• 예시 : "04" 또는 "23"

4. <month>

• "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" 중 하나가 표시
• 대소문자 구분

5. <year>

• 연도
• 네 글자로 표시
• 예시 : "1990" 또는 "2016"

6. <hour>

• 시간
• 두 글자로 표시
• 예시 : "09" 또는 "23"

7. <minute>

• 분
• 두 글자로 표시
• 예시 : "04" 또는 "59"

8. <second>

• 초
• 두 글자로 표시
• 예시 : "04" 또는 "59"

9. GMT

• 그리니치 표준시
• HTTP 날짜는 현지 시각이 아닌, 언제나 GMT로 표현

• If-None-Match 헤더는 If-Match 헤더와 비슷하지만 GET 방식에 있어서 차이가 있음
• If-None-Match 헤더는 GET에서는 If-Modified-Since 헤더처럼 사용
• If-None-Match 헤더를 이용해서 컨텐츠의 변경여부를 묻고 컨텐츠가 변경되지 않는 경우(기존 컨텐츠의 ETage정보가 요청의 If-None-Match 헤더의 ETag와 같다면) "304 Not Modified" 메시지를 전달
  
  
  

If-None-Match 헤더의 동작흐름

1. 먼저 GET으로 최초 이미지 컨텐츠를 요청한 후 ETag 정보를 받음

$ curl -H "Accept: application/json" -i http://localhost:8080/spring-boot-rest/foos/1
HTTP/1.1 200 OK
ETag: "f88dd058fe004909615a64f01be66a7"
Content-Type: application/json;charset=UTF-8
Content-Length: 52

2. 클라이언트가 If-None-Match 헤더에 동일한 ETag 를 전달하는 경우와 그렇지 않은 경우를 확인

• 웹서버는 If-None-Match 헤더의 값이 같은 경우 304 상태 코드를 반환 → 정상 응답 코드

• 웹서버는 If-None-Match 헤더의 값이 다른 경우 200 상태코드를 반환 → 정상 응답 코드

• GET에서는 If-None-Match의 값이 ETag와 같을 경우 캐싱되어 있는 이미지를 사용할 수 있도록 304 상태코드를 반환

• If-None-Match 헤더는 If-Modified-Since 헤더와 같은 목적으로 사용

  ## 확인한 ETag와 If-None-Match 헤더의 ETag가 동일한 경우
  $ curl -H "Accept: application/json" -H 'If-None-Match: "f88dd058fe004909615a64f01be66a7" -i http://localhost:8080/spring-boot-rest/foos/1
  HTTP/1.1 304 Not Modified
  ETag: "f88dd058fe004909615a64f01be66a7"
  
  ## 확인한 ETag와 If-None-Match 헤더의 ETag가 다른 경우
  $ curl -H "Content-Type: application/json" -i -X PUT --data '{ "id":1, "name":"Transformers2"}' http://localhost:8080/spring-boot-rest/foos/1
  HTTP/1.1 200 OK
  ETag: "d41d8cd98f00b204e9800998ecf8427e"
  Content-Length: 0

  

  
  

If-None-Match 헤더와 If-Modified-Since 헤더의 차이

• If-Modified-Since 헤더는 시간 정보를 담기 때문에 웹서버나 클라이언트의 환경적인 측면에서 정보의 정확성이 보장 X
• If-None-Match 헤더는 ETag 정보를 활용하기 때문에 컨텐츠의 변경 유무를 아주 정확하게 반영 가능
  
  
  

If-None-Match 헤더와 If-Match 헤더의 차이

• If-Match 헤더는 PUT과 같이 덮어쓰기 위한 동작에 사용 → 새로운 파일 생성을 금지
• If-None-Match 헤더는 신규로 생성하기 위한 동작에 사용 → 파일 덮어쓰기를 금지하는 컨셉

• If-Modified-Since 헤더는 캐시동작에 있어서 유효한 컨텐츠를 클라이언트에게 제공할 수 있게 해 주는 중요한 정보
• 중요한 If-Modified-Since 헤더의 정보에 오류가 있는 경우 웹 서버는 If-Modified-Since 헤더의 정보를 무시하고, 컨텐츠 전체를 서비스
  • If-Modified-Since 헤더의 표시 형식이 잘못 표기
  • 서버의 현재시간보다 If-Modified-Since의 표기 시간이 늦는 경우 문제 발생

• 캐시 동작의 장점 중 하나는 네트워크 대역폭(Bandwidth) 절감 가능 → 프록시 서버에 캐시되어 있는 컨텐츠가 큰 용량인 경우 프록시 서버와 실제 서버간의 네트워크 대역폭을 절약 가능

• If-Modified-Since 헤더는 If-UnModified-Since 헤더의 반대 의미
  • If-Modified-Since 헤더는 컨텐츠가 변경되었는지를 체크
  • If-Unmodified-Since 헤더는 변경되지 않았는지를 체크
    
    
    

If-Modified-Since (변경된 경우 중심)

• If-Modified-Since 헤더를 이해하기 위해서는 Last-Modified 헤더의 의미를 먼저 알아야함

  • Last-Modified 헤더는 ETag와 같이 응답헤더
  • Last-Modified 헤더는 단어 의미와 같이 컨텐츠가 마지막으로 변경된 시점 정보를 값으로 가짐
  • 웹서버의 컨텐츠가 가장 마지막으로 수정된 시점을 표현
    
    
    

• If-Modified-Since 헤더는 캐시(Cache)관련 헤더

  • 웹브라우져(클라이언트)나 캐시서버는 웹 서버의 응답 컨텐츠들을 디스크(Disk)나 램(RAM)에 저장
  • 캐싱(caching)된 이미지등의 컨텐츠들을 유효한지 여부 매번 확인 필요
  • 웹서버에서 컨텐츠가 변경되었는데, 그것을 반영하지 못하면 문제가 발생
    
    
    

• If-Modified-Since 헤더는 웹브라우져나 캐시서버가 웹서버에게 컨텐츠가 변경되었는지 확인하는 용도로 사용

  1. 웹브라우져 ↔ 캐시서버 : 내가 가지고 있는 이미지를 웹 브라우저에게 직접 줘도 되는지 웹 서버에 확인
  2. 캐시 서버 ↔ 웹 서버 : 응. 나도 똑같은 이미지 가지고 있으니까, 캐시 서버 너가 직접 보내줘
     
     
     

1. If-Modified-Since 헤더 참고 사진

2. 컨텐츠 변경 시 : 200 OK 메시지와 함께 신규 컨텐츠 전송

1. 클라이언트가 특정 컨텐츠를 요청
2. 프록시 서버는 클라이언트의 요청을 받아 대신 실제 서버로 전달
3. 실제 서버는 컨텐츠를 제공하는데 이때, 컨텐츠의 최종 수정시간을 Last-Modified 헤더에 포함하여 전달
4. 프록시 서버는 실제 서버의 응답컨텐츠를 자신의 디스크(Disk)나 램(RAM)에 저장한후 그대로 클라이언트에게 전달
   

   

   
   

3. 컨텐츠 미 변경 시 : 304 Not Modified와 함께 페이로드(payload) 미전송

1. 클라이언트가 같은 컨텐츠를 요청
2. 프록시 서버는 클라이언트 요청을 받아 서버에 전달할때, 캐시되어 있는 컨텐츠임을 알고 If-Modified-Since 헤더에 Last-Modified 의 값(시간정보)을 표기하여 전달
3. 실제 서버는 동일한 컨텐츠임을 확인하고 변경된 바가 없으니 직접 제공하라는 메시지를 전달(304 Not Modified)
4. 프록시 서버는 자신의 디스크(Disk) 또는 램(RAM)에 저장되어 있는 컨텐츠를 클라이언트에게 전달
   

   

   
   

• If-Match 헤더를 이해하기 위해서는 ETag 헤더를 먼저 이해하는 것이 좋음
• ETag 헤더 → 웹서버가 제공하는 컨텐츠들에 각각 부여되는 일종의 식별자 같은 정보
• 웹서버는 클라이언트에게 컨텐츠를 제공할때 ETag 정보를 같이 전달
• 클라이언트와 프록시서버들은 웹 서버에게 전달받은 ETag 정보를 다음 요청(subsequence Request)에 활용 가능
• 캐시기능에서 ETag를 활용 → 사용자가 요청한 컨텐츠가 이전에 제공했던 컨텐츠인지 새롭게 제공해야 할 컨텐츠인지 구별 가능
• If-Match 헤더는 요청 헤더의 한 종류이고 헤더 값(Value)으로 서버에서 제공해준 ETag 정보를 표기
• 저장된 리소스가 주어진 ETags의 하나와 일치하는 경우에만 요청을 조건부로 만들고 메소드를 적용
• 웹서버가 가지고 있는 컨텐츠 별로 ETag 정보를 부여하여 관리하게 되는데, 컨텐츠의 변경시 동시 작업의 경우 컨텐츠 무결성이 훼손 가능 → 컨텐츠 무결성 훼손을 방지하기 위해 If-Match 헤더를 사용
  
  
  

"nature.jpg"라는 자연 이미지 파일 하나가 있다고 가정

• 아래의 파일 이름(nature.jpg)은 같지만, 내용이 다르기 때문에 웹서버는 이를 구분해야 할때 ETag 정보를 활용 가능
• 여름은 여름에 맞는 이미지를 서비스 컨텐츠고 제공해야함
  

  

• 여름의 이미지는 겨울에 사용할 수 없기에, 겨울 이미지에 맞도록 변경
  

  

  
  

If-Match 헤더의 동작 흐름

1. 클라이언트 A와 클라이언트 B가 서버에게 전달받은 이미지는 같은 것이므로, ETag 정보도 같음 → 둘 다 ETag를 AABB로 가정

• 클라이언트 A가 특정 컨텐츠(자연 이미지->여름)를 요청
• 서버는 자연 이미지를 클라이언트 A에게 ETag 정보와 함께 정상적으로 전송
• 클라이언트 B가 같은 이미지를 요청
• 서버는 클라이언트 A에게 제공했던 같은 이미지를 B에게도 ETag 정보와 함께 전달
• 클라이언트 A와 클라이언트 B가 서버에게 전달받은 내용은 같기때문에 같은 ETag 정보도 가지고 있음
  

  

2. 클라이언트 A가 겨울복장의 트와이스 이미지로 변경한 이후, 클라이언트 B가 ETag AABB 이미지를 변경 요청

• 클라이언트 A가 PUT 요청방식(Method)를 이용하여 자연 이미지를 여름에서 겨울로 변경
• 클라이언트 A가 이미지를 변경하였기에 서버가 기존에 가지고 있는 이미지의 ETag와 다른 Etag가 저장
• 서버는 컨텐츠 이미지가 변경되었으므로 더이상 AABB 의 Etag 정보를 가진 컨텐츠를 제공 X
• 클라이언트 B가 클라이언트 A가 작업을 한지 모르고 PUT 방식을 이용하여 이미지 변경 요청 → ETag AABB 이미지 변경 요청
• 웹서버는 클라이언트 B가 전달해 준 ETag 정보(여름의 자연 이미지)와 다르기 때문에 실패라는 메시지를 클라이언트 B에게 전송
  

  

3. If-Match 헤더의 값으로 *(asterisk)" 를 사용

• 컨텐츠의 내용은 모르지만 파일이 존재하는 경우, 클라이언트의 요청을 서버에서 처리할 수 있음
• 클라이언트 B가 If-Match 의 값으로 특정 파일의 ETag AABB가 아닌 *(asterisk)를 사용했다면, 클라이언트 A가 이미 변경했음에도 불구하고 클라이언트 B가 요청한 이미지 변경 동작이 처리
• If-Match 헤더에 *(asterisk)를 사용하면 파일 검증없이 변경이 됨으로 위험함 → 주의해서 사용해야함
  
  
  

문법

If-Match: <etag_value>
If-Match: <etag_value>, <etag_value>, …

지시자

1. <etag_value>

• 요청된 리소스를 고유하게 나타내는 엔터티 태그
• 큰따옴표(예: "675af34563dc-tr34") 사이에 배치된 ASCII 문자 문자열
• W/"약함"을 나타내기 위해 접두사를 사용 가능
• 리소스를 의미론적으로 나타내지만 바이트 단위로 나타내지 않음
• If-Match 헤더에서 약한 엔터티 태그는 일치 X

2. * (asterisk)

• 별표는 모든 리소스를 나타내는 특수 값

3. If-Match 헤더 사용 예시

If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
If-Match: "67ab43", "54ed21", "7892dd"
If-Match: *

※ 이미지 제공 : https://papers.co

Host 헤더

• Host 헤더는 HTTP 1.1 버전에서 새로 추가된 헤더
  Host 헤더가 없는 HTTP 1.0 버전에서는 10개의 고객사 홈페이지를 운영하기 위해서는 1대의 물리적인 서버에서 운영 어려움 (거의 불가능)
• Host 헤더가 없는 형태로 요청이 서버로 전송됨 → 웹서버는 Host 헤더가 요청으로는 어느 회사 홈페이지로 접속했는지 알 수 없음
• HTTP 1.1 버전에서 Host 헤더가 HTTP 요청에 추가되면서, 흔히 알고 있는 가상 호스팅(Virtual Hosting)이 가능하게 됨
• 가상 호스팅(Virtual Hosting)으로 IP가 같아도 고객사 도메인을 모두 구분하여 처리 가능
• Host 헤더에는 클라이언트가 접속을 시도한 웹사이트 도메인 네임의 정보가 표시
• IP 주소가 아닌 Host 헤더의 값을 가지고 고객사를 구분
• IP 주소의 의미가 없어지면서 물리적인 한대의 웹서버에 여러개의 웹어플리케이션을 운영

  GET / HTTP/1.1
  Accept: */*
  User-Agent: Mozilla/5.0
  Host: www.Acompany.com

  
  

※ 참고

• HTTP Host 헤더가 없기 때문에 클라이언트가 보낸 헤더의 내용만으로는 구분이 불가능 → IP 주소로 구분 가능
• 한대의 물리적인 서버에 2개 이상의 NIC 포트가 있는 경우에는 포트 개수만큼의 웹어플리케이션 운영이 가능 → NIC 포트에 각각 다른 IP를 부여해야하기에 많은 IP가 사용됨
  
  
  

가상호스트(Virtual Hosts)

• 웹 초창기 웹을 이용하는 클라이언트(사용자)는 극히 제한적
• 웹 초창기 웹 서버의 역할 또한 정보를 제공하는 단순한 수준
• 현재 웹서비스는 이메일, 웹하드, 쇼핑, 티켓구매, 은행등등 다양해졌고, 클라이언트(사용자)의 스펙트럼도 굉장히 넓어짐
• 다양한 웹어플리케이션을 동작하기 위해서는 물리적인 웹서버의 수가 많이 필요 -> 많은 물리적인 웹 서버를 운영하는데 어려움이 있음
  

가상호스트(Virtual Hosts)가 적용 X

• 10개의 어플리케이션의에는 10개의 서버가 필요
• 어플리케이션들의 역할이 모두 다르기 때문에 서비스 IP나 도메인을 서로 다르게 설정 필요
• 10개의 서버를 위치시킬 물리적인 공간이 필요
• 10개의 웹어플리케이션중에서도 사용량이 적은 서비스의 경우에는 CPU, 메모리등의 서버 자원 낭비가 발생
  
  
  

가상호스트(Virtual Hosts)가 적용 O

• HTTP 1.1에서는 가상호스트(Virtual Hosts)를 사용하기 위해 Host 헤더 추가
• 단순한 Host 헤더 하나가 추가되었을 뿐인데, 웹서비스를 제공하는 경우 많은 이익이 생김
• 가상호스트(Virtual Hosts)는 하나의 물리적인 서버에서 다수개의 웹서비스를 운영이 가능하게 한 기능 → 서비스 도메인(웹주소)은 서로 다르더라도 한개의 IP 주소로 모든 서비스를 가능
• 웹호스팅 업체들은 HTTP의 가상호스트(Virtual Hosts)기능이 중요함
  

  

  
  

리다이렉션(Redirection)

• 가상호스트(Virtaul Hosts)가 하나의 서버에서 복수개의 웹사이트를 운영 가능케 했다면, 리다이렉션은 하나의 사이트가 복수개의 웹서버를 이용할 수 있게 해줌
• 가상호스트는 복수개를 하나로 모으는것이고, 리다이렉션은 하나를 복수개로 연결하는 것
• 리다이렉션은 서버가 클라이언트(사용자)를 다른 URI로 전달
• 리다이렉션은 매우 다양한 웹환경에서 필수 기능으로 웹어플리케이션의 리비젼, 컨텐츠 재배치등과 같이 어떤 변화에 유연하게 대처할 수 있게 해줌
• 리다이렉션은 물리적으로 다른 서버로도 클라이언트를 안내할 수도 있지만, 동일서버의 다른 컨텐츠로 연결하는 것 역시 가능
  

리다이렉션(Redirection) 예시

• 클라이언트가 첫번째 웹 서버의 컨텐츠를 요청
• 첫번째 웹 서버는 컨텐츠 대신 301 Moved 상태코드를 클라이언트에게 전송 → 응답데이터에는 301 Moved 상태코드와 함께 리다이렉션을 수행할 URI 정보도 포함됨
• 클라이언트는 3단계와 같이 리다이렉션할 URI로 새로운 접속과 요청을 시도
• 리다이렉션 URI 주소를 가지고 있는 웹서버는 200 OK 상태코드와 함께 컨텐츠를 전송
  
  
  

http://naver.com 주소로 클라이언트의 요청하면 301 응답 코드와 https://www.naver.com 주소를 리다이렉션(Redirection) 응답으로 전달

• 301 Moved permanently 응답 코드
• Location 헤더내에 리다이렉션 할 웹사이트 주소 → https://www.naver.com

  $ curl -vv http://naver.com
  *   Trying 223.130.195.95:80...
  * Connected to naver.com (223.130.195.95) port 80 (#0)
  > GET / HTTP/1.1
  > Host: naver.com
  > User-Agent: curl/7.71.1
  > Accept: */*
  >
  * Mark bundle as not supporting multiuse
  < HTTP/1.1 301 Moved Permanently
  < Server: NWS
  < Date: Sat, 06 Nov 2021 16:34:43 GMT
  < Content-Type: text/html
  < Transfer-Encoding: chunked
  < Connection: keep-alive
  < Location: http://www.naver.com/  # http://naver.com -> http://www.naver.com 전송
  < Vary: Accept-Encoding,User-Agent
  <
  <html>
  <head><title>301 Moved Permanently</title></head>
  <body>
  <center><h1>301 Moved Permanently</h1></center>
  <hr><center> NWS </center>
  </body>
  </html>
  * Connection #0 to host naver.com left intact

• 캐시서버(Cache server)는 저장한 컨텐츠들의 유효성 확인이 필수 → 클라이언트에게 캐시서버가 직접 컨텐츠를 전달해야 되는지 또는 그렇지 않은지에 대해 판단 (제공된 컨텐츠가 항상 신선해야함)
• 캐시서버가 클라이언트에게 전달해주는 컨텐츠가 신선한지 확인하는 HTTP 헤더가 몇가지 있는데, Expires 헤더가 그 중 하나
• Expires 헤더는 응답이 더 이상 신선하지 않다고 판단할 날짜/시간을 포함
• Expires 헤더는 단어 뜻 그대로 컨텐츠의 유효기간
• Expires 헤더에 명시되어 있는 기간이 지나게 되면, 더 이상 유효한지 아닌지를 실제 웹서버에서 확인 필요
• 만약 웹서버가 제공하는 컨텐츠가 캐싱되지 않기를 원한다면, Expires 헤더의 값을 응답하는 Date 헤더의 값과 같거나 지난 날짜를 설정해서 전달하면 됨 → 0과 같은, 유효하지 않은 날짜는 과거의 시간을 나타내어 리소스가 이미 만료되었음을 의미
• Cache-Control은 HTTP 1.1에서 등장한 헤더로, 응답 내에 "max-age" 혹은 "s-max-age" 디렉티브를 지닌 Cache-Control 헤더가 존재할 경우, Expires 헤더는 무시
  
  
  

문법

• <http-date>에는 timestamp 값이 들어감

  Expires: <http-date>

  
  

Expires 헤더 사용 예제

Expires: Mon, 21 Aug 2017 09:00:05 GMT

Expires 예제 사진