[최은수] 데이터 중심 애플리케이션 설계 1주차

2024-designing-data-intensive-applications/최은수/1장.md

@@ -0,0 +1,24 @@
+### 애플리케이션이 유용하기 위해 충족시켜야하는 요구사항
+## 기능적 요구사항
+- 여러 방법으로 데이터를 저장하고 조회하고 검색하고 처리하게끔 허용하는 작업 등
+## 비기능적 요구사항
+- 보안
+- 신뢰성
+- 법규 준수
+- 확장성
+- 호환성
+- 유지보수성
+
+
+### 신뢰성
+> 결함이 발생해도 시스템이 올바르게 동작하도록 만드는 것
+- 내 결함성 기술은 최종 사용자에게 특정 유형의 결함을 숨길 수 있게 해줌
+
+### 확장성
+> 부하가 증가해도 좋은 성능을 유지하기 위한 전략
+- 성능 측정 방법 : 응답 시간 백분위
+
+### 유지보수성
+> 엔지니어와 운영 팀의 삶을 개선
+- 좋은 추상화는 복잡도를 줄이고 시스템 변경을 쉽게 만든다
+- 좋은 운용성이란 시스템의 건강상태를 잘 관찰 할 수 있고 시스템을 효율적으로 관리하는 방법을 보유한다는 의미

2024-designing-data-intensive-applications/최은수/2장.md

@@ -0,0 +1,22 @@
+### 다양한 종류의 데이터 모델
+## 계층 모델
+- 하나의 큰 트리 모양
+- 다대다 관계 표현에 적절하지 않음
+
+## 네트워크 모델
+- 코다실 모델이라고도 불림
+- 계층모델을 일반화
+
+## 관계형 모델
+- 적합하지 않은 애플리케이션이 있음
+
+## 비관계형 데이터 저장소 NoSQL
+- 문서 데이터베이스
+  - 데이터가 문서 자체에 포함되어있으면서 하나의 문서와 다른 문서 간 관계가 거의 없는 사용사례를 대상으로 함
+- 그래프 데이터베이스
+  - 모든 것이 잠재적으로 관련 있다는 사용 사례를 대상으로 함
+
+### 쓰기 스키마(schema-on-write)
+- 관계형 데이터베이스의 전통적인 접근 방식으로 스키마는 명시적이고 데이터 베이스는 쓰여진 모든 데이터가 스키마를 따르고 있음을 보장한다
+- 반대되는 읽기 스키마(schema-on-read)
+  - 데이터 구조는 암묵적이고 데이터를 읽을 때만 해석된다

2024-http-the-definitive-guide/최은수/14장.md

