Cookies, Session, Cache에 대해 알아보자.(2)

 

쿠키, 세션, 캐시도 각각의 여러 종류가 존재해. 이걸 알아볼 거야.

 

Cookies🍪에도 Session Cookies(세션 쿠키), Persistent Cookies(지속 쿠키), Secure Cookies(보안 쿠키), HttpOnly Cookies(자바스크립트 금지 쿠키), SameSite Cookies (같은 사이트 쿠키)의 다양한 쿠키가 존재해. (벌써 어지럽다..)

 

먼저 이해하기 쉽게 예시를 들어 설명을 해줄께...!

(하- 뭐가 이렇게 많냐 ㅡ.ㅡ)

 

Cookies

1.Session Cookies (세션 쿠키)

이건 마치 식사하는 동안 먹을 음식이야. 한 끼 식사가 끝나면 테이블을 떠나면서 사라져. 브라우저를 닫으면 이 쿠키도 자동으로 없어지지.

세션 쿠키는 사용자가 브라우저를 닫을 때까지만 유지되는 쿠키야. 브라우저 세션이 유지되는 동안에만 사용되며, 브라우저를 닫으면 세션 쿠키는 삭제돼.

 

 

2. Persistent Cookies (지속 쿠키)

이건 조금 더 오래가는 음식이야. 냉장고에 보관하면 며칠 동안 계속 먹을 수 있어. 브라우저를 닫아도 계속 남아있어서, 다음에 브라우저를 열면 또 먹을 수 있어.

지속 쿠키는 설정된 만료 날짜까지 지속되는 쿠키야. 브라우저를 닫아도 유지될 수 있으며, 일반적으로 로그인 정보, 사용자 설정 등을 저장하는 데 사용돼.

 

 

3. Secure Cookies (보안 쿠키) 

이 음식은 특별하게 뚜이 덮여있어. 그래서 안전한 상황(HTTPS)에서만 뚜껑이 열리고, 중요한 정보를 전송할 때 안전하게 먹을 수 있어.

Secure쿠키는 안전한 연결(HTTPS)에서만 전송되는 쿠키야. 이는 중요한 정보를 전송하는 경우에 보안을 강화하기 위해 사용돼.

 

 

4.HttpOnly Cookies (자바스크립트 금지 쿠키)

이 음식은 자바스크립트로 접근할 수 없는 특별한 조리법으로 만들어져 있어. 그래서 좀 더 안전하게 먹을 수 있어. XSS(크로스 사이트 스크립팅) 공격에서 안전한 쿠키이지.

HttpOnly 쿠키는 JavaScript를 통해 접근할 수 없도록 하는 쿠키야. 이를 통해 XSS(크로스 사이트 스크립팅) 공격을 방지할 수 있어.
*XSS(크로스 사이트 스크립팅) : 웹 애플리케이션에서 발생하는 보안 취약점 중 하나로, 악의적인 사용자가 웹 페이지에 악성 스크립트를 삽입하여 다른 사용자들에게 전달되게 만드는 공격이야. 주로 사용자 입력을 신뢰하지 않는 웹 애플리케이션에서 발생하지. XSS공격은 사용자의 브라우저에서 실행되어 사용자의 세션 쿠키를 탈취하거나 악의적인 행동을 수행할 수 있어.

 

 

5. SameSite Cookies (같은 사이트 쿠키)

이 음식은 집에서만 먹을 수 있어. 다른 사람이나 다른 집에선 못 먹게 막아놨지. CSRF(크로스 사이트 요청 위조) 공격을 방지하기 위한 쿠키란다.

SameSite 쿠키는 요청이 사이트 간 (cross-site)으로 전송되지 않도록 하는 것을 목적으로 하는 쿠키야. 이는 CSRF(크로스 사이트 요청 위조) 공격을 방지하는 데 도움이 돼.
*CSRF(크로스 사이트 요청 위조) : 사용자가 자신의 의지와 무관하게 공격자가 의도한 행동을 수행하게 만드는 공격이야. 간단하게 설명하면, 사용자가 로그인한 상태에서 악의적인 웹 사이트에 방문하거나, 악의적인 이메일을 통해 공격자가 의도한 동작을 트리거 하는 방식으로 이루어져.

 

 

쿠키의 특성과 용도는 웹 애플리케이션에서 데이터를 효과적으로 관리하고 유지하기 위한 다양한 방법을 제공해. 개발자는 각 상황에 맞게 적절한 쿠키를 선택하여 사용해야 해.

 

1차 빡침

Session

1.Server-Side Session (서버 세션)

