[네트워크] 쿠키, 세션, 토큰 외

쿠키와 세션?

• 쿠키와 세션은 사용자의 상태를 유지하고 정보를 저장하는 데 활용된다.
• 쿠키
  • 클라이언트의 로컬 브라우저에 저장되는 데이터.
  • 주로 사용자가 웹사이트를 방문할 때 서버에서 클라이언트로 전송되어 클라이언트의 로컬에 저장된다.
  • 쿠키는 이름-값 쌍으로 이루어져 있고, 유효 기간을 설정할 수 있다.
  • 목적
    • 세션 관리: 로그인 정보 등을 저장하여 사용자의 세션을 유지한다.
    • 개인화: 사용자의 선호도나 설정 등을 저장하여 개인화된 경험을 제공한다.
    • 트래킹: 사용자의 행동을 기록하고 분석하기 위해 사용될 수 있다.
  • 쿠키는 클라이언트 측에 저장되기 때문에 보안에 취약하다. 따라서 민감한 정보는 서버 측에 저장하거나 보안 조치를 취해야 한다.
• 세션
  • 세션은 서버 측에서 사용자의 상태를 관리하는 메커니즘이다.
  • 각 세션은 고유한 세션 ID를 갖고 있고, 해당 세션 ID는 클라이언트와 관련된 쿠키에 저장된다.
  • 목적
    • 로그인 유지: 사용자가 로그인한 상태를 유지하고 인증 처리
    • 장바구니 관리: 사용자가 쇼핑할 때 장바구니 정보 유지
    • 세션 추적: 사용자 행동을 추적하고 분석하기 위해 사용
  • 세션은 일반적으로 서버에 저장되며, 세션 식별자는 쿠키를 통해 클라이언트와 관련짓는다. 서버에 저장되기에 쿠키보다 상대적으로 안전하다. 세션이 서버 자원을 사용하므로 과도한 사용은 서버에 부하를 줄 수 있다.
• 쿠키와 세션의 차이점
  • 저장 위치
    • 쿠키: 클라이언트의 로컬 브라우저에 저장됨
    • 세션: 서버에 저장됨
  • 보안
    • 쿠키: 클라이언트에 저장되므로 취약함
    • 세션: 서버에 저장되어 비교적 안전함
  • 용도
    • 주로 개인화, 트래킹, 세션 관리 등에 사용됨
    • 주로 로그인 유지, 장바구니 관리, 세션 추적 등에 사용됨
  • 생명주기
    • 쿠키: 클라이언트에서 설정한 만료 기간까지 유지됨
    • 세션: 브라우저를 닫거나 로그아웃할 때까지 유지됨

 

 

 

 

---

토큰, JWT?

• 토큰
  • 이상하게 생긴 string(text)이다.
  • 해당 토큰을 서버에 보내고 서버는 세션 DB에서 해당 토큰과 일치하는 유저를 찾는다.
  • 서버는 유저를 인증하는 데 필요한 정보를 토큰에 저장하고, 해당 토큰을 브라우저에 전달한다.
  • 페이지를 요청하면, 서버는 해당 토큰이 유효한지를 검증한다. DB가 필요 없다.
• JWT
  • JWT는 토큰 형식이다.
  • JWT로 유저 인증을 처리하면 세션 DB를 가질 필요가 없고, 서버는 유저를 인증하기 위해 많은 일을 하지 않아도 된다.
  • ‘May’가 로그인하는 과정
    • 유저명, 비밀번호를 서버에 보낸다.
    • 유저명, 비밀번호가 맞다면 서버는 DB에 무엇을 생성하지 않는다.
    • 서버는 유저 ID를 가져다가 사인 알고리즘을 이용해서 ‘사인’을 한다.
    • 해당 ‘사인 정보’를 string 형태로 보낸다.
    • 쿠키는 공간 제약이 있지만 JWT는 제약이 없어서 엄청 길어도 된다.
    • 로그인을 하면, DB를 건드리는 대신 정보를 사인하고 전달한다.
    • 이제 서버에 요청을 보내려면 세션 ID와 비슷하게 해당 ‘사인 정보’ 또는 토큰을 서버에 보내야 한다.
    • 서버가 토큰을 받으면, 해당 사인이 유효한지 체크하고 (토큰을 조작했는지 체크)
    • 토큰이 유효하다면 서버는 우리를 유저로 인증한다.
  • JWT는 암호화되지 않았다. 누구나 열어서 해당 컨텐츠를 볼 수 있다. 비밀 정보를 JWT에 두면 안된다.
  • 토큰을 사인하고, 이를 통해 유효한지 검증한다.

 

 

 

 

