[Spring boot] Spring 처리단계(Filter,DispatcherServlet,InterCepter,controller)

Spring Security를 구현하면서 그 동작원리를 이해하기 위해서는 Spring boot에서 request요청이 들어왔을때 어떤 단계로 처리되는지를 알아야 할 필요가 있다. 

 

구현하는데 급급해서 구현했지만 이론을 잘 모르니 필터나 커스텀이필요한 클래스들을 찾지못해 난감한 경우가 많았다. 차근차근 처리단계부터 공부를 시작해보자.

 

 

요청이 들어오면 위의 그림처럼 처리되는 흐름이다. 하지만 실제로는 Interceptor가 Controller로 요청을 위임하지는 않으므로, 아래의 그림은 처리 순서를 도식화한 것으로만 이해하고 자세한건 아래에서 살펴보자.

 

1. Filter

2. DispatcherServlet

3. Interceptor 

4. Controller

 

이런 단계를 거쳐 controller를 지나게 되는데 이를 숙지하고 하나씩 파헤쳐 보도록 하자.

 

Filter

<필터의 기본구조>

출처 -&nbsp;https://javacan.tistory.com/entry/58

필터는 Dispatcher-Servlet 이전 (Spring Context진입 전 Web Container가 관리한다)에 동작한다. 필터는 J2EE 표준 스펙 기능으로 디스패처 서블릿에 요청이 전달되기 전, 후에 url 패턴에 맞는 모든 요청에 대해 부가 작업을 처리할 수 있는 기능을 제공한다. 즉, 스프링 컨테이너가 아닌 톰캣과 같은 웹 컨테이너에 의해 관리가 되므로 디스패처 서블릿으로 가기 전에 요청을 처리하는 것이다. 그렇기 때문에 필터에서는 스프링과 무관하게 전역적으로 처리해야 하는 작업들을 수행하면 좋다. (대표적으로 보안관련) 그러면 스프링 컨테이너까지 요청이 전달되지 못하고 차단되므로 안정성을 더욱 높일 수 있다.

필터란  'HTTP 요청과 응답을 변경할 수 있는 재사용가능한 코드'이다. 필터는 객체의 형태로 존재하며 클라이언트로부터 오는 요청(request)과 최종 자원(서블릿/JSP/기타 문서) 사이에 위치하여 클라이언트의 요청 정보를 알맞게 변경할 수 있으며, 또한 필터는 최종 자원과 클라이언트로 가는 응답(response) 사이에 위치하여 최종 자원의 요청 결과를 알맞게 변경할 수 있다. 이를 그림으로 표현하면 위와 같다.

유일하게 ServletRequest, ServletResponse의 객체를 변환할 수 있다.

 

자원이 받게 되는 요청 정보는 클라이언트와 자원 사이에 존재하는 필터에 의해 변경된 요청정보가 되며, 클라이언트가 보게 되는 응답 정보는 클라이언트와 자원사이에 존재하는 필터에 의해 변경된 응답정보가 된다. 필터는 클라이언트와 자원사이에 1개가 존재하는 경우가 보통이지만, 여러개의 필터가 모여서 하나의 체인(chain)을 형성할 수 있다.

 

출처 - https://twofootdog.github.io/Spring-%ED%95%84%ED%84%B0(Filter)%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80/

 

두번째 그림 같이 여러 개의 필터가 모여서 하나의 체인을 형성할 때 첫번째 필터가 변경하는 요청 정보는 클라이언트의 요청 정보가 되지만, 체인의 두번째 필터가 변경하는 요청 정보는 첫번째 필터를 통해서 변경된 요청 정보가 된다. 즉, 요청 정보는 변경에 변경에 변경을 거듭하게 되는 것이다. 응답 정보의 경우도 요청 정보와 비슷한 과정을 거치며 차이점이 있다면 필터의 적용 순서가 요청 때와는 반대라는 것이다. (그림2를 보면 이를 알 수 있다.)

필터는 변경된 정보를 변경하는 역할 뿐만 아니라 흐름을 변경하는 역할도 할 수 있다. 즉, 필터는 클라이언트의 요청을 필터 체인의 다음 단계(결과적으로는 클라이언트가 요청한 자원)에 보내는 것이 아니라 다른 자원의 결과를 클라이언트에 전송할 수 있다. 필터의 이러한 기능은 사용자 인증이나 권한 체크와 같은 곳에서 사용할 수 있다.

 

필터에 대해 더 깊게 알고 싶다면 아래블로그들을 참고하자

https://javacan.tistory.com/entry/58

https://twofootdog.github.io/Spring-%ED%95%84%ED%84%B0(Filter)%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80/ 

 

Dispatcher Servlet

 

여기서부터는 Spring이 제공해주는 기능이다. 디스패처 서블릿의 dispatch는 "보내다"라는 뜻이다. 그리고 이러한 단어를 포함하는 디스패처 서블릿은  HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러(Front Controller)
라고 정의 할 수 있다.

