1. 일반 헤더
1-1. 헤더
- HTTP 전송에 필요한 모든 부가정보
- 최신 HTTP BODY
- 표현은 요청이나 응답에서 전달할 실제 데이터
- 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
- 표현: Content-Type, Content-Encoding, Content-Language, Content-Length(표현 헤더는 전송, 응답 둘다 사용)
1-2. 협상
- 협상 종류: Accept, Accept-Charset, Accept-Encoding, Accept-Language
- 우선순위
- 0~1, 클수록 높은 우선순위
- 구체적인 것이 우선
1-3. 전송 방식 설명
- 단순 전송(Content-Length)
- 압축 전송(Content-Encoding: 뭐로 압축했는지 알려줘야함)
- 분할 전송(Transfer-Encoding: Content-Length은 예측불가라 사용X)
- 범위 전송(Content-Range)
1-4. 일반 정보
- From: 유저 에이전트의 이메일 정보
- Referer: 이전 웹 페이지 주소
- User-Agent: 유저 에이전트 애플리케이션 정보
- Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
- Date: 메시지가 생성된 날짜
1-5. 특별한 정보
- Host
- 요청한 호스트 정보(도메인)
- 필수
- 하나의 서버 안에 실제 여러 애플리케이션 구동중일 수 있는데, 이때, host가 없으면 클라이언트가 A, B, C 어플리케이션 중 어디로 들어가야하는지 모름
- Location: 페이지 리다이렉션
- Allow: 허용 가능한 HTTP 메서드
- url경로는 있는데, get, head, put만 제공을 하는데 post를 보냈을 때 405 에러보내고 응답에 get, head, put만 허용된다고 보내야함(잘 사용X)
- Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
1-6. 인증
1-7. 쿠키
[ 쿠키 미사용시 ]
- 로그인 이후 /welcome이라고 보냈는데, 서버 입장에서는 지금 보낸 클라이언트가 로그인한 사람인지 아닌지 알 수 없음
- HTTP는 메세지 전송끝나면 연결 끊어버림
- 클라이언트와 서버는 서로 상태를 유지하지 않음
[ 쿠키 사용 ]
- 모든 요청에 사용자 정보 포함하면 내용이 길어지므로 쿠키 사용
- key: user, value: 홍길동이라는 값을 쿠기 저장소에 저장
클라이언트가 서버에 요청을 보낼 때마다 쿠기 저장소를 뒤져서 쿠키값을 무조건 꺼내서 cookie라는 http header를 만들어 서버로 보냄
[ 쿠키 ]
- 쿠키는 필요할때만 클라이언트 웹브라우저에 저장을 해두고 클라이언트 자바스크립트 로직에서만 사용하고 서버로 전송안하려면 웹 스토리지 사용해야함
- 쿠키는 세팅하면 무조건 서버로 계속 보냄
만약 쿠키가 100개라면 100개가 계속 서버로 전송됨 -> 네트워크 부화
- 생명주기: Expires, max-age
- 도메인
- 명시O -> 명시한 문서 기준 도메인 + 서브 도메인 포함
- 명시X -> 현재 문서 기준 도메인만 적용( example.org 에서만 쿠키 접근, dev.example.org는 쿠키 미접근)
- 경로: 경로를 포함한 하위 경로 페이지만 쿠키 접근(일반적으로 path=/ 루트로 지정)
- 보안: Secure, HttpOnly, SameSite( 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송)
2. 캐시와 조건부 요청
2-1. 캐시 적용
- 캐시가 없을 때 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야함 -> 효율적이지 못함
- 인터넷 네트워크는 매우 느리고 비쌈
- 첫번째 요청
- 두번째 요청
- 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨
- 비싼 네트워크 사용량을 줄일 수 있음
- 브라우저 로딩 속도가 매우 빠름
- 세번째 요청
- 캐시 시간초과가 되면, 다시 요청해야함
-> 서버에서 같은 캐시데이터 내려줌(이때 1.1M네트워크 다시 사용됨)
2-2. 캐시 시간 초과
- 캐시 만료후에도 서버에서 데이터를 변경하지 않았다면, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 있다면 확인 가능 -> 검증 헤더
- Last-Modified: 응답 결과를 캐시에 저장하고, 데이터 최종 수정일과 동일하면 있는 데이터 제공
- if-modified-since(조건부 요청 헤더): 캐시가 가지고 있는 데이터 최종 수정일과 확인해 데이터가 수정 여부 확인 -> 304 Not Modified + HTTP Body가없음
2-3. 검증 헤더와 조건부 요청
[ Last-Modified, If-Modified-Since 단점 ]
- 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
[ 해결방안 ]
- ETag(임의의 고유한 버전 이름), If-None-Match
- 캐시 제어 로직을 서버에서 완전히 관리
2-4. 캐시 제어 헤더
- Cache-Control: 캐시 제어
- 캐시 유효 시간(초단위)
- 데이터는 캐시해도 되지만, 항상 원(origin)서버에 검증하고 사용해야함
- Pragma: 캐시 제어(하위 호환)
- Expires: 캐시 만료일 지정(하위 호환)
2-5. 프록시 캐시
- 응답이 느리니까 미국에 있는 원서버에 바로 접근하면 느리니까 프록시 캐시서버를 거치게끔 되어있음 -> 빠른 응답 가능
- 공용으로 사용하는 캐시 서버
2-6. 캐시 무효화
- Cache-Control: no-cache, no-store, must-revalidate
[ no-cache ]
- 항상 원 서버에 검증하고 사용
[ no-store ]
[ must-revalidate ]
- 캐시 만료후 최초 조회시 원 서버에 검증해야함
- 원 서버에 접근할 수 없는 경우, 항상 오류가 발생