---

세션과 JWT?

• 세션과 JWT의 장단점
  • 세션
    • 세션을 사용하면, 서버는 로그인 된 유저의 모든 정보를 저장한다.
    • 해당 정보를 이용하여 새로운 기능들을 추가할 수 있다.
    • 예를 들어 특정 유저를 쫓아내고자 할 때, 그냥 세션을 삭제하면 된다.
    • 인스타그램의 경우 로그인된 모든 디바이스를 보여주는데, 원하지 않는 디바이스에서 강제 로그아웃을 할 수 있다.
    • 넷플릭스처럼 계정 공유 숫자를 제한할 수 있다.
    • 이게 가능한 이유가 서버가 누가 로그인했는지 저장했고, 세션 DB가 있기 때문이다.
    • 유저가 많아질수록 DB도 커져야 하기에 비용이 커진다.
    • 보통 이를 위한 DB로 Redis를 사용한다. 해당 목적을 수행하기 위한 빠르고 저렴한 DB이다.
  • JWT
    • 서버가 토큰을 저장하지 않고, 서버는 토큰이 유효한지 여부만 알고 있다.
    • DB가 필요 없다. 따라서 강제 로그아웃 등을 할 수 없다.
    • 특정 회원은 해당 토큰이 만료되기 전까지는 유효하다.
    • 데이터를 사인하고, 유저에게 보내고, 해당 데이터를 돌려받을 때 유효성을 검증할 수 있다.
    • 코로나 때 하는 QR 체크인은 JWT가 들어간 QR 코드이다.
    • 세션이나 DB 없이 유저를 인증하는 일을 한다.
    • 서비스가 커지고 유저 계정을 좀 더 잘 관리하고 싶다면 세션을 사용할 수 있다.

 

 

 

 

---

SOP와 CORS?

• SOP (Same-Origin Policy)와 CORS(Cross-Origin Resource Sharing)는 웹 보안과 관련된 개념으로, 다른 도메인 간의 자원 요청을 제어하고 보안을 강화하는 데 사용된다.
• SOP
  • 웹 보안의 기본 원칙 중 하나로, 같은 출처(Origin)에서 로드된 문서 간에만 상호작용이 허용되도록 정책을 시행한다. Origin이란 프로토콜, 호스트, 포트로 구성된 URL의 조합을 의미한다. 예를 들어 “https://example.com:8080/page”와 “https://example.com:8080/another-page”는 같은 출처에 속한다.
  • SOP의 주요 제한 사항
    • 스크립트 실행 제한: 한 출처의 페이지에서 로드된 스크립트가 다른 출처의 페이지와 상호작용할 수 없다.
    • 쿠키 및 헤더 제한: 브라우저는 다른 출처에서 로드된 리소스에 대한 쿠키 및 헤더를 제한한다.
    • XMLHttpRequest와 Fetch API 제한: 브라우저에서 동일 출처 정책을 위반하는 XMLHttpRequest 또는 Fetch API 호출이 차단된다.
• CORS
  • CORS는 다른 출처 간의 리소스 공유를 허용하기 위한 메커니즘이다.
  • SOP의 제한을 완화하여 다른 도메인에서 리소스를 요청하고 응답할 수 있도록 한다.
  • 서버 측에서 특정 HTTP 헤더를 사용하여 브라우저에게 허용된 출처 목록을 알려준다.
  • CORS 작동 과정
    • 요청: 클라이언트가 다른 출처의 리소스 요청
    • 프리플라이트 요청: 브라우저는 실제 요청을 보내기 전에 서버에게 ‘OPTIONS’ 메서드를 사용하여 프리플라이트 요청을 보낸다. 서버는 프리플라이트 요청에 대한 응답으로 어떤 출처에서 요청을 허용할지를 명시한다.
    • 실체 요청: 프리플라이트 요청이 성공하면 실제 요청이 전송된다.
  • CORS 서버 측 설정이 포함할 수 있는 HTTP 헤더
    • Access-Control-Allow-Origin: 어떤 출처에서 요청을 허용할지 지정
    • Access-Control-Allow-Methods: 어떤 HTTP 메서드를 허용할지 지정
    • Access-Control-Allow-Headers: 어떤 HTTP 헤더를 허용할지 지정
    • Access-Control-Allow-Credentials: 쿠키 및 인증 정보를 허용할지 여부를 지정
  • CORS를 사용하여 웹 어플리케이션이 다른 출처의 API 등을 안전하게 활용할 수 있다.

 

 

 

 

---

URL, URI, URN?

