
Cookie
HTTP의 특성
2022.04.27 - [분류 전체보기] - 9일 차 웹서비스 개발 기초
- HTTP는 기본적으로 무상태(Stateless) 프로토콜이다
- 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다. (서로 상태를 유지하지 않는다)
- 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다.
- 클라이언트와 서버는 서로 상태를 유지하지 않는다.
ㄴ정보가 유지되지 않으면, 매번 페이지를 이동할 때마다 로그인을 다시 하거나, 상품을 선택했는데 구매 페이지에서 선택한 상품의 정보가 없거나 하는 등의 일이 발생할 수 있다.
따라서, Stateful 경우를 대처하기 위해서 쿠키와 세션을 사용한다.
쿠키와 세션의 차이점
| 쿠키(Cookie) | 세션(Session) | |
| 저장 위치 | 클라이언트(=접속자PC) | 웹 서버 |
| 저장 형식 | Text | Object |
| 만료 시점 | 쿠키 저장시 설정 (브라우저가 종료되도, 만료시점이 지나지 않으면 자동으로 삭제되지않음) |
브라우저 종료시 삭제 (기간지정가능) |
| 사용하는 자원(리소스) | 클라이언트 리소스 | 웹 서버 리소스 |
| 용량 제한 | 총 300개 하나의 도메인 당 20개 하나의 쿠키 당 4KB(=4096byte) |
서버가 허용하는 한 용량제한 없음. |
| 속도 | 세션보다 빠름 | 쿠키보다 느림 |
| 보안 | 세션보다 안 좋음 | 쿠키보다 좋음 |
Cookie는 HTTP환경에서 상태를 유지하기 위한 기술이자 서버가 일방적으로 클라이언트에 전달하는 작은 데이터이며 단순히 서버에서 클라이언트에 쿠키를 전송하는 것만 의미하지 않고 클라이언트에서 서버로 쿠키를 전송하는 것도 포함된다.


Cookie의 특징
- 서버가 클라이언트에 데이터를 저장할 수 있다.
- 데이터 저장 이후 특정 조건을 만족해야 데이터를 가져올 수 있다.
-> 특정 조건을 옵션으로 표현할 수 있다.
Cookie 옵션
- Domain - 쿠키 옵션에서 도메인 정보가 존재한다면 클라이언트에서는 쿠키의 도메인 옵션과 서버의 도메인이 일치해야 쿠키를 전송
- Path - 서버의 요청의 세부 경로가 일치하는 경우 쿠키 전송(이 경로를 포함한 하위 경로 페이지만 전송 가능)
- Maxage - 쿠키의 유효를 시간으로 설정 (ex, Set-Cookie: max-age=3600) -> 3600초 뒤 소멸
- Expires - 쿠키의 유효를 기간으로 설정 (ex Set-Cookie: expires=Sat, 26-Dec-2021 04:39:21 GMT) -> 04시 39분 뒤 소멸
- HttpOnly - 스크립트의 쿠키 접근 가능 여부 설정 (XSS 공격 방지)
- Secure - HTTPS에서만 쿠키 전송 여부 설정
- SameSite - 같은 사이트에서만 쿠키를 사용할 수 있게 하는 설정(XSRF 공격 방지)
SameSite
다른 도매인의 요청을 받은 경우 요청에서 사용한 메서드와 해당 옵션의 조합으로 서버의 쿠키 전송 여부를 결정하게 됩니다. 사용 가능한 옵션은 다음과 같습니다.
- Lax :다른 도매인의 요청이면 'GET' 메서드에 대해서만 쿠키를 전송할 수 있습니다.
- Strict : 다른 도매인 요청이 아닌 도매인이 같을 경우에만 쿠키를 전송할 수 있습니다.
- None: 항상 쿠키를 보내줄 수 있습니다. 다만 쿠키 옵션 중 Secure 옵션이 필요합니다.
HTTP 주요 헤더
요청(Request)에서 사용되는 헤더
From: 유저 에이전트의 이메일 정보
- 일반적으로 잘 사용하지 않음
- 검색 엔진에서 주로 사용
- 요청에서 사용
Referer: 이전 웹 페이지 주소
- 현재 요청된 페이지의 이전 웹 페이지 주소
- A → B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청
- Referer를 사용하면 유입경로 수집 가능
- 요청에서 사용
- referer는 단어 referrer의 오탈자이지만 스펙으로 굳어짐
User-Agent: 유저 에이전트 애플리케이션 정보
- 클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
- 통계 정보
- 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
- 요청에서 사용
- e.g.
- 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.36
Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄
- 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다.
- 응답 헤더의 Access-Control-Allow-Origin와 관련
Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더
- “토큰의 종류(e.g. Basic) + 실제 토큰 문자”를 전송
- e.g.
- Authorization: Basic YWxhZGRpbjpvcGVuc2 VzYW1 l
Host: 요청한 호스트 정보(도메인)
- 요청에서 사용
- 필수 헤더
- 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용
- 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용

