[기술면접] Network | 캐시 쿠키 세션, CORS

💡 캐시, 쿠키 세션의 비교

 

캐시, 쿠키, 세션

웹 애플리케이션에서 데이터를 관리하고 사용자 경험을 개선하기 위한 중요한 요소들이다.

각각 다른 목적과 기능을 가진다.

 

 

캐시 (Cache):

• 캐시는 이전에 가져온 데이터나 웹 페이지의 일부를 저장, 동일한 데이터나 페이지를 다시 불러올 때 더 빠르게 접근하도록 돕는다.
• 클라이언트(브라우저)나 서버에 있을 수 있다
  브라우저는 웹 사이트의 자산(이미지, 스타일 시트, 스크립트 등)를 캐시하여 이후 요청에 대한 성능을 최적화한다.
• 캐시는 웹 페이지 로딩 시간을 줄이고 네트워크 트래픽을 감소시켜 효율적으로 웹 애플리케이션을 작동시킨다.

 

쿠키 (Cookies):

• 쿠키는 클라이언트(브라우저)에 저장되는 작은 데이터 조각
• 웹 사이트가 브라우저를 식별하고 정보를 기억할 수 있도록 돕는다.
• 과정 : 첫 요청 시 서버에서 설정 - 브라우저에 저장 - 클라이언트 요청에 함께 전송 - 서버가 사용자를 식별, 응답

 

세션 (Session):

• 세션은 클라이언트와 서버 간의 상태를 유지하고 관리하는 메커니즘
• 사용자 식별 및 상태 유지(=쿠키)에 사용되지만, 서버에 저장된다.
• 클라이언트가 서버에 접속할 때 -  세션 ID가 발급 - 클라이언트 요청+세션ID - 서버는 ID로 세션 메모리 정보를 확인, 클라이언트를 식별, 응답

 

캐시는 성능 최적화를 위한 데이터 저장 방법

쿠키는 클라이언트 식별 및 정보 저장

세션은 서버 상태 유지 및 클라이언트 식별에 사용된다

 

 

+++ 로컬 스토리지 관련

• 쿠키 : 일시적으로 필요한 가벼운 데이터 저장이 필요할 때
  • 다시 보지 않음 쿠키 팝업창 , 로그인 자동 완성
• 로컬 스토리지 : 지속적으로 필요한 데이터 저장이 필요할 때
  • 자동 로그인
• 세션 스토리지 : 일시적으로 필요한 데이터 저장이 필요할 때
  • 일회성 로그인, 입력 폼 저장, 비로그인 장바구니

참고: https://velog.io/@hs0217/쿠키-로컬-스토리지-세션-스토리지

 

 

 

 

💡 CORS는 무엇이고, 어떻게 구현하나요?

CORS하면 맨날 홍보하던 그 블로그! https://inpa.tistory.com/entry/WEB-📚-CORS-💯-정리-해결-방법-👏

 

 

Cross-Origin Resourse Sharing

• 교차 출처 리소스 공유 정책
• 웹 어플리케이션의 보안을 강화하기 위한 정책으로, 다른 출처에서 리소스에 접근하는 것을 제어할 수 있다.
  
  

과정:

1. 클라이언트에서 HTTP요청의 헤더에 Origin을 담아 전달
2. 서버는 응답헤더에 Access-Control-Allow-Origin을 담아 클라이언트로 전달
3. 클라이언트에서 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교 및 처리

 

CORS를 구현하기 위해서는 서버에서 Access-Control-Allow-Origin 헤더에 허용할 출처를 기재해서 클라이언트에 응답하면 된다!

 

 

---

 

위는 간단한 예시이고, 실제로 CORS는 3가지 방식으로 작동한다. 아래는 gpt에게 정리해달라고 한 내용.
그림 예시나 보다 자세한 설명이 필요하다면 위 링크를 참고하자!

 

1. 예비 요청 (Preflight Request)
   • 브라우저는 실제 요청을 보내기 전에 OPTIONS 메서드를 사용하여 서버에 예비 요청을 보냅니다.
   • 예비 요청은 주로 복잡한 요청(일부 헤더를 사용하는 경우 등)에 대한 사전 확인을 위해 사용됩니다.
   • 서버는 예비 요청을 받고 요청을 처리할 수 있는지 확인한 후, 허용 여부를 응답합니다.
     
     
2. 단순 요청 (Simple Request)
   • 특정 조건을 만족하는 간단한 요청은 브라우저에서 추가 확인 없이 직접 서버에 요청을 보냅니다.
   • 단순 요청은 GET, POST, HEAD 메서드 중 하나를 사용하고, 특정 헤더를 사용하지 않거나 아래 조건을 모두 충족해야 합니다:
     • 사용되는 헤더: Accept, Accept-Language, Content-Language, Content-Type (단, **Content-Type**은 application/x-www-form-urlencoded, multipart/form-data, text/plain 중 하나여야 함)
     • 사용되는 **Content-Type**은 위에서 허용된 형식이어야 함
       
       
3. 인증된 요청 (Credentialed Request)
   • 브라우저는 인증 정보(쿠키, HTTP 인증 헤더 등)를 요청에 포함시키기 위해 withCredentials 옵션을 사용하여 요청을 보냅니다.
   • 서버는 요청에 포함된 인증 정보를 검증하고, 허용 여부를 응답합니다.

 

 

 

💡 CORS가 왜 필요한가?

인터넷을 사용하여 오픈된 환경에서 여러 사람과 리소스를 공유하기 위해서는 다른 출처를 허용해야하기 때문이다.

이때 CORS를 통해 다른 출처의 리소스에 대한 접근을 제어함으로써 보안을 높일 수 있다.

 

 

 

Same-Origin Policy SOP

• 동일한 출처에 대한 정책.
• 동일한 출처에서만 리소스를 공유할 수 있다는 규칙을 가짐
• 서로 다른 두 어플리케이션이 자유로이 소통하는 것은 보안상 위험 (CSRF XSS등의 방법으로 해커가 개인정보를 가로챌 수 있기 때문)

• 하지만 인터넷을 사용하며 오픈된 환경에서 여러 사람과 리소스를 공유하기 위해서는 다른 출처를 허용해야한다!
  그래서 몇가지 예외 조항을 두고 허용하기로 하였다 = CORS
  
  

Cross-Origin Resourse Sharing (중요한건 한 번 더)

• 교차 출처 리소스 공유 정책
• 웹 어플리케이션의 보안을 강화하기 위한 정책으로, 다른 출처에서 리소스에 접근하는 것을 제어할 수 있다.