Peep

스토리지

• 쿠키의 단점을 보완해서 만든 기술이다.
• key, value로 이루어진 데이터 파일이다.
• 서버의 자원이 사용하므로 서버의 공간이 필요하다.
• 기기마다 차이는 있으나 모바일 2.5MB, 데스크탑 5MB~10MB정도 저장 가능하다.
• 쿠키 보다 보안이 우수하며 많은 정보를 담을 수 있다.
• Local Storage, Session Storage로 나뉘며 데이터의 만료에 따라 나뉜다. (사용자가 데이터를 삭제하지 않는 한)
• Local Storage = 만료기한 없음, Session Storage = 세션 종료 시 만료.

데이터의 만료기간이 없으며 사용자가 데이터를 지우지 않은 한 영구적으로 보존된다.
사이트 재 방문시 이전에 저장되었던 정보를 이용 할 수 있어 활용도가 높다.
사용자 설정 저장, 브라우저를 닫고 열었음에도 정보가 남아야 하는 것들을 저장할 때 사용한다.

예시

1. 구글메일에서 오프라인 메일 사용 체크 설정 변경(체크)
www.abcmart.co.kr/abc/order/addCartProducts 통신을 확인해 보면 해당 Cookie 정보 + 아이템 정보(JSON)이 전송되는 것이 확인 된다.

2. 구글메일에서 오프라인 메일 사용 체크 설정 변경
www.abcmart.co.kr/abc/order/addCartProducts 통신을 확인해 보면 해당 Cookie 정보 + 아이템 정보(JSON)이 전송되는 것이 확인 된다.

참고

• https://www.zerocho.com/category/HTML&DOM/post/5918515b1ed39f00182d3048
• https://developer.mozilla.org/ko/docs/Web/API/Window/localStorage
• https://developer.mozilla.org/ko/docs/Web/API/Window/sessionStorage

쿠키(Cookie)

• 클라이언트 로컬(하드)에 저장되는 key, value값이 들어 있는 데이터 파일이다.
• 서버에 저장되는 것이 아니기 때문에 보안과 상관없는 정보들에 사용한다.
• 재 요청 시 저장된 값을 참조, 재사용 한다.
• 사용자의 하드에 저장되기 때문에 공공장소에서 해킹 등의 악용이 가능하다.
• 클라이언트에 300개, 하나의 도메인에 20개의 값만 저장이 되며 하나의 쿠키는 4KB까지 저장 가능하다.
• 이름, 값, 만료 날짜(저장 기간), 경로 정보가 있어야하며 일정시간 동안 데이터를 저장할 수 있다.
• 같은 도메인 상에서 쿠키의 값은 공유된다.
• 클라이언트가 요청하지 않아도 브라우저 요청이 있을 경우 Request Header에 넣어서 자동으로 서버에 전송한다.

예시1

~ 동안 열지 않기
프로세스 추측

1. 3일 동안 열지 않기 클릭
2. 클릭으로 인해 쿠키 저장 이벤트 발생
3. 쿠키 저장 이벤트의 날짜는 3일로 지정되어있으므로 3일간 쿠키가 저장됨.
4. 페이지 재 접속(페이지 요청)시에 쿠키가 저장되어 있다면 팝업 열지 않음

예시2

장바구니 (데이터 확인은 fiddler4)

위의 예시에서는 쿠키만 사용한 것이 아니고 세션스토리지와 같이 사용한 예시이다.

처음 서버에 요청 시 세션 ID를 발급 받아서 (JSESSIONID) 이것을 쿠키에 저장한다,
그리고 다시 접속 할 때 이 쿠키 값을 이용해서 세션 ID값을 서버에 계속해서 전송하는 것이다.
쿠키는 자동으로 전송이 되기 때문에 세션 아이디에 따른 처리를 할 수 있다.

정보 확인 : https://sdevstudy.tistory.com/27

참고

• https://www.zerocho.com/category/HTML&DOM/post/5918515b1ed39f00182d3048
• https://developer.mozilla.org/ko/docs/Web/API/Window/localStorage
• https://developer.mozilla.org/ko/docs/Web/API/Window/sessionStorage

CND이란?

나는 jQuery나 js라이브러리, GoogleFont 등 위주로 많이 들어봤는데, 뭐 남의 서버에 있는거 가져다가 사용하는거 정도로 알고 있었다.

