HTTP 웹 기본 지식 02

- 김영한 님의 HTTP 웹 기본 지식을 듣고 정리하고자 쓴 글입니다.

---

1. HTTP 상태코드

상태코드란, 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능. 

• 1xx (Informational): 요청이 수신되어 처리중
• 2xx (Successful): 요청 정상 처리
• 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
• 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

 

- 2xx (Successful): 요청 정상 처리

200 OK 요청 성공

201 Created 요청 성공해서 새로운 리소스가 생성됨

202 Accepted 요청이 접수되었으나 처리가 완료되지 않았음 예) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함

204 No Content 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 예) 웹 문서 편집기에서 save 버튼

 

- 3xx - 리다이렉션 : 요청을 완료하기 위해 클라이언트 웹브라우저의 추가 조치 필요

영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동 ex) /event -> /new-event

301 Moved Permanently 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 

308 Permanent Redirect 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

두개는 기능이 똑같음. URI가 영구적으로 바뀌었다는 것. 실무에서는 301을 쓴다. 

 

일시 리다이렉션 - 일시적인 변경 ex) 주문 완료 후 주문 내역 화면으로 이동

302 Found 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
307 Temporary Redirect 302와 기능은 같음 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다.)
303 See Other 302와 기능은 같음 리다이렉트시 요청 메서드가 GET으로 변경 돼야함. 

 

일시적 리다이렉션은 언제 쓰나?

PRG: Post/Redirect/Get
POST로 주문후에 웹 브라우저를 새로고침하면? -> 새로고침은 다시 요청 -> 중복 주문이 될 수 있다. -> POST로 주문후에 새로 고침으로 인한 중복 주문 방지 -> POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트 -> 새로고침해도 결과 화면을 GET으로 조회 -> 중복 주문 대신에 결과 화면만 GET으로 다시 요청. -> URL이 이미 POSTGET으로 리다이렉트 됨 -> 새로 고침 해도 GET으로 결과 화면만 조회

 

307, 303 권장하지만 이미 302를 많이 쓰고 있다. 

 

특수 리다이렉션 ex) 결과 대신 캐시를 사용

304 Not Modified 캐시를 목적으로 사용. 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다. 304 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하므로)

 

- 4xx (Client Error) 클라이언트 오류

클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음. 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패함.

 

400 Bad Request 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음. 예) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때. 문자를 보내야 하는데 숫자가 보내거나 할 때. 

401 Unauthorized 클라이언트가 해당 리소스에 대한 인증이 필요함. 

인증(Authentication): 본인이 누구인지 확인, (로그인)
인가(Authorization): 권한부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한,인증이 있어야 인가가 있음)
오류 메시지가 Unauthentication이 되어야 하는데 Unauthorized. (이름이 아쉬움)

403 Forbidden 서버가 요청을 이해했지만 승인을 거부함. 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
• 예) 어드민 등급이 아닌 사용자가 로그인은 했지만, 어드민 등급의 리소스에 접근하는 경우

404 Not Found 요청 리소스를 찾을 수 없음. 요청 리소스가 서버에 없음.

 

- 5xx (Server Error) 서버 오류
서버 문제로 오류 발생. 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음(복구가 되거나 등등). 웬만하면 500에러 만들면 안된다. 정말 심각한 서버 오류일때.  

500 Internal Server Error 서버 문제로 오류 발생, 애매하면 500 오류.

503 Service Unavailable 서비스 이용 불가. 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음.

 

 

2. HTTP 헤더

HTTP 전송에 필요한 모든 부가정보. 과거에는 헤더를 크게 4가지로 분류했다. general, request, response, entity. 

스팩이 바뀜. entity 란 용어 대신 표현이란 것이 나옴.

 

메세지 본문= (payload)

표현= 표현 헤더(메타데이터)+ 표현 데이터.

메세지 본문을 통해 표현데이터를 전달한다. 

 

표현

• Content-Type: 표현 데이터의 형식 ex) application/json, text/html; charset=utf-8
• Content-Encoding: 표현 데이터의 압축 방식 ex) gzip
• Content-Language: 표현 데이터의 자연 언어 ex) ko
• Content-Length: 표현 데이터의 길이

 

 