• URI (Uniform Resource Identifier) - 통합 자원 식별자
  • URI는 자원을 식별하는 일반적인 개념, 표현.
  • URI는 URL과 URL을 포함하는 상위 개념
• URL (Uniform Resource Locator) - 통합 자원 지시자
  • URL은 Resource(자원)의 정확한 위치 정보(파일의 위치)를 나타냅니다.
  • URL을 통해 Resource가 어디에 있고, 어떻게 접근할 수 있는지 알 수 있다.
  • 예시
    • https://www.naver.com/ - 네이버의 URL
    • https://search.shopping.naver.com/best/today?rankDate=20231206 - 네이버 쇼핑의 오늘의 베스트 카테고리 URL
    • https://www.youtube.com/feed/subscriptions - 유튜브 구독한 목록 URL
  • URL의 구조
    • https://search.shopping.naver.com/best/today?rankDate=20231206
    • scheme: 통신 (방식) 프로토콜 결정. - https://
    • host: 웹 페이지가 위치한 도메인 또는 IP - naver.com
    • query: 리소스 형식 범위를 좁히기 위한 추가 질문 - rankDate=20231206
• URN (Uniform Resource Name)
  • URN은 특정 리소스에 대한 이름을 나타낸다.
  • URN은 리소스의 위치에 상관없이 리소스 ㅈ체를 식별하는 데 사용된다.

 

 

 

 

---

웹 캐시?

• 웹 캐시는 웹 브라우저나 네트워크 인프라에서 사용되는 임시 저장소로, 이전에 검색한 웹 페이지의 일부 또는 전체를 저장하는 역할을 한다.
• 웹 캐시를 사용함으로써 웹 페이지의 로딩 속도를 향상시키고 네트워크 대역폭을 절약할 수 있다.
• 웹 캐시 주요 목적과 동작
  • 로딩 속도 개선
    • 사용자가 이전에 방문한 웹 페이지의 자원(이미지 등)을 로컬에 저장하여, 다음에 같은 페이지를 방문할 때 해당 자원을 서버에서 다시 다운로드하지 않고 로컬에서 불러오게 한다.
    • 이로써 웹 페이지의 로딩 속도가 향상되어 사용자 경험이 개선된다.
  • 대역폭 절약
    • 로컬에 캐시된 자원을 사용하므로 네트워크 대역폭을 절약할 수 있다. 특히, 이전에 다운로드한 자원을 재사용함으로써 네트워크 비용과 시간을 절약할 수 있다.
  • 서버 부하 감소
    • 클라이언트가 캐시를 사용하면 서버는 이전에 전송한 자원을 다시 보낼 필요가 없어져서 서버 부하를 감소시킬 수 있다.
  • 버전 관리
    • 웹 캐시는 자원의 버전을 관리하고 업데이트된 자원이나 새로운 버전이 있을 때만 서버에서 자원을 다시 가져오도록 한다.

 

 

 

 

 

---

프록시?

• 프록시는 클라-서버 간의 중간에서 요청과 응답을 중계하는 서버 또는 소프트웨어이다.
• 프록시 서버는 클라이언트가 서버에 직접 연결하지 않고 간접적으로 통신하도록 하는 역할을 한다.
• 프록시의 주요 용도와 특징
  • 보안 및 개인 정보 보호
    • 클라이언트의 실제 IP주소를 감추어 익명성을 제공하고, 네트워크 트래픽을 암호화하여 보안을 강화할 수 있다.
  • 캐싱
    • 프록시는 이전에 요청한 자원을 캐싱하여 동일한 자원에 대한 요청 시 서버에 직접 요청하지 않고 캐시된 자원을 제공함으로써 성능을 향상시킬 수 있다.
  • 접근 제어 및 필터링
    • 프록시를 사용하여 특정 웹사이트 또는 콘텐츠에 대한 접근을 제어하거나 특정 유형의 콘텐츠를 차단하는 등의 정책을 적용할 수 있다.
  • 로드 밸런싱
    • 여러 서버에 대한 부하를 분산하고 효율적인 서버 관리를 위해 프록시가 로드 밸런싱을 수행할 수 있다.
  • 콘텐츠 필터링
    • 악성 콘텐츠, 광고 등을 필터링하여 클라이언트에게 보다 안전하고 최적화된 콘텐츠를 제공할 수 있다.
• 프록시는 주로 웹에서 사용되지만, 일반적으로 네트워크 통신에서 발생하는 다양한 프로토콜의 중계 및 제어에 사용될 수 있다.
• 프록시는 사용자 컴퓨터에 설정되어 있거나 네트워크 레벨에서 구성될 수 있다.