ThreadLocal
- 같은 스레드 내의 어디서든 접근 가능한 변수
- 스레드 내에서 작업이 완료된 후 꼭 스레드 로컬 변수를 클리어 해야함(해당 스레드를 다시 사용할 때 기존에 반납되지 않은 ThreadLocal 변수에 접근해 예상치 못한 결과를 나게 할 수 있음)
Thread per request
- WAS는 ThradPool을 생성함 (Tomcat 기본값 200)
- HTTP 요청이 들어오면 Queue에 적재되고, ThreadPool 내의 특정 Thread가 Queue에서 요청을 가져와 처리하게됨
- HTTP 요청은 처음부터 끝까지 동일한 Thread에서 처리됨
- HTTP 요청 처리가 끝나면 Thread는 다시 ThreadPool에 반납됨
- 즉, WAS의 최대 동시 처리 HTTP 요청의 갯수는 ThreadPool의 갯수와 같음
- Thead 갯수를 늘리면 동시 처리 갯수가 늘어나지만, Thread Context 스위칭에 의한 오버헤드도 커지기 때문에 성능이 선형적으로 증가하지는 않음
- WebFlux를 이용할 경우 적은 스레드로 최대한 효율적인 처리를 하기 위해 비동기 논블록킹 방식을 이용함(따라서 기본적인 스레드 per 요청 모델에 맞지 않음)
SecurityContextHolder
- 시큐리티 컨텍스트를 담는 그릇
- 실질적인 구현은 SecurityContextHolderStrategy가 구현함
구현체는 총 3개가 있는데
기본적으로 사용되는 구현체는 ThreadLocalSecurityContextHolderStrategy가 사용된다.
ThreadLocal식으로 ThreadLocal 변수가 사용된다.
즉, SecurityContextHolder.getContext()를 사용하면 컨트롤러, 서비스, 리포지토리 어디서든 접근 가능하다.
위와 같은 구조로 되어 있고 세부적인 내용을 살피자면 아래와 같다.
SecurityContext
- SecurityContext는 Authentication에 대한 set, get 메소드가 있다. 즉 인증 정보를 설정하고 불러올 수
있음
Authentication
- Authentication에는 아래의 필드를 갖고 있다.
Principal(인증 전: 로그인 아이디(String), 인증 후: 유저 객체(User)) Credetials(비밀번호) Authorities(권한)
'Spring > Security' 카테고리의 다른 글
Spring Security 8: 데이터베이스를 이용해 인증하기(JPA) #2 (0) | 2023.08.12 |
---|---|
Spring Security 7: 데이터베이스를 이용해 인증하기(JDBC) #1 (0) | 2023.08.11 |
Spring Security 5: Security Filter #4 (0) | 2023.08.11 |
Spring Security 4: Security Filter #3 (0) | 2023.08.10 |
Spring Security 3: SecurityFilter #2 (0) | 2023.08.08 |