웹서버란?
- 정적으로 화면(CSS, HTML, JS)을 다루는 서버
- Apache, Nginx등이 존재
- 특징
- 로드밸런싱
- 보안 설정 가능
- 리버스 프록시 : 서버의 경로를 알 수 없게끔 함
WAS(Web Application Server)란?
- 동적으로 화면을 구성할 수 있게끔 해주는 서버
- DB와의 상호작용으로 화면을 구성
- 내부에 서블릿 컨테이너를 포함
서블릿이란?
- WAS에서 구동되는 자바 프로그램
- init(), service(), destroy() 함수가 존재
- 나오게 된 계기
: 초반에는 CGI(Common Gateway Interface) 방식으로 실행이 되었습니다.
해당 방식은 URL 요청당 프로세스가 실행되는 방식으로 효율성이 낮다는 판단하에 서블릿 방식으로 변환되었습니다.
변환방식
URL 요청이 발생하면 서블릿 컨테이너 내부에 멀티 쓰레드 방식으로 서블릿을 구동합니다.
이는 싱글톤 패턴으로 구성되어있기 때문에 만일 컨테이너 내부에 서블릿이 존재하면 init은 생략하고 service코드를 실행합니다.
서블릿 컨테이너가 구동될 초기에 서블릿 인스턴스는 모두 초기화되며, destroy의 호출 시점은 서블릿 컨테이너가 조절합니다.
서블릿 컨테이너란?
- 서블릿이 구동될 수 있는 환경을 제공
- 서블릿 생명주기를 관리
- 서블릿과 URL을 1대 1 매칭을 시켜줌
- 종류에는 Tomcat등이 존재
Spring MVC 구조의 탄생배경
CGI 방식이 비효율적이라는 판단 하에 서블릿방식으로 변환을 하였지만, 이 또한 service 함수 내부에 view코드가 중복해서 호출이 된다는 단점이 존재했습니다.
이에 따라 dispatcherServlet이 탄생하였습니다.
이는 프론트 컨트롤러로써 각 URL마다 호출되는 서블릿을 매핑시켜주며 viewResolver와도 상호작용합니다.
기존에는 한 url 요청 당 하나의 서블릿을 생성하였지만, 이제는 dispatcherservlet하나만 생성하여 컨트롤러로 1대1 매핑을 해주는 구조로 변경
Model : 어플리케이션의 데이터를 정의하는 것
View : 어플리케이션에서 보여줄 화면을 보여주는 것
Controller : Model과 View를 연결하며, 내부 비즈니스 로직을 수행한다.
- Tomcat을 통해 요청이 들어옴
- filter을 거침 -> HTTPServletRequest & HTTPServletResponse로 요청을 넘겨줌
- dispatcher servlet으로 요청이 넘어감
---여기 까지는 servlet container 영역 - handler mapping으로 요청에 해당되는 controller를 찾음
- 해당 컨트롤러를 구현체인 handler adapter로 수행되게끔 함
- interceptor을 거침
- AOP를 거침
- 컨트롤러에서 비즈니스 로직 수행 -> model & view 반환
- AOP -> interceptor를 거친 뒤 dispatcherServlet으로 다시 돌아옴
- ViewResolver에게 해당 view가 존재하는지 확인 -> 있으면 화면에 보여줌
AOP vs Interceptor vs Filter
- 공통되는 코드의 중복을 제거하기 위해서 사용
- filter
- spring container 외부 영역에 존재
- spring과 관련없는 공통로직들을 수행(XSS 방지 등)
- request, response 조작 가능
- dispatcher servlet 외부에 존재
- throw를 던지면 따로 에러처리를 해줘야 함
- interceptor
- 세부적인 보안 로직 처리
- 컨트롤러의 전후로 호출
- 응답이 boolean타입으로만 가능. 객체의 정보 수정정도만 가능
- interceptor에서 throw를 던지면 controller advice에게 넘김
- 왜냐하면 dispatcher servlet 뒤에 있기 때문
- AOP
- 흩어진 관심사를 모듈화함으로써 비즈니스 로직과 부가 로직을 분리시켜주는 기법
- Aspect : 흩어진 관심사를 모듈화 한 것.
- Advice : Aspect의 구현체
- Target : AOP가 적용될 대상
- JoinPoint : AOP가 적용될 구체적인 대상. ex) 메서드 초기
- PointCut : JoinPoint를 정규식으로 표현한 것
- 2가지 방법으로 구현
- JDK Proxy- 인터페이스를 구현한 것을 프록시 객체로 생성
- 리플렉션 기법을 활용하여 성능 저하
- Spring AOP의 기본 방식
- CGLIB 방식
- 프록시 객체는 클래스를 상속받음
- 매개변수로 클래스에 대한 정보가 넘어오기에 리플렉션 기법은 활용X -> 성능 좋음
- Spring Boot의 기본 방식
- 리플렉션 기법이란*
- 클래스에 대한 정보를 모를 때 이름을 바탕으로 정보를 가져올 수 있는 자바 API
- static 영역에 클래스 정보를 저장해두기 때문에 런타임시에도 클래스 정보를 가져올 수 있다.
- 대신 성능저하가 발생한다.
- IOC 컨테이너는 리플렉션 기술을 활용하여 인스턴스를 싱글톤 패턴으로 생성하여 주입시킨다.
- 따라서 엔티티의 경우 기본생성자가 필요한 데, 기본생성자를 활용하여 클래스의 정보를 가져오기 때문이다.
프록시 패턴이란?
- 프록시는 대리인을 뜻하는 말로, 부가적인 기능을 프록시에게 위임하고 핵심 코드는 본 서브젝트가 담당할 수 있도록 하는 패턴
- ex) AOP
이처럼 부가가능을 프록시 객체를 이용하여 대신 처리한다.
Spring Security
- 인가, 인증 요청을 처리해주는 스프링 하위 프레임워크
- 서블릿 필터단에서 스프링 기능을 활용할 수 있는데요, 이는 서블릿 필터 내부에 delegating filter proxy가 스프링 빈을 담고 있는 filter chain proxy를 담고 있어 서블릿 필터와 스프링 필터를 이어주는 역할을 수행하기 때문입니다.
요청 수행 순서
1. filter로 요청이 들어옴 -> doFilter을 통해서 필터체인을 타고 들어감
2. delegating filter proxy bean을 만남
3. delegating filter proxy 내부의 filter chain proxy에서 스프링 빈들을 필터 체인으로 엮어서 가지고 있음
4. 필터체인 중에 exception이 존재하지 않다면, 넘어감
스프링부트 사용 시 내장 톰캣을 사용하기 때문에 delegating filter proxy가 없어도 자동으로 스프링빈을 필터에 등록시켜줌
세부 수행 순서
1. 클라이언트가 password, username을 입력
2. authentication filter로 요청이 들어옴
3. 인증되지 않은 usernamePasswordAuthenticationToken이 생성됨
3. Authentication manager가 실질적인 구현체인 Authentication Provider에 있는 authenticate함수를 호출
4. 해당 함수를 통해 userdetailsService를 통해 dB조회 후 userdetails를 반환받음(인증된 authentication)
5. Authentication manager가 해당 authentication을 security context holder 내부에 있는 security context에 저장함
6. 해당 security context는 thread local이기에 특정 쓰레드 내부 어디서나 호출 가능