이건 마치 요리사가 특별한 요리를 만들어서 각 손님에게 제공하는 스타일이야. 요리사(서버🧑‍🍳)가 각각의 테이블(클라이언트🧑‍💻)에게 특별한 식별자(세션 ID)를 부여하고, 각각의 손님이 주문한 내용(세션 데이터)을 서버가 기억하고 있어. 손님은 특별한 메뉴(세션 데이터)를 즐길 수 있지.

세션 데이터를 서버에 저장하는 방식이야. 서버는 각 세션에 대한 고유한 식별자를 생성하고 클라이언트에게 해당 식별자를 제공해. 클라이언트는 이 식별자를 쿠키 또는 URL 매개변수 등을 통해 저장하고 전송해. 서버는 세션 데이터를 저장하고 관리하며, 클라이언트는 세션 식별자를 사용하여 세션 데이터에 액세스해.

 

 

2.Client-side Session (클라이언트 세션)

이건 마치 각자가 자신이 먹고 싶은 음식을 고르는 뷔페 스타일이야. 각각의 손님(클라이언트 🧑‍💻)이 자신만의 플레이트(로컬 스토리지🍽️)에 원하는 음식(세션 데이터)을 담아서 즐기는 거야. 서버가 덜 일하고 각자가 편하게 즐길 수 있어.

세션 데이터를 클라이언트 측에 저장하는 방식이야. 주로 웹 브라우저의 로컬 스토리지 또는 세션 스토리지를 사용하여 데이터를 저장해. 이는 서버에 부담을 덜 줄 수 있고, 클라이언트 측에서 빠르게 데이터에 액세스 할 수 있도록 하지.

 

 

세션 쿠키 자체에는 여러 "종류"가 아니라, 주로 세션의 지속 기간에 따라 다르게 사용돼.
이러한 선택은 개발자의 요구 사항과 보안 고려사항에 따라 달라져.

 

 

2차 빡침

 

Cache

1. Browser Cache (브라우저 캐시)

브라우저는 방문한 웹페이지의 정보를 상자에 담아둬. 다음에 같은 페이지를 찾을 때, 이전에 담아둔 정보를 사용해서 페이지를 빨리 보여줄 수 있어. 마치 책을 다시 읽을 때 책살피를 펼치듯이!

• Page Cache (페이지 캐시) : 웹 페이지의 HTML, CSS, JS 등의 자원 저장
• Image Cache (이미지 캐시) : 웹 페이지에 표시되는 이미지를 저장

 

2. Server Cache (서버 캐시) 

서버는 만들어진 음식(페이지)을 미리 쟁여둬. 손님이 같은 음식을 요청하면 매번 새로 만들지 않고, 이미 만들어진 것을 그대로 가져다주는 거야. 서버는 요리사처럼 사소한 변경 사항만 조리해서 제공해. 

• Page Cache (페이지 캐시) : 서버에서 생성된 동적인 페이지의 결과를 캐시에 저장해
• API Cache (API 캐시) : 서버에서 제공하는 API 응답을 캐시에 저장하여 반복적인 요청에 대한 성능을 향상. 특히 외부 데이터에 대한 요청이 많은 경우 유용해

 

3. CDN Cache (CDN 캐시) 

CDN은 세계 각지에 음식 배달원(서버)을 둬서 빠르게 음식을 가져다주는 거야. 가까운 곳에 있는 배달원이 요청을 빠르게 처리해 주기 때문에 음식이 빨리 도착하게 돼.

• Static Content Cache (정적 콘텐츠 캐시) : CDN은 세계 곳곳에 분산된 서버를 가지고 있어 정적인 자원(이미지, 스타일 시트, 스크립트 등)을 브라우저에 가까운 위치에 저장하여 전송 속도를 향상해.

