2021.01.04 일지

0후·2021년 1월 4일
0

비트캠프

목록 보기
54/112

쿠키

  • 클라이언트가 서버에 방문한 정보를 클라이언트 단에 저장하는 작은 파일을 의미한다.
  • 클라이언트의 브라우저 메모리 혹은 하드디스크에 저장이 된다. (↔ 세션)
  • 매번 서버에 전송되므로 크기가 클 경우 서버에 부담이 갈 수 있다.
  • SameSite 옵션이 Strict가 아닌 경우, 다른 도메인에서 요청할 때도 자동 전송되는 위험성이 있다. (CSRF 취약)
  • 대략 4KB까지의 데이터를 저장할 수 있으며 유효 기간이 존재한다.
  • 대부분의 브라우저가 지원한다.

웹스토리지

  • 클라이언트에 데이터를 저장할 수 있도록 HTML5부터 새롭게 지원하는 저장소이다.
  • 키(Key)와 값(Value)의 쌍 형태로 데이터를 저장한다.
  • 쿠키와 달리, 서버에 전송되지 않으므로 서버에 부담이 가지 않는다. (명시적으로만 전송 가능)
  • 쿠키와 달리, 필요한 경우에만 꺼내 쓰는 것이므로 자동 전송의 위험성이 없다. 다른 도메인에서 요청하는 경우에는, 꺼내 쓰고 싶어도 도메인 단위로 접근이 제한되는 특성 덕분에 값을 꺼내 쓸 수 없다. (CSRF 안전)
  • 쿠키와 달리, 대략 5MB까지의 데이터를 저장할 수 있으며 유효 기간이 존재하지 않는다.
  • HTML5를 지원하지 않는 브라우저에서는 사용할 수 없다.
  • 종류로는 로컬 스토리지(Local Storage)와 세션 스토리지(Session Storage)가 있다. 이들은 window 객체의 프로퍼티로서 존재하며, 같은 Storage 객체를 상속하기 때문에 동일한 메소드들을 가진다. 이 둘의 가장 큰 차이점은 데이터의 영구성이다.

로컬스토리지

  • window.localStorage 객체
  • 브라우저를 종료해도 유지되는 데이터로, 명시적으로 지우지 않는 한 영구적으로 저장된다.
  • 도메인별로 생성되며, 다른 도메인의 로컬 스토리지에는 접근이 불가능하다.
  • 서로 다른 브라우저 탭이라도 동일한 도메인이라면 동일한 로컬 스토리지를 사용한다.
  • 지속적으로 필요한 정보를 저장하기에 좋다. (ex. 자동 로그인 등)

세션스토리지

  • window.sessionStorage 객체
  • 세션 쿠키와 달리, 탭/윈도우 단위로 세션 스토리지가 생성된다. 즉 window 객체와 동일한 유효 범위 및 생존 기간을 가지며, 탭/윈도우를 닫을 시 데이터가 삭제된다. 또한 동일한 탭/윈도우라도 다른 도메인이라면 또 다른 세션 스토리지가 생성된다.
  • 서로 다른 세션 스토리지는 서로 영향을 주지 않으며 독립적으로 동작한다.
  • 윈도우 복제로 생성된 경우, 혹은 스크립트로 새 창을 연 경우 세션 스토리지가 복제되어 생성된다.
  • 잠시 동안 필요한 정보를 저장하기에 좋다. (ex. 입력 폼 저장, 일회성 로그인 등)

쿠키와 세션

(1) 쿠키
   1) 설명 : 클라이언트측에 저장되는 서버측 정보(부스러기)
   2) 제한 크기 : 4KB 이하 제한/(사이트)
   3) 제한 갯수 : 3004) 최대로 저장 가능한 쿠키의 용량 : 1.2 MB
   5) 종류 
	   <1> 클라이언트의 하드 디스크에 저장되는 쿠키(파일)
	   <2> 클라이언트의 메모리에 존재하는 쿠키 
		  ( 브라우져가 열려져 있을 때까지만 존재 )
		  1> JSessionID
		  2> setMaxAge(0 || 음수) -> (MaxAge 기본값 -1)

   6) 주의 
	   <1> 한글이 지원 안된다.
	   <2> MaxAge 가 지났을 때, 하드의 파일에는 지워지지 않지만
		  CookieGet.jsp를 실행하게 되면 MaxAge가 지난 Cookie는 
		  검출되지 않는다.

(2) 세션 
    1) 설명 : HTTP 프로토콜은 무상태(stateless)프로토콜
	            이기때문에 상태를 유지할 수 없다.
	            세션이라는 기술은 그 상태 정보를 유지할 수 있도록 
	            만들어진 "기술"이다.
	            ex) 쇼핑몰의 장바구니, 로그인, ...

   2) 원리 : 클라이언트의 첫번째 요청에 의해서 서버측 
	           메모리에는 JSessionId라는 ID로 해당 클라이언트를 
	           위한 방(공간)이 만들어지고, 첫번째 답변으로 그 
	           JSessionId를 쿠키 형태로 클라이언트에게 전달한다.

	           다음 요청부터는 클라이언트가 JSessionId을 가지고 
	           서버에게 요청함으로써 서버는 그 클라이언트를 식별 
	           할 수 있고, 그 클라이언트의 방을 공유할 수 있게 한다.
	           따라서, 그 방에 있는 객체(세션변수값==세션속성값)들로
	           상태정보를 유지 할 수 있는 것이다.

    3) 주의
	         같은 서버에서는 하나의 클라이언트의 브라우져에 대해서
	         WebApplication(Context)마다 JSessionId가 따로 생성된다.
	         ex) Tomcat 서버 

	       cf1) 위의 사항은 서버마다 차이가 있을 수 있다. 
	       cf2) 증명( 같은 브라우져에서 ) 
		    [1] NewContext WebApp 호출 
			http://~/nc/JSP/mutiAppSession/multiApp.jsp
			 -> jsId : 6B7800F047F22D76CC261C87575EFC06

		    [2] Root WebApp 호출
			http://~/JSP/mutiAppSession/multiApp.jsp
			 -> jsId : B7E6A183517F3B54B89967F316C2CA83 
profile
휘발방지

0개의 댓글