3 - 무빈

DB/hjk0761.md

@@ -0,0 +1,60 @@
+[데이터베이스]
+- 데이터베이스에서 인덱스를 사용하는 이유와 장단점
+    - 장점: 정렬된 상태 유지로 조회 성능 향상
+    - 단점: 인덱스를 저장하기 위한 메모리 필요, 조회 이외의 작업(추가, 삭제, 수정 등)시 기존 인덱스 구조를 새로 만들어야 함
+- InnoDB 인덱스 구조
+    - B-Tree(balanced-tree): 루트 노드(인덱스 키:자식 노드 주소), 브랜치 노드(인덱스 키:자식 노드 주소), 리프 노드(인덱스 키:PK 혹은 주소)
+    - 디스크 I/O 를 최대한 줄임
+    - 클러스터링 인덱스: PK 기준으로 클러스터링
+    - Secondary Index: 클러스터링 인덱스(PK 인덱스) 를 제외한 모든 인덱스
+    - 스캔
+        - 인덱스 레인지 스캔: 검색해야 할 인덱스의 범위가 결정된 경우, 리프 노드에서 시작점을 찾고 거기부터 쭉 읽어나감
+        - 인덱스 풀 스캔: 쿼리의 조건절에서 사용된 칼럼이 인덱스의 첫 번째가 아닌 경우, 인덱스 처음부터 쭉 읽어나감
+        - 루스 인덱스 스캔: 중간에 필요하지 않은 인덱스 키 값은 넘어가며 읽어나감
+        - 인덱스 스킵 스캔: 필요하지 않은 인덱스 칼럼을 건너뛰고 읽어나감
+- InnoDB 버퍼 풀, REDO로그, UNDO로그
+    - InnoDB 버퍼 풀: 캐싱을 위한 메모리 공간, MySQL 서버 종료 시 유실
+    - REDO 로그: 변경 내용을 로그로 먼저 기록하여 비정상적인 서버 종료 시 이를 통해 복구
+    - UNDO 로그: 변경되지 이전의 데이터를 보관, 트랜잭션 및 격리 수준 보장을 위해 사용
+- 트랜잭션이란?
+    - 작업완전성, 데이터정합성을 보장하기 위해 논리적인 작업 단위를 온전히 반영하거나, 온전히 복구하도록 하는 기능, MySQL 기준 InnoDB 스토리지 엔진만 트랜잭션 사용
+        - 원자성(Atomicity): 트랜잭션은 온전히 반영되거나, 전혀 반영되지 않아야 함
+        - 일관성(Consistency): 트랜잭션의 처리 결과는 일관성 있어야 함
+        - 독립성(Isolation): 하나의 트랜잭션의 연산에 다른 트랜잭션이 끼어들 수 없음
+        - 지속성(Durability): 트랜잭션이 성공적으로 완료된 경우 결과는 영구적으로 반영되어야 함
+    - 작업 성공 시 Commit 으로 반영 후 결과를 로그에 저장, 실패 시 Rollback 으로 트랜잭션 이전 상태로 복구
+- 트랜잭션 격리 수준: 여러 트랜잭션 간의 작업 내용을 어더ㄸㅎ게 공유하고 차단할 지 결정하는 레벨
+    - Read Uncommited: 각 트랜잭션의 변경 사항이 Commit, Rollback 여부와 상관없이 다른 트랜잭션에서 읽을 수 있음
+        - Dirty Read(커밋되지 않은 데이터를 읽을 수 있는 현상), Non-Repeatable Read, Phantom Read 발생
+    - Read Commited: Commit 이 완료된 데이터만 다른 트랜잭션에서 조회 가능(오라클 Default)
+        - Non-Repeatable Read(한 트랜잭션에서 같은 쿼리를 쏠 때 결과가 다를 수 있는 현상), Phantom Read 발생
+    - Repeatable Read: 변경 전 데이터를 언두 로그로 복사해 한 트랜잭션 안에선 같은 결과가 나오도록 개선(MySQL:InnoDB 스토리지 엔진 Default)
+        - 사실 InnoDB 스토리지 엔진에서 Read Commited 도 이 방법을 사용하지만 이는 주기적으로 삭제됨. Repeatable Read 에서는 현재 트랜잭션 이후의 언두 로그 데이터를 삭제할 수 없도록 제한해 트랜잭션 내부에선 같은 결과를 볼 수 있도록 함
+        - Phantom Read(다른 트랜잭션의 수행에 의해 레코드가 보이거나 안보이는 현상) 발생
+    - Serializable: 읽기 작업에서도 공유 락을 획득해야 함. 
+- MySQL의 Repeatable Read에서의 Phantom Read
+      - InnoDB 스토리지 엔진에서는 갭 락, 넥스트 키 락을 통해 SELECT FOR UPDATE, SELECT LOCK IN SHARE MODE 를 제외하면 Phantom Read 는 발생하지 않음: 이들 쿼리는 레코드에 쓰기 잠금을 거는데 언두 레코드에는 잠금을 걸 수 없으므로 현재 레코드의 값을 가져오게 됨.
+- 데이터베이스 정규화란?
+    - 정의: 데이터 중복을 줄이고 무결성을 향상시키기 위한 과정, 일반적으로 테이블을 작고 잘 조직된 테이블로 나누는 과정을 의미
+        - 제1정규화: 삽입, 갱신, 삭제 이상을 방지하기 위함: 각 요소는 한 개의 값을 가지고, 중복된 테이블을 분리한다.
+        - 제2정규화: 기본키 중 특정 컬럼에만 종속된 컬럼이 없는 상태(완전 함수 종속: 후보키에 속하지 않은 속성은 기본키 전체로만 결정되어야 함)
+        - 제3정규화: 테이블 내의 키가 아닌 모든 컬럼이 테이블의 모든 키에 이행적 종속이 되지 않는 상태(이행 종속: x->y, y->z 일 때 x->z 성립)
+        - BCNF: 모든 결정자가 후보키가 된 상태
+- Join이란?
+    - 복수의 테이블을 연결하는 것
+    - Inner join, Outer join, left join, right join
+- RDBMS vs NoSQL
+    - RDBMS: 관계형 데이터를 기반으로 모든 데이터를 2차원 테이블 형태로 표현하는 데이터베이스 시스템, 외래키를 통한 Join 가능
+        - 장점: 명확한 데이터 구조를 보장, 데이터가 중복되지 않음
+        - 단점: 시스템이 커질 경우 복잡한 쿼리가 생성 가능, Scale-up 만을 지원, 스키마 변경이 어려움.
+    - NoSQL: 스키마와 특정한 데이터 구조 없이, Document, key-value 등 다양한 형태로 저장. Scale-out 을 용이하게 하기 위해 테이블 간 관계를 정의하지 않음. 
+        - 장점: 스키마가 없어 유연하며 자유로운 데이터 구조를 가질 수 있음. 언제든 저장된 데이터를 조정하고 새로운 필드를 추가할 수 있음.
+        - 단점: 데이터 중복이 발생 가능, 중복된 데이터 모든 컬렉션에서 수정 수행. 명확한 데이터 구조를 보장하지 않음, 데이터 구조 결정이 어려움
+- CAP 정리(브루어 정리)
+    - 다음 세 조건을 모두 만족하는 분산 시스템은 존재하지 않는다.
+        - consistency(일관성): 모든 노드가 같은 순간에 같은 데이터를 볼 수 있다.
+        - availability(가용성): 모든 요청이 성공 또는 실패 등의 결과를 반환활 수 있다.
+        - partition tolerance(분할 허용성): 메시지 전달이 실패하거나 시스템 일부가 망가져도 시스템이 계속 동작할 수 있다.
+- 파티셔닝과 샤딩
+    - 파티셔닝: 매우 큰 테이블을 여러개의 테이블로 분리, 물리적으로 분리된 테이블이지만 사용자는 하나의 테이블에 접근하는 것으로 느껴짐
+    - 샤딩: 동일한 스키마를 가진 여러 DB 서버에 데이터를 분산 저장

