히포

• MTU(Maximum Transmission Unit)는 네트워크 인터페이스에서 세그먼트 없이 보낼수 있는 최대 데이터그램 크기 값
• 데이터가 MTU 값 이상이라면 여러개의 패킷으로 분할
• MTU는 패킷이 한번에 보낼 수 있는 최대 크기라고 함
• 주로 사용하는 이더넷의 MTU 값은 일반적으로 1500 바이트
• 과거의 모뎀을 통해 접속하던 PPPoE 연결은 1492 바이트를 가짐
• 점보프레임은 9000 바이트의 큰 크기를 가짐
  
  
  

MSS(Maximum segment size)

• MTU는 각 패킷 프레임 안에 최대 전송할 수 있는 값 → MSS(Maximum segment size)
• MTU는 MSS + TCP/IP 헤더 크기 → 반대로 MSS는 MTU - 40 바이트가 됨
• 40 바이트는 IP와 TCP 헤더 각각 20 바이트임
• 일반적으로 사용하는 TCP 환경에서 애플리케이션이 사용할 수 있는 크기는 헤더를 제외한 1460 바이트 → MSS가 1460를 의미
• RFC1323에서 정의한 타임스탬프 옵션이 확장되어 사용되면 12바이트가 늘어 1448 바이트까지 사용 가능

1.TCP 프로토콜 연결시 SYN 패킷을 보낼 때 MSS 크기를 함께 보냄

• SYN 패킷 안에 0x0204 0x05B4 값이 있음 → 0x0204 0x05B4는 MSS를 의미
• 02 → MSS 옵션의 시작점
• 04 → 옵션의 크기(4바이트)
• 0x05B4 → 크기를 의미하는데, 10진수로 표시하면 1460 바이트
• MSS 크기를 전송하면 받는 측에서도 어떤 크기로 전송해야 할지 알고 준비하게 됨

2.MTU와 속도 상관 관계

• 전용선 라인 T1을 사용한다고 가정 → T1은 1.544Mbps (1,544,000 bits/sec)
• 1개 패킷을 전송할 때 속도 → MTU가 1500 바이트 가정하면, (1460 + 40 ) * 8 / 1544000 = 7.772ms
• 1Mbytes의 파일을 전송
• 1Mbyte는 1024KB 이고 바이트로는 1,048,576 바이트
• 1Mbyte를 전송하려면 패킷의 데이터 영역인 MSS(1460)으로 나눠야함 → 1048576bytes / 1460 = 718.2
• 1MByte를 T1라인에서 전송하려면 718.2 * 7.772 = 5581ms 시간 발생
• T1라인에서는 1Mbyte 크기의 데이터를 전송하는데 꽤 오랜 시간이 발생한다고 할 수 있음
• T1라인을 사용한다고 하고, 다른 네트워크 환경을 감안하지 않고 산술적으로 계산한 것이기에 실제와 다를 수 있음 → 이론적인 것이므로 네트워크 환경에 따라 달라짐
  
  
  

리눅스의 MTU 값 확인 → ifconfig 명령어를 이용하면 쉽게 확인이 가능

• ifconfig 명령어를 통해 확인한 인터페이스 상태

  $ ifconfig eth0
  eth0      Link encap:Ethernet  HWaddr bc:ae:c5:xx:xx:xx
          inet addr:192.168.xx.xx Bcast:192.168.xx.255  Mask:255.255.255.0
          inet6 addr: fe80::beae:xxxx:xxxx:b436/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:22530399 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16150847 errors:0 dropped:1 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10308945022 (10.3 GB)  TX bytes:3971757833 (3.9 GB)
          Interrupt:45 Base address:0x2000

  
  

• mtu 값 변경도 ifconifg 명령어를 통해 쉽게 가능

  $ ifconfig eth0 mtu 9000

  
  
  

윈도우 MTU 확인

• 윈도우에서는 netsh 명령어를 통해 인터페이스 정보를 확인 가능

  C:\>netsh interface ip show interface
  
  The Routing and Remote Access Service is not currently running on the local machine.
  Please use 'net start remoteaccess' on the machine to start the service.

  
  

• 서비스가 시작되어 있지 않다고 remoteaccess 서비스를 시작

  C:\>net start remoteaccess
  System error 1058 has occurred.
  
  The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

  
  

• Startup Type을 자동 또는 수동으로 변경후 시작해 주면, 인터페이스 결과를 얻을 수 있음

