등딱지빌런

등딱지빌런

안녕하세요. 정인호입니다.

Chapter7. HTTP 헤더 & 쿠키

Date:     Updated:

카테고리:

태그:

인프런에 있는 김영한님의 모든 개발자를 위한 HTTP웹 기본 지식 강의를 듣고 정리한 내용입니다.
중간에 등장하는 ppt 내용들은 모두 강의자료를 캡처한 것입니다.


✈️ HTTP 헤더

  • HTTP 전송에 필요한 모든 부가 정보
  • ex) 메시지 바디의 내용, 크기, 압축정보, 인증, 캐시 관리 등등…
  • 표준 헤더는 무수히 많음. 필요시 임의의 헤더 추가 가능


RFC2616 - 1999년 (과거 버전)

ch7 1

  • General 헤더 : 메시지 전체에 적용되는 정보
    • ex) Connection: close
  • Request 헤더 : 요청 정보
    • ex) User-Agent: Mozilla/5.0 (Macintosh; ..)
  • Request 헤더 : 서버 정보
    • ex) Server: Apache
  • Request 헤더 : 엔티티 바디 정보 (메시지 바디)
    • ex) Content-Type: text/html, Content-Length: 3423, …

현재 RFC2616은 폐기 ➡️ 2014년 RFC7230~7235 등장

RFC723X 변화

  • Entity(엔티티) -> Representation(표현)
  • Representation = Representation Metadata (표현 헤더) + Representation Data (표현 데이터)

실제 리로스는 html이나 json이 아님. html(json)로 표현해주는 것


RFC7230 HTTP Body

  • 메시지 바디를 통해 표현 데이터 전달
  • 메시지 바디 = 페이로드(payload)
  • 표현: 요청이나 응답에서 실제 전달할 데이터
  • 표현 헤더: 표현 데이터를 해석할 수 있는 정보 제공
  • 참고: 사실 표현 헤더는 표현 메타데이터와 페이로드 메시지를 구분해야 함. 여기서는 생략


✈️ HTTP 표현 헤더

표현 헤더는 전송, 응답 둘 다 사용

  • Content-Type
  • Content-Encoding
  • Content-Language
  • Content-Length


Content-Type

표현 데이터의 형식 설명

  • 미디어 타입, 문자 인코딩
  • ex)
    • text/html; charset=utf-8
    • application/json
    • image/png


Content-Encoding

뭘로 압축했어?

ch7 2

  • 표현 데이터를 압축하기 위해 사용
  • 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
  • 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
  • ex)
    • gzip
    • deflate
    • identity(압축 안함)


Content-Language

ch7 3

  • 표현 데이터의 자연 언어를 표현
  • ex)
    • ko
    • en
    • en-US


Content-Length

  • 바이트 단위
  • 전송 방식에 따라 content-length 사용하면 안되는 경우가 있음 (전송 방식에서 설명)


✈️ Content Negotiation - 협상

클라이언트가 선호하는 표현을 요청
서버가 반드시 해줄 수 있는 것은 아니지만 클라이언트가 요청한 우선순위를 최대한 맞춰준다. (협상 헤더는 요청시에만 사용)

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


협상과 우선순위

방법 1. Quality Values(q) 값 사용

ch7 4

  • 0~1, 클수록 높은 우선순위 (생략하면 1)
  • ex)
    • Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7 요청
    • 서버가 한국어 지원은 안하지만 독일어, 영어 지원 ➡️ 영문 페이지 응답


방법 2. 구체적인 것이 높은 우선순위
ex) Accept: text/*, text/plain, text/plain;format=flowed, */*

  1. text/plain;format=flowed
  2. text/plain
  3. text/*
  4. */*


✈️ 전송 방식

전송 방식에 따라 표현 헤더가 표기해야 할 정보가 달라진다.

  • 단순 전송 : Content-Length 표기
  • 압축 전송 : Content-Encoding 표기
  • 분할 전송 : Transfer-Encoding 표기
  • 범위 전송 : Content-Range 또는 Range 표기


분할 전송 & 범위 전송

ch7 5

chunked (덩어리)로 분할 전송 or byte단위로 범위 전송


✈️ 일반 정보

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


Referer - 이전 웹 페이지 주소

  • 요청에서 사용
  • A -> B로 이동하는 경우 B를 요청할 때 Referer: A 표기
  • 유입 경로 분석 가능 (광고 데이터에서 많이 사용)
  • 참고: referrer의 오타이지만 고치기에는 너무 늦었다고 한다..


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

  • 요청에서 사용
  • 클라이언트의 애플리케이션 정보 (os 정보, 웹 브라우저 정보, 등등.. )
  • ex) user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/ 537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.3
  • 어떤 종류의 브라우저에서 장애가 발생하는지 파악 등 통계 정보에 유용


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

  • 응답에서 사용
  • Origin server란 중간에 거치는 서버가 아닌 실제 표현 데이터를 만들어주는 최종 목적지 서버
  • ex) Server: Apache/2.2.22 (Debian)


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

  • 응답에서 사용
  • 그리니치 평균시 GMT 사용
  • ex) Date: Tue, 15 Nov 1994 08:12:31 GMT
  • 과거에는 요청에서도 사용했다고 함


✈️ 특별한 정보

  • Host : 요청한 호스트 정보(도메인)
  • Location : 페이지 redirection
  • Allow : 허용 가능한 HTTP method
  • Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간


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

ch7 7