CDN(Content Delivery Network의 약자로, 전 세계 여러 지역에 분산된 서버 네트워크를 의미함

 

 

4. Proxy Cache (프록시 캐시)

프록시 서버는 손님이 가는 길에 있는 레스토랑처럼 중간에서 요리를 쟁여둬. 손님이 많아서 요리사에게 부담이 되지 않게끔 중간에 쟁여두면, 모두가 더 빨리 식사를 할 수 있지.

• 사용자와 서버 사이의 캐시 : 웹 서버와 클라이언트 사이에 위치한 프록시 서버에서 응답을 캐시함. 이를 통해 동일한 자원에 대한 요청을 여러 클라이언트가 공유할 수 있고, 서버 부하를 줄일 수 있어.

 

5. Memory Cache (메모리 캐시)

브라우저는 가장 흔히 사용하는 음식 몇 가지를 기억해 둬. 매번 요청할 때마다 신속하게 서빙할 수 있게끔. 메모리는 용량이 제한돼 있어서 자주 사용하는 것만 쟁여두는 거지.

• 브라우저 메모리에 저장되는 캐시 : 브라우저는 페이지를 방문할 때 사용하는 자원을 메모리에 캐시해. 메모리는 빠른 속도를 제공하지만, 용량이 제한적이므로 일부 자원은 디스크에도 저장돼.

캐시는 성능 향상과 대역폭 절약을 위해 중요한 개념이며, 적절한 캐시 전략을 사용함으로써 웹 애플리케이션의 성능을 향상시킬 수 있어.

 

펑...

 

---

 

서버 캐싱에 대해

 

서버 캐싱은 서버가 데이터를 저장해 두고, 동일한 요청이 있을 때마다 매번 새 데이터를 생성하지 않고 저장해둔 데이터를 빠르게 반환하는 방식이다. 주로 데이터베이스 접근 비용을 줄이고 응답 속도를 높이는 데 큰 효과를 준다. 

서버 캐싱 방식은 몇 가지가 있는데, 그중 대표적인 것들을 살펴보자.

 

1. HTTP 캐싱

HTTP 캐시는 클라이언트와 서버 간의 HTTP 헤더를 이용해 데이터를 캐싱하는 방식이다. 서버가 브라우저나 프록시 서버에 Cache-Control이나 Expires헤더를 보내면, 브라우저는 이 데이터가 유효한 동안(유효 시간이나 조건을 만족하는 동안) 다시 서버에 요청하지 않고 캐시된 데이터를 보여준다.

 

예를 들어, Cache-Control : max-age=3600 라는 헤더가 있으면, 브라우저는 해당 데이터를 1시간 동안 캐싱하고 재요청을 하지 않는다.

 

2. 서버 메모리 캐싱 (예: Redis, Memcached)

서버 메모리 캐싱은 Redis나 Memcached 같은 인메모리 데이터 저장소를 사용한다. 데이터를 서버 메모리에 저장하고 필요할 때 빠르게 불러오는 방식이다. 이 방식은 데이터베이스 쿼리를 줄여 서버 부하를 크게 낮출 수 있다.

 

예를 들어, 사용자가 처음 요청한 데이터는 Redis에 저장해 두고, 이후 동일한 요청이 들어오면 Redis에서 데이터를 바로 꺼내 반환하는 방식이다.

 

3. Reverse Proxy 캐싱 (예: Nginx, Varnish)

Reverse Proxy 서버는 클라이언트 요청을 웹 서버로 전달하면서 응답 데이터를 캐싱하는 방식이다. 클라이언트가 동일한 요청을 반복하면, 프록시 서버가 기존에 캐싱해 둔 데이터를 빠르게 반환하고, 서버로 요청을 보내지 않는다.

 

예를 들어, Nginx에서 특정 URL의 데이터를 캐싱하도록 설정하면, 해당 URL의 데이터는 다시 서버에 접근하지 않고 Nginx에서 즉시 제공하게 된다.

 

4. CDN 캐싱 (Content Delivery Network)

CND은 정적 콘텐츠(이미지, 비디오, CSS 파일 등)를 전 세계 여러 서버에 분산 저장해 두고, 사용자 위치에 가까운 서버에서 데이터를 제공하는 방식이다. 사용자가 특정 리소스에 접근할 때 가장 가까운 CDN 서버에서 콘텐츠를 받아오니, 로딩 속도가 크게 향상된다.

 

5. 데이터베이스 쿼리 결과 캐싱

데이터베이스가 자주 조회하는 쿼리 결과를 캐시 테이블에 저장하거나 메모리에 보관해 두는 방식이다. 복잡한 쿼리를 매번 실행하지 않고, 결과를 재사용할 수 있어 성능을 높이는 데 유리하다.

 

예를 들어, 웹 페이지의 인기 게시글을 자주 조회할 경우, 서버는 처음 조회할 때만 데이터베이스에서 가져와 캐싱하고, 이후 요청에서는 캐시에서 바로 응답하게 한다. 이렇게 하면 데이터베이스 요청을 줄이고, 사용자에게 빠르게 데이터를 제공할 수 있다.

 

서버 캐싱을 통해 서버는 불필요한 작업을 줄이고, 더 빠르게 데이터와 서비스를 제공할 수 있다. 특히 대규모 트래픽이나 반복되는 요청이 있는 경우 서버 캐싱이 큰 효과를 발휘한다.