Goal

  • Cookie와 Session이 왜 필요한 이유
  • Cookie란 무엇인지에 대해 이해한다
  • Session이란 무엇인지에 대해 이해한다
  • Cookie와 Session의 차이에 대해 이해한다

쿠키와 세션의 사용 이유

HTTP 프로토콜의 특징

  1. 비연결지향(Conectionless)
    • HTTP는 클라이언트가 요청(Request)을 서버에 보내고, 서버는 클라이언트에 요청에 맞는 응답(Response)를 보내면 바로 연결을 끊는다
  2. 상태 정보를 유지 안 함(Stateless)
    • 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나면 상태 정보를 유지하지 않는다

쿠키와 세션의 필요성

  • HTTP 프로토콜은 위와 같은 특징으로 모든 요청간의 의존관계가 없다
  • 즉, 현재 접속한 사용자가 이전에 접속했던 사용자와 같은 사용자인지 아닌지 알 수 있는 방법이 없다
  • 계속해서 연결을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것이 큰 장점이지만, 통신할 때마다 새로 연결하기 때문에 클라이언트는 매 요청마다 인증을 해야한다는 단점이 있다
  • 이전 요청과 현재 요청이 같은 사용자의 요청인지 알기 위해서는 상태를 유지해야한다
  • HTTP프로토콜에서 상태를 유지하기 위한 기술로 쿠키와 세션이 있다

쿠키 (Cookie)

쿠키란?

  • 쿠키는 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일한다
  • 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 쿠키가 유지된다는 특징이 있다
  • 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조한다

구성요소

  • 쿠키의 이름(name)
  • 쿠키의 값(value)
  • 쿠키의 만료시간(Expire)
  • 쿠키를 전송할 도메인 이름(Domain)
  • 쿠키를 전송할 경로(Path)
  • 보안 연결 여부(Secure)
  • HttpOnly 여부(HttpOnly)
  • 지속 쿠키
    • 만료 날짜/시간을 지정하지 않으면 항상 유지하라는 것으로 판단하고 지속 쿠키에 저장된다
    • 파일로 저장되므로 브라우저가 종료되어도 쿠키는 남아있다
  • 세션 쿠키
    • 만료 날짜/시간을 지정하면 세션 쿠키로 저장된다
    • 브라우저 메모리에 저장되므로 브라우저가 종료되면 쿠키는 사라지게 된다

동작 방식

스크린샷 2020-11-10 오후 9 36 25

  1. 웹 브라우저가 서버에 요청
  2. 상태를 유지하고 싶은 값을 쿠키(Cookie)로 생성
  3. 서버가 응답할 때 Http Response Header의 Set-Cookie에 쿠키를 포함해서 전송
    1
    Set-Cookie: id=chan
  4. 전달받은 쿠키는 웹 브라우저에서 관리하고 있다가, 다음 요청 때 쿠키를 Http 헤더에 넣어서 전송
    1
    cookie: id=chan
  5. 서버에서는 쿠키 정보를 읽어 이전 상태 정보를 확인 후 응답

쿠키 사용 예

  • 아이디, 비밀번호 저장
  • 쇼핑몰 장바구니

쿠키의 제약사항

  • 클라이언트에 최대 300개까지 쿠키를 저장할 수 있다

  • 서버 도메인 하나당 최대 20개의 쿠키를 저장할 수 있다

  • 하나의 쿠키 값은 최대 4KB까지 저장할 수 있다

    쿠키는 사용자가 별도로 요청하지 않아도 브라우저(Client)에서 서버에 요청시 Request Header에 쿠키 값을 자동으로 넣어 보낸다

    그렇다고 모든 쿠키 값을 모든 요청에 넣어서 비효율적으로 동작하지 않고 지정 도메인에 해당하는 쿠키 값만을 제공한다

세션(Session)

세션이란?

  • 세션은 쿠키를 기반으로 동작하지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다
  • 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다
  • 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능하다
  • 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다
  • 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 된다
  • 클라이언트가 Request를 보내면, 해당 서버 엔진이 클라이언트에게 유일한 ID를 부여하는데 이것이 세션이다

동작 방식

스크린샷 2020-11-10 오후 11 21 26

  1. 웹 브라우저가 서버에 요청
  2. 서버가 해당 웹 브라우저(클라이언트)에 유일한 ID(Session ID)를 부여함
  3. 서버가 응답할 때 HTTP Header(Set-Cookie)에 Session ID를 포함해서 전송
    • 쿠키에 Session ID를 JSESSIONID라는 이름으로 저장
      1
      Set-Cookie : JSESSIONID=g3r2sddh
  4. 웹 브라우저는 이후 웹 브라우저를 닫기까지 다음 요청 때 부여된 Session ID가 담겨있는 쿠키를 HTTP Header에 넣어서 전송
    1
    Cookie : JSESSIONID=g3r2sddh
  5. 서버는 세션 ID를 확인하고, 해당 세션에 관련된 정보를 확인한 후 응답

세션도 쿠키를 사용하여 값을 주고받으며 클라이언트의 상태 정보를 유지한다

즉, 세션이 상태 정보를 유지하는 수단으로 쿠키를 사용한다

