배움 __IL/TIL 1기

TIL : 54번째- 230220 [2-3-월]

Mo_bi!e 2023. 2. 20. 18:28

I. 프로젝트

1.  피드백

 

 

 

II. 웹개발

1. 들어가며

1)

왜 분리하려고 함? 프론트컨트롤러 두면 그냥 컨트롤러는 순수 자바로 두고 싶어서

매개변수로 입력을 받고, 리턴으로 출력하는 함수형태를 받고 싶어함

 

즉 프론트컨트롤러는 서블릿 / 컨트롤러는 순수자바

이렇게 하려면 서블릿을 몰아주자

 

다 떼어내면 컨트롤러는 출력으로 JSP를 떼어내고, 입력은 프론트컨트롤러를 뗴어내면

이제 컨트롤러는 자바만 남는다.

 

2)

서블릿으로 사용자 입력을 받는 방법을 우리는 찾고있다.

 

3)

왜 프론트 컨트롤러 왜 또 나왔어 대체!!!

앞으로 뺴는 이유는? 서블릿을 베어내기 위해서!

 

첫번째 입력부분을 잘라내고, 두번째 포워딩위한 디스패처 부분을 잘라내기

(pojo class : Plain old Java object)  -> 프론트컨트롤러로 보내기

이러면 순수하게 자바(pojo)만 남는다. 즉 지금까지 순수자바가 아니었다

 

2.  프론트 컨트롤러

(1) post 

1)

옵션 적을게 많은 경우

 

검색어는 목록어 달라고 하기 위해서는 get : 달라고하는 것이다

선택적으로 내가 달라는게 아니라면 form 을 제공할 수있는 것이다.

 

달라고하는 요청이 많은데, 요청이 많으면 post가 맞다

get 방식은 요청이 많으면 url이 길어지고 감당못한다

 

post로 하면 method 에다가 post 를 한다

 <form action="/input" method="post">
	<fieldset>	
		<legend>쿼리 값</legend>

이렇게 하면 url에 안나오고 요청 body에 나온다.

 

 

2)

쿼리스트링은 하이퍼링크로 선택한 것이 정해져있다.

쿼리로 전달하는 값을 직접 하는것의 form을 get요청이다

form 을 이용한 쿼리스트링이다. form을 이용할 때 선택적으로 post가 가능하다 post하면 쿼리스트링으로 진행한다

요청body로 한다

 

어느경우에 post?? : 사용자가 요청한게 주소로 가잖아

입력값이 큰 경우에 주소로 보내도 돼? 안돼

 

보안때문에 그렇다고 하는 것도 있지만 그런 것은 아님

 

(2) 쿠키

1)

일반적으로 흔히 웹 이용중 쿠키 허용 물어본다. 찝찝하긴하지만 사실 그런게 아님

웹에서 나에게 커스터마이징 하기위해서 데이터를 심는 것임

 

쿠키는 서버가 나에게 보내는 데이터이다. 내 것을 빼가는게 아니야!

 

쿠키란 무엇인가?

그 이전에 상태를 저장하는방식이 여러가지이다. 

A서블릿에서 B서블릿으로 이동할 때 매번 유지하는게 쉽지않다 왜냐? 이동하면서 기존 것이 사라지기 때문이다

 

사라져도 남는공간 첫번째 request 이다 포워드 하면 같이 가지고 간다

포워드 관계는 상태유지라고 보기는 어렵다

 

저장소에서 session, application 은 서블릿 사라져도 남는 저장소이다.

다만 이들은 서버에 저장되는 것이다

 

 

2)

*** 세션: 시간(기간)적의미이다. "세션(기간)동안 사용하는 객체" 라고 표현이 바람직하다

"세션 몇개" 는 말이 안되는 말이다. 세션은 기간인데 

 

우리가 게임을 하면 접속을 한다. 접속상태에서 연결 유지되어야

서버에 계속 내 상황을 보내고, 참여하고 있는 상황을 받는다. 이것은 연결유지상태에서의 환경이다

그런데 웹은 안그렇다. 웹은 요청하면 응답이 오면 끊어진다 그리고 끊어져도 계속 볼 수있다

우리에게 필요한건 연결이 유지가 안되도 쓸 수있어야한다

 

세션이란 : 클라이언트가 요청을 하고, 서버는 문서를 돌려줄 때 다음에 또 올지도 모르기 때문식별자를 준다 마치 회원번호처럼!

식별자가 걔를 식별하는 키이다. 이것을 기억 위한 공간이 필요해

