- Files
- .newInputStream
- .toPath()
transient
: Serialize하는 과정에서 제외하고 싶은 경우 선언하는 키워드
- 패스워드와 같은 보안정보가 직렬화 과정에서 제외하고 싶은 경우 적용하거나 데이터를 전송하고 싶지 않을 때 선언
instanceof
: 특정 클래스에 속하는지 확인
# Pair.of
- String.startsWith
:
MessageDigest
MD5, SHA를 이용한 알고리즘을 사용하려면 해당 클래스를 이용해야한다.
해당 클래스에는 update() 메서드가 있는데 이 메서드를 호출할 때 마다 객체 내에 저장된 digest 값이 계속해서 갱신된다.
최종적으로 digest() 메서드를 호출하면 그 값을 가져올 수 있다.
degest()
: 바이트 배열로 해쉬를 반환합니다. 패딩 등의 최종 처리를 행해 해시 계산을 완료.
update()를 실행, 해시 계산 완료 후 해시화된 값을 반환한다.
ByteBuffer
: 바이트 데이터를 저장하고 읽는 저장소
참고
Runnable
Runnable 인터페이스는 구현할 메소드가 run() 함수 하나뿐인 인터페이스이다.
runnable은 다른 인터페이스를 구현할 수 있을 뿐만 아니라, 다른 클래스도 상속받을 수 있습니다. 따라서 해당 클래스의 확장성이 중요한 상황이라면 Runnable 인터페이스를 구현하는 것이 더 바람직할 것
참고
- XSS Filter
Filter
J2EE 표준 스펙 기능으로 디스패치 서블릿에 요청이 전달되기 전/후에 url 패턴에 맞는 모든 요청에 대해 부가작업을 처리할 수 있는 기능을 제공
- 스프링 범위 밖에서 처리되는 것
- 스프링 컨테이너가 아닌 톰캣과 같은 웹 컨테이너(서블릿 컨테이너)에 의해 관리가 되는 것 (스프링 빈으로 등록은 된다)
용도 및 예시
필터에서는 기본적으로 스프링과 무관하게 전역적으로 처리하는 작업을 할 수 있다.
인터셉터보다 앞단에서 동작하므로 전역으로 처리해야하는 보안검사(XSS 방어 등)를 하여 올바른 요청이 아닐 경우 차단할 수 있다.
그러면 스프링 컨테이너까지 요청이 전달되지 못하고 차단되므로 안정성을 더욱 높일 수 있다.
또는 이미지나 데이터의 압축이나 문자열 인코딩과 같이 웹 애플리케이션에 전반적으로 사용되는 기능을 구현하기에 적당하다.
-
Filter는 다음 체인으로 넘기는 ServletRequest/ServletResponse 객체를 조작할 수 있다는 점에서 인터셉터보다 훨씬 강력한 기술이다.
-
공통된 보안 및 인증/인가 관련 작업
-
모든 요청에 대한 로깅 또는 감사
-
이미지/데이터 압축 및 문자열 인코딩
-
spring과 분리되어야 하는 기능
init()
: 필터 객체를 초기화하고 서비스에 추가하기 위한 메소드
웹 컨테이너가 1회 init 메소드를 호출하여 필터 객체를 초기화하면 이후의 요청들은 doFilter를 통해 처리
doFilter()
: url-pattern에 맞는 모든 HTTP 요청이 디스패처 서블릿으로 전달되기 전에 웹 컨테이너에 의해 실행되는 메소드이다. doFilter의 파라미터로는 FilterChain이 있는데 doFilter 통해 다음 대상으로 요청을 전달하게 된다.
destory()
: 필터 객체를 서비스에서 제거하고 사용하는 자원을 반환하기 위한 메소드
웹 컨테이너에 의해 1번 호출되며 이후에는 이제 doFilter에 의해 처리되지 않는다.
interceptor
spring이 제공하는 기술로 디스패처 서블릿이 컨트롤러를 호출하기 전/후에 요청과 응답을 참조하거나 가공할 수 있는 기능 제공
- 스프링 컨텍스트에서 동작
- HandlerInterceptor를 구현받아야한다.
- 디스패처 서블릿은 핸들러 매핑을 통해 적절한 컨트롤러를 찾도록 요청하는데 그 결과로 실행 체인 (HandlerExecutionChain)을 돌려준다.
그래서 이 실행 체인은 1개 이상의 인터셉터가 존재하면 순차적으로 인터셉터를 거쳐서 컨트롤러가 실행되게하고 없다면 바로 컨트롤러를 실행한다.
preHandle()
: preHandle 메서드는 컨트롤러가 호출되기 전에 실행되기 때문에 그렇기 때문에 컨트롤러 이전에 처리해야 하는 전처리 작업이나 요청 정보를 가공하거나 추가하는 경우에 사용할 수 있다.
- 반환 타입이 Boolean이기 때문에 반환값이 true이면 다음단계로 넘어가고 아니면 작업을 중단하여 이후의 작업(다음 인터셉터 또는 컨트롤러)은 진행되지 않는다
postHandle()
: 컨트롤러를 호출한 후에 실행된다.
컨트롤러 이후에 처리해야 하는 후처리 작업이 있을 때 사용
- 이 메소드는 ModelAndView 타입의 정보가 제공되는데 최근에 json 형태로 데이터를 제공하는 restApi기반의 컨트롤러 @RestController를 만들면서 자주 사용하지 않는다
- 컨트롤러 하위 계층에서 작업을 진행하다가 중간에 예외가 발생하면 해당 메서드는 호출되지 않는다
afterCompletion()
: 모든 뷰에서 최종 결과를 생성하는 일을 포함하여 모든 작업이 완료된 후에 실행.
요청 처리 중에 사용한 리소스를 반환할 때 사용하기에 적합하다.
postHandler와 달리 컨트롤러 하위 계층에서 작업을 진행하다가 중간에 예외가 발생하더라도 반드시 호출된다.
참고
로드밸런싱
네트워크/서버 요청 받은 것을 여러 서버로 부하 분산 시켜주는 것
작업을 나누는 것
1) Scale-up : 서버 자체의 성능을 확장하는 것. 비유하자면 CPU가 i3인 컴퓨터를 i7으로 업그레이드하는 것과 같다.
2) Scale-out : 기존 서버와 동일하거나 낮은 성능의 서버를 두 대 이상 증설하여 운영하는 것을 의미한다. CPU가 i3인 컴퓨터를 여러 대 추가 구입해 운영하 것에 비유할 수 있다.
=> 이 경우, 여러 대의 서버로 트래픽을 균등하게 분산해주는 로드밸런싱이 반드시 필요하다!!
로드밸런싱 알고리즘
- 라운드로빈방식
- 서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식
- 클라이언트의 요청을 순서대로 분배하기 때문에 여러대의 서버가 동일한 스펙을 가지고 있고 서버와의 연결(세션)이 오래 지속되지 않는 경우에 활용하기 적합.
- ip 해시방식( auth에 통신 보낼 때 / 특정 connector에만 call을 할 수 있게 처리 )
- 클라이언트의 ip 주소를 특정 서버로 매핑하여 요청을 처리
- 사용자의 ip를 해싱해서( 임의의 길이를 지닌 데이터를 고정된 길이의 데이터로 매핑하는 것 또는 그러한 함수 ) 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장한다.
로드밸런서
참고
