스프링부트 개념정리 2

스프링부트 동작원리

내장 톰켓을 가지고 있다
socket : 운영체제가 가지고 있는 것
통신 : 연결시 스레드를 생성 > 연결이 계속 유지 > 부하가 심함

http 통신 : 문서를 전달하는 통신 / Stateless 방식 
- 한번 연결후 응답을 하면  response 후 연결 끊음
- 부하가 적지만 다시 연결되면 새로운 것으로 인식 (같은 곳에서 요청을 하더라도 전에 요청했던 곳인지 알 수 없음)
- 문서전달의 목적으로 만들어짐 html(확장자)


톰켓

소켓을 불러서 사용 (system call)
http 기반 = 소켓
톰켓과 웹서버의 차이 ? 
웹서버 : 
url 의 마지막 l = location
static 자원 : 정적인 자원
아파치 = 요청을 받고 응답을함 (HTML, CSS, PNG...  )
톰켓 : 자바코드가 요청이 되면 컴파일해서 HTML 파일로 변환 후 돌려줌
아파치는 java 코드를 인식못함 그래서 톰켓을 추가함 java 코드가 오면 톰켓에게 제어권을 넘김
톰켓 > JSP > 자바코드 컴파일 > HTML 문서로 아파치에게 만들어줌 >


서블릿 객체의 생명주기

서블릿 컨테이너 (톰켓)
최초 요청시 > 객체생성 후 실행
재 요청시 > 실행
URL : 자원접근
URI : 식별자 접근
스프링은 URL 자원접근이 안됨 막아둠

requset 가 java 관련 자원이면 서블릿 컨테이너가 호출
html, css => 아파치가 돔

requset 가 들어왔을때 
1번째 호출 >
1. 서블릿 객체 생성 init() 초기화  호출 
2. service() 호출 (POST, GET, PUT, DELETE 중 어느것으로 요청인지 판별)
- service 는 호출되기 직전에 새로운 스레드1이 생성되서 service를 호출함

2번째 호출 (재사용함) >
init() 호출 X

스레드 2번을 생성해서 실행

자바의 메모리
static heap, stack >> heap 에는 hello() 를 스캔 저장, stack에는 hello() 의 내부코드를 저장
>>> new 를 할 시에 stack 에는 heap 과 다르게 호출시마다 hello() 내부코드의 독립적인 공간을
호출 후 만큼 생성

 

Pooling 기법
톰켓 기본설정 > Auto
ex) 20개로 저장해두고 21번째 요청이 오면 21번째 요청은 대기.
>앞의 요청(스레드1)이 끝나서 response 가 되면 21번의 스레드를 생성하지 않고 스레드1 번을 재사용

1 . requset 
- 최초요청시 서블릿객체 생성 > 판별후 스레드 1 생성
response 후 > 스레드 1을 제거하지 않고 스레드 1 재사용 

2. ex) 20명 동시접근시 (스레드 제한 20한다면)
스레드가 20개가 생성됨
25명 동시접근시 20개로 돌리고 나머지 5명대기, response 가끝나는대로 각각의 스레드를 재사용
컴퓨터의 성능을 업그레이드 = 스케일업
분산능력을 키움 = 스케일 아웃



웹 배포서술자 web.xml

★mine type? 데이터의 타입이 뭐냐 확인 후 데이터 가공
welcome file list >>>> 목적이 없는 접근을 특정 위치로 보냄( 메인페이지 같은, )
리스너 > 특정 요청에 반응
- ServletContext 의 초기 파라미터
- Session의 유효시간 설정
- Servlet/JSP 에 대한 정의
- Servlet/JSP 매핑
- Mime Type 매핑
- Welcom File list
- Error Pages 처리
- 리스너/ 필터 설정
- 보안

 >>> web.xml 에 할일이 많아지기 때문에 FrontController 패턴을 사용.

FrontController 패턴

requset 요청 URI, JAVA File > 바로 자원 접근 X > 톰켓 > web.xml > FrontController
ex) .do(특정주소) 는 FrontController 가 잡아주게 설정가능
> FrontController 가 새로 requset 해서 자원에 접근 (덮어씌움)
>> 이렇게 되면 처음에 받은 requset/ response 의 정보가 없어질 수 있다 > 이걸 방지하기위해서 있는것이
requsetDispatcher  (FrontController 에 도달했을때 기존의 req, res 를 유지 재사용)
★이걸 사용해야지 페이지간 데이터 이동이 가능


DispatchServlet 

DispatchServlet 은 FrontController  + requsetDispatcher 임
따라서 Spring 에서는 패턴을 직접 짜거나 구현 할 필요가 없음 ( JSP 에서는 따로 해줘야한다)
DispatchServlet 이 자동생성되서 수많은 객체가 IoC 된다 보통 필터들.
하는일 주소분배, 


스프링 컨테이너

ApplicationContext 에 수 많은 객체들이 등록됨 IoC 

web.xml > DispatchServlet(컴포넌트 스캔) 전에 실행이되는게 있음
ContextLoaderListener 가 root-ApplicationContext file을 읽음
공통적(DB)으로 쓰이는것을 읽어줌

DispatchServlet (Servlet-Application) > 은 DB 에 접근이 가능
 root-ApplicationContext 에서 읽은 DB 는 DispatchServlet (Servlet-Application) 에서 스캔뜬 IoC에 접근이 불가능(아직 로드가 안되어있음)
root => 최상위에서 모든정보를 꿰참 => DB관련 객체를 생성
servlet => 웹과 관련된 모든정보를 꿰참

Root-ApplicationContext 
-> Service , Repositories

Servlet-Application
-> controllers, ViewResolver, HandleMapping

Bean Factory
초기에 메모리에 로드되지 않고 필요할 때 메모리에 로드 IoC > layz-loading 이 됨
@confinguation
class A {
 @Bean
 asdf();
}


요청 주소에 따른 적절한 컨트롤러로 요청 (Handle Mapping)

응답 
- html , jsp등 파일을 응답 > ViewResolver
 해당 파일 앞, 뒷머리말에 web-INF/views/파일이름.jsp   경로와 확장자를 붙여준다
> Data 를 응답 > MessageConverter (기본전략 JSON)
>> @ResponseBody > 해당 리턴값을 data 로 인식 > MessageConverter(jackson) 가 JSON으로 변환해줌 (일반 String이 아닌 Entity라면 )