티스토리 뷰
HTTP 상태코드
상태코드 - 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 ( OK, forbidden)
1xx (Informational) : 요청이 수신되어 처리중
2xx (Successful) : 요청 정상 처리
- 200 OK
- 201 Created, 요청이 성공하여 새로운 리소스(회원 가입같은)가 생성됨
- 202 Accepted, 요청은 접수되었지만 처리는 안됨
- 204 No Content, 요청을 성공적으로 수행했지만, 반환할 데이터가 없음(필요가 없기에)
3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면, Location 위치로 자동 이동한다.
영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동, 기존 URL 사용 x
- 301 Moved Permanently, 리다이렉트 시 요청메서드가 GET으로 변경된다. (추천)
- 308 Permanent Redirect, 리다이렉트 시 요청메서드를 유지해준다.
일시 리다이렉션 : 일시적인 변경, PRG
- 302 Found, 리다이렉트 시 대부분 요청메서드가 GET으로 변경된다.
- 307 Temporary Redirect, 리다이렉트 시 요청메서드와 본문을 유지해야 한다.( 변경 x )
- 303 See Other, 리다이렉트 시 요청메서드가 GET으로 변경된다. (302의 확정적인 변경)
- PRG : POST/Redirect/Get, 주문을 완료(POST)하고 새로고침(POST) 재주문이 될 수도 있음, 이를 방지
특수 리다이렉션 : 결과 대신 캐시를 사용
- 300 Multiple Choices 사용하지 않음.
- 304 Not Modified, 캐시를 목적으로 사용 -> 클라이언트가 로컬 PC의 저장된 캐시로 재사용한다.
4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
- 400 Bad Request, 클라이언트가 잘못된 요청(파라미터 오류), 클라이언트는 검토 후 재요청
- 401 Unauthorized, 인증 되지 않음 (로그인 같이 인증을 요구)
- 403 Forbidden, 인증 자격은 있지만, 접근 권한이 불충분한 경우
- 404 Not Found, 요청 리소스를 찾을 수 없음 (서버에 없는 리소스를 요청할 경우)
5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함
- 500 Internal Server Error, 서버 내부 문제로 오류 - 애매하면 500
- 503 Service Unavailable, 서버의 과부하나 예정 작어으로 요청을 처리 못하는 경우
+) 클라이언트가 인식할 수 없는 상태 코드를 서버가 반환하면?
- 상위를 보고 해석하자, 277 -> 아 성공했구나, 411 -> 클라이언트 오류네?
HTTP 헤더 <- 많은 Header의 구성요소들
과거 HTTP의 헤더 ( RFC2616 )
- General 헤더: 메시지 전체에 적용되는 정보, 예) Connection: close
- Request 헤더: 요청 정보, 예) User-Agent: Mozilla/5.0 (Macintosh; ..)
- Response 헤더: 응답 정보, 예) Server: Apache
- Entity 헤더: 엔티티 바디 정보, 예) Content-Type: text/html, Content-Length: 3423
과거 엔티티 헤더는 엔티티 본문(메세지 본문)의 데이터를 해석할 수 있는 정보를 제공했다.
RFC 최신 버전에서는 엔티티 (Entity) -> 표현 ( Representation )
표현 = 표현 메타 데이터(헤더) + 표현 데이터(본문) ==> 요청이나 응답에서 전달하실제 데이터
현재의 표현 헤더는 표현 데이터(메시지 본문)의 데이터를 해석 할 정보를 전달한다.
표현 헤더의 구성
- Content-Type: 표현 데이터의 형식
- Content-Encoding: 표현 데이터의 압축 방식 , gzip deflate 등등..
- Content-Language: 표현 데이터의 자연 언어, ko en 등등..
- Content-Length: 표현 데이터의 길이
표현 헤더는 전송, 응답 메시지에 둘 다 사용한다.
협상 헤더의 구성
협상(콘텐츠 네고시에이션) - 클라이언트가 선호하는 표현 요청
- Accept: 클라이언트가 선호하는 미디어 타입 전달
- Accept-Charset: 클라이언트가 선호하는 문자 인코딩
- Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
- Accept-Language: 클라이언트가 선호하는 자연 언어
협상 헤더는 요청시에만 사용
협상의 우선순위 - ko를 선호하지만 없다면 기본값인 jp 보단 en을 원해 ~
-> Quality Value인 q 사용하여 0~1까지의 우선순위를 두고 값을 요청한다.
또한, 구체적으로 명시한 것에 대해 우선순위가 높게 부여된다. - text/* 이 */* 보다 우선순위가 높다.
전송 방식
1. 단순 전송 - 한 번에 요청하고 한 번에 다 받는 방식
2. 압축 전송 - Content-Encoding에 압축 타입을 넣고 데이터를 압축하여 전송하는 방식
3. 분할 전송
- Transfer-Encoding: chunked(묶음) 으로 지정하여 데이터를 묶음 분할하여 전송
- Content-Length를 지정하지 않아야 하며, \r\n 을 종료 플래그로 보낸다.
4. 범위 전송
- Content-Range를 지정하여 데이터를 전송하는 방식
일반 정보
- From: 유저 에이전트의 이메일 정보, 요청에서 사용
- Referer: 현재 웹 페이지의 이전 웹 페이지 주소, 요청에서 사용
- User-Agent: 유저 에이전트(클라이언트) 애플리케이션 정보, 요청에서 사용
- Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보 - 진짜 요청 서버(클라이언트)
- Date: 메시지가 생성된 날짜, 응답에서 사용
특별한 정보
- Host: 요청한 호스트 정보(도메인) - 요청에서 필수임! 하나의 IP주소에 여러 도메인이 사용될 때 사용
- Location: 페이지 리다이렉션, 3xx 응답 결과의 리다이렉션 주소
- Allow: 허용 가능한 HTTP 메서드, 405 Method Not Allowed에 포함되야 할 정보
- Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
인증
- Authorization : 클라이언트 인증 정보를 서버에 전달한다. (로그인 같은 정보)
- WWW-Authenticate - 리소스 접근시 필요한 인증 방법 정의, 401 Unauthorized 에 사용
쿠키
리마인드 : HTTP는 무상태 프로토콜이다. -> 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어짐
로그인 후 페이지 재접속한다면 HTTP 메시지로 서버가 클라이언트를 구분할 수 없게 된다.
이를 위해 있는 것이 쿠키 - 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달
쿠키 저장소에 리소스를 포함한 사용자 정보를 저장하여 요청을 처리한다.
쿠키 정보는 항상 서버에 전달되기에 최소한의 정보만을 사용하도록 하자(세션 id, 인증 토근)
보안에 민감한 데이터는 저장하면 안된다. 항상 다시 요청할 수 있게 (주민등록번호, 카드 번호 등등..)
구성 요소
set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure
1. 생명 주기
- expires : 만료일 설정, 만료일이 되면 쿠키가 삭제된다.
- max-age : 쿠키가 지속될 시간(초 단위)
- 세션 쿠키 - 만료 날짜를 생략하면 브라우조 종료 까지 유지
- 영속 쿠기 - 만료 날짜 입력하면 만료일까지 유지 ( expires, max-age )
2. 도메인
- 도메인을 명시 : 명시한 문서 기준 도메인 + 서브도메인 포함하여 쿠키를 생성
- 도메인을 생략 : 현재 문서 기준 도메인에서만 쿠키를 생성
3. 경로
- 명시된 경로를 포함한 하위 경로 페이지만 쿠키 접근, 일반적으로 path=/ 사용
4. 보안
- Secure - https인 경우에만 클라이언트에서 서버로 쿠키를 전송하는 것
- HTTPOnly - XSS 공격 방지를 위하여 사용, 자바스크립트에서 쿠키 접근을 막음
- SameSite - XSRF 공격 방지를 위하여 사용, 요청 도메인과 쿠키의 도메인이 같은 경우에만 쿠키 전송하는 것
캐시의 기본 동작
캐시가 없다면 네트워크를 통해 데이터를 계속 받아야 한다. (속도, 비용 등 불편함을 느낀다)
캐시를 사용한다면 서버에 요청할 때, 브라우저 캐시의 유효 시간을 검증한 후 캐시로부터 데이터를 받을 수 있다.
캐시가 유효 시간을 초과한다면? - 기존에 받은 데이터를 다시 다운한다 -> 비효율적
캐시 만료 후 캐시에 저장된 데이터와 서버의 데이터가 일치한다면?
서버 응답 메시지의 Last-Modified를 캐시는 기록하고, 요청 메시지에 캐시에 기록된 Last-Modified를 포함하여 전달한다.
서버와 요청 메시지의 최종 수정일을 비교하여 수정이 되지 않았다면
304 Not Modified를 담은 응답 메시지를 보낸다. 이때, HTTP Body를 빼야 한다.(요청한 데이터는 캐시에)
검증 헤더
캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
Last-Modified
ETag(Entity Tag) -> 캐시용 데이터에 임의의 고유한 버전 이름을 부여, 데이터 변경 시 Hash를 다시 생성
조건부 요청 헤더
검증 헤더로 조건에 따른 분기를 발생시킴, 조건이 만족하면 304 만족하지 않으면 200
If-Modified-since : 서버와 캐시의 데이터가 일치하는지를 확인, Last-Modified를 사용
-> 1초 미만 단위로 조정이 불가능하고, 날짜 기반이기에 A->B->A 식의 데이터 수정도 200을 반환한다.
If-None-Match : 위와 같은 역할을 하지만, 날짜가 아닌 ETag를 비교하여 검증한다.
-> 캐시 제어 로직을 서버에서 완전히 관리한다.
캐시 제어 헤더
1. Cache-Control : max-age, no-cache, no-store
max-age : 캐시 유효 기간, 초 단위
no-cache : 데이터는 캐시해도 되지만, 항상 origin 서버에 검증하고 사용
no-store : 데이터에 민감한 정보가 있으므로 저장하면 안됨 (주민번호처럼)
2. Pragma : no-cache , 하위 호환 잘 사용하지 않음
3. Expires : 날짜 , 하위 호환 잘 사용하지 않음 -> 날짜로만 검증
프록시 캐시
Origin 서버(원 서버) - 진짜 Resource가 있는 서버
원 서버에 접속하려면 0.5초 걸리는 상황을, 프록시 캐시 서버를 통해 0.1초에 접속할 수 있다.
Cache-Control의 캐시 지시어
public : 응답이 public 캐시에 저장돼도 됨
private : 응답이 private 캐시에만 저장되야 함 - 중요 개인 정보, default 값
캐시 무효화
Cache-Control의 확실한 캐시 무효화 응답
요즘 웹 브라우저들이 알아서 캐시에 저장하는 것들이 있는데, 캐시에 저장되면 안되는 것들이 있다.
이를 위하여 아래의 데이터를 보낸다.
1. Cache-Control: no-cache
- 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용( 로그인 됐는지 )
Cache-Control: no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)
Cache-Control: must-revalidate
- 캐시 만료후 최초 조회시 원 서버에 검증해야함
- 원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
- must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
Pragma: no-cache -> HTTP 1.0 하위 호환일 경우 Cache-Control 대신 사용
no-cache vs must-revalidate
no-cache는 만약 원 서버에 접근하지 못한다면 프록시 캐시 서버의 데이터를 보여준다.
must-revalidate는 이름대로 원 서버에 접근하지 못한다면 오류를 발생한다.
-> 정말 중요한 정보라면 must-revalidate
본 포스팅은 인프런 강의 김영한님의
[ 모든 개발자를 위한 HTTP 웹 기본 지식 ] 을 수강하며 작성한 내용입니다.