✅HTTP 웹 기본지식(헤더)

📘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 공격 방지
• 요청 도메인, 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

📘캐시와 조건부 요청

캐시가 없을때

같은 요청을 여러번해도 계속 네트워크를 통해 데이터를 다운받아야한다.

캐시 적용 후

• 응답 결과를 캐시에 적용하고, 캐시 가능 시간동안에는 캐시에서 바로 조회가 가능하다.-> 네트워크 사용이 필요없다.
• 캐시 가능 시간이 초과 되면, 재요청해야한다.

캐시 만료 후

1. 두 번째 요청시 검증헤더(If-Modified-Since)에 데이터 최종 수정일을 포함하여 보낸다.
2. 서버에서의 데이터 최종 수정일과 일치한다면
3. 서버에서 바디 없이 수정되지 않았음을 알리는 헤더만 포함해서 응답결과로 보낸다.
4. 캐시에서 다시 데이터를 불러와서 사용한다.
   

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한 프록시 캐시 서버를 둬서 응답을 빠르게 한다.