20/09/05 웹 프로그래밍 (기본 객체, 세션, 쿠키)

<기본객체>

:jsp 페이지에 대해 최초의 요청이 발생하면 생성되는 servlet 소스가 파싱되는 시점에 자동으로 생성되는 객체들

 

 

CAC: Context-Awared Computing: 맥락이나 환경을 인지하고 컴퓨팅 

e.g. 내가 공연장 가면 알아서 폰이 조용해짐 

웹앱스라는 독베이스 아래에 context폴더있어야함 

 

1. request(HttpServletRequest): 클라이언트와 요청에 대한 모든 정보를 캡슐화한 객체 (요청 분석 과정에서 쓰이는 진짜나 가짜 객체들)

 

2. response(HttpServletResponse): 클라이언트 쪽으로 전송될 응답에 대한 모든 정보를 캡슐화한 객체

 

3. out(JSPWriter): 응답 버퍼의 데이터를 기록하기 위한 스트림 객체이면서 응답 버퍼의 관리자 (모든 jsp페이지는 응답버퍼를 사용함)

 

4. session(HttpSession): 한 클라이언트의 세션에 대한 모든 정보를 캡슐화한 객체 

세션: 데이터가 오가는 통로(db에서 쓰임)이자, 서버-클라이언트 간의 통로가 연결되어있는 시간(web에서 쓰임)

 

5. application(ServletContext): 하나의 어플리케이션과 서버에 대한 모든 정보를 캡슐화한 객체 

 

6. page(Object): 현재 페이지가 생성된 서블릿 싱글턴 객체의 reference.

우리가 지금짜는 jsp도 사실은 서블렛이자나 그래서 그 서블렛은 싱글톤 객체라 그거에 대한 레퍼런스 근데 이건 Object타입이라 이거 쓸바엔 this 쓰는게 나음. 왜냐 this는 자기자신의 타입을 그대로 가지고있어서 캐스팅할 필요 없음. page는 항상 casting 필요함 

 

7. config(Servletconfig): 서블릿이 등록되고 매핑되는 과정의 모든 메타데이터들을 캡슐화한 객체 

잘 안 쓰임 걍 jsp도 서블렛이구나만 보여줌

 

8. exception(Throwable): 에러 처리 페이지에서 발생한 에러나 예외에 대한 정보를 캡슐화한 객체 

 

9. *****pageContext(PageContext): 모든 기본객체 중에 가장 먼저 생성되고, 나머지 기본 객체들을 모두 가진 객체

 

나중에 EL 배울때 pageContext만 있고 나머지 기본객체들은 get해오게 된다.

톰캣에 의해 실제로 만들어진 jsp Servlet. pageContext가 가장 먼저 만들어지고 거기서 get해서 만들어짐

---

Buffer <응답 버퍼의 관리자>

출력버퍼: 웹 브라우저에 바로 전송되지 않기 때문에, JSP 실행 도중에 버퍼를 비우고 새로운 내용(에러메시지, )을 보여 줄 수 있다. 버퍼가 다 차기 전까지는 헤더를 변경할 수 있다. but 버퍼가 이미 응답으로 나갔었으면 다시 못 나감

include로 b에서 a로 올라갈땐 b에서 가져가는 거를 a데이터에 append하거나 prepend함. 근데 이것 버퍼없으면 안됨

 

//위에서 flush했기때문에 (응답이 클라이언트로 이미 전해져버렸기때문에) forward와는 구조가 맞지않음

---

Session

통로(DB): 클라이언트와 서버 사이의 유일하게 개방되어있는 통로 

시간(WEB): 클라이언트가 서버의 어플리케이션을 사용하고 있는 동안을 한 세션으로 정의 

               최초의 요청 ~~~ 종료

 

HTTP의 단점: stateless(대화가 불가능하다)

connectless('세션'이 web에선 '시간'이라는 의미로 쓰이는 이유. 비연결지향형:  웹에서 통로로 계속 열어놓으면 부하가 너무 크니 사용이 끝나면 다 끊어버린다) 

(HTTP1.1 은 connectfull, 연결지향형 버전이긴 함)

 

세션과 쿠키의 차이점

-만약 알라딘에서 장바구니 담을때 정보를 클라이언트쪽에 저장하면 쿠키, 서버쪽에 저장하면 세션

 

 

세션-브라우저 다르면 다름, 세션 ID존재 

 

<Session Tracking Mode>

: 세션 ID를 통해 세션을 식별하는 방법

클라이언트한테서 요청이 왔는데 ID가 없으면 최초의 요청으로 인식하고 새로운 ID를 만든다. 그 후 응답데이터에 ID를 포함시켜 보내면 클라이언트쪽에서 다시 그 ID를 담아서 보냄 

1. COOKIE: e.g. JSESSIONID 와 같은 세션 아이디를 식별할 수 있는 쿠키를 C-S 사이에서 주고 받는다.

2. SSL : Secure Layer를 통해 세션 아이디를 주고받는 방법. 전송 계층을 보안 처리하여 데이터를 보호하는 방법의 일종

     http: non-secure, https: secure

3. URL: 세션 식별을 위한 아이디를 request line을 통해 주고받는 방법 (보안에 취약)

 

종료 조건

1. timeout 이내에 동일한 클라이언트로부터의 새로운 요청이 없을 때 / 톰캣: 30분 

2. 브라우저 종료

3. 더이상 쿠키(JSESSIONID) 전송이 없을 때 **세션과 쿠키의 차이점 기술면접 잘나옴

4. *직접 로그아웃을 했을 때 (session을 invalidation)

 

=> 이 정보들을 모두 session이라는 객체가 포함한다.

세션이 종료될 때 session scope도 사라진다.

---

<application: ServletContext>: 서블릿의 운영 주체인 어플리케이션과, 어플리케이션을 관리하는 서버에 대한 정보를 캡슐화한 객체

서버 없이 서블렛 동작 불가능

app 없이 서블렛 동작 불가능

 

1. 어플리케이션에 대한 정보 확인 application.getContextPath() 

2. 서버의 정보 확인 application.getServerInfo() 

3. 로그 기록

4.** 웹 리소스를 확보할 때 

      1) classpath resource (src, res)

      2) filesystem resource (전부)

      3) web resource (webapp)

 

virtual path: 웹에서 자원에 접근하기 위해 사용되고 있는 논리적인 URL

real path: 파일 시스템 상의 절대 경로 -> 이걸 확인하고 싶을때 application 사용함 

 

5. 파일의 MIME 확보

6. 컨텍스트의 초기화

---

Model 1 : 책임이 섞여있음, 여러 언어가 섞여 가독성 떨어짐, 소스 길어짐 -> 유지보수 불편

Model 2: 요청을 처리/ 응답을 처리하는 부분이 나뉘어져있음. 

---