2020-11-19 2일차 웹어플리케이션

jsbak·2020년 11월 19일

웹어플리케이션

웹기반 어플리케이션

목록 보기

2/40

어제

qualified name?
IP 물리적인 서비스 식별자
PORT 논리적이 서비스 식별자

서버의 역할
데몬스레드 형태로 돌아가는 하나가 존재해야한다. 포트를 감시해야하기 때문에
감시해서 요청이 오면 해당하는 응답을 서비스해준다.

단독 설치 스텐돌른 어플리케이션 "standalone"이었음.

포트를 감지하는 코드도 존재해야한다.

요청을 잡는 톰켓,
네트워크 (미들티어)?가 존재하기 때문에 개발자가 상대적으로 쉽게 개발할 수 있다.
미들티어로서의 역할을 맡기기위해서 필요하다?

서버 : 웹 서버, 웹어플리케이션 서버, 클라이언트 요청 대기(요청이 어떤 것이 있는지 고려해야함, 요청의 공통점 : 요청을 처리할 수 있는 파일이 존재한다는 공통점이 존재(고정적으로 존재한다, 정적인 요청), 오늘날짜가 며칠이냐?, 이번달의 베스트셀러 리스트, 오늘자 멜론차트, 주식(공통점 : 형태가 일정하지 않음, 동적인 요청)
미리 만들수 있는 방식이 있고, 그때마다 해줘야하는 방식이 있다.

웹서버 계열 : 아파치, IIS 등 (정적인 데이터를 제공하기 위한 녀석), 무조건 자기가 존재하는 자원을 찾음. ,현재요청이 누구를 원하는지 찾아야함, 찾는데 파일이 있거나 없거나 , 자원형태로 존재 그 존재하는 자원을 읽어드림 스트림을 변환해서 내보냄 반대로 없다라면 없다라는 응답을 줄 수 있어야한다.(이럴때 사용하는 것이 응답 코드이다 ex. 404) 문제의 원인이 클라이언튼냐 서버냐 분석하여(즉, 상태코드가 어떤게 있는지 개발자는 알고 있어야한다, 그리고 HTTP 구조를 알고 요청을 처리해야한다.)
웹서버가 동적처리를 위해 만들어진 맨처음 방식 CGI(단점, 1000개가 따로 요청이온다 그러면 1000개 어플리케이션을 실행해버림, 자원이 오지게 낭비된다., 동시에 처리할 수 있는 것이 부족하다.)
서블릿은 그 해당요청에 대해서 처리할수 있는 스레드를 식별(확장CGI방식) 하나의 요청을 처리할 수 있는 쓰레드를 계속 쪼갠다? 멀티 쓰레딩 방식으로 운영한다. 자원의 소모를 줄인다(동시처리가능한 요청 수가 늘어난다, 확장CGI(JSP,ASP등등), 왜때문에 우리가 서블릿과 JSP스펙을 사용하는가?(핵심의 근간의 자바이다, 자바를 스펙으로 하기 때문에, 그럼 자바 기반이 어떤 장점이 존재하는가?, 자바 언어의 장점 1.(WORA, JVM에 존재하기 때문 플랫폼만 존재하면 된다.)이식성!이 좋기 때문이다.(C는 플랫폼 종속적이다. exe는 window가능 UNIX계열 불가능),2. 쉽다?(개발과정에서 필요한 재료를 얻는 법이 쉽다는 것(PYTHON도 마찬가지), 그래서 확장CGI방식으로 운영을 한다면 웹서버 - 웹어플리케이션서버 - 그다음..)

웹서버가 정적인 운영을 받으면 웹어플리케이션 서버에 위임, 요청을 처리할수 있는지 분석, 분정기능을 이용 , 웹서버한테 돌려줌, 응답을 받아서 다시 클라이언트에 포워드해줌.

cf.티어(tier)?(클라이언트 서버 시스템의 구조를 이야기 할때 사용한다.)
정적 요청 처리 2티어
동적 요청 처리 이상 3티어 이상

N-tier 구조? 적어도 동적어플리케이션하나를 잘 운영하려면 최소한 4티어(요청- WS - WAS - DB)

웹 어플리케이션 서버의 계열 :
역학
1. 확장 CGI방식의 웹 어플리케이션의 운영하기 위해
2.

정리되지 않은 데이터도 존재한다? 모든 요청을 다 처리할수 있다.(즉 WS 없어도되지만 큰 규모의 경우 WS 가 있어야한다.)
우리는 3티어 구조 (요청 - WAS- DB)

두녀석의 차이 ?

JAR 자바 아카이브 파일 의 약자 안에 클래스들이 존재한다.
jsp-api.jar와 servlet-api.jar 없으면 톰캣이 안돌아간다.

webapps?? 톰캣의 모든 폴더에 대해서 매우 중요함 어플리케이션이 들어 있는 폴더이다.
톰캣|WAS|
5개 폴더 존재 톰캣안에는 5개의 컨텍스트가 운영되고 있다.?? 또한 각각의 이름하나가 컨텍스트 name이 될것이다.

server.xml

이렇게 잡혀 있다.

webapps에 접근하기 위한 가상의 주소
가상 주소 체계 쓰는 개방하는 것을 제한하기 위해서 URL을 쓰는 것이었다
서버의 주소를 클라이언트에게 일부 개방하기 위해서 사용했다.

webapps를 docbase라 부를예정

firstApp이 컨텍스트 페이지가 될 예정이라는 것?/

정적인 서비스다 지금 이것이 서버 재구동 안함.

01폴더 만들고 inner.html생성

firstApp\WEB-INF
WEB-INF 만들고 안에 webINFINNER.html만듬 하지만 접근 불가
WEB-INF는 서버상에서만 사용할 수 있는 주소 체계이다. 즉, 클라이언트가 사용할 수 없는 자원 서버만 사용할수 있는 자원(톰캣의 금고), 외부에 노출을 해서는 안되는 녀석들이 들어간다.

firstApp\WEB-INF
WEB-INF - classes 만듬
클래스를 역컴파일하면 소스가 나오기 때문

firstApp\WEB-INF
WEB-INF - src, lib

외부에서 접근 불가능한 보호해야할 자원을 가지는 폴더가 되는 것이다. WEB-INF

webapps\docs
webapps\docs\WEB-INF
webapps\examples\WEB-INF
...
모든 컨텍스트에 존재한다. 약속이 되어있는 녀석이다.
web.xml에 안을 보면 어떤 자원이 사용되고 있는지 다 볼수 있기 때문

\webapps\firstApp\WEB-INF
에 web.xml 복사해서 가져옴 위해서

root element 맨처음 나오는 것

!!
해보라 주신것
패키지 어디로감??

standalone이 클래스패스가 되야한다.
-classpath(cp) path(파일 절대 경로):
컴파일러가 컴파일 하기 위해서 필요로 하는 참조할 클래스 파일들을 찾기 위해서 컴파일시 파일 경로를 지정해주는옵션

-d directory
클래스 파일을 생성할 루트 디렉터리를 지정합니다.
기본적으로 컴파일러는 -d옵션을 주지 않으면, 소스파일이 위치한 디렉터리에 클래스 파일을 생성시킵니다.

-d 클래스파일을 어디다가 저장할것이냐(클래스패스 지정해라)
참고 : https://payoff.tistory.com/401

클래스패스 클래스를 찾는 위치 에러난다 못찾아서

클래스패스를 잡을 때 환경변수에 잡히있는 녀석을 대상으로도 할수 있다.
클래스패스는 클래스를 찾을때 식별할때 경로
클래스패스이후의 모든 경로에서 찾는다.
클래스를 검색하기 시작하는 위치

그동안 서블릿은 누구에 의해서 됐을까 main도 없는데
운영 주체 tomcat이었다.

// 1. 웹어플리 케이션 요청 분석
// 2. 분석 결과에 따라 데이터 생성

맨 처음 jre에서 한번 뒤지고
그다음 개발자가 커스텀해둔 클래스 패스를 뒤진다.
그래서 아래 이거 못찾음.

그래서 톰캣을 클래스 패스로 찾아줘야한다.

클래스패스 지정해서 컴파일 해줬다.

이제 web.xml에 설정해준다.

왜/hello가 되고 hello는 안될까?
클라이언트 사이드와 서버사이드 의 경로 설정??

cf. startup.bat 안되면 catalina.bat run해보면 기존창에서 서버 올라는 것을 볼 수 있다.

이후 url를 치면 나온당.

톰켓도 싱글턴으로 운영이된다.
그래서 서버를 다시 구동하지 않으면 새로운 서블릿을 만들거나 저장을 해도 인지를 못한다.
리로딩뿐...

서블릿의 직접적인 단점 : 언어가 HTML, 자바 둘다 들어가고있다.(즉, 협업에 문제가 생긴다. 그래서 템플릿을 이용한다.)

변경때마다 컴파일하고 재구동하고 이러니까 JSP 스펙을 이용하게 된것 이다.

서버 리로딩하는 이유 톰켓이 싱글턴패턴으로 구성되어있기 때문에

쓰레드가 찍히는게 1~10 까지 10개까 찍힌다
쓰레드 풀링(풀링 : 일정 갯수를 미리 만듬) , 그리고 만들어진 녀석으로 할당된 것 (확장CGI방식의 대표적인 예이다. CGI 방식과 여기서 차이가 난다.)

클래스패스?
톰켓의 역할?
1. 어플리케이션 운영
2. 어플리케이션 운영하다가 요청이 들어오면(감당되거나 안되가거나(web.xml에서 서블릿 매핑에서 찾아본다.) 처리할수 있는 녀석을 분석한다.
쓰레드 풀링, 만들어진 녀석중에서 하나 할당 받아서 서블리에서 콜백메서드를 호출받음.
응답이 만들어지면 하나의 응답을 보내주게된다.

그래서 WAS가 어떤 구조로 동작하는지 알게되면 어떤 WAS를 써도 문서만 보면 알수 있게하는 힘을 기르기 위함.(톰켓을 뜯어서 알아보는 이유)

서버가 구동될때 맨 처음 web.xml을 한번 구동(리소스가 많이 소모되기 때문에) 그래서 서블릿을 변경하면 재구동을 하는 것임.

jsp 디렉티브를 통해서 import를 지원 <%@ page import ~~%>
뎊스 구조??

jsp는 협업이라는 문제를 해결

catalina_home에서 work-Catalina-localhost, 밑에 우리가 본 컨텍스트
apache-tomcat-8.5.37\work\Catalina\localhost\firstApp\org\apache\jsp_02
Hello_jsp.java
Hello_jsp.class

firstApp이 까지 ContextRoot로 잡혀있다.

public final class Hello_jsp extends org.apache.jasper.runtime.HttpJspBase
HttpJspBase는 서블릿을 상속받음
따라서 jsp와 서블릿은 다른게 아닌 것이다...

존재... 형태가 서블릿이 가지고 있던 콜백 메서드가 존재한다.
즉 jsp는 가짜 파일을 가지고 있고(템플릿일뿐...), 진짜는 결국 다시 만들어진다.

JSP와 서블릿이 같냐?
같은 스펙이고 JSP는 곧 서블릿이다.
둘이 같이 쓸때 톰켓이 어떤 역할을 하는지를 이야기해야한다.
톰켓이 JSP를 할때 JSP 컨테이너
servlet을 할때 servlet 컨테이너 (객체를 생성해줌, 싱글턴이 될지 안될지를 지가 판단)
컨테이너? 컨테이너 안에서 관리되는 컴포넌트 태어나게 죽게 태어하면서 죽을떄 까지
컨테이너는 컴포넌트의 라이프 사이클을 관리한다.
다만 서블릿과 jsp의 라이프 사이클이 조금 달랐던 것뿐
서블릿은 매핑되면 그걸 톰켓이 처리
jsp는 jsp를 만들면 개발자는 그걸로 끝(소스, 컴파일, 등록, 매핑, 이런걸 안함 즉, 톰켓이함)
즉, JSP라이프 사이클을 관리할때에 톰켓이 할 일이 많아진다.
서블릿은 개발자가 할일이 많아짐.
JSP는 개발자가 편함, 톰켓이 할일이 많아짐.

클래스패스
서블릿 스펙이 따라서 어떻게 진행, 역할, 컨테이너가 뭔지
서블릿의 단점, 그단점을 보완할 JSP특징, 그리고 JSP가 어떻게 진행되는지