HTTP #8 헤더 (요청헤더, 응답헤더, 쿠키, 캐시, 프록시)

HTTP 헤더에는 StartLine 정보 (HTTP 버전, URI, 상태코드)를 제외한 모든 정보를 넣는다.

Key-Value 구조를 가지며 하나의 Key에 여러개의 값을 할당할 수 있다. 물론 이렇게 사용하는 경우는 거의 없지만.

참고로 헤더이름(key)는 대소문자를 구분하지 않는다. (내용, 즉 입력값만 대소문자 구분)

 

# 1999년 - HTTP 표준 RFC2612

헤더의 종류를 구분하고 순서대로 작성했었다.

 

# 2014년 - 표준 RFC7230~5

[Entity헤더와 Body메시지]를  [Representation헤더와 Payload메시지]로 바꾸고 HTTP 스펙을 크게 개정하였다.

한글로하면 [엔티티 헤더와 바디메시지]가  [표현헤더와 페이로드]로 바뀐 셈.

 

이제 Request, Response의 구분이 없다.

표현 헤더는 전송 데이터를 해석할 수 있는 정보를 제공해주며 [Request Response]에 둘 다 사용한다.

➡ Contet-length처럼 해석 정보가 아니라 값 자체가 정보인 경우는 Payload 헤더라고 말한다.

 

 

---

# 표현 헤더(Content Representation)

메시지 내용에 대한 메타데이터를 의미한다.

컨텐츠(Body)의 메타데이터

• Content-Type: 표현 데이터의 형식, [ text/html, application/json, image/png, multipart/...등 데이터 형식정보]
• Content-Encoding: 표현 데이터의 압축 방식, [gzip, defalte, identity(=압축안했음) 등 현재 데이터의 압축방식]
• Content-Language: 표현 데이터의 자연 언어 [ ko, jp, en, en-US ]
• Content-Length: 표현 데이터의 길이 [ 바이트 단위 Body 길이 ]
  ➡ 참고로 Transfer-Encoding을 사용하면 길이가 포함되어있어 Content-Length를 따로 쓰면 안된다. 

 

---

# 협상 헤더(Content Negotiation)

클라이언트가 보내는 데이터의 형식, 클라이언트가 선호하는 데이터의 형식을 입력한다.

Accept에 적혀있는 인코딩을 지원하지않는다면, 서버에서는 다른 걸 보내거나 400오류를 띄울 수 있다.

 

 

• 이를 협상이라고 표현한 이유는, 원하는 응답 형식이 없다면 다음 우선순위를 지정할 수 있기 때문이다.

이렇게 각각의 우선순위를 다르게 지정할 수 있다. text/html;q=1, application/json;q=0.9

 

 