그런데 언제올지 몰라! 그 사이에 다른 손님이 올 때 모두 기억해야해 모든 손님 회원번호 저장하면 기억하기 한계가 와

 

회원에게 말함! : 30분 줄게 30분 내 안오면 나 까먹어! (손님과 내가 유지되기 위한 key에 대한 유지기간, 식별기간을 줌)

즉 나를 인식할 수있게 해주는 세션기간이다.

 

3)

누군가가 나에게 요청이 왔을 때 서버는 나를 식별하는 키를 알고있고, 세션 타임아웃 전에 세션저장소(세션객체)를 사용할수 있게한다

세션은 다음에 왔을 때 식별할 이유가 있을 때 이것이 발급된다

 

session ID : 발급한 회원 번호

응답헤더 : 돌아올 때 서버가 멤버에게 회원번호를 준다 이것이 session key이다.

서버는 html로 요청하면 session key를 안준다. 왜냐 정적페이지 이기 때문에

즉 굳이 기억할 필요가 없는 회원이다

 

4)

html 이 아니라 서버코드로 방문시 응답 헤더에 쿠키를 준다.

이후에 새로고침하면 요청헤더에 쿠키가 있다

이것이 사용자 식별하기 위한 메커니즘이다. 

 

응답 시 준 쿠키(키)는 누가 가지고있어? : 브라우저 (클라이언트)

다 띄어서 프로세스가 사라져야 다 사라진다.

(반면 세션서버에 저장된것이여서 볼수가 없다)

 

서버는 클라이언트가 언제올지 몰라서 30분 내 방문안하면 다른 사람이다.

 

<정리>

세션이란 기간(세션)동안 사용할수 있는 객체인데, 30분에서 또 길어질 수도있다.

다시 30분이 될 수도 있다. 키가 길어질수 있다. 유지가 되려면 30분 내 다시 요청이 들어와햔다

세션이란 사람의 수가 아니라 클라이언트 수 이다!

 

 

5)

키와 관련된 것이 3가지이다

세션기간도 중요하지만 세션객체도 있다

세션키와 관련된 쿠키도 있다

 

WAS 는 저장소가 두개이다.

application 저장소와 session 객체이다.

모든 서블릿이 접근이 아니라 자기 id 할당된 것만 사용이 가능하다

 

처음에는 SID없다. -> 이후 response 때 받아오고 : Add(107) -> 다음 requset (107) 때 ADD를 한다

 

같은 키를 쓰면 같은 공간을 쓴다

세션객체는 서버에 있음, 서블릿등이 이용할수있는 공간이있다

같은 서블릿인데 요청자가 다르면 다른공간을 씀

 

3번키를 가진 사용자가 서블릿 호출하면 3번 서블릿공간을 쓰면 / 5번키는 서블릿 요청하면 5번 서블릿공간을 씀

 

<정리하면>

 

<listController3.java>

HttpSession session = req.getSession();
session.setAttribute("haha222", "hoho111");

listController3 에서 세션 "hoho111" 를 setAttribute 로 서블릿공간을 쓴다

 

 

<listController2.java>

HttpSession session = req.getSession();
String haha = (String) session.getAttribute("haha222");

System.out.println(haha);

이후 listcontroller2에서 hoho111 의 서블릿 공간을 가져와서 콘솔로 출력한다.

 

 

6)

 

<또 정리>

세션이란 시간적 이야기이고 기간을 말하는것이다 (세션객체일정한 세션(기간)동안 살아있는 객체)

다음에 왔을 때에도 구분하기 위해서 앞으로 30분동안 인식할수있는 키를 줄태니까

다음부터는 나에게 와 회원번호 줄태니까 기억해줄게

 

세션 객체를 말할 때 저장소를 알고있어야해

저장소는 신기하게도 내가 서블릿요청하면 세션객체를 얻어 쓸 수 있는데,

같은 코드인데 1번고객이 요청하면 세션이 담는건 1번 고객 캐비넷에 들어가고 3번사용자가 요청하면 3번 캐비넷에 들어간다.

3번 고객이 요청하면 3번에서 꺼내주는것을 테스트한 것이다!

 

 

(3) 쿠키를 이용해서 상태값 유지하기

세션키로 활용할수 있는 또 다른것은 세션쿠키이다.

 

1)

세션객체의 문제가 있음 : 고객마다 캐비넷 준비하는것도 녹록치않음...

서버에 저장하려고함 그런데 서버쪽 자원을 덜쓰는법은 없을까? 사용자의 값을 세션이아니라 클라이언트에 저장!

 

