3-Springboot 동작 원리(METACODING-SPRINGBOOT-개념정리)

1-1소켓

socket : 운영체제가 어플리케이션으로 부터 데이터를 받는 입구

어플리케이션이(B) ip주소를 통해서 port번호 5000인 메인에 연결하려한다

스레드를 하나 생성하고 port번호 5001로 할당 한뒤 B에 연결시킨다

B와 메인은 연결을 끊는다

어플리케이션이(C) ip주소를 통해서 port번호 5000인 메인에 연결하려한다

스레드를 하나 생성하고 port번호 5002로 할당 한뒤 C에 연결시킨다

C와 메인은 연결을 끊는다

main은 항상 다른 어플리케이션의 연결을 받아야 하기 때문에 비워둬야 한다

 

http통신-stateless 방식

위의 과정과 유사하게 소켓을 통해 동작한다, 지금은 중앙 집권화 되어있다

1-2톰켓?

http : 소켓 기반의 시스템콜로 만들어졌다,

시스템콜 = 어떤 프로그램이 운영체제가 가지고 있는 기능을 이용해서 만들어지는것

톰켓 vs 웹서버

웹서버 => 갑(웹서버)이 필요한 데이터를 을(다른 컴퓨터)에게 통신하는것

을은 갑에게 요청(REQUEST)하는데 URL(갑의 주소=IP + 을이 원하는 갑의 데이터 위치)을 통해서 한다

갑은 을에게 응답(RESPONSE)하는데 을에게 자신이 누구인지 알리면서 데이터를 전송해준다

갑은 을의 주소를 모른다

 

만약 을이 .JSP파일을 요청하거나 자바 코드가 적혀있는것을 요청을 하면 아파치(웹서버)는 이해하지 못한다

왜? 웹서버는 .HTML 통신을 위해서 존재하니까

그래서 아파치 + 톰켓을 사용한다

다시 위와 같은 요청이 오면 아파치는 톰켓에게 위임한다

톰켓은 모든 자바파일을 컴파일하고 .HTML파일로 변환하고 아파치에게 돌려준다

아파치는 리퀘스트 요청한 웹브라우저에게 돌려준다

2-서블릿 컨테이너 = 톰켓

Client -> 서블릿 컨테이너(톰켓) -> 최초요청 o -> [메모리 로딩 -> 객체생성 -> init()] ->Service(req,resp)

Client -> 서블릿 컨테이너(톰켓) -> 최초요청 x -> Service(req,resp)

URL(a.png)       : 자원에 접근 -> spring에서 사용 불가

URI (picture/a)  : 식별자 접근 -> 특정한 파일 요청을 할 수 없다, 요청시에는 무조건 자바를 거친다

즉 spring에서는 무조건 톰켓이 사용된다                                              

 

자바 요청이 올때마다 톰켓은 스레드와 서블릿객체를 생성하고 둘이 연결시킨다

스레드 개수는 제한 되어 있어서 요청 갯수가 스레드 개수보다 많으면 대기한다

대기중인 요청이 있으면 작업이 끝난 스레드-서블릿객체가 그 요청을 대신한다

 

서블릿객체= Service(HttpServiceRequest, HttpServiceResponse)

 

3-web.xml

web.xml = 문지기

-ServletContext의 초기 파라미터 : 어디에서든지 사용가능한 암구호

-Session : 체류 가능기간, 문지기 한테 신고하면 초기화 가능, 체류 기간이 끝나면 쫒겨난다

-Servlet/JSP 정의,매핑 : 목적지 위치를 알려주는것

-MimeType 매핑 :

 MimeType = 들고온 데이터 타입

 아무것도 안들고 왔다? get 사용(Select)

 MimeType에 따라 적절한 위치로 보내줘야 한다

-WelcomFileList : 아무런 정보도 없는 것들을 특정 구역으로 보낸다

-Error처리 : 문지기 (web.xml)이 알지 못하는곳으로 가려 하는것들도 특정 구역으로 보낸다

-리스터/필터 설정 :

필터 - 말그대로 거르는것

리스너 - 모든 출입하는 파일에 대해 특정 성질 유무만을 판단하며 만약 보유하고 있으면 그대로 통과 시킨다

-보안 : 말그대로 성을 보호하는것

4-FrontController

request가 들어오면 바로 자원으로 가는게 아니라 톰켓으로 간다

톰켓에서는 req,resp객체를 만든다

이제 web.xml로 가게 되는데 만약 .do를 요청하면 frontcontroller가 처리하라고 설정할 수 있다

frontcontroller에 걸린 요청들은 내부 자원에 접근하기 위해 새롭게 req를 실행하고 새로운 req,resp가 생성된다

이때 기존에 생성되어 있던 req,resp객체가 지워지는데 이를 방지하기 위해 RequestDispatcher가 존재한다

즉 특정요청이오면 어디로 가야할지 알려주는것이다

 

5-RequestDispatcher

ReqeustDispatcher를 통해서 만들어지는 req,resp는 기존의 것과 새로운것 둘다 동시에 사용 할 수 있다

이를 통해 지난페이지에서의 데이터를 새로운 페이지에 들고와서 사용 할 수 있다

6-DispatchServlet

Spring에서는 4,5번이 합쳐져있는 DispatchServelt이 구현 되어 있다

DispatchServelt이 자동생성되어 질 때 수 많은 객체가 생성(IOC)되는데 이는 보통 필터들이다

JSP에서는 4,5를 직접 구현해야하지만 Spring에서는 간단한 개념만 알고 있어도 무방하다

7-스프링 컨테이너(환경)

DispachServlet에서 만들어지는 객체는 어디서 관리 되는걸까?

request -> web.xml ->ContextLoaderListener-> DispachServlet(컴포넌트 스캔 )

 

ContextLoaderListener : 스레드가 전부 공통적으로 사용하는것(ex) db와 연결하는 connetion)은

일일이 메모리에 띄울 필요가 없기때문에 여기서 한번 생성하고 계속 사용된다

root-context와 servlet-context로 이루어져 있는데

root는 DB관련 객체들이 메모리에 로딩되고

servlet은 DispachServlet이 메모리에 로딩된다

 

컴포넌트 스캔 : frontcontroller 패턴은 특정 req가 오면 정해진 자바객체에 담아서 자원에 접근하게 하는데

자원에 접근하기 위해선 자원이라는것이 메모리에 띄워져있어야 한다

모든 자바 파일에 대해서 사람이 직접 하기 힘들었지만

springboot에서는 관련 패키지 이하의 모든 자바파일을 어노테이션에 따라 IOC기법으로 메모리에 띄운다

8- 요청 주소에 따른 적절한 컨트롤로 요청

url형식으로 주소 요청이 오면 적절한 컨트롤러의 함수를 찾아서 실행한다

9- 응답

response는 Data와 html중에 하나를 선택해서 응답해야 한다

html 파일을 응답하면 ViewResolver가 관여하고

Data 파일이 응답하면 MessageConverter가 작동한다 -> json이 기본 전략

Class class{

user A(){

int id

string name

return user }  }

여기서 Data가 응답되면 json형식으로  {"id" : 1, "name" : "홍길동"}

html파일이 응답되면 web-INF/views/A.jsp 이렇게 응답된다

 

총정리 모식도

 

 

출처

https://www.youtube.com/playlist?list=PL93mKxaRDidG_OIfRQ4nztPQ13y74lCYg