• 만약 우선순위가 같거나 포함관계(text/*, text/html/..)라면 구체적인 것을 먼저 사용한다.

*/*는 아무거나 받겠다는 의미

 

---

# 전송방식 헤더 (Transfer-Encoding, Content-Range)

일반전송, 압축전송, 분할전송등 보내는 방식을 의미하는 헤더이다.

분할 전송(Transfer-Encoding)의 경우에는 Content-Length를 적으면 안된다. (분할해서 알 수가 없으니까)

Transfer-Encoding를 사용하면 분할된 메시지를 보낼 때 크기를 함께 보낸다.

 

• Range와 Content-Range는 일부만 다시 받고싶을 때 사용한다.(분할전송등으로 이미 절반은 받은 경우)

Range는 요청, Content-Range는 응답

---

# 일반 정보헤더

클라이언트 정보, 서버 정보, 요청기기, 날짜 등 일반정보를 담는 헤더이다.

• From : 유저의 이메일 정보, 거의 사용하지 않는 헤더이다. (ex 크롤링을 할 때, 내가 누구인지 알려주는 연락처역할)
• Referer : <요청전용> 이전 웹사이트의 URI 주소이다. 유입경로를 확인할 수 있으며 현업에서 정말 자주 사용한다.
  ➡ 참고로 이는 Referrer는 오타인데 이미 브라우저를 다 만들어버려서 바꿀 수가 없다고 한다..ㅋㅋ; 
• User-Agent : <응답전용> 유저의 에이전트 정보, 즉 사용한 브라우저, 사용한 기기등을 확인할 수 있다.

클라이언트 앱(브라우저) 정보, 통계 정보등으로 요청에만 사용하는 헤더이다.

• Server : <응답전용>요청을 처리하는 서버(Origin 서버)의 소프트웨어 정보

• Date : <응답전용> 메시지가 발생한 날짜와 시간을 적어보낸다. 최신 스펙에서는 응답만 사용하도록 바뀌었다.

 

---

 # 특별한 정보헤더

• Host : 요청한 호스트(도메인) 정보. 입력이 필수인 헤더이다.
  Host 헤더가 필수가 된 이유는, 하나의 IP에 여러 도메인이 적용되는 경우(가상 호스트)가 많아졌기 때문이다.

• Location : 페이지 리다이렉션, 응답에 Location값이 있으면, 해당 값으로 리다이렉션 시킨다.

• Allow : 보통 [405 Method Not Allowed] 응답에 포함하는 헤더이며 허용가능한 HTTP 메서드를 제공한다.
  ➡ 다만 서버에서 이런 에러까지 구분해서 구현하는 일은 거의 없다.
• Retry-After : [503 Service Unavailable]의 응답에 사용하는 헤더이며, 서버가 복구되는 시간이나 날짜를 제공한다.

다만 실제로 Retry-After를 사용하는 일은 거의 없다. 언제 복구될지 모르니까 ㅠㅠ..

 

---

인증 요청헤더(Authorizaition)

인증헤더는 OAuth2등을 찾아보면 어떻게 사용하는지 쉽게 알 수 있다.

• Authorization : 인증정보를 전달할 수 있다.
• WWW-Authenticate : [401 Unauthorized] 응답에 함께 사용하며, 필요한 인증정보를 형식을 제공한다.

 

---

# 쿠키 (Cookie)

HTTP는 무상태, 비연결을 지향하는 프로토콜이다. 여러 연결에서 상태를 유지하려면 쿠키나 토큰을 사용해야한다.

• 요청을 보낼 때 쿠키는 브라우저에서 웹 헤더에 넣어 같이 보낸다. (HTTP 스펙이 그렇게 만들어져있다.)
  ➡ 그래서 서버에 보내지않고, 브라우저에서만 사용할 데이터는 웹스토리지(LocalStorage)를 사용한다.
• Set-Cookie를 이용하여 서버에서 클라이언트로 쿠키를 전달하고 클라이언트에서 사용할 수 있다.

2021.08.29 - [Backend/Spring MVC] - Spring Login#1 쿠키와 세션

다른 사이트의 쿠키(Third-party Cookie)를 읽어 맞춤형 광고에 개인정보 문제가 있어 Chrome에서는 Floc이란걸 밀고 있다.

 

 

@쿠키의 유효기간

쿠키는 유효기간이 없다면 [세션쿠키, 브라우저 종료까지만 유지]되고

만료 기간이 있다면 [영속 쿠키]로 로컬PC에 저장된다. 즉, 쿠키는 변조하거나 탈취하기 쉬워 개인정보를 넣으면 안된다.

 

 

@쿠키 Path, Domain 지정

• 쿠키값에 domain을 지정해주면, 명시한 도메인(naver.com)과 서브도메인(blog.naver.com)만 사용가능하다.

물론 세션쿠키로 사용해야 보안에 의미가 있다. 로컬PC가 아닌 브라우저 메모리에만 존재하니까

• 마찬가지로 쿠키를 사용할 경로를 지정해줄 수 있다. Domain 제한과 함께 사용해야 의미가 있긴하다.

 

 

@ 쿠키 - 보안 (Seucre, HttpOnly, SameSite)

이는 보안관련 공부를 할 때 자연스럽게 알게된다. 참고로 SameSite는 최근에 나온 쿠키 보안기능이다.

 

---

# 조건부 요청[304 Not Modified]

바뀐 데이터가 없는데, 계속해서 반복요청하는건 네트워크 비용을 상당히 많이잡아먹는다.

• 그래서 브라우저에서는 같은 요청의 경우 캐시 저장소를 사용해서 받은 데이터를 재사용한다.
• 서버에서는 HTTP 헤더에 cahce-control등으로 캐시의 보관을 요청할 수 있다. 

 

• 해당 캐시는 max-age=60, 즉 60초동안만 캐시로 활용하고 그 이후에는 서버에 다시 요청을 한다.
  ➡ 이 경우 서버에서 [304 Not Modified]를 이용하여 브라우저 캐시를 다시 사용하도록 리다이렉트 시킬 수 있다.
• 서버에서는 Last-Modified 등의 헤더정보로 304를 보낼지, 새로운 데이터를 보내줄지 여부를 결정할 수 있다.
  ➡ 그래서 응답을 보낼 때 Last-Modified를 적어서 보내는 이유도 있다.

  

  브라우저가 자동으로 포함시킨 if-modified-since 값

요청할 떄에는 if-modified-since를 이용해서 마지막 수정일자 정보를 서버에 넘기면 된다.

 

그러면 서버에서 갱신할 필요가 없다고 판단되면, [200 OK] 대신 [304 Not Modified]를 전송한다.

 

 

---

# 검증 헤더와 조건부요청

하지만 Last-Modified와 If-Modified-Since만 사용하게되면 다음과 같은 문제점이 있다.

• A->B->A 같이 수정은 되었지만, 내용이 그대로인 경우에도 불필요하게 다시 다운로드 한다.
• 시간(날짜)기반의 헤더라서 1초 미만단위이나 아예 데이터 버전 기반으로 신규요청/캐시사용 조정이 불가능하다.
  ➡ ETag( Entity Tag )를 이용해서 캐시데이터에 고유한 이름 or 버전을 명시할 수 있다.

  

 

@ ETag와 If-None-Match

• If-None-Match 를 이용하여 ETag를 서버안에서 조건 컨디션처럼 사용할 수 있다.
  ➡ 동작은 단순하다. If-None-Match에 포함한 ETag의 값이, 서버와 다른경우만 요청[200]을 보내는 방식

검증 헤더와 조건부 요청 헤더의 정의

 

---

# 조건부 요청헤더를 이용한 캐시설정

대부분 Cache-Control 헤더를 이용해서 설정하고, 옛날 HTTP에서는 Pragma와 Expires를 사용했었다.

 

• Cache-Control의 값은 3가지가 있다. no-cache 옵션은 캐시데이터를 사용하는 옵션임을 기억하자.

no-cache는 항상 서버에 검증하여 304를 받고 캐시를 사용하라는 의미이다.

 

HTTP 1.0 이하 버전에서는 이렇게 사용했었다.
➡ 참고로 Cache-Control와 함께 사용해서 충돌이 발생하면 아래 헤더들은 무시된다.

• pragma: no-cache
• expires: Mon, 01 Jan 1990 00:00:00 GMT

 

---

# 프록시 캐시 서버 (CDN 서버, AWS_클라우드 프론트)

요청 속도를 올리기위해서, 중간에 대체자(Proxy)서버를 두어 캐시하여 사용하는 방법이다.

프록시 캐시는 아래와 같은 Cache-Control 값을 이용해 설정할 수 있다.

그래서 최초 접근한 유저는 속도가 느린데, 그 다음 유저부터는 속도가 빨라지기도 한다.

 

---

# 캐시 무효화

최근의 웹 브라우저는 따로 헤더를 조작하지 않더라도 캐시를 적극적으로 사용한다.

그래서 캐시가 되면 안되는 민감한 데이터의 경우 Cache-Control을 통해 캐시를 무효화하는 방법이 있다.

➡ 은행의 통잔잔고가 캐시되어서 계속 재사용된다고 생각해보자. 확실하게 무효하지않으면 큰일날 수 있다. 

혹시나 HTTP1.0 이전버전을 사용할까봐 Pragma도 함께 넣어주는게 일반적이다.

 

이 4가지를 조합하면 아래와 같이 동작한다. 즉 모든상황에서 확실하게 캐시를 무효화 시킬 수 있다.

이정도만 해줘도 충분하다. 구글 같이 변태같은 곳만 추가적인 max-age=0까지 해주는 경우가 있다 한다.

no-cache로 항상 요청하고, no-store로 캐시저장을 방지하면 충분할 것같은데 must-revalidate까지 쓴다.

그 이유는 프록시 서버 때문이다.

 

• no-cache로 사용하는 경우, 원 서버(Origin)가 응답이 없어도 요청을 전송하게 동작할 가능성이 있다.

개발자 입장에서는, 서버가 끊겼을 때 500에러보다는 프록시 응답을 해주는게 더 낫다고 생각하는게 당연하다.

 

• must-revalidate는 프록시를 무시하고 무조건 원서버에서 요청을 받아온다.