엘비

2차 저장 공간

업데이트:

태그: , ,

카테고리:

Cookie

  • HTTP 서버는 stateless이다.
    • 이 덕분에 서버 디자인이 쉬워졌고 이에따라 수많은 TCP연결을 처리할 수 있는 고성능 웹서버를 만들 수 있게되었다.
    • 하지만, 웹 서버가 stateless일지라도, 웹사이트가 유저를 인식하는게 좋을때가 있다.
      • 유저의 접근을 제한한다던지
      • 사용자에따라 다른 컨텐츠를 제공한다던지를 위해
    • 이러한 목적을 위해 HTTP는 Cookie를 사용해 유저를 추적한다.

스크린샷 2022-09-01 오후 8 50 35


구성요소

  • Cookie 설정은 4가지의 구성요소로 이뤄진다.
    1. HTTP response message의 cookie header line
    2. HTTP request message의 cookie header line
    3. 유저의 end system의 브라우저에 의해 관리되는 cookie파일
    4. 웹 사이트의 백엔드 데이터베이스


절차

  • 사용자가 웹사이트에 방문하면 서버는 백엔드 데이터베이스에 유저의 유일한 식별숫자를 생성한다.
  • 서버가 response를 날릴때, set-cookie라는 헤더와 유저 식별 숫자를 함께 날리게되고, 이는 사용자의 컴퓨터에 저장된다.
  • 사용자가 계속 이 사이트를 사용할때마다, 이 유저 식별 숫자를 cookie header line에 포함해 request msg에 보내게되는데, 이를통해 서버는 이 숫자로 사용자를 계속 식별할 수 있다.


쿠키가 사용되는 예시

  • 세션관리, 개인화(맞춤 광고 설정) 등등


쿠키 파일 확인

  • m1 Mac기준, 크롬의 쿠키파일은 ~/Library/Application Support/Google/Chrome/Default에 저장되어있다.

  • 해당파일 정보를 file명령어를 통해 확인해보면 sqlite3의 형식으로 저장되어 있는것을 확인할 수 있다.
    • 스크린샷 2022-09-01 오후 9 11 59
  • 실제 이 데이터베이스에 접속해 쿼리문을 날려보면 아래와 같은 정보를 얻을 수 있다.
    • 스크린샷 2022-09-01 오후 9 14 45



Web Caching

  • Web cache == proxy server는 원래 목적지 서버를 대신해 HTTP 요청을 수행하는 네트워크 객체이다.
  • Web cache는 자신만의 저장공간을 가지며, 최근에 요청된 객체들을 보관하고있다.
  • 사용자의 브라우저는 Web cache를 향해 HTTP 요청을 먼저 수행하도록 설정될 수 있다.


절차

Web cache는 클라이언트, 서버의 역할을 모두 수행한다.

스크린샷 2022-09-01 오후 9 26 09

  1. 브라우저는 일단 Web cache와 TCP연결을 하고, HTTP request를 날리게된다.
  2. 만약 Web cache가 요청된 객체를 스토리지에 갖고있으면 해당 객체를 HTTP response로 전송한다.
  3. 만약 없으면 원본 서버와 TCP 연결 후 해당 객체를 받는다.
  4. 받은 객체를 Web cache 저장소에 저장하고, 복사해서 브라우저에 HTTP response로 전달한다.


사용하는 이유

  1. 클라이언트와 원본 서버 사이에 속도가 클라이언트와 Web cache 사이의 속도보다 느리다면 클라이언트 요청에 대한 병목을 줄일 수 있다.
    • access link를 통해 원본 서버에 접근하는 속도가 일반적으로 훨씬 느리다.
    • caching hit 비율이 높으면 높을수록 평균적인 응답속도는 더 빨라진다.
  2. 기관의 access link에 대한 트래픽을 감소시킬 수 있다.
    • access link를 업그레이드 하는 비용은 매우 비싸기에 caching을 사용해 비용을 줄일 수 있다.
  3. CDNs(Content Distribution Networks)의 증가
    • CDN 기업은 인터넷에 지역적으로 분산환 cache들을 설치해 트래픽을 지역화한다.(한곳에 몰리지 않게 한다.)



Conditional get

  • web caching을 이용할때의 문제점은 cache의 객체가 오래된 것일수도 있다는 것이다.
  • 즉, 사본이 클라이언트(proxy server)에서 캐시된 이후 웹 서버(원본 서버)에 저장된 오브젝트가 수정되었을 수 있다.
  • 따라서, web cache가 자신이 가진 객체가 최신의 것인지 확인하는 방법이 필요한데, HTTP가 사용하는 이 메커니즘은 conditional GET이라고 한다.(조건부 GET이라고 해도 될 듯)


예시

  1. proxy server가 웹 서버에 request message를 보낼때(cache not hit)일때를 생각해보자.
  2. 웹 서버는 cache에 객체를 보내는데, Last-modified 필드를 포함해서 보내게된다.
  3. cache는 이 객체를 저장하고, 브라우저에게 보내게된다.
  4. 일정시간이 지난 후에 다른 브라우저가 cache에 동일한 객체를 요청하면, cache는 up-to-date check를 conditional get을 통해 하게된다.
  5. cache는 if-modified-since헤더에 객체의 Last-modified필드의 값을 기입해서 원본 서버에 HTTP get request를 보내게되는데,
    • 만약 원본 서버의 객체가 수정되어 이 헤더 필드의 값과 달라지면, cache의 객체를 최신의 객체로 업데이트하는 절차를 밝고,
    • 수정되지 않은 상태면 304 not modified를 status line에 기입해 HTTP response로 보내게된다.

댓글남기기

참고