스위치(허브)가 아닌 서버 레벨에서의 로드 밸런싱(부하 분산). DNAT(Destination Network Address Translation) 방식을 이용해 하나의 VIP에 여러 서버들이 붙어있을 수 있음예를 들어, nginx g/w의 vip는 하나이지만 실제 서버

: 말 그대로 역할에 따라 리소스에 접근할 수 있는지 여부를 결정 (ex. 상품 관리자 / 채널 관리자 / 일반 유저..): 사용자(역할일 수 있음) / 리소스 속성(유형, 만든 사람, 중요도 등) / 환경(액세스 위치, 날짜 등)과 같이 보다 다양한 속성을 기반으로

위와 같은 방식으로 사용하던 클래스에서 스프링 부트 3.XX(+자바 17)로 업데이트 이후 오류가 발생했다. (빨간 줄과 함께 에러는 뜨지만 돌아는가는 케이스..)https://www.baeldung.com/configuration-properties-in-s

프로그래밍 종류 명령형 프로그래밍 - java 선언형 프로그래밍 함수형 프로그래밍 -> 선언형 프로그래밍 스타일을 어느정도 익힐 수 있음 함수형 프로그래밍 장점 멀티 쓰레드, 멀티 cpu 환경에서 상태를 변경하지 않는 방식을 강조하는 함수형 프로그래밍의 이점 ( 객

테스트 종류1\. 도메인 객체 단위테스트2\. 인수테스트3\. 서비스 레이어 테스트=> 계속 하고자 하는 부분은 서비스에 산재되어있던 비즈니스 로직을 연관된 도메인 객체로 옮기고 도메인 객체 단위테스트를 작성하는 것=> 이렇게 됐을 때 서비스 레이어의 mock 기반 테

상속 관계 (Is - a 관계)조합 관계(has - a 관계)\-> 둘 다 가능한 경우 조합을 먼저 트라이 해보는게 좋음.코드의 재사용성 측면에서는 상속이 유리하지만, 유연성 측면에서는 조합이 더 유리.조합도 코드를 재사용하는 거긴함 (좀 더 코드가 많아진다는 단점)가

자바는 가장 작은 동작 단위가 클래스 -> 람다처럼 함수로 구현해도 결국 내부 구현은 클래스이다인터페이스 추출해서 넣어주는거 자체가 DI(Dependancy Injection) -> 소프트웨어의 유연성을 위해 스프링 이전부터 많이 쓰던 기법.리팩토링 전리팩토링 후\->

테스트하기 어려운 코드를 object graph의 상위쪽으로 옮긴다 (옮기기 전 단계는 결국 테스트할 수 없어지지만, 우리는 모든 코드를 테스트하는게 목표는 아님)\-> 테스트 하기 어려운 부분을 분리해서 핵심로직을 테스트하는게 목적메소드의 크기가 최대 10라인을 넘지

TDD는 단순 테스트 기법이 아니라, 요구사항을 분석하고 설계하는 기법이다.요구 사항을 작은 단위로 쪼갠다각 요구 사항에 맞는 테스트 코드를 작성한다.테스트 코드를 하나 완성할 때마다(최소 요구 사항 단위) 테스트를 통과하기 위한 실제 기능 코드를 구현한다.(이 과정에

일단 flatMap과 doOnNext의 차이는,flatMap은 앞에서 전달받은 아이템을 다른 형태로 변환하여 방출하는 반면, doOnNext는 로깅, api 콜과 같은 부가적인 동작을 하되, 전달받은 아이템을 변환하여 넘기는 동작은 하지 않는다는 점이다. 즉, sour

상속에서 쓰임.추상 클래스가 설계도인 인터페이스를 구현(implements)하는 경우\-> 위 예시와 같이 Transport 인터페이스에 정의된 메서드들(반드시 모두 public abstract, 생략 가능)을 override하며 default가 되는 값을 반환해줄 수

비밀번호를 그대로 보내지 않음 -> 비밀번호를 비가역적으로 섞은 지문(fingerprint) 혹은 요약(digest)를 보냄 재전송 방지를 위한 난스 이용 -> 난스를 비밀번호에 섞으면 난스가 바뀔 때마다 요약도 바뀌게 만들어줌

HTTP는 다음을 보장객체는 올바르게 식별됨 (Content-Type, Content-Language)객체는 올바르게 압축이 풀림(Content-Length, Content-Encoding)객체는 항상 최신(엔티티 검사기, 캐시 만료 제어)사용자의 요구를 만족(Acce

HTTPS는 HTTP의 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작이 보안 계층은 Secure Socket Layer(SSL) 혹은 Transport Layer Security(TLS)를 이용해 구현된다 SSL, HTTPS에는 암호 인코딩 기법이 적용된다

인증은 내가 누구인지 증명하는 것.HTTP에는 기본 인증과 다이제스트 인증이 있음<기본 인증 예시>(a) 요청을 보냄(b) 서버가 사용자에게 인증요구를 보냄. 401 Unauthorized + WWW-Authenticate 헤더(어디서 어떻게 인증할지 설명)(c)

서버에서 클라이언트 IP를 알 수 있는 방법nginx 같은 웹 서버에서는 기본적으로 remote_addr 헤더를 통해 클라이언트 IP를 얻을 수 있음그러나 nginx에 도달하기 전에 프록시, 로드밸런서 등을 거치는 경우에는 이러한 클라이언트 IP가 프록시의 IP로 변경

HTTP/1.1은 구현의 단순성과 접근성에 주안점을 둠\-> 성능이 희생됨 (ex. 응답을 받아야만 그 다음 요청을 보낼 수 있음)\-> 이런 문제를 해결하기 위해 병렬 커넥션(커넥션을 동시에 여러개 맺는건데, 근본적인 해결책은 아님), 파이프라인 커넥션(사용되지 않음

웹 관리자는 웹 사이트의 모든 콘텐츠에 대한 차단 규칙을 종합적으로 기술한 robots.txt 파일을 생성할 책임이 있다.\-> 없다면 로봇은 제약없이 사이트에 접근한다.\-> 401 혹은 403 권한 없음으로 응답하면 로봇은 해당 사이트로의 접근을 아예 해서는 안된다

백엔드에 레디스가 있다면 프론트엔드에는 웹 캐시(http cache)가 있다. 웹 캐시의 종류브라우저 캐시 : 사용자 컴퓨터의 로컬 저장소에 이전 방문한 웹페이지의 정적 자원을 저장해 사용한다.프록시 웹 캐시 : 클라이언트와 origin 서버 간의 프록시\-> ex)

게이트웨이는 HTTP 트래픽을 다른 프로토콜로 자동 변환 \-> 원 서버의 부하를 줄여주지만, 게이트웨이와 원 서버 사이에 있는 네트워크가 안전한지 확실히 확인하고 써야함애플리케이션 서버도 게이트웨이의 일종. 애플리케이션 서버는 게이트웨이와 목적지 서버를 한 개의 서버