어떤 자바 웹 어플리케이션이던지 요청을 받으면 그것을 HTTP프로토콜로 전송한다.
왜? 우리 브라우저들은 HTTP 프로토콜로만 이해할 수 있기 때문.
HTTP프로토콜을 이용해서 내 브라우저들은 내 WAS에 요청을 보낼 수 있다. (프론트 -> 백)
서블릿
내 자바 코드들은 이러한 HTTP프로토콜 요청을 이해할 수 없어서 자바코드와 브라우저 사이에 중개자가 존재한다.
이 중개자를 우리는 서블릿 컨테이너(Servlet Container) 또는 웹 서버라고 부른다.
우리는 서블릿 컨테이너인 Apache Tomcat같은 웹 서버를 사용한다.
이 중개자, 서블릿 컨테이너가 할 일은 브라우저로부터 받은 HTTP메시지를 ServlerRequest Object로 변환하는 것이다.
그리고 이 동일한 Object를 WAS에 사용하고 있는 자바 코드 프레임워크(Jakarta)에도 주어진다.
비슷하게도 브라우저에 다시 요청을 보내려고 할때 서블릿은 HTTP ServletResponse Object를 가져다가 브라우저가 이해할 수 있는 HTTP 메시지로 변환한다.
이러한 모든 작업은 서블릿이라는 컨셉 때문에 일어난다.
서블릿은 웹 어플리케이션에서 매우 중요한 역할을 하지만 안타깝게도 그들의 복잡한 로직 때문에 아무도 직접 사용하려고 하지 않는다.
따라서 우리의 일을 쉽게 만들기 위해 Spring Boot와 Spring FrameWork가 등장하게 된 것이다.
그럼 내부적으로 Spring Boot와 Spring Framework가 서블릿을 생성하고, 서블릿 관련된 복잡한 로직 또한 얘네들이 담당해서 처리한다.
필터
서블릿이 있는 것과 같이 웹 애플리케이션에는 필터라는 개념이 존재한다.
필터는 특별한 종류의 서블릿으로 웹 애플리케이션을 향해 들어오는 모든 요청을 가로챌 수 있다. (인터셉터와는 다름)
이러한 필터에는 실질적인 비즈니스 로직이 실행되기 전에 일어났으면 하는 프리 로직이나 프리 워크를 정의할 수 있다.
고객은 TomCat과 같은 서블릿 컨테이너에 배포한 백엔드 WAS에 요청을 보내려고 한다.
그러면 아래 화면처럼 HTTP Request가 WAS로 보내지는데, 스프링(톰캣같은 서블릿 컨테이너에 배포한 자바 프레임워크)에서 구현한 필터에 먼저 낚아채지게 된다.
이러한 클라이언트와 실질적인 서블릿 사이에 필터를 사용할 수 있다. 그리고 이러한 필터들은 웹 애플리케이션에 관한 모든 요청을 가로채는 역할을 하게 되고 필터에 정의내린 로직을 실행하게 된다.
이런 필터를 사용해야지만 Spring Security 프레임워크는 웹 애플리케이션에서 한 설정에 따라 보안을 시행한다.
따라서 Spring Security 프레임워크의 내부 구조를 이해하려면 필터와 서블릿의 역할에 대한 이해도를 가지는 것이 매우 중요하다..!!!
'Spring > Spring Security' 카테고리의 다른 글
스프링 시큐리티 - SESSION (3) 인가 작업 (0) | 2024.02.07 |
---|---|
스프링 시큐리티 - SESSION (2) 프로젝트 생성 (0) | 2024.02.07 |
스프링 시큐리티 - SESSION (1) 간단 동작 원리 (0) | 2024.02.06 |
Spring Security 의 내부 동작 과정 (0) | 2024.01.02 |
Spring Security 같은 보안 FrameWork를 사용해야 하는 이유 (0) | 2023.12.29 |