@@ -0,0 +1,90 @@
+## 14장 보안 HTTP
+
+### HTTP를 안전하게 만들기
+> 서버인증, 클라이언트 인증 , 무결성, 암호화, 효율, 편재성, 관리상 확장성, 적응성, 사회적 생존성을 제공하는 HTTP 보안 기술이 필요하다
+- HTTPS
+  - 요청과 응답이 네트워크로 보내지기전 암호화
+  - HTTP 하부에 전송 레벨 암호 보안 계층을 제공하면서 동작함
+  - 보안계층 = 안전 소켓 계층 (SSL), 전송 계층 보안(TLS)
+### 디지털 암호학
+> 암호, 키, 대칭키 암호 체계, 비대칭키 암호 체계, 공개키 암호법, 디지털 서명, 디지털 위증서
+- 비밀 코드의 기술과 과학
+- 암호
+- 암호 기계
+- 키가 있는 암호
+  - 코드 알고리즘과 기계가 적의 손에 들어가더라도 올바른 다이얼 설정(키 값)이 없으면 디코딩 못함
+- 디지털 암호
+### 대칭키 암호법
+- 키 길이와 열거 공격
+  - 대부분의 경우 인코딩/디코딩 알고리즘은 알려져있으므로 키가 중요
+  - 무차별적으로 모든 키 값을 대입하는 공격 = 열거공격
+- 공유키 발급하기
+  - 대칭키 암호의 단점 : 발송자와 수신자가 둘 다 공유키를 가져야함
+  - 관리자 입장에서 힘듬
+### 공개키 암호법
+> 한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용 X
+> 공개키 암호법은 두 개의 비대칭 키를 사용 (인코딩을 위한 키(공개), 디코딩을 위한 키(비공개, 호스트만 알고 있음))
+- RSA
+  - 공개키, 가로채서 얻은 암호무의 일부, 메시지와 그것을 암호화한 암호문을 알더라도 비밀인 개인 키 계산 X
+  - 위를 만족하는 공개키 암호 체계 중 하나가 RSA
+- 혼성 암호 체계와 세션 
+  - 공개키 알고리즘은 계산이 느리다
+  - 노드들 사이의 안전한 의사소통 채널 수립 = 공개키
+  - 만들어진 채널을 통해 임시의 무작위 대칭 키 생성/교환 -> 데이터 암호화 = 대칭키 사용
+### 디지털 서명
+- 서명은 암후 체크섬이다
+  - 서명은 메세지를 작성한 저자가 누구인지 알려줌
+  - 서명은 메시지 위조를 방지한다
+  - 디지털 서명은 보통 비대칭 공개키에 의해 생성됨
+  - ![img_3.png](img_3.png)
+### 디지털 인증서
+디지털 인증서(흔히 certs라고 불림)는 신뢰할 수 있는 기관으로부터 보증받은 사용자나 회사에 대한 정보를 담고 있음
+- 인증서의 내부
+  - 공식적으로 '인증 기관'에 의해 디지털 서명된 정보의 집합이 담겨있음
+  - 대상의 이름, 유효 기간, 인증서 발급자, 인증서 발급자의 디지털 서명, 대상에 사용된 서명 알고리즘에 대한 정보, 대상의 정보키
+- 서버 인증을 위한 인증서 사용하기
+### HTTPS의 세부사항
+> HTTPS는 HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한것
+- HTTPS 개요
+  - HTTPS는 암호화되지 않은 HTTP메세지를 TCP를 통해 보내기 전에 그것을 암호화 하는 보안계층으로 보내는것.
+  - ![img_4.png](img_4.png)
+- HTTPS 스킴
+  - 만약 URL이 http 스킴을 가지고 있다면 클라->서버에 80번 포트로 연결, 평범한 HTTP 명령
+  - 만약 URL이 https 스킴을 가지고 있다면 클라->서버에 443번 포트로 연결, SSL 보안 매개변수를 교환하면서 핸드셰이크를 하고 암호화된 HTTP 명령
+- 보안 전송 셋업
+  - HTTPS에서， 클라는 먼저 웹 서버의 443 포트(보안 HTTP 기본포트)로 연결한다.
+  - 일단 TCP 연결이 되고 나면， 클라와 서버는 암호법 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화한다.
+  - 핸드셰이크가 완료되면 SSL 초기화는 완료되며， 클라는 요청 메시지를 보안 계층에 보낼 수 있다. 
+  - 이 메시지는 TCP로 보내지기 전에 암호화된다
+- SSL 핸드셰이크
+  - 암호화된 HTTP 메세지를 보내기 전, 클라와 서버는 SSL 핸드셰이크를 해야한다.
+  - SSL 핸드셰이크
+    - 프로토콜 버전 번호 교환
+    - 양쪽이 알고 있는 암호 선택
+    - 양쪽의 신원 인증
+    - 채널을 암호화하기 위한 임시 세션 키 생성
+- 서버 인증서
+  - SSL은 서버 인증서를 클라이언트로 나르고, 다시 클라이언트 인증서를 서버로 나르는 상호 인증을 지원한다
+  - BUT 오늘날 클라이언트 인증서는 웹브라우징에서 흔히 쓰이지는 X
+  - 보안 HTTPS 트랜젝션은 항상 서버 인증서를 요구
+- 사이트 인증서 검사
+  - 날짜 검사, 서명자 신뢰도 검사, 서명 검사, 사이트 신원 검사
+- 가상 호스팅과 인증서
+  - 가상 호스트(하나의 서버에 여러 호스트 명)
+  - 보안 트랜잭션을 시작하는 모든 사용자들을 리다이랙트하는 방법
+
+### 진짜 HTTPS 클라이언트
+- SSL 클라이언트와 서버 프로그래밍을 쉽게 만들어주는 상용 혹은 오픈 소스 라이브러리
+  - OpenSSL
+### 프락시를 통한 보안 트래픽 터널링
+- 클라가 서버로 보낼 데이터를 서버의 공개키로 암호화 -> 프락시가 HTTP 헤더를 읽을 수 없음 -> 프락시가 요청을 어디로 보내야하는지 모름
+- 이를 위해 클라가 프락시에게 어디에 접속하려고 하는지 말해주는 방법을 수정해야한다.
+- 인기 있는 기법이 HTTPS 터널링 프로토콜
+  - 클라이언트가 프락시에게 자신이 연결하고자하는 안전한 호스트와 포트를 말해준다
+  - 클라이언트는 이 내용을 프락시가 읽을 수 있도록 암호화가 시작되기 전에 평문으로 말해줌
+  - HTTP가 CONNECT라 불리는 확장 메서드를 이용해 평문으로된 종단 정보를 전송
+  - CONNECT 메서드는 프락시에게 희망하는 호스트 와 포트번호로 연결을 해달라고 말해준다
+  - 위에서 요청한 연결이 완료되면， 클라이언트와 서버 사이에서 데이터가 직접적으로 오갈 수 있게 해주는 터널을 만든다.
+  - CONNECT 메서드는，안전한 원 서버의 호스트명과 포트를 콜론으로 구분된 형태로 제공하는， 한 줄로 된 텍스트 명령
+    - 호스트:포트에 뒤이어 스페이스 하나와 HTTP 버전 문 자열과 CRLF가 순서대로 온다.
+    - 0개 이상의 HTTP 요청 헤더줄들이 이어진 다음， 빈 줄. 빈 줄 다음에， 만약 커넥션을 수립하기 위한 핸드셰이크가 성공했다면，SSL데이터 전송이 시작된다.