클라이언트로부터 어떠한 요청이 오면 Tomcat(톰캣)과 같은 서블릿 컨테이너가 요청을 받게 된다. 그리고 이 모든 요청을 프론트 컨트롤러인 디스패처 서블릿이 가장 먼저 받게 된다. 그러면 디스패처 서블릿은 공통적인 작업을 먼저 처리한 후에 해당 요청을 처리해야 하는 컨트롤러를 찾아서 작업을 위임한다. 

Front Controller는 주로 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아서 처리해주는 컨트롤러로써, MVC 구조에서 함께 사용되는 디자인 패턴이다.

 

Dispatcher Servlet 동작 과정

출처 -&nbsp;https://mangkyu.tistory.com/18

 

1. 클라이언트의 요청을 디스패처 서블릿이 받음
2. 요청 정보를 통해 요청을 위임할 컨트롤러를 찾음
3. 요청을 컨트롤러로 위임할 핸들러 어댑터를 찾아서 전달함
4. 핸들러 어댑터가 컨트롤러로 요청을 위임함
5. 비지니스 로직을 처리함
6. 컨트롤러가 반환값을 반환함
7. 핸들러 어댑터가 반환값을 처리함
8. 서버의 응답을 클라이언트로 반환함

 

출처 -&nbsp;https://velog.io/@zooyeop/Spring-Dispatcher-ServletFilterInterceptor-1

 

디스패처 서블릿에 관해 더자세하게 알고 싶다면 아래블로그를 참고하자

https://mangkyu.tistory.com/18

[Spring] Dispatcher-Servlet(디스패처 서블릿)이란? 디스패처 서블릿의 개념과 동작 과정

 

Interceptor

 

컨트롤러(Controller)의 '핸들러(Handler)'를 호출하기 전과 후에 요청과 응답을 참조하거나 가공할수 있는 일종의 필터이다. interceptr 란 단어는 '낚아채다'라는 의미이다. 해당 단어의 의미와 같이 사용자 요청에 의해 서버에 들어온 Request 객체를 컨트롤러의 핸들러(사용자가 요청한 url에 따라 실행되어야 할 메서드, 이하 핸들러)로
도달하기전에 낚아채서 개발자가 원하는 추가적인 작업을 한후 핸들러로 보낼수 있도록 해주는것이 인터셉터 이다.

 

인터셉터에서는 클라이언트의 요청과 관련되어 전역적으로 처리해야 하는 작업들을 처리할 수 있다. 개발자는 특정 Controller의 핸들러가 실행되기 전이나 후에 추가적인 작업을 원할때 Interceptor를 사용한다. 대표적으로 인증이나 인가와 같이 클라이언트 요청과 관련된 작업 등이 있다. 이러한 작업들은 컨트롤러로 넘어가기 전에 검사해야 하므로 인터셉터가 처리하기에 적합하다.

또한 인터셉터는 필터와 다르게 HttpServletRequest나 HttpServletResponse 등과 같은 객체를 제공받으므로 객체 자체를 조작할 수는 없다. 대신 해당 객체가 내부적으로 갖는 값은 조작할 수 있으므로 컨트롤러로 넘겨주기 위한 정보를 가공하기에 용이하다. 예를 들어 JWT 토큰 정보를 파싱 해서 컨트롤러에게 사용자의 정보를 제공하도록 가공할 수 있는 것이다.

 

interceptor에 대한 더 자세한 내용은 아래블로그를 참고하자

https://popo015.tistory.com/115

[Spring] 스프링 인터셉터(Interceptor)란 ?

 

 

이렇게 보면 Filter와 interceptor가 비슷해보이는데 차이점이 뭘까?

 

https://velog.io/@zooyeop/Spring-Dispatcher-ServletFilterInterceptor-1

 

필터와 인터셉터 모두 비즈니스 로직과 분리되어 특정 요구사항(보안, 인증, 인코딩)을 만족시켜야 할 때 적용하면 좋다. 하지만 필터는 보통 특정 요청과 컨트롤러에 관계없이 전역적으로 적용하면 좋을 때 사용하면 좋다는 것이고, 인터셉터는 요청과 관련된 작업에 대한 추가적인 요구사항을 만족해야 할 때 적용하면 좋다는 것이다. 모든 API가 인증을 요구하진 않을 수도 있으니까 말이다. 그럴 땐 인터셉터를 이용해 특정 요청에 대해서만 인증을 요구하도록 하면 될 것이다.

 

참고 블로그

https://funveloper.tistory.com/27

스프링부트 Filter, DispatcherServlet, Interceptor, Controller

https://velog.io/@zooyeop/Spring-Dispatcher-ServletFilterInterceptor-1

[Spring] Dispatcher Servlet/Filter/Interceptor (1)

 

https://aljjabaegi.tistory.com/632

Springboot MVC Filter, Interceptor, AOP 차이 실행시점 구현방법

 

https://velog.io/@ansalstmd/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-%EB%8B%A4%EC%96%91%ED%95%9C-%EA%B8%B0%EB%8A%A5-5.-Spring-Boot-Filter%EC%99%80-Interceptor

스프링부트 다양한 기능 5. Spring Boot Filter와 Interceptor