협상 헤더 (콘텐트 네고시에이션) - 클라이언트가 선호하는 표현 요청. 4가지 종류가 있다.

• Accept: 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
• Accept-Language: 클라이언트가 선호하는 자연 언어

GET /event
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

예를 들어 한국어브라우저를 이용한다. 다중언어를 지원하는 서버인데 기본적으로 영어를 제공한다. 숫자가 클수록 높은 우선순위를 가진다는 뜻이다. 

 

전송방식

• 단순 전송: 요청하면 응답을 준다. 콘텐트에 대한 길이를 알 때.

• 압축 전송: gzip으로 압축해서 보내는 것. 용량 줄어든다.
• 분할 전송: 나눠서 보내는 것.
• 범위 전송: 어디서 어디까지 

 

일반정보

• From: 유저 에이전트의 이메일 정보
• Referer: 이전 웹 페이지 주소
• User-Agent: 유저 에이전트 애플리케이션 정보
• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
• Date: 메시지가 생성된 날짜

 

특별한 정보

• Host: 요청한 호스트 정보. 하나의 서버(ip)에 여러개의 도메인이 묶였을 때.
• Location: 페이지 리다이렉션
• Allow: 허용 가능한 HTTP 메서드
• Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

 

3. 쿠키

• Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
• Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달

 

쿠키 - 생명주기 Expires, max-age
• Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT: 만료일이 되면 쿠키 삭제
• Set-Cookie: max-age=3600 (3600초): 0이나 음수를 지정하면 쿠키 삭제
• 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
• 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

 

4. 캐시

캐시 : 캐시는 웹 페이지 요소를 저장하기 위한 임시 저장소이다.

 

캐시가 없으면 자료가 변경되지 않아도 매번 다운받아야 한다. 그럼 당연히 불필요하게 느려지겠지. 그래서 캐시 유효기간을 두고 그 사이에 자료가 변경되지 않았다면 네트워크를 사용하지 않아도 되는거다. 그런데 말입니다.... 만약 캐시 유효시간이 초과하면 서버를 통해 다시 조회하고 캐시를 갱신해야 한다. 이때 다시 네트워크를 다운로드 해야한다. 

 

캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다.
1. 서버에서 기존 데이터를 변경함 ex) 데이터 -> 데이터
2. 서버에서 기존 데이터를 변경하지 않음 ex) 데이터

 

캐시 만료후에도 서버에서 데이터를 변경하지 않았다면 데이터를 전송하는 대신 저장해두었던 캐시를 쓸 수 있다. 근데 대신 클라이언트의 데이터와 서버의 데이터가 같다는 것을 확인하는 방법이 필요하다. 

 

그래서 검증헤더가 추가되는 것. 

cache-control: max-age=60
Last-Modified: 2020년 11월 10일 10:00:00

날짜를 확인해서 서버의 수정일과 클라이언트의 수정일이 같다면 데이터가 변경되지 않았다는 뜻임. 정리하자면 아래와 같다.

 

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
• 304 Not Modified + 헤더 메타 정보만 응답(바디X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책

 

그런데 만약 데이터를 수정해서 날짜가 다른데 같은 데이터로 수정해서 결과가 달라진게 없다면? 이게 바로 Last-Modified의 단점이다. 그래서 ETag를 도입했다. ETag의 특징은 다음과 같다.  

 

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

 

캐시 제어 헤더

Cache-Control: 캐시 제어
Pragma: 캐시 제어(하위 호환)
Expires: 캐시 유효 기간(하위 호환)

 

프록시 캐시

origin서버가 미국에 있고, 클라이언트 브라우저는 한국에 있다고 하자. 미국에서 데이터를 가지고 오려면 시간이 꽤 걸리겠지? 몇초라도 말이다. 그걸 빠르게 하기 위해 한국 어딘가 프록시 캐시서버를 둔다. 그리고 처음 요청하면 원서버에서 가져오고 이후에 또 요청되면 프록시 서버에서 전달해준다.