[Network] 7. HTTP 특징과 데이터 저장 방식

[그림으로 쉽게 이해하는 웹/HTTP/네트워크를 읽고 정리합니다.]

 

HTTP = Statelss protocol

HTTP는 이전 요청과 응답에 대한 정보를 서버에서 따로 저장하지 않는 무상태 프로토콜이다.

어떤 상태든 상태와 관계없이 지금 들어온 요청에 대한 응답만을 수행하기 때문에 모든 응답과 요청은 독립적이다.

무상태 프로토콜로는 HTTP, IP, UDP가 대표적이다.

 

반대로 상태 프로토콜도 존재한다.

상태 정보를 저장하는 프로토콜로, 상태에 따라 서버의 응답이 달라질 수 있다.

각 패킷의 전송 상태를 파악하고 신뢰성을 보장하는 TCP가 대표적이다.

 

무상태 프로토콜의 장점은 서버의 상태를 고려할 필요가 없어 서버를 단순하게 설계할 수 있고,

통신이 갑자기 끊어졌을 때 남겨진 상태를 어떻게 처리해야 할지 고민할 필요가 없다는 점이다.

 

반면 상태가 필요한 상황에서 요청할 때마다 추가 정보를 전달해야 하는 번거로움이 있는게 단점인데,

예컨대 로그인을 한 후 장바구니에 저장할 때 로그인 상태를 저장하지 않아 뭘 할 때마다 로그인을 해야 하는 것이다.

 

이런 번거로움을 해소하기 위해 외부에 따로 저장소를 둬 여기서 상태를 저장하고,

필요에 따라 서버에 상태를 저장하는 방식을 사용하고 있다.

 

이러한 상태 저장 방식에는 쿠키, 웹 스토리지, Indexed DB가 있다.

---

쿠키

쿠키는 브라우저에서 데이터를 저장하는 방식 중 하나로,

1994년 웹 브라우저 기업 넷스케이프의 개발자 루 몬툴리가 발명한 기술이다.

 

일반적으로 데이터는 데이터베이스에 저장되지만,

[팝업 오늘 보지 않기]나 [다크모드 유지] 같은 데이터를 모두 데이터베이스에 저장한다면 어떻게 될까?

 

이러한 데이터는 하루, 또는 수시로 들어올 텐데 100만, 1000만 유저들의 데이터를 모두 데이터베이스가 관리하게 된다면

서버에 부담이 갈 수 밖에 없고, 속도가 느려지고, 비용이 많이 들 수밖에 없다.

 

그래서 이러한 데이터를 각 사용자의 브라우저가 갖게 한다면

브라우저에서 값을 바로 받아오기에 속도도 빠르고 서버 비용도 절감할 수 있게 된다.

 

그래서 클라이언트(브라우저)에서 해당 웹 사이트의 데이터를 저장하고자 하는 수요가 생겼고,

그로 인해 쿠키와 같은 클라이언트 기반 저장소(client-side storage)가 생기게 됐다.

 

• 쿠키의 데이터는 키/값의 형태로 되어 있으며 문자열 형식만 저장할 수 있다.
• 한 개의 키에 최대 4KB까지 저장할 수 있다.
• 이름, 값 외에도 만료 기간, HTTP 통신에서만 접근할 수 있는지(HttpOnly) 등 다양한 정보를 확인할 수 있다.
• 세션 쿠키는 만료 기간이 따로 정해지지 않아 브라우저가 종료될 때 같이 사라진다.
• 영구 쿠키는 만료 기간이 존재해 해당 기간이 끝나면 삭제된다.

쿠키는 HTTP 통신 중 서버에서 클라이언트로 응답할 때 쿠키 정보를 함께 전송한다.

응답 메세지 안에 Set-Cookie 헤더를 추가하고 브라우저에 저장할 쿠키의 이름과 값을 넣어주면 된다.

응답을 받은 클라이언트는 쿠키 정보를 브라우저 공간에 저장하고, 이후 클라이언트 -> 서버의 모든 요청에 쿠키를 담아 전달하게 된다.

서버는 이렇게 요청 메세지의 쿠키 정보를 확인해 사용자를 식별, 적절한 데이터를 보내주게 된다.

 

단, 쿠키는 보안에 취약해 누구나 쉽게 접근 및 조작할 수 있어 탈취되거나 변조될 위험이 크다.

또 모든 요청마다 쿠키 정보가 함께 전송되기에 데이터의 양이 더 커져 웹 통신의 성능이 떨어지는 원인이 되기도 한다.

더불어 사용자의 활동 기록을 추적해 개인 정보를 침해한다는 문제점이 있다.

 

쿠키는 유저가 방문한 웹 사이트에서 직접 발행하는 퍼스트 파티 쿠키(웹 사이트 주소와 같은 도메인)와,

제 3자가 발행하는 서드 파티 쿠키(웹 사이트 주소와 다른 도메인)로 나뉜다.

 

이 서드 파티 쿠키는 유저로부터 충분한 동의 없이 웹 브라우징 활동을 추적해 표적 광고에 이용하기 때문에 논란의 여지가 있다.

따라서 현재 많은 브라우저에서 서브 파티 쿠키 지원을 중단하고 있다.

---

웹 스토리지(Web storage)

HTML5(2014) 이전까지 클라이언트 기반 저장소는 쿠키가 유일했지만,

HTML5와 함께 웹 스토리지, 이후 IndexedDB가 등장하면서 개발자들은 니즈에 맞는 방식을 선택할 수 있게 됐다.

 