2024-http-the-definitive-guide/최은수/15장.md

@@ -0,0 +1,92 @@
+## 15장 엔터티와 인코딩
+> 엔터티 및 그와 연관된 엔터티 헤더들과 그들이 웹상의 화물을 수송하기 위해 하는일
+### 메시지는 컨테이너, 엔티티는 화물
+- HTTP 메시지 = 인터넷 운송 시스템의 컨테이너
+- HTTP 엔터티 = 메시지의 실질적인 ㅣ화물
+- 엔터티 본문
+  - 가공되지않은 데이터만을 담고 있다. 나머지는 헤더에!
+### Content-Length : 엔티티의 길이
+- Content-Length 헤더는 메시지의 엔터티 본문의 크기를 바이트로 나타냄
+- 필수적으로 있어야함
+- 서버 충돌로 인해 메시지가 잘렸는지 감지할때, 지속 커넥션을 공유하는 메시지를 올바르게 분할할때 필요
+- 잘림 검출
+  - 옛날버전 HTTP는 커넥션 닫힘 = 메세지 끝났음 이렇게 인지함
+  - 그러나 Content-Length가 없다면 메시지 전송 중에 서버에 충돌이 발생한건지, 커넥션이 정상적으로 닫혔는지 구분하지 못한다.
+  - 즉 메시지 잘림을 검출하기 위해 Content-Length가 필요
+  - 메시지 잘림은 프락시 서버에 특히 취약
+    - 명시적으로 Content-Length 헤더를 가지고 있지 않은 HTTP 본문은 캐시하지 않음
+- 잘못된 Content-Length
+- 콘텐츠 인코딩
+  - 인코딩 되지 않은 원본의 길이가 아닌, 인코딩된 본문의 길이를 바이트 단위로 정의
+  - 어떤 HTTP 애플리케이션은 인코딩 전의 크기를 보내기도 하는데 이는 지속커넥션일때 심각한 오류를 유발함
+- 엔터티 본문 길이 판별을 위한 규칙
+  - 본문을 갖는 것이 허용되지 않는 특정 타업의 HTTP 메시지에서는， 본문 계산을 위한 Content-Length 헤더가 무시된다.
+  - 메시지가 Transfer-Encoding 헤더를 포함하고 있다면， 메시지가 커넥션이 닫혀서 먼저 끝나지 않는 이상 엔터티는 ‘0 바이트 청크’라 불리는 특별한 패턴으로 끝나야 한다.
+  -  메시지가 Content-Length 헤더를 갖는다면， Transfer-Encoding 헤더가 존재하지 않는 이상 Content-Length 값은 본문의 길이를 담게 된다.
+  - 메시지가 multipart/byteranges’ 미디어 타입을 사용하고 엔터티 길이가 Content-Length 헤더로 별도로 정의되지 않았다면， 멀티파트 메시지의 각 부분은 각자가 스스로의 크기를 정의할 것이다.
+  - 위의 어떤규칙에도해당되지 않는다면， 엔터티는커넥션이 닫힐 때 끝난다.
+  - HTTP/1.0 애플리케이션과의 호환을 위해，엔터티 본문을 갖고있는 HTTP/1.1 요청은 반드시 유효한 Content-Length 헤더도 갖고 있어야 한다
+### 미디어 타입과 차셋
+Content-Type 헤더 필드는 엔터티 본문의 MIME 타입을 기술
+- 텍스트 매체를 위한 문자 인코딩
+  - 엔터티의 비트 집합을 텍스트 파일의 글자로 변환하기 위해 charset 매개변수 사용
+- 멀티파트 미디어 타입
+  - 서로 붙어있는 여러 개의 메시지를 포함하며 하나의 복합 메시지로 보내짐
+  - 각각 자신에 대해 서술하는 헤더 포함
+- 멀티파트 폼 제출
+- 멀티파트 범위 응답
+  - 범위 요청에 대한 HTTP 응답 또한 멀티파트가 될 수 있다.
+### 콘텐츠 인코딩
+HTTP 애플리케이션은 때때로 콘텐츠를 보내기 전에 인코딩을 하려고한다.
+- 콘텐츠 인코딩 과정
+- 콘텐츠 인코딩 유형
+- Accept-Encoding 헤더
+  - 지원하는 인코딩 목록
+  - Q값의 범위는 가장 원치 않음을 의미하는 0.0에서 가장 선호함을 나타내는 1.0
+  - *는 그 외 모두 를 의미
+### 전송 인코딩과 청크 인코딩
+- 안전한 전송
+  - HTTP에 전송된 메시지의 본문이 문제를 일으킬 수 있는 이유
+    - 알 수 없는 크기, 보안
+- Transfer-Encoding 헤어
+  - 전송 인코딩을 제어하고 서술하기 위해 정의된 헤더는 단 두 개뿐
+    - Transfer-Encoding, TE
+- 청크 인코딩
+  - 메시지를 청크 여럿으로 쪼갠다. 서버가 각 청크를 순차적으로 보낸다.
+    - 이를 이용하면 메세지를 전송하기 전에 전체 크기를 알 필요가 없어짐.
+    - 본문이 동적 생성됨에 따라 서버는 그 중 일부를 버퍼에 담은 뒤 그 한 청크를 그것의 크기와 함께 보냄 -> 본문 전체를 보낼때까지 반복
+  - 청크와 지속 커넥션
+    - if 클라와 서버 사이의 커넥션이 지속적이지 않으면, 클라는 본문의 크기를 알 필요가 없다. 서버가 커넥션을 닫을때까지가 본문으로 인식
+    - 청크 인코딩에서는 크기가 0인 청크로 본문이 끝났음을 알리고, 다음 응답을 위해 커넥션을 열린채로 유지
+      - 클라는 서버가 청크 인코딩을 받아들여줄지 모르기 때문에 청크 요청이 411 Length Required 응답으로 거절당하는 것에 대비해야함
+  - 청크 인코딩된 메시지 트레일러
+    - 두 조건 중 하나 이상을 만족하면 청크 메시지에 트레일러 추가 가능
+      - 클라이언트의 TE 헤더가 트레일러를 받아들일 수 있음을 나타내고 있는 경우
+      - 트레일러가 웅답을 만든 서버에 의해 추가되었으며， 그 트레일러의 콘텐츠는 클라이언트가 이해하고 사용할 필요가 없는 선택적인 메타데이터이므로 클라이언트가 무시하고 버려도 되는 경우
+    - 트레일러에는 메시지 시작 시점에서는 그 값을 알 수 없는 추가적인 헤더 필드를 담을 수 있음.
+- 콘텐츠와 전송 인코딩의 조합
+  - 콘텐츠 인코딩과 전송 인코딩은 동시에 사용될 수 있음
+- 전송 인코딩 규칙
+  - 수신자가 메시지의 전송 길이를 알아낼 수 있게 하기 위함
+  - 전송 인코딩의 집합은 반드시 ‘chunked’를 포함해야 한다. 유일한 예외는 메시지가 커넥션의 종료로 끝나는 경우뿐이다.
+  - 청크 전송 인코딩이 사용되었다면， 메시지 본문에 적용된 마지막 전송 인코딩이 존재해야한다.
+  - 청크 전송 인코딩은 반드시 메시지 본문에 한번 이상 적용되어야한다.
+### 시간에 따라 바뀌는 인스턴스
+- 웹 객체는 정적이지 않다.
+- 인스턴스 조작 = HTTP 프로토콜이 어떤 특정한 종류의 요청이나 응답을 다루는 방법들을 정의
+  - 대표적인 두가지가 범위 요청과 델타 인코딩
+  - 둘 모두 클라이언트가 자신이 가지고 있는 리소스의 사본이 서버가 가지고 있는 것과 정확히 같은지 판단하고, 상황에 따라서 새 인스턴스를 요청할 수 있는 능력을 가질것을 요구
+### 검사기와 신선도
+> 조건부 요청이라고 불리는 이 특별한 요청은， 클라이언트가 서버에게 자신이 갖고 있는 버전을 말해주고 검사기를 사용해 자신의 사본 버전이 더 이상 유효하지 않을 때만 사본을 보내달라고 요청하는 것이다.
+- 신선도
+- 조건부 요청과 검사기
+  - 만약 서버의 문서가 캐시가 갖고 있는 것과 같음에도 불구하고 항상 그 문서를 가져온다면 캐시는 네트 워크의 대역폭을 낭비하고， 캐시와 서버에 불필요한 부하를 주고， 모든 것을 느려지게 만들게 된다.
+  - 이를 고치기 위해， HTTP는 클라이언트에게 리소스가 바뀐 경우에만 사본을 요청하는 조건부 요청이라 불리는 특별한 요청을 할 수 있는 방법을 제공한다.
+  - 조건부 요청은 if- 로 시작하는 조건부 헤더에 의해 구현
+    - if-Modified-Since, if-Unmodified-Since, if-Match, if-None-Match
+  - 검사기 2 종류 : 강한 검사기, 약한 검사기('W/'를 붙여서 표시)
+### 범위 요청
+- 클라이언트가 문서의 일부분이나 특정 범위만 요청할 수 있도록 해줌
+- Range 헤더
+### 델타 인코딩
+> 델타 인코딩은 객체 전체가 아닌 변경된 부분에대해서만 통신하여 전송량을 최적화하는，HTTP 프로토콜의 확장이다.