JPA/hjk0761.md

@@ -0,0 +1,28 @@
+[JPA]
+- JPA란?
+	- JPA(Java Persistence API)란 자바 진영에서 ORM(Object-Relational Mapping) 기술 표준으로 사용되는 인터페이스의 모음으로, 구현된 클래스와 매핑을 해주기 위해 사용되는 프레임워크. JPA를 구현한 대표적인 오픈소스로는 Hibernate, Spring Data JPA가 존재.
+- JPA 사용 이유
+	- 장점: Method를 통해 DB 조작 가능으로 개발자는 객체 모델을 이용하여 비즈니스 로직을 구성하는데만 집중할 수 있음.
+	- 단점: 속도 저하 및 일관성 문제, 복잡하고 무거운 Query는 별도 튜닝이 필요하기 때문에 SQL문을 써야할 수 있음
+- JPA 영속성 컨텍스트
+	- 영속성(영구적인 저장)을 관리하는 환경
+	- Entity Manager 를 통해 Entity 를 저장 및 조회하면 em 이 Persistance Context 에 Entity 를 저장 및 관리함
+	- 트랜잭션 커밋 시에 flush() 가 호출되면서 실제로 DB 에 저장됨
+	- 1차 캐시, 동일성 보장, 쓰기 지연, 변경 감지, 지연 로딩
+    ![image](JPA.png)
+- JPA N+1 문제
+	- 연관 관계에 있는 객체에 Eager(즉시 로딩) 설정 시, 객체 호출 시 연관 관계의 객체들까지 n 번 더 호출하는 문제
+- JPA N+1 문제의 해결
+	- fetch-join: 설정 시 연관된 엔티티도 join 할 때 같이 찾아 한 번에 조회 가능 단, 지연 로딩보다 우선순위가 높아 즉시로딩으로 동작
+- JPA Transaction 전파
+	- @transactional 어노테이션의 propagation 속성으로 설정 가능
+	1. REQUIRED: 기본값, 기존 트랜잭션이 있는 경우 사용, 없으면 새로운 트랜잭션 생성
+	2. REQUIRED_NEW: 항상 새로운 트랜잭션 생성
+	3. SUPPORTS: 기존 트랜잭션이 있는 경우 사용, 없으면 없는대로 진행
+	4. NOT_SUPPORTS: 트랜잭션이 있든 없든 없이 사용
+	5. MANDATORY: 기존 트랜잭션이 있는 경우 사용, 없으면 예외 발생
+	6. NEVER: 기존 트랜잭션이 있는 경우 예외 발생, 없으면 그대로 진행
+	7. NESTED: 기존 트랜잭션이 있는 경우 중첩 트랜잭션 실행, 없으면 새로운 트랜잭션 실행
+- OSIV
+	- Open session in view: 영속성 컨택스트 생명주기를 HTTP 요청의 시작부터 끝까지 연장하는 것 -> 기존은 트랜잭션 범위 안에서만 영속성 컨텍스트가 동작
+	- 비즈니스 계층부터 view 까지 영속성 컨텍스트가 살아 view 랜더링 시에도 쿼리문이 나갈 수 있고, 계층 간 분리가 약화