쿠키와 세션의 차이

  • 저장 위치
    • 쿠키는 클라이언트(브라우저)의 메모리 또는 파일에 저장
    • 세션은 서버 메모리에 저장
  • 보안
    • 쿠키는 로컬에 저장되고, 특히 파일로 저장되는 경우가 있어 탈취, 변조에 위험하고 Request/Response시에 스니핑당할 위험이 있다
    • 세션은 클라이언트 정보 자체가 서버에 저장되어 있으므로 비교적 안전하다
  • 라이프 사이클
    • 쿠키중 지속 쿠키는 브라우저가 종료하더라도 저장되어있다
    • 세션은 만료시간/날짜를 정해서 기간이 지나면 자동으로 삭제하고 세션쿠키에서 세션 아이디를 정한 경우, 브라우저 종료시 세션아이디가 삭제된다
  • 속도
    • 쿠키는 클라이언트에 저장되어 있기 때문에 서버 요청시 속도가 빠르다
    • 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린 속도를 낸다

참고 - 캐시

  • 브라우저 캐시는 이미지(.png, .jpg)나 css, js파일등이 사용자의 브라우저에 저장되는 것이다
  • 이를 이용해서 같은 자원을 로드(load)해야할 경우에, 해당 자원을 다시 서버에 요청하지 않고 브라우저에 캐시되어 있는 자원을 쓰는 방식이다
  • 자원이 브라우저 캐시에 저장되면 브라우저에 있는 결 재사용하기 때문에 경우에 따라서 자원이 변경되어도 변경된 자원을 참조할 수 없는 경우가 있다
  • 따라서 사용자는 브라우저 캐시를 지워주거나 서버에서 클라이언트에 응답을 보낼 때 header에 자원 캐시 만료시간을 명시하는 방식을 사용하여 위와같은 문제를 해결할 수 있다

Comment and share

Web-HTTP

in Web, HTTP

HTTP

정의

  • HTTP(Hyper Text Transfer Protocol)는 웹 서버(Apache, Nginx 등)와 클라이언트(브라우저)가 인터넷 상에서 HTML문서와 같은 리소스들을 주고받을 수 있도록 하기 위해 만든 프로토콜(통신 규약)

    스크린샷 2020-11-10 오후 4 51 43

  • HTTP통신은 클라이언트가 데이터를 요청(request)하면 그 요청을 처리하여 서버가 다시 클라이언트에게 응답(response)하는 큰 흐름을 따른다

  • 어떠한 데이터의 형태도 주고 받을 수 있다

특징

  • 무상태(stateless) & 비연결성(Connectionless)
    • 한 번의 요청에 대해 TCP통신을 설정한 후 한 번의 요청에 대한 응답이 처리되면 TCP연결을 끊어 버리는 형태의 통신
    • TCP연결을 끊어 버리는 형태의 통신으로 연속적인 통신에 부적합
    • 하지만, 인터넷과 같이 다수의 사용자를 대상으로 한 Pull방식의 사용자가 필요한 문서 서비스를 전달 받는 구조에는 적합한 통신 구조
    • 한 번의 요청에 대해 한 번의 응답으로 트랜잭션이 종료되므로 연속적인 작업 처리에 필요한 트랜잭션 상태 정보를 관리하기 위한 Overhead가 없다
    • HTTP를 상업적으로 이용하면서 이러한 구조는 큰 단점이 되었다
      • 대안 기술: Cookies & Session Tracking

HTTP Request Message의 구조

3가지 부분으로 구성

스크린샷 2020-11-10 오후 5 17 15

  • start line(request line)

    • HTTP Method: GET, POST 등 action을 정의
    • Request target: request가 전송되는 uri(end point)
    • HTTP Version
  • headers

    • 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해주며, key:value 값으로 되어있다
    • Host: (가상 호스팅을 위해) 서버의 도메인명과 서버가 리스닝하는 (부가적인) TCP 포트를 특정한다
    • User-Agent: 요청을 보내는 클라이언트에 대한 정보
    • Accept
      • MIME 타입으로 표현
      • 클라이언트가 이해 가능한 컨텐츠 타입이 무엇인지 알려준다
      • 서버는 제안 중 하나를 선택하고 사용하며 Content-Type 응답 헤더로 클라이언트에게 선택된 타입을 알려준다
    • Cache-Control(HTTP/1.1)
      • Cache를 이용하여 웹 서버와 클라이언트간의 요청과 응답 횟수를 줄여 대역폭을 향상하기 위해 사용된다
      • 만기일(expiration)과 유효일(validation)을 지정
    • Connection
      • 트랜젝션 종료후에 네트워크 연결을 유지할지 말지를 결정한다
      • HTTP/1.0은 트랜젝션 이후의 커넥션을 종료한다
      • colse : 연결을 끊음
      • keep alive : 연결을 지속
    • Content-Type
      • 해당 요청이 보내는 메세지 body의 타입
      • 예를 들어 JSON을 보내면 application/json
    • Content-Length: 메세지 body의 길이
  • blank line: 요청에 대한 meta 정보가 전송되었음을 알린다

  • body:

    • 해당 request의 실제 메세지/내용이 들어있다
    • XML, HTML, JSON 데이터가 들어갈 수 있다

HTTP Response 구조

스크린샷 2020-11-10 오후 6 56 58

  • status line

    • response의 상태를 간략하게 나타내며, 3부분으로 구성되어 있다

      • HTTP Version
      • status code: 응답 상태를 나타내는 코드
      • status text: 으답 상태를 설명(ex: Not Found)
    • headers

      • request의 header와 동일하다
      • response에서만 사용되는 header값이 있다. (예: User-Agent가 없고, Server가 있음)
    • blank line

    • body: 실제 응답하는 데이터를 나타낸다

Comment and share

  • page 1 of 1

Yechan Kim

author.bio


author.job