(ex: 헬스장 라커(세션) 돈아까워 내가 내 짐 직접 들고다니기(쿠키) )

옛날에는 어려웠지만 요새는 네트워크가 활발하다

 

쿠키 단점 : 사용자에게 물어보아야한다.

장바구니 데이터를 세션 혹은 DB에 저장가능하다 임시데이터인데 DB저장하기 아까움 왜냐 DB는 영구저장소임

잠깐 쓰고 말거면 DB는 오버야!! 적당한게 세션인데 장바구니 목록이 커지니까 서버가 싫어해!!!! 그러면 니가 쿠키 들고다녀

 

DB X -> 세션 X -> 쿠키

 

이런경우인데 사용자가 쿠키 비허용하면 어떡해?

기존에는 안물어봤는데, 정책이 바뀌어서 일정경우 물어보게끔 하였다

 

2)

처음에 response에 준다

Cookie cookie = new Cookie("haha22", "hoho11");
resp.addCookie(cookie);

처음에 Response 에다가 Cookie가 나온다. 즉 클라이언트가 서버의 출력을 받는다.

이후에 한번 더 새로고침 하면  

Request 에 Cookie가 있다. 즉 클아이언트가 서버에 Cookie를 입력한다.

 

 

 

3)

세션 쿠키 중 무엇을 해야할까?

쿠키의 장점 2가지가 있다

 

첫번째

브라우저를 닫아도 쿠키를 기록시킬수있다. 세션이 끝나도 쿠키는 다음에도 가져갈수있다 세션키와 상관없어!!

일반적으로 세션공간은 timeout되면 사라지는데 쿠키는 브라우저에게 오래 가지고있어 하면 1년 10년 가지고있는다

세션은 이만한 기간 가지게 하기에는 감당할수없다. 오랜기간 저장할 데이터라면 무조건 쿠키!!!!

 

두번째

쿠키는 세션과 달리 클라이언트 자원이기 때문에 시간을 마음대로 조정이 가능하다 

내가 원하는 경로의 서블릿만 쓸수있다 (특정 경로에서)

 

 

4)

 

<첫번째 특징>

다른 서블릿으로 가면 기존 쿠키가 없어지지만

menu 이하로 시작하는 경로에있는 서블릿들만 쿠키를 가질 수있다

 

http://localhost:8080/menu/

이하 메뉴 이하 경로에서 쿠키를 클라이언트에 심었다면 menu경로 안에서만 쿠키가 간다

 

사이트전체에 쓰고싶다면 설정을 바꾸면된다.

 

cookie.setPath("/");

/ root 경로를 설정하는 모든 경로에서 확인이 가능하다

 

<두번째 특징>

특별이 지정하지않으면 쿠키는 브라우저상에 저장이 된다.

cookie.setMaxAge(60*24);

브라우저 어플리케이션 저장소에 있다가, 날짜를 길게 가져간 경우(setMaxAge()) 하룻동안은 컴퓨터에 올라간다.

 

쿠키는 컴퓨터를 떠나서 다른곳에서 하면은 그 데이터를 이어갈수 없다.

 

5)

한편 쿠키는 다양한형식은 안되고 문자열만 저장이 가능하다

만약 복잡한데이터 (ex: 객체의 값들을 장바구니에 저장해야겠다 싶을 때) 에는 JSON방식으로 바꿔주어야한다

URL만 사용가능한 키워드가 가능한데 문자열로 저장가능한 방식으로 저장해야한다!!

 

 

 

 

(4) 쿠키 읽어오기

하기가 불편한데, 스프링을 쓰면 매우 쉽다.

 

 


1. 보충

 

 

 

2. 회고 

1) post 방식을 이용해보고, 그차이를 직접적으로 느껴서 신기했다

post는 url에 흔적이 안남으니까 신기하다

 

2) 쿠키와 세션간의 차이를 알수있어서 좋았다

우선 세션은 서버에 저장하는 식별자이자 일정한 세션(기간)동안 살아있는 객체라는 점

쿠키는 클라이언트에 저장하는 식별자이다.

 

 

 

 

'배움 __IL > TIL 1기' 카테고리의 다른 글

TIL : 56번째- 230222 [2-3-수]  (0) 2023.02.22
TIL : 55번째- 230221 [2-3-화]  (0) 2023.02.21
TIL : 53번째- 230217 [2-2-금]  (0) 2023.02.17
TIL : 52번째- 230216 [2-2-목]  (0) 2023.02.16
TIL : 51번째- 230215 [2-2-수]  (0) 2023.02.15