초창기 웹사이트
초창기 웹은 단순 정보 제공용 웹사이트임
초창기 웹은 웹을 프로그램이라고 취급하지도 않았음
웹 브라우저의 장점
웹 브라우저는 htp를 준수하기 때문에 웹 브라우저를 주요 프로그램으로 쓰려고 함
웹 개발이 갖는 장점은 개발 대비 웹 개발이 갖는 장점은 개발이 쉽고 수많은 os 문제로부터 자유롭고 고객이 업데이트를 할 필요가 없음
쿠키의 개념
웹사이트를 통해서 단순한 정보 제공용을 넘어서 회원마다 다른 권한을 가지는 복잡한 프로그램을 하고 싶음
서버가 브라우저들을 구분할 수 있어야 할까 없어야 할까 물음
쿠키는 서버가 브라우저들을 구분할 수 없을 때 뒤늦게 추가된 개념임
쿠키의 장점
쿠키는 종이 쿠폰으로 서버가 기억하기 힘들고 클라이언트가 기억해야 함
인증은 두 가지로 이루어져 있는데 인증을 확인하는 행위와 인증서 발급임
인증을 확인하는 행위는 db를 조회해 보는 것임
웹 서버의 인증서 발급
웹 서버와 손님이 브라우저인 경우 서버인 우리가 브라우저를 기억하는 게 맞는지 아니면 손님한테 인증서를 발급해 주는 게 맞는지 물음
학생이 1명 2명 3명 4명 5명 6명 늘어나면 증서를 보여줘야 하기 때문에 증서를 발급해 줘야 함
브라우저의 기억 방식
브라우저가 특정 회원의 사용자가 특정 회원이라는 것을 기억하는 방식은 두 가지가 있음
서버가 껐다 켜지기라도 하면 정보가 다 날아가기 때문에 주의를 해야 함
리퀘스트 객체와 리스폰스 객체가 생성됐다는 것은 b가 요청을 보냈다는 것임
리스폰스 객체의 역할
리퀘스트는 보낸 편지의 내용이 그대로 정리돼서 들어가는 것임
리스폰스 객체는 요청이 오면 응답을 준비하기 위해서 만드는 것임
쿠키는 하나의 쿠폰으로 고객이 사이트에 갈 때 자동으로 가지고 가고 올 때 자동으로 가지고 옴
웹 서버와 웹브라우저의 역할
요청을 하면 응답을 받는 건 웹 서버랑 웹브라우저가 알아서 다 해놨음
고객이 어디 있는지 찾을 필요 없고 누구한테 하면 됨
실시간으로 고객이 볼 수 없음
쿠키는 도메인을 안 적어서 안 보이는 것임
서버 저장 방식의 개선 필요성
세션 저장 방식의 개선 방안
세션 스토리지의 필요성과 구현 방안
다음 할 일
회원별 사물함 매칭 방법 개발
세션 스토리지 구성 방법 검토
세션 스토리지에 방 번호 부여 방법 개발
요약
커피숍 쿠폰 폐지 논란
손님들이 더 많아졌는데 매출하고 커피 계산을 확인해 보니까 희한하게 들어오는 돈보다 커피가 더 많이 나감
도장 전문가가 커피 하나 사 먹고서 도장을 정교하게 만들어가지고 다 찍어버림
쿠폰을 아예 폐지할까요 어떻게 해야 될까요 개발이라 생각하지 말고 한번 생각해 보라고 함
웹 애플리케이션 서버의 역할
서버에 저장하는 방식으로 바뀌어야 함
대부분의 현대 어플리케이션은 서버가 두 군데로 나눠져 있음
웹 서버는 대외적인 업무를 해주고 웹 애플리케이션 서버는 직접 응답을 해줌
스프링 부트의 특징
스프링 부트는 웹 서버가 아님
보통 통신하려면 웹 서버랑 웹 애플리케이션 서버가 2개가 있어야 되는데 스프링 부트는 얘에 가깝고 와스를 4장을 하고 있음
순수 http로는 한계가 있는데 우리는 뭐예요 그 http를 준수하는 웹 서버 뒤에 스프링 부트가 버티고 있어서 http 이상의 것을 할 수 있음
세션은 서버가 기억력을 갖는 것으로 쿠키의 반대 개념임
서버의 고민
서버가 웹 서버를 기억하고 싶어 세션을 운영했는데 저장할 수 있는 능력은 구비했지만 문제는 손님에 대한 방도 만들어졌음
서버가 기억을 못하는 게 아니라 구분할 방법이 없음
서버가 각각의 회원마다 회원의 사물함을 만들어놨는데 매칭할 방법이 없음
웹 서버의 기억력
웹 서버로는 서버의 기억력이 제로임
와스를 붙이면 안에 거대한 세션 저장소를 둘 수 있음
세션으로 바꾸고서 설명을 한 번 드리겠음
쿠키를 셀 쿠키를 몇 번 하라고 날아와 있음
세션 스토리지의 방 번호
세션 스토리지에 브라우저마다 방이 있어야 함
세션 스토리지에 방 번호를 알아 찾아가야 함
세션 삭제
세션에 값이 없으면 롱으로 형분환해서 다시 하고 세션을 뒤져봐서 값이 없으면 세션을 삭제함
세션을 삭제하면 세션의 키가 있어야 하는데 세션의 키가 없으면 세션을 통째로 날려버린 것임
주요 주제
summary score펼침
쿠키와 서버 간의 관계
타임 리프와 html 생성기의 역할
서버와 브라우저 간의 데이터 공유 방법
다음 할 일
summary score펼침
쿠키 리스폰스 객체에 저장하여 고객 전달 방법 검토
타임 리프 실행 결과 html 생성기 연결 구문 검토
요약
쿠키의 정의
쿠키는 주인이 가지고 있거나 고객들이 자기 쿠폰을 가지고 다님
브라우저는 서버와 쿠키 저장소가 있음
쿠키는 3개라고 생각하고 변수라고 생각하면 됨
로그인 버튼을 눌렀을 때 정보가 총 5개가 날아감
서버가 원하는 것은 인증서를 하나 만들어서 가지고 있게 하는 것임
쿠키의 정의
쿠키는 서버에서 만드는 것으로 실질적으로 쿠키일까 지시문일까에 대해 물음
서버에서 만든 쿠키는 진짜 쿠키일까 지시문일까에 대해 물음
쿠키의 정의
쿠키가 없으면 요청이 안 감
쿠키가 있으면 서버가 브라우저에게 보내는 쿠키 조작 지시문이 담김
애플리케이션에 쿠키를 보면 됨
도메인에 대한 쿠키
도메인에 접속할 때는 도메인에 대한 쿠키가 날아감
도메인에 대한 요청이 뒤에가 뭐든 쿠키는 날아감
도메인은 따로 있음
쿠키는 적을수록 좋음
타임 리프 결과물
쿠키를 리스폰스 객체에 담는 이유는 고객한테 전달이 돼야 하기 때문임
타임 리프 결과물이 실리는 건 아니고 타임 리프가 실행된 결과물 html이 실리는 것임
타임 리프 결과물을 고객한테 알려주는 방법은 두 가지가 있음
타임 리프의 역할
타임 리프는 html 생성기라고 말씀드림
타임 리프가 서버에서 실행이 되면 html 생성기가 생성된 html이 리스폰스에 실림
타임 리프의 결과물이 고객 브라우저에 보여줌
스프링 부트가 리스폰스 객체를 구해서 타임 리프를 실행한 다음에 연결하는 구문을 직접 쓰실래요 아니면 규칙을 정해서 액션 메서드가 리스폰스 바디 없이 실행을 하면은 타임 리프가 실행이 되고 그 결과가 리스폰스에 담겨서 나간다라는 룰을 정한 다음에 스프링 부트가 실행하게 하시겠어요? 당연히 스프링 부트가 실행하게 하겠죠 네 그래서 이 두 가지를 기억하시면 됨
리스폰스는 응답에 대한 모든 것이라고 보면 됨
쿠키의 정의
쿠키는 브라우저랑 서버랑 공유하는 데이터임
무조건 2번은 아님
쿠키는 문자열밖에 없어서 문자열로 써야 되기 때문에 여기다 붙여가지고 문자열화해서 저장을 함
유저 네임으로 로그인 멤버의 아이디가 아니라 유저 네임으로 해보겠음
타임 리프의 멤버 서비스
타임 리프에서 회원 객체를 얻으려면 멤버 서비스가 필요함
멤버 서비스가 필요하면 이렇게 하면 됨
옛날에는 필요할 때마다 뉴를 했지만 지금은 한 번 만들어진 멤버 서비스가 공유가 돼서 아무 낭비 없이 쓸 수 있음
쿠키의 정의
서버에 요청을 보낼 때 추가적인 파라미터를 보내지 않음
서버에 데이터를 보낼 때 파라미터와 쿠키를 보냄
쿠키는 리퀘스트에서 얻어야 함
옵셔널의 개념
옵셔널에는 데이터가 있을 수도 있고 없을 수도 있음
옵셔널은 옵션 론이 따로 있음
옵셔널 롱은 따로 타입이 있음
옵셔널은 널이 아닐 때만 값으로 떨어짐
서버는 금붕어보다 기억력이 없음
