Base64
- 이진 데이터를 ASCII 문자로 바꾸는 인코딩 방식
- ASCII 는 7bit 이고 1bit는 시스템별로 처리하는 방식이 상이하고 일부 제어문자의 경우 시스템별로 다른 코드 값을 가짐
- 따라서 Base64 는 이진 데이터를 시스템 독립적으로 동일하게 전송 또는 저장되는 것을 보장하기 위해 사용함
- ASCII 중 안전한 64개의 출력 문자를 사용
- 데이터를 6비트 단위로 자름(64진법)
- 자른 데이터를 Base64 코드표의 0~63에 해당하는 문자로 변환하는 것을 반복
JWT
- Header - JWT 에서 사용할 타입과 해시 알고리즘 종류
- Payload - 서버에서 첨부한 사용자 권한 정보와 데이터
- Signature - Header, Payload 를 Base 64 URL safe Encode 하고 Header 에 명시된 해시함수를 적용하고, 개인키로 서명한 전자서명
JWT Filter
- request에 token이 포함되어있으면 추출하여 validation 하고 유효하면 인증객체를 생성하여 SecurityContextHolder 에 저장
필터
디스패처 서블릿
- 스프링 프레임워크에서 요청을 먼저 받는 프론트 컨트롤러
- 요청을 처리할 컨트롤러를 찾아서 요청을 위임해주는 역할
인터셉터
- 스프링 기술
- 디스패처 서블릿이 컨트롤러를 호출하기 전/후에 처리
- 필터 -> 디스패처 서블릿 -> 인터셉터 -> 컨트롤러
인터셉터 vs AOP
- 인터셉터 대신 컨트롤러에 적용할 부가기능을 어드바이스로 만들어 AOP 적용가능
- 단 인터셉터를 사용하는 것이 나을 수 있음
- 컨트롤러는 타입과 실행 메서드가 제각각이라 포인트컷 작성이 어려움
- 컨트롤러는 파라미터나 리턴 값이 일정하지 않음
- AOP에서는 HttpServletRequest, HttpServletResponse 객체를 얻기 어렵지만 인터셉터에서는 파라미터로 넘어옴
필터 vs 인터셉터
- 필터는 Request, Response 객체를 다른 객체로 바꿔서 전달하는 것이 가능
- 인터셉터는 true, false 로 반환하므로 Request, Response 객체를 바꾸는 것이 불가능
- 필터는 스프링과 무관하게 전역적으로 처리해야하는 작업들
- 인터셉터는 세부적으로 처리해야하는 인증/인가 작업들, 특정 그룹 사용자에 대한 처리 등
인증vs인가
- 인증
- 사용자가 누구인지 확인하는 행위 ex) 로그인
- 인가
- 사용자의 권한이 있는지 확인하는 행위 ex) 유저 권한, 어드민 권한
트랜잭션
- 물리 트랜잭션
- 실제 데이터베이스에 적용되는 트랜잭션으로, 커넥션을 통해 커밋/롤백하는 단위
- 논리 트랜잭션
- 스프링이 트랜잭션 매니저를 통해 트랜잭션을 처리하는 단위
- 트랜잭션 진행중 추가로 트랜잭션을 사용하는 경우에 사용
- 논리 트랜잭션, 물리 트랜잭션 동작 원칙
- 모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션이 커밋됨
- 하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션은 롤백됨
- 내부 논리 트랜잭션이 롤백되면 롤백 전용 마크를 표시
- 외부 트랜잭션을 커밋할 때 롤백 전용 마크를 확인하여 롤백 전용 마크가 표시되어 있으면 물리 트랜잭션을 롤백하고, UnexpectedRollbackException 예외가 발생함
- 스프링 JPA 에서 readOnly=true 설정시 성능 최적화 발생
- 트랜잭션 커밋 시점에 플러시 호출하지 않음
- 변경 감지를 위한 스냅샷 객체를 생성하지 않음
- 예외
- 체크 예외 발생시 트랜잭션 커밋
- 언체크 예외 발생시 트랜잭션 롤백
- 전파
- 트랜잭션 진행 중 추가로 트랜잭션을 수행했을 때 어떻게 동작할지 결정하는 것
- REQUIRED
- 기존 트랜잭션이 없으면 생성하고, 있으면 참여
- 기존 트랜잭션 없음: 새로운 트랜잭션을 생성
- 기존 트랜잭션 있음: 기존 트랜잭션에 참여
- REQUIRES_NEW
- 항상 새로운 트랜잭션을 생성
- 기존 트랜잭션 없음: 새로운 트랜잭션을 생성
- 기존 트랜잭션 있음: 새로운 트랜잭션을 생성
- SUPPORT
- 기존 트랜잭션이 없으면, 없는대로 진행하고, 있으면 참여
- 기존 트랜잭션 없음: 트랜잭션 없이 진행
- 기존 트랜잭션 있음: 기존 트랜잭션에 참여
- NOT_SUPPORT
- 트랜잭션을 지원하지 않는다는 의미
- 기존 트랜잭션 없음: 트랜잭션 없이 진행
- 기존 트랜잭션 있음: 트랜잭션 없이 진행(기존 트랜잭션 보류)
- MANDATORY
- 트랜잭션이 반드시 있어야 함
- 기존 트랜잭션이 없으면 예외 발생
- 기존 트랜잭션 없음: IllegalTransactionStateException 예외 발생
- 기존 트랜잭션 있음: 기존 트랜잭션에 참여
- NEVER
- 트랜잭션을 사용하지 않는다는 의미
- 기존 트랜잭션이 있으면 예외 발생
- 기존 트랜잭션 없음: 트랜잭션 없이 진행
- 기존 트랜잭션 있음: IllegalTransactionStateException 예외 발생
- NESTED
- 기존 트랜잭션 없음: 새로운 트랜잭션을 생성한다.
- 기존 트랜잭션 있음: 중첩 트랜잭션을 만든다.
- 중첩 트랜잭션은 외부 트랜잭션의 영향을 받지만, 중첩 트랜잭션은 외부에 영향을 주지 않음
- 중첩 트랜잭션이 롤백 되어도 외부 트랜잭션은 커밋할 수 있음
- 외부 트랜잭션이 롤백 되면 중첩 트랜잭션도 함께 롤백
ORM vs SQL Mapper
- SQL Mapper
- JDBC 를 편리하게 사용할 수 있음
- 개발자는 SQL 만 작성하면 됨
- JDBC 의 반복 코드를 제거해주고 SQL 응답 결과를 객체로 편리하게 변환해줌
- JdbcTemplate, MyBatis
- ORM
- 객체를 관계형 데이터베이스 테이블과 매핑
- SQL 을 직접 작성할 필요 없음
- JPA (자바 ORM 표준 인터페이스), 하이버네이트, 이클립스 링크
TCP
- 전송 제어 프로토콜(Transmission Control Protocol)
- 데이터 전달 보증, 순서 보장, 신뢰할 수 있는 프로토콜
- 통신하고자 하는 양쪽 단말(Endpoint)이 통신할 준비가 되었는지, 데이터가 제대로 전송되었는지, 데이터가 가는 도중 변질되지 않았는지, 수신자가 얼마나 받았고 빠진 부분은 없는지 등 체크
- 3-way handshake
- TCP 통신은 3-way handshake 를 통해 통신을 시작, 수신자 송신자가 준비가 되어있는지 미리 확인
- SYN, SYN/ACK, ACK
- 송신자가 수신자에게 SYN 전송
- 수신자가 송신자에게 SYN 을 받고 SYN/ACK 를 송신자에게 전송
- 송신자가 수신자의 SYN/ACK 을 받고 ACK 를 전송
- 데이터 전달 보증
- 데이터 전송, 수신자는 송신자에게 ACK 전송
- 순서 보장
UDP
- 사용자 데이터그램 프로토콜(User Datagram Protocol)
- 3-way handshake, 데이터 전달, 순서가 보장되지 않지만 단순하고 빠름
- IP + PORT + 체크섬 정도만 추가된 형태