• 윈도우에서는 netsh 명령어를 통해 인터페이스 정보를 확인 가능 (MTU 1500 확인 가능)

  C:\Users\hippo>netsh interface ip show interface 
  색인     메트릭         MTU          상태                이름
  ---  ----------  ----------  ------------  ---------------------------
   1          75  4294967295  connected         Loopback Pseudo-Interface 1
  18           5       65535      disconnected     OpenVPN Wintun
  15          50        1500      connected         Wi-Fi
  21           5         1500      disconnected     이더넷
   9          25         1500      connected         OpenVPN TAP-Windows6
   2          25         1500      disconnected     로컬 영역 연결* 1
   5          65         1500      disconnected     Bluetooth 네트워크 연결
  10          25        1500      disconnected     로컬 영역 연결* 10
  32          15        1500      connected         vEthernet (WSL)
  23          35        1500      connected         VMware Network Adapter VMnet1
   7          35         1500      connected         VMware Network Adapter VMnet8

  
  

• ping 명령어에 -l 옵션으로 데이터 크기를 지정하여 ping 테스트

  1. MTU 크기 값 이상이 되면 Fragment 메시지를 볼 수 있게 되어, MTU를 알 수 있음
  2. 인터페이스에 설정된 MTU 값은 1500 바이트
  3. IP 헤더가 20 바이트이고 ICMP 헤더가 8바이트(TYPE, CODE, CHECKSUM, DATA)로 1500 - 28 = 1472 바이트됨
  4. 만약 1473 바이트로 ping을 날리면 fragment가 필요하다고 출력됨

     C:\>ping -f -l 1472 packetinside.com
     Ping packetinside.com [216.239.38.21] 1472바이트 데이터 사용:
     216.239.38.21의 응답: 바이트=68 (1472 보냄) 시간=76ms TTL=53
     216.239.38.21의 응답: 바이트=68 (1472 보냄) 시간=74ms TTL=53
     216.239.38.21의 응답: 바이트=68 (1472 보냄) 시간=74ms TTL=53
     216.239.38.21의 응답: 바이트=68 (1472 보냄) 시간=72ms TTL=53
     216.239.38.21에 대한 Ping 통계:
     패킷: 보냄 = 4, 받음 = 4, 손실 = 0 (0% 손실),
     왕복 시간(밀리초):
     최소 = 72ms, 최대 = 76ms, 평균 = 74ms

     
     

• 1472 바이트보다 크게 1 바이트를 늘려서 전송해 보았더니 fragment 가 필요하다고 출력

  C:\>ping -f -l 1473 packetinside.com
  Ping packetinside.com [216.239.38.21] 1473바이트 데이터 사용:
  패킷 조각화가 필요하지만 DF가 설정되어 있습니다.
  패킷 조각화가 필요하지만 DF가 설정되어 있습니다.
  패킷 조각화가 필요하지만 DF가 설정되어 있습니다.
  패킷 조각화가 필요하지만 DF가 설정되어 있습니다. 
  216.239.38.21에 대한 Ping 통계:
   패킷: 보냄 = 4, 받음 = 0, 손실 = 4 (100% 손실),

  
  

참고 : http://www.packetinside.com/2013/02/mtumaximum-transmission-unit.html

• HTTP 헤더 중에는 Vary 헤더가 있음

• Vary 헤더는 동일한 URL에 대해 요청을 하더라도 요청한 사용자의 특징(User Agent, Accept Encoding, Origin 등등)에 따라 서로 다른 응답을 해 주기 위해서 존재함

• 웹 캐시에서는 Vary 헤더를 확인하고 해당 헤더에서 명시하는 조건에 따라 동일 URL이라 하더라도 다른 종류의 컨텐츠를 캐싱하고, 제공함

• Vary 헤더는 200 OK 응답과 동일하게 304 Not Modified 응답에서도 설정되어야함

• Vary 헤더를 사용하는 경우, 서버는 캐쉬한 응답을 적절한 Accept-Encoding 요청 헤더를 보낸 클라이언트에게만 보내도록 Vary: Accept-Encoding으로 설정

  
  

• 하나의 웹컨텐츠를 데스크톱과 모바일에서 서로 다르게 보여줘야 할 경우가 있음 → URI 정보로는 동일한 컨텐츠

  1. 웹서버에서는 프로그램으로 잘 표현되나, 캐시서버가 컨텐츠를 캐싱하고 있는 경우 문제가 발생 가능
  2. 모바일에서 컨텐츠를 요청하였을 때, 캐시서버가 데스크톱 컨텐츠를 직접 전달하여 문제가 발생할 수 있음
  3. 반대로 데스크톱 컨텐츠를 요청하였을 때, 캐시서버가 모바일 컨텐츠를 직접 전달하여 문제가 발생할 수도 있음
  4. Vary 헤더의 값으로는 HTTP 요청 헤더명이 사용
  5. 예시로 User-Agent를 값으로 사용

     Vary: User-Agent

     
     

