HTTP 웹 기본 지식 - ~ 섹션8. 캐시와 조건부 요청

 

 

http 상태코드는, 1xx, 2xx, 3xx, 4xx, 5xx가 있는데 주 내용을 보자.

1xx는 요청이 수신되어 처리중이라는 코드인데 거의 안쓴다.

 

2xx은 성공

- 200 OK

거의 다 200 사용

- 201 Created

이 요청에 의해 뭔가 저장되었을 때

- 202 Accepted

요청이 접수되었으나 아직 완료되지 않았음

- 204 No Content

요청은 완료했지만 보낼 데이터가 없음. 임시저장 같을때에 가끔 쓰일 듯.

 

실전에선 거의 대부분 200, 201로 한다.

 

3xx은 똑같은 redirect인데 왜 많냐면, 공통적으로 Location 해더가 있으면 Location 위치로 자동 이동한다.

- 300 Multiple Choices

- 301 Moved Permanently

- 302 Found

- 303 See Other

- 304 Not Modified

- 307 Temporary Redirect

- 308 Permanent Redirect

 

왠만하면 301, 302를 사용하는 듯.

영구 리다이렉션은 301과 308인데, 리소스의 URI가 영구적으로 이동되었으며(더 이상 사용 안하니 이쪽으로 와라), 검색 엔진 등에서도 인지한다. 차이는 Location으로 다시 이동하는게 좋겠다고 클라이언트한테 Location 과 함께 보낼 때, 처음 요청 보낸 메서드를 유지할지 말지 선택하는 것이다.

 

 

일시적인 리다이렉션은 302, 307, 303이 있다. 원래 302만 있었지만 나머진 추가된거임.

사용 예시를 보며 언제 써야할 지 감을 잡아보자.

 

사용자가 장바구니에 담은 물건들 가지고 구매 버튼을 눌렀을 경우, 한 번 주문 사용 누른 뒤 로딩이 오래걸려 새로고침을 했다고 하자. 같은 결과 화면에서 새로고침을 하면 두번 구매될 수 있다(물론 서버에서 주문번호로 주문 방지 해줘야 하지만, 일단 서버의 부담을 최대한 낮추기 위해 클라이언트에서도 뭔가 해주는게 베스트다.).

그래서 주문을 하면 GET만 되는 안전한 페이지(safe)로 리다이렉트 시키면 좋다.

 

 

302가 처음 만들어졌을 때 메소드가 아마 GET으로 변할 수도 있고, 307은 변하면 안되고, 303은 변해야 한다. 대부분은 걍 302 쓴다.

 

 

4xx는 클라이언트 오류. 주로 400, 401, 404가 있다.

400은 잘못된 요청.

401는 인증되지 않았다는 Unauthorized인데 인증 에러도 종류가 있다. 누구인지 인증해야 하는 Authentication, 권한이 필요한 Authorization. 401 오류 발생 시 응답 헤더에 WWW-Authenticate로 인증 방법을 설명하는 것이 좋다.

403은 요청을 이해했으나 접근 권한 불충분으로 승인 거부.

404은 요청을 찾을 수 없음. 실제로 없고, 있어도 숨기고 싶을 때.

 

5xx은 서버 오류.

애매하면 거의 500.

503은 서비스 이용 불가라서 Retry-After 헤더로 언제 복구되는지 알려줄 수 있는데 잘 안씀.

 

 

 

HTTP 헤더는 1999년에 나온 표준 RFC2616 쓰다가 2014년에 나온 RFC7230~7235를 쓰는 편이다.

변화는 엔티티(Entity)->표현(Representation) 으로 이름 바꾸는 등 소소한 변화.

 

 

내용을 압축하고 바이트 코드로 변환한 뒤 body에 넣고 Content-Encoding에서 gzip이라고 알려주면 웹 브라우저가 가져와 알아서 압축풀고 하는 방식. 그래서 헤더가 중요하다. Content-Length는 분할 전송인 Transfer-Encoding에선 못씀.

 

저 4개의 Content 말고 협상인 Accept도 존재한다. 클라이언트가 뭘 선호하는지 알려주는 것.

 

우선순위는 q로 정할 수 있고(1~0. 높을수록 우선), 구체적일수록 우선이다.

 

 

이 후엔 일반 정보들이 있다.

 

특별한 정보도 있다.

Host는 꼭 필요한데, 하나의 서버 IP가 여러 도메인을 처리할 때 어디쪽으로 다뤄야 하는지 표시해야 하기 때문.

 

인증도 있다 (아까 봤던 401)

 

 

 

중요한 쿠키는 서버에서 '이 정보는 쿠키로 저장해서 앞으로는 이 정보도 함께 넘겨라' 라고 해서 클라이언트가 자동으로 포함하여 같이 보내는 개념. localstorage, sessionstorage는 자바스크립트로 저장해서 원할 때마다 꺼내쓰는거라 좀 다름.

여기에 보안상 추가 정보로 expires, max-age, secures 등도 지원한다.

도메인은 당연히 있어야 하며, 어느 도메인에 이 정보를 자동으로 보낼지 명시해야 하고, 경로도 지정한 경로를 포함한 하위 경로 페이지에만 쿠키 접근 하도록 설정할 수 있다.

 

쿠키를 저장할 때 얼마나 오래 저장할 수 있는지, 만료되어도 확인했을 때 안달라졌다면 그냥 쿠키에 있는거 가져다 쓰라고 하는 방법론들이 있는데, max-age, content modified date 방법들이 있다. 이렇게 보면 어떻게든 서버에 부하 덜 가게 하는지

 

max-age는 시간으로 해서 만약 해당 시간이 초과되면 다시 받아온다. 조금 개선한 것이 시간이 초과되었어도 정말 달라졌는지 확인해서 안달라졌다면 그냥 캐시에 있는거 그대로 사용하면 된다. 마지막 수정 날짜로 비교하면 되고, 데이터가 수정되지 않았다면 304 응답을 body없이 헤더만 보냄. 안바뀌었다는 것을 확인하면 다시 갱신한다.

 

 

위 2개 비교 말고도 자기가 직접 버전을 지정하는 ETag 방식이 있는데, 캐시 기간이 초과되었다면 ETag과 함께 보내서 ETag가 같으면 같다고 확인하고 갱신한 뒤 그대로 사용하는 것. 이것의 장점은 서버 측면에서 캐시 제어 로직을 완전히 관리할 수 있다(상의해서 특정 서버에 ETag를 통일하는 등).

 

 

캐시보고 무슨 행동을 하라고 제어할 수 있는 Cache-Control도 있다. Pragma와 Expires는 하위버전.

 

 

프록시 캐시도 있는데, 원 서버와의 거리가 머니 중간에 캐시만 저장하는 프록시 캐시 서버가 있는거다. 이런거 때문에 사람들이 자주보는 컨텐츠는 다운로드 속도가 빠른거.

 

 

캐시 무효화로는 Cache-Controll의 no-cache, no-store, must-revalidate가 있다. no-cache와 must-revalidate의 차이점은 원 서버가 죽었을 때 프록시 캐시에 있던 예전거라도 보여주느냐, 새거인지 무조건 확안해야 한다며 이 악물고 오류내느냐 차이가 있다.

.