응답(Response)에서 사용되는 헤더
Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
- 응답에서 사용
- e.g.
- Server: Apache/2.2.22 (Debian)
- Server: nginx
Date: 메시지가 발생한 날짜와 시간
- 응답에서 사용
- e.g.
- Date: Tue, 15 Nov 1994 08:12:31 GMT
Location: 페이지 리디렉션
- 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 리다이렉트(자동 이동)
- 201(Created): Location 값은 요청에 의해 생성된 리소스 URI
- 3xx(Redirection): Location 값은 요청을 자동으로 리디렉션 하기 위한 대상 리소스를 가리킴
Allow: 허용 가능한 HTTP 메서드
- 405(Method Not Allowed)에서 응답에 포함
- e.g.
- Allow: GET, HEAD, PUT
Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
- 503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
- e.g.
- Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기)
- Retry-After: 120(초 단위 표기)
표현 헤더(Representation Headers)

표현은 요청이나 응답에서 전달할 실제 데이터를 뜻하며, 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.
HTTP 메시지는 헤더와 바디로 구분할 수 있습니다. HTTP 바디에서는 데이터 메시지 본문(Message body)을 통해서 표현(Representation) 데이터를 전달한다. 이때, 데이터를 실어 나는 부분을 페이로드라 한다.

헤더의 용도
- HTTP 전송에 필요한 모든 부가정보
- 예) 메시지 바디에 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보... 등등정말 무수한 정보들이 들어간다. - 표준 헤더가 너무 많다.
- 필요시 임의의 헤더 추가 가능
- helloworld : hihi
표현 헤더

- Content-Type : 표현 데이터의 형식 (HTML, JSON)
- Content-Encoding : 표현 데이터의 압축 방식
- Content-Language : 표현 데이터의 지연 언어 (한국어인지, 영어인지)
- Content-Length : 표현 데이터의 길이
- 표현 헤더는 전송, 응답 둘 다 사용한다.
Content-Type (표현 데이터의 형식 설명)
- 미디어 타입, 문자 인코딩
예) text/html; charest=utf-8 - application/json
- image/png

Content-Encoding (표현 데이터 인코딩)
- 표현 데이터를 압축하기 위해 사용
- 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
- 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제

ex) gzip : GNU zip 인코딩이 적용되었음을 의미
deflate : zlib 포맷으로 압축되었다는 의미
identity : 어떤 인코딩도 수행되지 않았음을 의미. (Content-Encoding 헤더가 존재하지 않는다면, 이 값인 것으로 간주)
Content-Language (표현 데이터의 자연언어)
- 표현 데이터의 자연 언어를 표현
ex)
- ko
- en
- en-US


Content-Length (표현 데이터의 길이)
- 바이트 단위로 표현
- Transfer - Encoding(전송 코딩)을 사용하면 Content - Length 사용 X

콘텐츠 협상(Content negotiation)
콘텐츠 네고시에이션/클라이언트가 선호하는 표현 요청이다.
- Accept : 클라이언트가 선호하는 미디어 타입 전달
- Accept-Charset : 클라이언트가 선호하는 문자 인코딩
- Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
- Accept-Language : 클라이언트가 선호하는 자연 언어
- 협상 헤더는 요청 시에만 사용

한국어 브라우저를 사용하여 외국 사이트에 들어갈 때 외국 사이트에 기본 언어는 영어고 서브 언어로 한국어도 지원한다고 되어있다. 그러면 클라이언트가 한국어인지 아닌지 아무런 정보가 없으니 서버에서는 영어 관련된 내용으로 한국어 브라우저에 응답을 해준다. 그럴 때 Accept-Language:KO로 전달하면 한국어를 원한다라고 클라이언트에서 서버로 알아서 전달이 된다. 그럼 서버에서는 기본 언어는 영어이지만 한국어도 지원하기 때문에 알아서 클라이언트가 원하는 한국어로 바디에 뿌려준다.

그러나 한국어가 없을 때 클라이언트가 원하는 건 한국어인데, 서버에서는 기본 언어가 독일어고 서브 언어가 영어이다. 이럴 경우에는, 우선순위가 필요하다.
협상과 우선순위 1 (Quality Values)

- Quality Values(q) 값 사용
- 0~1, 클수록 높은 우선순위
- 생략하면 1
ex)
1순위 ko-KR;q=1 (q생략)
2순위 ko;q = 0.9
3순위 en-US;q = 0.8(영어)
4순위 en;q=0.7
출저 ) https://velog.io/@leemember/HTTP-%ED%97%A4%EB%8D%94#-%ED%91%9C%ED%98%84
'TIL' 카테고리의 다른 글
| 15일차 WAS와 Web Server (0) | 2022.05.06 |
|---|---|
| 14일차 REST API (0) | 2022.05.04 |
| 12일차 Git과 버전 관리 시스템 (0) | 2022.05.02 |
| 11일차 Git과 버전 관리 시스템 (0) | 2022.04.29 |
| 10일차 웹 서비스 개발 기초 (0) | 2022.04.28 |