• 캐싱하고 있는 컨텐츠의 최초 User-Agent 정보가 일치하지 않으면 캐싱된 컨텐츠를 전달 X

• 최초 모바일로 트와이스 이미지를 요청하여 전달받게 되면 캐싱된 트와이스 이미지는 모바일 User-Agent 값인 경우에만 직접 전달 가능 ->데스크톱에서는 캐싱된 트와이스 이미지를 사용 불가
  
  
  

Vary 헤더를 사용한 캐시와 웹 서버의 동작

1. 모바일 사용자가 twice.jpg 이미지를 요청 (최초의 요청)
2. 최초 요청이기 때문에 캐시 서버는 웹서버에게 클라이언트의 요청을 그대로 전달
3. 웹 서버에게 클라이언트의 요청 이미지를 전달 받음(응답에 Vary: User-Agent 헤더 포함)
4. 전달받은 이미지는 캐시 서버의 저장공간에 저장한 후 모바일 사용자에게 전달
5. 동일한 이미지를 모바일 사용자가 아닌 데스크톱 사용자가 요청
6. 분명 동일한 URI 경로에 요청임에도 불구하고 캐싱된 이미지를 전달 X(이전 캐싱된 컨텐츠와 요청한 컨텐츠의 User-Agent가 다름) → 웹 서버에게 클라이언트의 요청을 그대로 전달
7. 웹서버가 캐시 서버에게 동일하지만 Vary 헤더가 다른 컨텐츠를 전달
8. 그렇기에 프록시 서버는 동일한 URI 요청임에도 불구하고 캐싱할 당시의 User-Agent 정보를 비교하고 내용이 다르기에 캐싱된 컨텐츠를 직접 전달 X → 응답 헤더의 Vary : User-Agent가 다른 경우 caching된 컨텐츠 전달 X
   

   

HTTP의 Vary 헤더의 문법

Vary: *
Vary: <header-name>, <header-name>, ...

HTTP Vary 헤더의 지시자

1. * (asterisk)

• 각 요청에 대해서 캐시할 수 없는 요청으로 간주
• 더 좋은 방법으로 Cache-Control: no-store를 사용 → 객체를 저장하면 안된다는 의미로 좀 더 명확하게 표시

2. <header-name>

• 헤더 이름은 쉼표로 구분되며 캐시된 응답을 사용할 수 있는지 여부를 결정할 때 사용
  

• HTTP 프로토콜에서 server 헤더는 웹 서버의 종류를 나타냄 →서버의 소프트웨어 정보
• 너무 길고 상세한 서버의 정보는 불특정한 상대에게 공격을 받을 수 있기 때문에 주의해야함
• 공격자들이 서버의 정보를 보고 쉽게 보안상의 문제점을 찾아 공격 가능
  

문법

Server: <product>

server 헤더의 지시자 <product>

• 요청을 처리하는 소프트웨어 혹은 하위 제품의 이름
• HTTP 프로토콜의 server 헤더의 사용 예제

  Server: Apache/2.4.1 (Unix)

  
  

• 클라이언트(웹브라우저)는 서버가 제공하는 컨텐츠에서 일부분을 다시 요청하거나 갱신할 필요가 있는 경우 발생
• HTTP Range 요청 헤더는 서버에게 데이터의 일부분만 요청하는 헤더

• HTTP 프로토콜 Range 헤더를 사용하는 경우
  1. 스트리밍같은 동영상 데이터일 경우 총 5분짜리 영상인데, 처음부터 2분까지만 먼저 다운 → 다시 다운로드를 받으려 할때, 굳이 0 ~ 2분까지 모든 데이터를 다시 받을 필요 X
  2. 웹서버에서 특정 파일을 다운로드 하고 있는 중 여러가지 이유로 다운로드가 완료되지 못하고 중간에 끊어지는 경우 발생 → 처음부터 다시 받기 보다는 중간에 다운로드가 끊긴 시점부터 다시 받으면 효율적

