[TIL 2022-2-8] HTTP 헤더 공부

HTTP 헤더

- 헤더 분류

1999RFC RFC2616(폐기됨)

1. General 헤더 - 메세지 전체에 적용되는 정보 ex) Connection: close
2. Request 헤더 - 요청 정보
3. Response 헤더 - 응답 정보
4. Entity 헤더 - 엔티티 바디 정보 ex) Content-Type: text/html 등 엔티티 본문의 데이터를 해석할 수 있는 정보 제공

RFC723x

엔티티 -> 표현(Representation)으로 변경됐다. 메시지 본문 = 페이로드(payload) 이다. 메시지 본문에 표현 데이터가 포함된다. 메시지 본문을 통해 표현 데이터를 전달한다. 표현 헤더는 표현 데이터를 해석할 수 있게하기위해 데이터 유형, 길이, 압충 정보 등을 전달하기 위해 존재한다.(REST API 의 REST(Representational State Transfer) 의 Representatinal은 여기서의 Representation을 말한다)

 

 

표현(Representation) 헤더

Content-Type - 표현 데이터의 형식 ex) text/html, application/json, image/png 등의 value를 가짐

 

Content-Encoding - 표현 데이터의 압축 방식. 데이터를 읽는 쪽에서 이 헤더를 보고 압축을 품

   ex)gzip, deflate, identity(압축안함)

 

Content-Language - 표현 데이터의 자연 언어

   ex) ko, en, en-US

 

Content-Lengh - 표현 데이터의 길이, 바이트 단위

 

협상(Content Negotiation) 헤더

협상 헤더는 요청시에만 사용한다. 응답을 받을 때, 응답 데이터에 대해 클라이언트가 선호하는 데이터를 협상 헤더를 통해 요청한다.

 

Accept - 클라이언트가 선호하는 미디어 타입으로 전달해달라고 요청

Accept-Charset, Encoding, Language - 클라이언트 선호하는 문자 인코딩, 압축 인코딩, 자연언어를 전달해달라고 요청

 

항상 서버가 내가 원하는대로 데이터를 제공해줄 순없기 때문에Quality Values(q) 를 통해 가중치를 주어 이를 보완한다.

ex) Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7 (q값이 없으면 1, 0~1 사이에서 클수록 높은 우선순위) 

 

 

전송 방식

- 단순 전송: Content-Length 의 크기만큼의 데이터를 분할이나 압축등의 저리없이 한번에 전송

- 압축 전송: gzip과 같이 압축해 데이터를 전송, 용량이 확 줄어듬

- 분할 전송: Transfer-Encoding: chunked 를 활용해 분할해서 전송, Content-Lengh 는 없어야함!! 

- 범위 전송; Range: 1001-2000 과 같이 범위를 정해서 그부분만 전송

 

 

일반 정보 헤더 

Form - 크롤링등 할 때 본인 메일주소 기입, 잘 쓰진 않음

Referer - 이전 웹 페이지 주소를 가짐(블로그 관리에서 내글로 어디서 부터 유입됐는지 확인할 수 있는데 이를 통해)

User-Agent - 유저 에이전트의 애플리케이션 정보이다

Server - 요청을 처리하는 오리진 서버의 소프트웨어 정보, 응답에서 사용한다.

Date - 메시지가 발생한 날짜와 시간, 응답에만 사용!!

 

 

특별한 정보 헤더

Host - 요청에서 사용하는 필수 해더. 하나의 서버에 여러 도메인이 존재할 경우 이를 통해 구분.

 

Location - 웹 브라우저가 3xx 응답의 결과에 대해 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트) 201 응답 코드일 때는 요청에 의해 생성된 리소스 URI를 가짐

 

Allow - 서버에서 허용 가능한 HTTP 메서드를 알려줌 ex) GET,HEAD, PUT

 

Retry-After - 503 응답코드일 떄 서버가 언제까지 불능 상태인지 알려줌.(날짜 또는 초단위 표기)

 

 

쿠키 

HTTP는 Stateless 하다. 하지만 로그인상태처럼 상태가 필요한 경우가 있기 때문에 이를 쿠키를 통해 제공한다.쿠키는 도메인에 요청할때마다 헤더에 추가되어 보내지기 때문에 항상 보내는게 아니라 필요할 때만 헤더가 아닌 다른 방법으로 보내고싶다면 브라우저의 세션스토리지나 로컬 스토리지를 활용한다.

 

 

캐시

캐시는 요청 리소스를 가까운 곳에 복사하여 저장하고있다가 요청시 제공하는 기술을 말한다. 데이터의 실 저장소와 요청하는 클라이언트 사이에서, 데이터를 캐시에 저장하여 실 저장소로부터 데이터를 받을 필요 없이 가까운 캐시 저장소에서 데이터를 받으므로써 훨씬 효율적으로 데이터를 얻을 수 있다. 이 캐시의 개념은 컴퓨터구조부터 웹까지 다양한 분야에서 쓰인다.

 

HTTP 프로토콜에서 말하는 웹캐시는 두가지가 있는데 사설 브라우저 캐시와 공유 프록시 캐시다. 

 

사설 브라우저 캐시는 말 그대로 각각의 클라이언트가 사용하는 웹 브라우저에 존재하는 캐시로, 이 캐시저장소에서는 사용자가 서버로부터 다운로드 받은 데이터들이 저장되어있고, 다시 이전에 요청했던 데이터를 요청하면, 이 캐시에서 찾아 다시 다운로드 받을 필요없이 바로 사용한다.

 

캐시를 이렇게 동작하도록 하기위해 클라이언트와 서버는 서로 캐시를 컨트롤하는 HTTP 헤더를 주고받는다.

 

cache-control  - 캐시의 생존 시간을 결정한다. 서버가 "cache-control: max-age=60" 와 같이 설정하면 클라이언트는 브라우저 캐시에 데이터를 60초 동안 저장한다. 프록시 서버의 개념에서 프록시 서버에 응답이 저장되거나 막을 수도 있다.

 

Last-Modified , ETag 검증 헤더로 캐시데이터와 서버의 데이터가 같은지 검증하기 위해 존재한다. Last-Modified는 최근에 수정된 시각, ETag는 캐시용 데이터에 임의로 이름을 달아줌으로써 캐시로 저장될 데이터가 변경되면 이 검증헤더를 업데이트하여 클라이언트가 origin 서버에 재요청을 보내도록 한다.

 

If-Modified-Since, If-Match 각각Last-Modified, ETag가 맞는지 클라이언트에서 요청할 때 사용하는 헤더다. 조건부 요청헤더라고 한다. If-Modified-Since, If-Match 도 있다.

 

https://developer.mozilla.org/ko/docs/Web/HTTP/Caching

HTTP caching - HTTP | MDN