HTTP (4) | Network

November 5, 2023

HTTPNetwork

이 글은 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 듣고 정리한 내용입니다.

HTTP 헤더1

용도

HTTP 표준 최신 스펙 - RFC7230

HTTP BODY - message body

HTTP/1.1 200 OK
<!-- 표현 헤더 -->
Content-Type: text/html;charset=UTF-8
Content-Length: 3423

<!-- 표현 데이터, 메세지 본문 -->
<html>
  <body>...</body>
</html>

표현 헤더

협상 (콘텐츠 네고시에이션)

클라이언트가 선호하는 표현요청

전송 방식

일반 정보

From - 유저 에이전트의 이메일 정보

Referer - 이전 웹 페이지 주소

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

Server - 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보

Date - 메세지가 발생한 날짜와 시간

특별한 정보

Host - 요청한 호스트 정보(도메인)

GET /hello HTTP/1.1
HOST: aaa.com

Location - 페이지 리다이렉션

Allow - 허용 가능한 HTTP 메서드

Retry-After - 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

인증

Authorization - 클라이언트 인증 정보를 서버에 전달

WWW-Authenticate - 리소스 접근시 필요한 인증 방법 정의

쿠키

쿠키를 사용할 때 다음과 같은 헤더를 사용한다.

Stateless

대안 1

모든 요청에 사용자 정보를 포함한다. -> 모든 요청과 링크에 사용자 정보가 포함된다. -> 보안에 문제가 된다.

대안 2 - 쿠키!!

로그인 시

POST /login HTTP/1.1
user=홍길동

HTTP/1.1 200 OK
Set-Cookie: user=홍길동

홍길동님이 로그인했습니다.

GET /welcome HTTP/1.1
Cookie: user=홍길동

모든 요청에 쿠키 정보를 자동 포함한다.

생명주기

도메인

경로

보안

HTTP 헤더2

캐시 기본 동작

캐시가 없을 때

캐시 적용

웹 브라우저의 요청

GET /star.jpg

서버의 응답

HTTP/1.1 200 OK
Content-Type: image/jpeg
<!-- 캐시가 유효한 시간: 60초동안 캐시가 유효하다. -->
cache-control: max-age=60 
Content-Length: 34012

lkj123kdkfjaodjgasdjfoasdf
sasdf;qkawj9;o4ruasawekfasdf;skfjaf1234

최초 요청시 star.jpg를 받는다. 웹브라우저에는 캐시를 저장하는 저장소가 있는데, 응답 결과를 캐시에 저장한다. (60초 동안 유효하다.) 두 번째 요청시 캐시를 뒤지고, 유효하다면 캐시에서 이미지를 바로 가져온다.

캐시 시간이 초과 한다면?

캐시가 만료되었어도 클라이언트가 가진 데이터와 서버가 가진 데이터가 똑같다면 굳이 데이터를 또 받을 필요가 있을까?

검증 헤더와 조건부 요청1

  1. 서버에서 기존 데이터를 변경함
  2. 서버에서 기존 데이터를 변경하지 않음

1. 캐시 만료후에도 서버에서 데이터를 변경하지 않음

요청 1

HTTP/1.1 200 OK
Content-Type: image/jpeg
cache-control: max-age=60
<!-- 데이터가 마지막에 수정된 시간 -->
Last-Modified: 2020년 11월 10일 10:00:00
Content-Length: 34012

lkj123kdkfjaodjgasdjfoasdf
sasdf;qkawj9;o4ruasawekfasdf;skfjaf1234

위의 응답 결과를 캐시에 저장하고, 60초 초과후 이미지를 요청하면 브라우저 캐시가 만료되었기 때문에 요청2를 다시 보낸다.

요청 2

GET /star.jpg
<!-- 조건부 요청 -->
if-modified-since: 2020년 11월 10일 10:00:00

서버에서 위의 요청을 받고 데이터 최종 수정일과 if-modified-since가 같으면 아래의 HTTP 메세지를 클라이언트에 보낸다.

HTTP/1.1 304 Not Modified
Content-Type: image/jpeg
cache-contorl: max-age=60
Last-Modified: 2020년 11월 10일 10:00:00
Content-Length: 34012
<!-- 아래에는 HTTP Body가 없다. -->

위 메세지를 받은 클라이언트는 캐시를 다시 세팅하고 캐시를 다시 불러와서 사용한다.

정리

검증 헤더와 조건부 요청2

If Modified Since: 이후에 데이터가 수정되었으면?

Last-Modified, If-Modified-Since 단점

ETag, If-None-Match

  • 진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기!
  • 캐시 제어 로직을 서버에서 완전히 관리
  • 클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)
  • 예)
    • 서버는 배타 오픈 기간인 3일동안 파일이 변경되어도 ETag를 유지
    • 애플리케이션 배포 주기에 맞추어서 ETag 모두 갱신

캐시와 조건부 요청 헤더

Cache-Control

프록시 캐시

원서버 직접 접근

원서버가 미국에 있다고 가정해보자. 너무 멀어서 데이터를 받는 속도가 느리다.

프록시 캐시 도입

한국 어딘가에 프록시 캐시 서버를 도입해서 속도를 줄인다. (중간에서 공용으로 사용하는 캐시서버!)

Cache-Control

캐시 무효화

확실한 캐시 무효화 응답

이 페이지는 캐시를 하면 안된다 싶을 때

캐시 지시어

⬅ 이전 포스트
String, Date | MySQL
다음 포스트 ➡️
GROUP BY | MySQL