• HTTP 프로토콜에서 Range 헤더를 사용할 때 동작 흐름도
  1. 클라이언트는 웹서버에게 200~400 bytes에 해당하는 데이터를 달라고 요청
  2. 웹서버는 "206 Partial Content" 라는 상태코드 메시지와 함께 요청한 200~400 바이트에 해당하는 데이터를 전달함.
  3. 클라이언트는 Range 헤더를 통해 여러 부분을 한번에 요청 가능하며, 서버는 클라이언트가 요청한 범위에 대한 데이터를 전달 가능
  4. 범위가 유효하지 않다면, 서버는 "416 Range Not Satisfiable" 에러를 보냄
  5. 서버는 Range 헤더를 무시하고 200 상태 코드와 함께 전체 문서를 전송
     

     

     
     
     
     

Range 헤더 문법

Range: <unit>=<range-start>-
Range: <unit>=<range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>, <range-start>-<range-end>

Range 헤더 사용 예제

Range: bytes=200-1000, 2000-6576, 19000-

지시자

1. <unit>

• 범위를 결정하는 단위.
• 보통 bytes

2. <range-start>

• 범위 요청의 시작 지점을 알리는 단위를 뜻하는 정수.

3. <range-end>

• 요청한 범위의 끝을 알리는 단위를 의미하는 정수.
• range-end 값은 옵션으로 사용할 수 있으며, 생략한다면 문서의 끝부분을 요청의 끝으로 사용
  
  
  

• HTTP/1.0 Pragma 헤더는 요청-응답 체인에 다양한 영향을 줄 수 있는 구현 관련 헤더
• HTTP/1.0 헤더 옵션 중 하나
• HTTP/1.1 Cache-Control 헤더가 생기기 전, HTTP/1.0 Pragma 헤더는 Cache-Control 헤더의 역할을 대신하는 헤더로 사용
• 캐시가 캐시 복사본을 릴리즈 하기 전에 원격 서버로 요청을 날려 유효성 검사를 강제하도록 함
• Cache-Control: no-cache와 동일 효과 → HTTP/1.0 Pragma 헤더는 캐시서버가 응답한 컨텐츠를 저장하지 말 것을 요구하는 헤더
  
  
  

HTTP1.0에서 Pragma 헤더 사용법

• Cache-Control: no-cache 와 동일한 효과
• 서버에서 사용되는 경우는 중간의 캐시서버가 응답한 컨텐츠를 저장하지 말 것을 요구하는 헤더
• 요청이건 응답이건 포함되어 있는 경우에는 캐시서버의 캐싱 동작 자체를 거부

  Pragma: no-cache

  
  
  

Pragma 헤더 주의 사항

• Pragma는 HTTP 응답에서 명시되지 않았던 헤더 → HTTP/1.1 Cache-Control 헤더의 신뢰할만한 대체재로 사용될 수 없음
• Pragma 헤더는 HTTP/1.0를 사용하는 클라이언트만을 위한 비공식적인 헤더
• 캐시서버의 동작을 거부하려면, Expires 헤더와, Cache-Control을 이용하는게 HTTP 1.1에서는 더욱 바람직한 방법임

• Last-Modified 헤더는 브라우저가 서버로 요청한 파일의 최종 수정 시간을 알려줌
• Last-Modified 헤더는 응답을 HTTP 헤더에 서버가 알고 있는 가장 마지막 수정된 날짜와 시각을 담고 있음
• 저장된 리소스가 이전과 같은지 유효성 검사자로 사용
• ETag 헤더보다는 덜 정확하지만, Last-Modified 헤더는 ETag 헤더에 대한 차선책으로 사용
• Last-Modified 헤더를 쓸 경우 브라우저가 다음에 다시 접속할 때 서버에게 파일이 수정되었는지 여부를 물어봄 → 서버가 수정 여부를 내려주는 헤더인 조건 요청은 If-Modified-Since 또는 If-Unmodified-Since (en-US) 헤더를 사용
• 캐싱을 해 성능을 향상시킬 수 있는데 이미지/CSS/JS와 같은 정적파일들은 아파치에서 자동적으로 Last-Modified, If-Modified-Since 헤더를 붙여줌
• php파일과 같은 동적 파일들에는 로직상에서 헤더를 붙여주면 됨
• 응답 날짜 헤더(Date Header)는 언제 응답이 나타났는지 나타내는 반면, Last-Modified 헤더는 지난 할당되어진 자원이 바뀔 때를 나타냄
• 즉, Last-Modified value는 Date value보다 최근일 수 없음
  
  
  

Last-Modified 헤더의 사용시점

• Last-Modified 헤더는 시간 값을 기준으로 파일 수정 여부를 판별
• 짧은 시간 내에 변경되는 리소스 등에는 Last-Modified 헤더를 사용하는 것이 적합
  
  
  

Last-Modified 헤더 참고 사진

지시자

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로 표현

• 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 와 함께 전체 데이터 전송