네이버 백과님께 물어봤더니 아래와 같이 답해주시더라.

게임 클라이언트나 콘텐츠를 효율적으로 전달하기 위해 분산된 서버에 데이터를 저장해 사용자에게 전달하는 시스템

즉, 남의 서버에 저장된 콘텐츠를 빌려다가 사용한다는 거다.

근데, 솔직히 말하면 작업할 때, CDN 잘 안쓴다.

왜? 

읽어봅시당 >> https://xetown.com/tips/793706

그렇습니다.

남의 서버를 쓰다보니 서버가 뻑이나면 답이 없습니다.ㅎㅎㅎㅎㅎ

위의 트래픽 폭주에도 안정적인 CDN서비스 라고 적혀있는 것만 봐도, 트래픽이 폭주하면 = 불안정 이라는 거죠..

회사 클라이언트들은 그런거 싫어합니다.

서버가 뻑이나면 서버엔지니어에게 화내고 싶어하지.. CDN 서버에 화를 낼 수 없어요 (GoogleFont ?)

여튼 고려해서 적당----히 씁시다.

책임은 본인들이! 헤헷 (3년 동안 일하면서 단 한차례도 회사에서 cdn 쓴 적이 없지만^^..)

디자인 패턴은 개발 도중 발생한 문제에 대해 정리하여 각 상황에 맞게 쉽고 간편하게 적용해서 사용할 수 있도록 돕기위한 패턴으로, 수단 중에 하나입니다.

MVC 패턴 (Model View Controller)

구성요소를 세가지 역할로 구분한 패턴입니다.

페이지, 데이터 처리, 컨트롤 영역의 3가지 파트를 나누어 담당하게 되면 유지보수성, 확장성, 유연성이 증가합니다.

또한 각 역할의 파트가 정해져있기 때문에 중복코딩이 줄어드므로 효율적입니다.

조작은 Controller로 하며 Model을 통해 데이터를 가져옵니다.

그리고 이것을 바탕으로 View를 제어하여 시각적인 것을 사용자에게 노출합니다.

Model

애플리케이션의 정보들을 나타내며 이러한 데이터들의 가공을 책임지는 컴포넌트입니다.

즉, 내부 비즈니스 로직을 처리하기 위한 역할을 합니다.

View나 Controller에 종속적이면 안됩니다. 즉 Model이 View나 Controller로부터 데이터를 참조해서 데이터를 가공하면 안된다는 것을 의미하며 Model은 재사용이 가능해야합니다.

View

데이터, 객체 입력, 출력을 담당하며 사용자들이 볼 수 있는 화면인 요소(사용자 인터페이스, UI)입니다.

View는 여러개가 존재할 수 있습니다.

Model이 보낸 데이터를 그리기만 해야하며 View에서 따로 저장하면 안됩니다.

즉 해당 데이터 만을 제외하고는 다른 요소를 참조하면 안됩니다.

Controller

데이터 Model과 사용자 인터페이스 View를 연결하는 다리 역할입니다.

화면의 로직을 처리하기 위한 역할을 합니다. (사용자가 데이터를 클릭하거나 수정하거나 등의 이벤트를 담당하는 부분)

사용자의 요청을 받아 처리되는 부분이라서 요청을 분석, Model과 View에 업데이트를 요청합니다.

따라서 Model과 View의 존재를 알고 있어야합니다. (Model과 View 두개가 직접적으로 의존하는 것을 막는 역할)

한계

Controller하나에 다수의 Model, View가 존재하는 경우가 생길 수 있는데, 

이것을 Massive View Controller (대규모 MVC 어플리케이션) 이라고 하며 테스트나 분석이 어렵습니다.

복잡해질 수록 Controller 분리가 어려워서 생기는 문제입니다.

Controller는 프로그램 실행 시 로직이 병렬적으로 분기된다면 하나일 필요가 없으며 여러개를 둬도 상관이 없고 더 깔끔한 설계가 될 수 있습니다.

참조해서 읽어 볼 글

velog.io/@ljinsk3/MVC-%ED%8C%A8%ED%84%B4

https://medium.com/@jang.wangsu/%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-mvc-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80-1d74fac6e256