TIL

13일차 HTTP

김영재0412 2022. 5. 3. 16:45

 

Cookie

HTTP의 특성

2022.04.27 - [분류 전체보기] - 9일 차 웹서비스 개발 기초

  • HTTP는 기본적으로 무상태(Stateless) 프로토콜이다
  • 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다. (서로 상태를 유지하지 않는다)
  • 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다.
  • 클라이언트와 서버는 서로 상태를 유지하지 않는다.

정보가 유지되지 않으면, 매번 페이지를 이동할 때마다 로그인을 다시 하거나, 상품을 선택했는데 구매 페이지에서 선택한 상품의 정보가 없거나 하는 등의 일이 발생할 수 있다.

 

따라서, Stateful 경우를 대처하기 위해서 쿠키와 세션을 사용한다.

 

쿠키와 세션의 차이점

 

  쿠키(Cookie) 세션(Session)
저장 위치 클라이언트(=접속자PC) 웹 서버
저장 형식 Text Object
만료 시점 쿠키 저장시 설정
(브라우저가 종료되도, 만료시점이 지나지 않으면 자동으로 삭제되지않음)
브라우저 종료시 삭제
(기간지정가능)
사용하는 자원(리소스) 클라이언트 리소스 웹 서버 리소스
용량 제한 총 300개
하나의 도메인 당 20개
하나의 쿠키 당 4KB(=4096byte)
서버가 허용하는 한 용량제한 없음.
속도 세션보다 빠름 쿠키보다 느림
보안 세션보다 안 좋음 쿠키보다 좋음

 

Cookie는 HTTP환경에서 상태를 유지하기 위한 기술이자 서버가 일방적으로 클라이언트에 전달하는 작은 데이터이며 단순히 서버에서 클라이언트에 쿠키를 전송하는 것만 의미하지 않고 클라이언트에서 서버로 쿠키를 전송하는 것도 포함된다.

 

홍길동으로 로그인을 하면 서버는 Set-Cookie : user=홍길동을 쿠키 저장소에 저장한다. 그 후 도메인은 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 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용

Host

 

응답(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-Type 회원이라는 리소스가 있다. 이걸 HTML이라는 형식으로 전달한다는 뜻이다.

 

 

Content-Encoding (표현 데이터 인코딩)

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

gzip로 압축 됐다는 뜻이다.

 

ex) gzip : GNU zip 인코딩이 적용되었음을 의미

      deflate : zlib 포맷으로 압축되었다는 의미

      identity : 어떤 인코딩도 수행되지 않았음을 의미. (Content-Encoding 헤더가 존재하지 않는다면, 이 값인 것으로 간주)

 

 

 

Content-Language (표현 데이터의 자연언어)

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

ko 여서 한국어, en여서 영어

 

Content-Length (표현 데이터의 길이)

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

content-length 521바이트를 의미함

 

 

 

콘텐츠 협상(Content negotiation)

콘텐츠 네고시에이션/클라이언트가 선호하는 표현 요청이다.

 

  • Accept : 클라이언트가 선호하는 미디어 타입 전달
  • Accept-Charset : 클라이언트가 선호하는 문자 인코딩
  • Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
  • Accept-Language : 클라이언트가 선호하는 자연 언어
  • 협상 헤더는 요청 시에만 사용

Accept-Language 예시

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

Accept-Language 예시

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

 

협상과 우선순위 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