웹 스토리지는 쿠키와 비슷하지만 약간의 차이점이 있다.

• 키/값으로 데이터를 저장하고 문자열만 저장할 수 있는 점은 쿠키와 동일하다.
• 쿠키(4KB)에 비해 5MB ~ 10MB까지 저장할 수 있다.
• 쿠키에 클라이언트/서버 모두 접근할 수 있다면 웹 스토리지는 클라이언트만 접근할 수 있다.
• 쿠키는 설정 후 HTTP 헤더에 담겨 서버로 전송되지만 웹 스토리지는 따로 전송하지 않아도 돼 통신량이 줄어든다.

웹 스토리지는 로컬 스토리지, 세션 스토리지로 나뉜다.

 

로컬 스토리지는 한 번 브라우저에 저장되면 의도적으로 삭제하지 않는 이상 데이터가 유지된다.

세션 스토리지는 클라이언트와 서버의 연결이 끊어지면 데이터도 같이 삭제된다. (세션은 브라우저의 탭을 기준으로 함)

 

따라서 로컬 스토리지에는 자동 로그인이나 다크모드 같이 계속 지속해서 사용하는 데이터를 저장하고,

세션 스토리지에는 일회성으로 잠깐 필요한 정보들을 저장한다.

 

웹 스토리지는 JS 코드로만 접근할 수 있으며,

데이터를 추가할 때는 setItem('key', 'value) 메서드로 추가하고,

데이터를 삭제할 때는 removeItem('key') 메서드로 삭제하거나 clear() 메서드로 리셋하고,

데이터를 가져올 때는 getItem('key', 'value') 메서드로 아이템을 조회할 수 있다.

 

+) 버전에 따라 미지원하는 경우도 있어 에러 처리가 필요하다. (ex. 사파리 시크릿 모드)

---

Indexed DB

Indexed DB는 브라우저에 내장된 데이터베이스로 웹 스토리지보다 더 강력하게 데이터를 저장한다.

 

쿠키나 웹 스토리지가 문자열 형태의 데이터만 저장할 수 있는 반면, Indexed DB는 더 다양한 타입의 데이터를 저장한다.

특히 용량 제한이 특별히 없어 저장할 수 있는 데이터의 크기도 크고, 데이터 조회를 용이하게 해 많은 양의 데이터를 체계적으로 관리한다.

쿠키나 웹 스토리지는 반드시 키로 값을 조회할 수 있었는데, Indexed DB는 cursor 개념을 이용해 쉽게 전체 데이터를 조회한다.

(테이블이나 객체 저장소를 사용해 데이터를 구조화하고, 쿼리할 수 있다.)

 

JS로 조작할 수 있지만 유사 데이터베이스를 생성하는 일이기 때문에 쿠키나 웹 스토리지보다 복잡하다.

보통 데이터베이스에는 실제 데이터를 담는 객체 저장소가 있는데, 여기에 데이터를 저장한다.

 

또 비동기적으로 작업하며, 데이터베이스 작업이 이벤트 기반으로 처리되기 때문에

웹의 응답성을 유지하는데에 도움이 된다. (쿠키나 웹 스토리지는 동기적으로 작동해 블로킹 작업이 발생할 수 있음)

 

*참고

https://kangdanne.tistory.com/197

[WEB] 웹 저장소 - 쿠키/로컬스토리지/세션스토리지

---

세션

브라우저의 데이터는 다른 사람들이 쉽게 접근할 수 있어 여러 웹 공격에 노출될 위험이 있는데,

이를 세션으로 보완할 수 있다.

 

세션은 서버에서 일시적으로 데이터를 저장하는 기술이다. (클라이언트/서버가 연결된 상태로도 쓰이지만 여기서도 동명이 쓰임)

 

세션의 동작 과정은 아래와 같다.

 

1. 로그인 성공 후 클라이언트 -> 서버에게 회원 정보 전달

2. 서버는 요청을 보낸 클라이언트의 접근 이력을 확인하고, 없다면 고유값인 세션 ID를 발급해 데이터베이스에 저장

3. 서버 -> 클라이언트로 요청에 대한 응답과 세션 ID 전달

4. 클라이언트는 세션 ID를 나중에도 쓸 수 있게 쿠키에 저장

 

세션이 실제 서비스에 사용되는 과정은 아래와 같다.

 

1. 유저가 장바구니 화면을 요청

2. 클라이언트는 해당 요청과 저장해둔 쿠키 안의 세션 ID를 서버에게 전달

3. 서버는 데이터베이스에서 해당 세션 ID에 부합하는 클라이언트를 확인, 있다면 장바구니 화면을 응답 데이터로 전송

4. 클라이언트는 응답 받은 정보를 화면에 그리고 유저는 그 화면을 봄

 

세션은 정보를 서버에서 관리하기 때문에 쿠키만 사용했을 때보다 보안이 우수하고,

클라이언트별로 고유 ID인 세션 ID를 부여해 관리하기에 맞춤형 서비스를 제공할 수도 있다.

 

다만 세션은 서버에서 데이터를 저장하는 것이기 때문에

유저가 많아지면 서버의 부담도 커지고, 브라우저에서 바로 제공하는 것보다 속도가 느릴 수 있다.

따라서 로그인 정보처럼 브라우저에 저장하기엔 민감하고 보안상 중요한 것들을 세션에 저장해 사용하는 것이 좋다.