localStorage 대 sessionStorage 대 쿠키 – 자세한 비교

쿠키는 오랫동안 우리와 함께 해왔습니다(Internet Explorer v2는 1995년 10월에 쿠키를 지원했습니다). 그들에게는 아무런 문제가 없었고 확실히 웹을 더 즐거운 곳으로 만들었지만 거의 25년 후에 많은 것이 바뀌었습니다.

Local Storage(W3의 Web Storage에서 찾을 수 있음)는 쿠키를 대체하는 기능이 아닙니다. 그게 가장 혼란스럽습니다. 대부분의 경우 쿠키 대신 localStorage를 안전하게 사용할 수 있으며 쿠키가 동일하지만 그렇지 않다는 (잘못된) 인상을 받을 수 있습니다. localStorage를 사용하여 쿠키를 대체하는 방법과 시기에 대한 말도 안되는 분석을 보려면 계속 읽으십시오.

혁명인가 진화인가?

로컬 스토리지, localStorage, DOM 스토리지 또는 웹 스토리지(이러한 이름을 짓는 것이 아닙니다. 모두 사용 중이며 모두 동일한 것을 참조합니다)는 2012년에 "HTML5 특징". 그것은 쿠키를 대신할 신의 선물처럼 보였습니다. 항상 불필요한 데이터를 전송하는 부풀려진 요청에 대한 수정 및 크기 제한. 이러한 문제를 "해결"하기는 하지만 쿠키에 대한 사과 대 사과는 아닙니다.

그리고 우리는 불필요한 데이터의 주제에 대해 이야기하고 있습니다. 요청이 불필요한 팽창을 일으킬 수 있는 유일한 것이 아니라 귀하의 사이트도 그럴 수 있다는 것을 알고 계셨습니까? 운 좋게도 해결 방법이 있으며 WP 재설정이라고 합니다.

WP Reset은 축적된 데이터 및/또는 추가 기능(플러그인, 테마, 사용자, 위젯, 콘텐츠 등)을 사이트에서 제거하고 전체 사이트를 깨끗하게 닦을 수도 있습니다. 놀랍죠? 하지만 그게 다가 아닙니다. 다른 기능들 중에서 이 플러그인은 데이터베이스 스냅샷을 생성할 수 있을 뿐만 아니라 필요한 만큼 클릭으로 설치할 수 있는 플러그인 및 테마 컬렉션을 생성할 수 있습니다. 확실히 체크아웃할 가치가 있는 도구입니다.

하지만 이제 localStorage에 대해 다시 이야기해 보겠습니다.

이름에서 알 수 있듯이 데이터는 사용자의 장치에 로컬로 저장됩니다. 따라서 모든 HTTP 요청으로 네트워크를 통해 전송할 필요가 없으며 공간을 줄이고 데이터를 저장할 수 있는 더 많은 공간을 제공합니다. 그 "로컬 전용" 패러다임은 쿠키와 로컬 저장소 간의 가장 중요한 차이점입니다. 쿠키는 서버 측과 클라이언트 측 모두에서 읽을 수 있으며 로컬 저장소는 클라이언트 측에서만 읽을 수 있습니다. 그게 전부입니다. 앱이 서버 측 쿠키를 읽고 이를 기반으로 콘텐츠를 생성하는 데 크게 의존하는 경우 로컬 저장소로 전환하면 앱을 다시 작성하게 됩니다. 인터페이스에서 활성화된 탭과 같은 설정을 저장하기 위해 쿠키만 사용하는 경우 로컬 저장소가 이상적인 대안입니다.

믿을 수 없을 정도로 유사

아래 표는 쿠키, localStorage 및 sessionStorage의 차이점과 사용 사례에 대한 명확한 통찰력을 제공합니다. 필요한 답변을 얻기 위해 빠르게 살펴보고 떠날 수 있지만 더 자세한 내용으로 들어가는 다소 긴 각주를 읽는 것이 좋습니다. 네, 바쁘셔서 다음 고양이 영상을 보고 싶은 건 알지만, 상황이 흑백이 아니므로 조금 더 깊이 파보시면 좋을 것 같습니다.

