📘HTTP 헤더
(과거)
General 헤더
메시지 전체에 적용되는 정보
Request 헤더
요청 정보
Response 헤더
응답 정보
Entitiy 헤더
엔티티 바디 정보 ex) content-type
(최신)
- 메시지 본문 = 페이로드
- 엔티티 대신 표현이란 단어로 대체, 요청이나 응답에서 전달할 실제 데이터
- 헤더 이름도 표현 헤더로 변경
Content-Type
표현 데이터의 형식 설명.
미디어타입, 문자 인코딩
ex) text/htl: charset=utf-8, application/json
Content-Encoding
표현 데이터 인코딩
데이터 전달하는 곳에서 압축후 인코딩 헤더 추가, 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
📗협상(content negotiation)
Accept~로 클라이언트가 선호하는 미디어 타입을 전달한다.
협상헤더는 요청시에만 사용
📗전송 방식
단순전송
한번에 요청하고 한번에 받는것
압축전송
서버에서 압축해서 Content-encoding 정보를 포함해서 클라이언트에 보낸다.
분할전송
일정 바이트 수의 데이터를 나눠서 보낸다. 마지막에 0표시 하고 \r\n 을 보낸다.
-> 분할전송시에는 content-length 보내면 안된다.
범위전송
클라이언트가 content의 범위를 지정해서 요청하면 서버에서 해당 범위만큼의 데이터만 보낸다.
📗일반 정보
From
유저 에이전트의 이메일 정보, 요청에서 사용
Referer
현재 요청 페이지의 이전 웹 사이트의 주소
Referer를 사용해서 유입 경로 분석 가능
요청에서 사용
User-Agent
웹 브라우저 정보, 애플리케이션 정보
어떤 종류에 브라우저에서 장애가 발생하는지 파악가능,
요청에서 사용
Server
요청 처리하는 ORIGIN 서버의 소프트웨어 정보
응답에서 사용
Date
메시지 발생 날짜와 시간
응답에서 사용
📗특별한 정보
Host
요청한 호스트 정보(도메인)
요청에서 사용하는 필수 값
하나의 ip주소에 여러 도메인이 매핑되어 있을때(통신은 ip로 하기때문에 도메인들을 구분할 수 없어서 따로 host 헤더를 넣어준다.)
Location
페이지 리다이렉션
201(Created):Location 값은 요청에 의해 생성된 리소스 URI
3xx(Redirectino):Locatino 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴
Allow
허용 가능한 HTTP 메서드
405 응답에 포함해야함
Allow: Get,Head,Put
Retry-After
유저 에이전트가 다음 요청까지 기다려야 하는 시간
📗인증
- Authorization: 클라이언트 인증정보를 서버에 전달
- www-Authenticate:
401 오류시 해당 인증을 사용해야한다는 정보를 클라이언트에 전달
📗쿠키
Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
Cookie: 클라이언트가 서버에서 받은 쿠키 저장하고 HTTP 요청시 서버로 전달
쿠키를 사용하는 이유
- http는 무상태 프로토콜이므로, 로그인 후 서버는 클라이언트가 누구인지 알 수 식별 불가
- 로그인시 user 정보를 서버에 보내면 서버에서는 set-cookie:의 형태로 클라이언트에 보낸다(이때 유저의 정보를 sessionid의 형태로 바꿔서 보낸다). 클라이언트는 set-cookie의 데이터를 쿠키 저장소에 저장한다.
- 클라이언트는 요청마다 cookie의 값을 무조건 꺼내서 서버에 보낸다.
모든 요청에 쿠키 정보 자동 포함
쿠키의 생명주기
- 영속쿠키
Set-Cookie:expires =
형태로 만료일이 지나면 쿠키 삭제한다. - 세션 쿠키
만료 날짜를 생략하면 브라우저 종료시 까지만 유지한다.
쿠키 도메인
- 도메인 명시
명시한 도메인 + 서브 도메인 - 생략
현재 문서 기준 도메인만 적용
쿠키 경로
- 이 경로를 포함한 하위 경로 페이지만 쿠키 접근 가능
쿠키 보안
Secure
- 적용하면 https인 경우에만 쿠키 전송
HttpOnly - XSS 공격 방지
- 자바 스크립트에서 접근 불가
- Http 전송에만 사용
SameSite - XSRF 공격 방지
- 요청 도메인, 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송
📘캐시와 조건부 요청
캐시가 없을때
같은 요청을 여러번해도 계속 네트워크를 통해 데이터를 다운받아야한다.
캐시 적용 후
- 응답 결과를 캐시에 적용하고, 캐시 가능 시간동안에는 캐시에서 바로 조회가 가능하다.-> 네트워크 사용이 필요없다.
- 캐시 가능 시간이 초과 되면, 재요청해야한다.
캐시 만료 후
- 두 번째 요청시 검증헤더(If-Modified-Since)에 데이터 최종 수정일을 포함하여 보낸다.
- 서버에서의 데이터 최종 수정일과 일치한다면
- 서버에서 바디 없이 수정되지 않았음을 알리는 헤더만 포함해서 응답결과로 보낸다.
- 캐시에서 다시 데이터를 불러와서 사용한다.
If-Modified-Since의 단점
- 1초 미만의 캐시 조정이 불가능
- 날짜 기반의 로직 사용
- 수정해서 날짜는 다르지만 데이터 결과가 똑같은 경우
- 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
ETag
- 캐시용 데이터에 임의의 고유 버전을 달아둔다.
- 데이터가 변경되면 이름 바꾸어서 변경한다(Hash 다시 생성).
- 캐시 제어 로직을 서버에서 관리할 수 있다.
Cache-Control
max-age: 캐시 유효시간
no-cache: 데이터 캐시해도 되지만, 항상 origin 서버에 검증하고 사용하라
no-store: 데이터 민감한 정보 있으므로 저장하면 안됨
public: public캐시에 저장되어도 됨
privae: private캐시에 저장되어야함
must-revalidate: no-cache와 비슷한 기능을 하지만 origin서버에 접근할 수 없을경우엔 무조건 504오류를 응답하도록 한다.
프록시 캐시
- origin 서버까지 거리가 너무 멀경우, 가까운 public한 프록시 캐시 서버를 둬서 응답을 빠르게 한다.