일반적인 웹 서버 (서버 3대) 가상호스트 웹 서버 (서버 1대)
aaa.com (IP : 111.111.111.111) aaa.com (IP : 111.111.111.111)
bbb.com (IP : 222.222.222.222) bbb.com (IP : 111.111.111.111)
ccc.com (IP : 333.333.333.333) ccc.com (IP : 111.111.111.111)


실제 서버는 가상 호스트를 통해 하나의 IP로 여러 도메인을 처리 하는 경우가 많다. 따라서 요청시 서버의 어떤 호스트로 접근할지 표기해야 한다.

ch7 6

  • 요청에서 사용
  • 필수


Location - 페이지 redirection

  • 응답코드 201(Created)의 Location 값은 새로 생성된 리소스 URI
  • 응답코드 3xx(Redirect)의 Location 값은 요청을 자동으로 redirection하기 위한 대상 리소스 URI


Allow - 허용 가능한 HTTP Method

  • 응답코드 405(Method Not Allowed)에 포함
  • ex) Allow: GET, HEAD, PUT
  • 잘 안씀


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

  • 응답코드 503(Service Unavailable)에 포함
  • Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
  • Retry-After: 120 (초단위 표기)


✈️ 인증

  • Authorization: 클라이언트 인증 정보를 서버에 전달
    • Authorization: Basic xxxxxxxxxxxxxxxx
  • WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의
    • 응답코드 401(Unauthorized)에 포함
    • ex) WWW-Authenticate: Newauth realm=”apps”, type=1, title=”Login to "apps"”, Basic realm=”simple”


✈️ 쿠키🍪

한 사용자가 웹 브라우저에 로그인을 했다고 가정해보자. HTTP는 Stateless Protocol이기 때문에 클라이언트와 서버는 서로 상태를 유지하지 않는다. 즉 로그인 화면 이후 요청에 대해서 서버는 클라이언트가 로그인을했는지 안 했는지 알 수 없다. 이에 대한 대안으로 로그인 이후 모든 요청에 사용자 정보를 포함하는 방안이 있겠지만 이는 좋은 대안이 아니다. 보안에도 문제가 있을 수 있고, 요청마다 로그인 정보를 확인해야 하므로 매우 비효율적이다. 일정한 기간 동안(ex. 브라우저 종료 이전까지) 간편하게 로그인 정보를 유지할 수 없을까? 이때 등장하는 개념이 바로 쿠키🍪이다.


쿠키 작동 원리

로그인

ch7 8

  • 클라이언트의 로그인 요청이 성공하면 서버는 Set-Cookie 헤더를 통해 쿠키를 전달한다.
  • 응답 받은 쿠키는 클라이언트 쿠키 저장소에 저장된다.


로그인 이후

ch7 9

set-cookie 이후 요청에서는 무조건 쿠키 저장소를 뒤지고, Cookie 헤더를 통해 쿠키 정보를 같이 요청한다.


쿠키 사용법

  • 사용처
    • 사용자 로그인 세션 관리
    • 광고 정보 트래킹
  • 쿠키 정보는 항상 서버에 전송됨
  • 네트워크 트래픽 추가 유발
  • 따라서 최소한의 정보만 사용 (세션 id, 인증 토큰)

  • 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 참고(localStorage, sessionStorage)

  • 주의)
    • 보안에 민감한 데이터는 저장하면 안됨 (주민번호, 신용카드 정보, 등등..)
    • 사실 로그인 쿠키도 세션id(실제 아이디, 비밀번호가 아닌 서버만 아는 key값) 이용


쿠키 문법

set-cookie: [key=value];[Expires];[path];[Domain];[Secure]

ex) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure


쿠키 생명주기

ex) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure

  • 세션 쿠키(디폴트 값) : 브라우저 종료시 까지 유지
  • 영속 쿠키 : 쿠키 유지 기간 설정
    • expires=Sat, 26-Dec-2020 04:39:21 GMT (날짜 표기)
      • 만료일이 되면 쿠키 삭제
    • max-age=3600 (초단위 표기)
      • 0이나 음수를 지정하면 쿠키 삭제


쿠키 경로

ex) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure

  • 명시한 경로를 포함한 하위 경로 페이지만 쿠키 접근
  • 일반적으로 path=/ 루트로 지정


쿠키 도메인

ex) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure

  • 클라이언트가 가지고 있는 쿠키를 모든 도메인에서 쓰는 것은 바람직하지 않음
  • 도메인 명시 : 명시한 문서 기준 도메인 + 서브 도메인 포함
    • domain=example.org 지정해서 쿠키 생성
    • example.org 쿠키 접근 가능
    • dev.example.org 쿠키 접근 가능
  • 도메인 생략 : 현재 문서 기준 도메인만 적용
    • example.org에서 쿠키를 생성하고 domain 지정 생략
      • example.org 에서만 쿠키 접근 가능
      • dev.example.org 쿠키 접근 불가


쿠키 보안

ex) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure

  • Secure
    • 쿠키는 http, https를 구분하지 않고 전송
    • Secure 적용하면 https만 전송
  • HttpOnly
    • HTTP 전송에만 사용
    • 자바스크립트에서 접근 불가 (document.cookie)
    • XSS 공격 방지
  • SameSite
    • XSRF 공격 방지
    • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송



맨 위로 이동하기

Network 카테고리 내 다른 글 보러가기

댓글 남기기

최근 글 10 개 :)