웹 스토리지 및 쿠키 자세히 알아보기

로컬에 저장할 수 있는 최대 데이터 양은 브라우저에 따라 다릅니다. 보장은 없으며 안전한 베팅을 원하시면 5MB 미만에서 약 2MB로 이동하십시오. 이 편리한 도구를 사용하여 브라우저에서 허용되는 최대 로컬 스토리지 크기를 테스트하십시오.

사용자가 타사 또는 모든 쿠키를 차단 하는 것은 일반적인 시나리오입니다. 로컬 스토리지에도 동일한 규칙이 적용됩니다. 보장은 없으며 앱은 로컬 저장소를 사용할 수 없는 환경에서 작동해야 합니다(또는 최소한 중단되지 않아야 함).

모든 쿠키는 어느 시점에서 만료 되지만 사람들은 인터넷 시간으로 영원히 보이는 몇 년으로 수명을 설정하는 경향이 있습니다. 반면 로컬 저장소는 만료되지 않으며 앱이나 사용자가 삭제할 때까지 사용할 수 있습니다. 탭이나 창이 닫히면 세션 저장소가 제거됩니다. 예외는 없습니다.

“ 문자열만 저장할 수 있다는 게 무슨 말씀이세요? 나는 항상 물건을 저장합니다!” JSON을 사용하면 객체 및 기타 데이터 유형을 문자열 형식으로 저장할 수 있습니다. 변환은 사용자가 모르는 사이에 읽고 쓸 때 이루어집니다. 쿠키 및 로컬 저장소를 처리하기 위한 사운드 라이브러리를 사용하면 데이터 유형에 대해 생각할 필요가 없습니다. 그러나 문자열만 기본적으로 지원된다는 사실은 변경되지 않습니다.

모든 브라우저가 지원하는 단일 클라이언트 측 기능은 없습니다. 안타까운 사실이지만 여전히 사실입니다. Can I Use에서 특정 숫자를 확인할 수 있지만 쿠키와 로컬 저장소가 있는 한 이를 지원하지 않는 모든 브라우저는 무시하겠습니다. 그들은 미미하고 1% 미만입니다.

서버 측 처리를 통해서만 localStorage에 액세스할 수 없습니다. JS도 필요합니다. 사용자가 페이지를 요청하고 PHP가 페이지를 생성하기 위해(또는 사용하는 모든 서버 측 언어) 시작되면 세션 또는 영구 데이터에 액세스할 수 없습니다. 페이지가 로드되고 JS가 실행되면 로컬 데이터에 액세스하고 필요한 모든 작업을 수행할 수 있습니다. 사용자 인터페이스를 조정하거나 AJAX를 사용하여 로컬 데이터를 서버로 다시 보낼 수 있습니다. 예, 로컬 데이터를 서버로 다시 가져올 수 있지만 쿠키를 사용하는 것과 같은 방식으로 같은 순간에 얻을 수는 없습니다. 귀하의 요구 사항에 따라 쿠키에서 로컬 저장소로 전환할 때 거래 차단기가 될 수 있으므로 미리 계획하십시오!

로컬 저장소를 사용 하면 클라이언트와 서버 간에 데이터가 전송되지 않습니다 (명시적으로 그렇게 하는 코드가 없는 경우). 페이로드 크기를 줄이는 데 좋습니다. 반면 쿠키는 설정된 도메인에 대한 모든 요청과 함께 HTTP 헤더 필드로 전송됩니다. 이는 변경하거나 선택적으로 끌 수 없습니다.

사용자는 로컬 데이터에 액세스하여 직접(앱 외부에서) 변경해서는 안 되지만 그렇게 하는 데 방해가 되는 것은 없습니다. 로컬에 저장된 데이터를 편집하는 데 사용할 수 있는 다양한 디버깅 도구가 있습니다. 따라서 로컬 데이터를 신뢰하거나 사용자가 데이터를 만지지 않았다고 가정하지 마십시오. 항상 더 나쁜 것을 가정하십시오.