NETWORK/hjk0761.md

@@ -0,0 +1,74 @@
+[네트워크]
+- 브라우저에 URL을 입력했을 때 무슨 일이 일어날까?
+	- DNS -> IP -> ROUTER -> 등등
+- Ethernet
+	- DataLink 계층, 오류가 발생하면(CLC 로 확인) 그 값을 버림 2계층: 물리 계층으로부터 온 비트를 묶어서 다음계층으로 전달하는 역할
+- CSMA
+	- Carrier Sense Multiple Access/Collision Detection
+	- 반송파 감지(회선 사용 여부) - 다중 접근 - 충돌 감지 - 충돌 신호 - 백오프 알고리즘으로 대기 - 재시도
+	- 네트워크 허브가 생겨 네트워크가 버스형에서 스타형으로 바뀌면서 이더넷에선 충돌이 발생하지 않음
+- IPv4에서 주소 부족 문제의 이유와 해결법
+- TCP
+- TCP handshaking
+	- 3way - 연결 수립 시
+	- 4way - 연결 해제 시
+- TCP Error Control
+	- checksum: TCP checksum 헤더와 비교
+	- ack 및 재전송
+	- parity bit? Cyclic Redundancy Check (CRC)?
+- TCP Congestion Control(혼잡 제어)
+	- 혼잡 제어: 송신, 수신 측 속도 차이로 인해 발생하는 혼잡을 제어하기 위한 기술
+	- congestion window 사용
+	- 마지막으로 전송한 패킷 - 마지막으로 ack 를 받은 패킷 <= cwnd
+	- ack 를 받을 때 window 를 옆으로 하나씩 옮김
+		- cwnd = 패킷 손실 발생 전까지 가법적 증가, 손실 발생 시 승법적 감소
+	- slow start: 시작 시 cwnd = 1, 첫 RTO(retransmission timeout) 발생 전까지 지수적 증가, 발생 시 이전 값을 임계로 두고 다시ㅏ cwnd 를 1부터 지수적 증가, 임계값부턴 기존 로직대로 1씩 증가
+	- congestion avoidance: 3dup ack
+- TCP Flow Control
+	1. Stop and wait: 한 프레임 별로 수신측이 잘 받았으면 ACK 를, 받아야 할 프레임을 못 받았으면 NAK 을 보냄, 데이터 손실으로 수신을 못 받으면 timeout 을 지나면 다시 보냄
+	2. Go-back n: 송신측에선 계속 보냄, 수신으로부터 NAK 을 받으면 그 프레임부터 다시 보내기 시작
+- 그럼 UDP는 왜 쓰나?
+	- 보안보다 속도가 중요할 때 사용
+- UDP로는 신뢰성 있는 통신을 할 수 없나?
+- 종단 간 신뢰성 보장 어떻게 할 수 있나?
+
+- HTTP란 무엇인가?
+    - Hyper Text Transfer Protocol, 요청과 응답으로 정보를 주고 받음, 헤더와 본문으로 이루어짐, 둘 구분은 `\r\n`, 본문 구분은 헤더의 본문 크기를 지정
+    - 무상태성, 클라이언트-서버 모델, OSI 7계층에 위치
+- HTTP 버전별 차이점
+	1. 0.9 - 헤더도 없음
+	2. 1.0 - 헤더 생김, 커넥션 하나 당 요청, 응답 하나씩 처리 가능(요청 마다 커넥션 수립), HTML 외 다른 타입 가능
+	3. 1.1 - timeout 동안 연결 끊지 않음, pipeline, 
+	4. 2.0 - binary 인코딩, multiplexed stream - 한 커넥션이 여러 요청, 응답 처리 가능, 헤더 중복 제거
+	5. 3.0 - QUIC(quick UDP internet connection) - 3way handshaking 	개선
+
+- HOL Blocking이 무엇인가?
+	- Head-of-line blocking: 앞 패킷 처리가 늦어 뒤 패킷들도 지연되는 상황
+- HTTPS는 무엇인가?
+	- HTTP + Secure: SSL/TLS 프로토콜 위에서 작동, 기밀성(TLS 대칭 키로 암호화), 무결성(MAC(메시지 인증 코드)로 데이터 변경 여부 확인), 인증(신뢰가능한 서버임을 증명)의 특징
+	- 구성: TLS(Transport Layer Security), SSL(Secure Socket Layer) + CA 인증서 + 암호화
+- TLS handshaking / CA인증
+	- TLS handshaking: 서버와 클라이언트가 안전한 연결 수립을 위해 암호화 알고리즘과 키를 교환하는 과정
+		1. 클라이언트가 서버로 지원 가능한 암호화 알고리즘 및 TLS 버전 정보 전송(Hello)
+		2. 서버가 선택한 암호화 알고리즘과 인증서를 전송(Hello + 인증서)
+		3. 클라이언트가 인증서 검증(유효성, CA 인지, 도메인 일치 등)
+		4. 클라이언트가 서버의 공개 키로 대칭키를 암호화 해 전달, 서버는 자신의 비밀 키로 복호화 해 대칭 키 획득
+		5. 클라이언트와 서버가 대칭 키를 사용하여 암호화된 데이터 통신 시작(세션 키 설정)
+	- CA(Certificate Authority) 인증:  서버는 신뢰할 수 있는 기관이 발행한 SSL/TLS 인증서를 클라이언트로 제공, 클라이언트는 이 인증서로 서버의 신뢰성 확인
+- 웹 캐시 (프록시 서버)
+	- 서버 클라이언트 사이에서 웹 페이지, 이미지 등을 캐시하는 서버
+	- 브라우저 캐시(로컬 디스크에 저장), 프록시 캐시(네트워크 경로에 저장)
+- 스위치 vs 라우터
+	- 스위치: 같은 네트워크(LAN) 내에서 데이터 전송, MAC 주소로 상호 판별, 2계층(Data-link), 컴퓨터와 장치를 연결하는 데에 주로 사용
+	- 라우터: 다른 네트워크끼리의 데이터 전송, IP 주소로 상호 판별, 3계층(network), 인터넷 및 네트워크 경로 설정에 사용
+- OSI 7계층은 왜 필요한가?
+- DASH, CDN
+	- DASH (Dynamic Adaptive Streaming over HTTP): 동영상 스트리밍 기술, 네트워크 상태에 따라 화질을 동적으로 조정, 클라이언트가 자신에게 적합한 비디오 세그먼트를 요청
+	- CDN (Content Delivery Network): 지리적으로 분산된 서버 네트워크, 클라이언트와 가까운 서버에서 콘텐츠를 제공하여 속도와 안정성을 향상
+- 비대칭 키와 대칭키를 사용하여 기밀성, 무결성, 인증을 만족하는 통신 과정
+    - 비대칭 키(공개키 암호화): 데이터 교환 초기 설정
+	- 대칭 키: 빠른 데이터 암호화
+		1. 서버 인증 (인증): 클라이언트가 서버의 공개키를 CA 인증서로 확인
+		2. 키 교환 (기밀성): 클라이언트가 서버의 공개키로 세션 키(대칭 키)를 암호화하여 전달
+		3. 데이터 전송 (기밀성): 양측은 대칭 키를 이용해 데이터를 암호화하여 전송
+		4. 무결성 보장: 메시지 해시를 계산하고 전송(디지털 서명), 수신자는 해시를 검증하여 데이터 변경 여부를 확인