쿠키에는 설정할 수 있는 "보안" 속성 이 있지만 애플리케이션에서 브라우저로 전송되는 쿠키를 보호하지는 않습니다. 따라서 보안과는 거리가 멀지만 없는 것보다 낫습니다. 클라이언트 측 전용 기술인 로컬 저장소는 HTTP 또는 HTTPS를 사용하는지 여부를 알지 못하거나 신경 쓰지 않습니다. 보안은 데이터를 처리하는 방식에서 출발해야 ​​합니다. 신용 카드 번호 또는 비밀번호와 같은 민감한 데이터를 어떤 형태의 로컬 저장소에도 저장하지 마십시오! 항상!

시작하기 위한 약간의 코드

이 기사는 JavaScript 웹 저장소 자습서가 아니라 문제를 해결하기 위해 여기에 로컬 저장소가 있는 Hello World 예제가 있습니다.

// store a value
localStorage.setItem( 'name', 'John' );

// retrieve a value
localStorage.getItem( 'name' );

// remove the value
localStorage.removeItem( 'name' );

// only string values can be stored so for objects, use JSON
var post = {
  title: 'Cookies are old',
  author: 'Gordan'
}
localStorage.setItem( 'post', JSON.stringify( post ) );

// and to retrieve
var post = JSON.parse( localStorage.getItem( 'post' ) );

위의 코드는 작동하며 가능한 한 간단합니다. 그러나 사용을 권장하지 않습니다. 쿠키와 마찬가지로 아무도 document.cookies 를 사용하여 쿠키와 상호 작용하지 않습니다. 고려해야 할 브라우저 간 약간의 차이가 있으며 문자열만 저장하기 때문에 모든 읽기 및 쓰기에서 문자열화하고 JSON으로 구문 분석해야 합니다. 이것이 우리가 js-cookie와 같은 쿠키를 처리하는 데 도움이 되도록 작은 라이브러리를 사용하는 이유입니다. 로컬 스토리지도 마찬가지입니다. 코드와 API 사이에 작은 추상화 계층을 배치하면 장기적으로 도움이 될 것입니다. store.js를 추천합니다. 그것은 잠시 동안 주변에 있었고, 브라우저 간 넌센스와 폴백을 처리하고 기능을 확장하는 편리한 플러그인도 있습니다. 코딩 실습에 관심이 있다면 자신의 라이브러리를 만들고 jQuery 플러그인으로 변환하십시오.

쿠키는 나쁘다, 그렇지? 우리는 새로운 것이 필요합니다!

쿠키는 나쁘지 않습니다. 그들은 수십 년 동안 그들의 목적을 수행해 왔으며 지역 저장고가 "사과를 위한 사과" 대체품이 아니기 때문에 계속 그렇게 할 것입니다. 그러나 쿠키는 노화의 징후를 보이고 있습니다. 그 외에도 설계상의 단점 중 일부는 곧 사라지지 않습니다. 즉, 쿠키 페이로드와 작은 최대 페이로드 크기로 도메인의 모든 요청을 "오염"시킵니다.

부적절하고 오래되든 그렇지 않든 쿠키는 계속 존재하므로 로컬 저장소가 조만간 완전히 인수될 것이라고 생각하지 마십시오. 그러나 일부 사용 사례에서는 의심할 여지 없이 로컬 스토리지가 더 나은 선택입니다.

서버에 거의 전송되지 않는 클라이언트 측에 저장할 데이터가 많고 해당 데이터에 민감한 정보가 포함되어 있지 않은 경우 - 로컬 스토리지 사용을 시작 하십시오! 그것은 바로 그것을 위해 만들어졌습니다. 도메인의 모든 HTTP 요청을 더 가볍게 만들어 더 빠른 앱을 만들고 새로운 것을 사용하는 따뜻한 퍼지 느낌을 얻을 수 있습니다.