[4주차] 7장 - 캐시, 8장 - 통합점: 게이트웨이, 터널, 릴레이 (정리)

7장-캐시/QA.md

@@ -0,0 +1,31 @@
+## 7장 - 캐시
+### (찬규) [캐시 버스팅](https://toss.tech/article/smart-web-service-cache)
+- 의도적인 캐시 무효화.
+- 빌드 마다 이름 바꾸기 등.
+<br/>
+
+### (찬규) 캐시 만료 기한은 얼마로 설정하는게 적절할까?
+- 자주 바뀌는 건 몇 초 단위.
+- 일반적으로는 분 단위.
+- 거의 변하지 않는 데이터는 하루나 이틀.
+<br/>
+
+### (연진) Must-Revalidate에서 유효성 검사를 하는 이유?
+- 처음에는 무조건적으로 서버에 재검사를 받는다고 생각했음
+- 알고 보니 유효하지 않은 사본은 반드시 재검사하지만, 유효한 사본은 그냥 반환하는 것이었음.
+<br/>
+
+### (연진) Must-Revalidate vs no-cache
+- 일반적으로, 유효하지 않은 사본이라도 네트워크가 안되면 그냥 반환한다.
+- 하지만 Must-Revalidate를 절대로 유효하지 않은 사본을 반환하지 않는다.
+<br/>
+
+### (민지) no-cache와 max-age=0의 차이점
+- 대부분의 브라우저에서 동일한 뜻을 가진다.
+- HTTP/1.0에는 no-cache가 없었기 때문에 max-age=0을 이용하곤 했다
+- no-cache = (max-age=0) + must-revalidate. (max-age=0은 네트워크가 안될때 유효하지 않은 사본을 반환할 수 있다)
+<br/>
+
+### (민지) only-if-cached인데 캐시 사본이 없으면?
+- 서버에 요청 자체를 보내지 않는다.
+- 오프라인 모드에 활용되기도 한다.

7장-캐시/README.md

@@ -0,0 +1,42 @@
+## 7장 - 캐시
+### 캐시
+- 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치
+- 웹 요청이 캐시에 도달했을 때, 캐시된 로컬 사본이 존재할 경우 그 문서는 원 서버가 아니라 그 캐시로부터 제공된다.
+<br/>
+
+### 캐시 처리 단계
+1. 요청 받기: 커넥션을 통해 활동 감지하고, 들어오는 데이터를 읽어들인다. 
+2. 파싱: 캐싱 소프트웨어가 쉽게 처리할 수 있도록 헤더 부분을 조작하기 쉬운 자료 구조에 담는다. 
+3. 검색: 로컬 사본이 있는지 검사한다. 
+4. 신선도 검사: 사본의 유효 기간을 체크한다. 유효 기간이 지났을 경우 서버로부터 유효 기간을 재검사받는다.
+5. 응답 생성: 캐시된 서버 응답 헤더를 토대로 응답 헤더를 생성한다.
+6. 전송: 캐시는 응답을 클라이언트에게 돌려준다. 
+7. 로깅
+<br/>
+
+### 캐시 적중과 부적중
+- 캐시 적중: 캐시 사본이 존재하는 것.
+- 캐시 부적중: 캐시 사본이 존재하지 않아 원 서버로 요청을 전달하는 것.
+<br/>
+
+### 사본을 신선하게 유지하기
+1. 문서 만료 확인하기: Cache-Control, Expires 헤더 확인
+2. 조건부 메서드 사용하기(재검사): If-Modified-Since<sup>1</sup>(날짜), If-None-Match<sup>2</sup>(ID).
+<br/>
+
+- 재검사: 캐시 사본이 유효한지 서버로부터 검사받는 것.
+- 재검사 결과 캐시 사본이 유효하다면(느린 적중) 크기가 작은 304 Not Modified 응답을 받는다.
+- 캐시 사본이 유효하지 않다면 크기가 큰 200 OK 응답을 받는다.
+- 서버에 원본이 삭제되었다면 404 Not Found 응답을 받는다. 이 경우 캐시는 사본을 삭제한다.
+<br/>
+
+### 캐시 제어
+1. no-cache: 항상 서버로부터 재검사받는다.
+2. no-store: 캐시 사본조차 만들 수 없다.
+3. max-age: 리소스의 유효 기간(단위: 초). 이 기간이 지나면 재검사를 진행한다.
+4. Expires: 만료 날짜.
+5. Must-Revalidate: 캐시 사본이 유효하지 않은 경우 반드시 재검사한다.
+<br/><br/>
+
+<sup>1</sup>클라이언트 요청의 If-Modified-Since 헤더와 서버 응답의 Last-Modified 항목을 비교한다.<br/>
+<sup>2</sup>클라이언트 요청의 tag(If-None-Match 헤더)와 서버 응답의 ETag를 비교한다. HTTP/1.1은 캐시 사본을 무효화하지 않으면서 문서를 수정하도록 하는 약한 검사기 기능을 지원한다.<br/>

8장-통합점: 게이트웨이, 터널, 릴레이/QA.md

@@ -0,0 +1,15 @@
+## 8장 - 통합점: 게이트웨이, 터널, 릴레이
+### (연진) 네트워크 게이트웨이와 애플리케이션 게이트웨이의 차이점
+- 네트워크 게이트웨이: 주로 네트워크 통신에서 사용되는 용어로, 로컬 네트워크(예: LAN)와 외부 네트워크(예: 인터넷) 사이에서 트래픽을 중계하는 장치.
+- 애플리케이션 게이트웨이: 주로 애플리케이션 레벨에서 사용되는 용어로, 클라이언트와 백엔드 서버 사이에서 트래픽을 중계하고 다양한 기능을 제공하는 소프트웨어나 하드웨어.
+<br/>
+
+### (연진) SSL 터널링을 사묭할떄 전송되는 프로토콜도 TCP 위에서 동작해야 할까?
+- SSL 터널링을 사용하여 다른 프로토콜을 전송할 때, 그 위의 프로토콜은 일반적으로 TCP 위에서 동작하는 프로토콜이어야 한다.
+- SSL/TLS 터널링은 TCP 연결을 설정하고 이후 SSL/TLS 핸드셰이크를 통해 보안 연결을 수립하는 방식으로 동작한다.
+<br/>
+
+### (민지) 게이트웨이 vs 프록시
+- 프록시도 리다이렉팅을 통해 프로토콜 게이트웨이처럼 동작할 수 있다.
+- API 게이트웨이를 검색해보면 혼용되는 걸 봐선 비슷한 역할인 것 같다.
+- [참고 자료](https://velog.io/@dasa/내가-필요해서-정리-Proxy-vs-Gateway에-대해)

8장-통합점: 게이트웨이, 터널, 릴레이/README.md

@@ -0,0 +1,37 @@
+## 8장 - 통합점: 게이트웨이, 터널, 릴레이
+### 게이트웨이
+- 리소스와 애플리케이션을 연결하는 역할
+- 동적인 콘텐츠를 생성하거나 데이터베이스에 질의를 보낼 수 있다.
+- HTTP 트래픽을 다른 프로토콜로 자동으로 변환한다.
+<br/>
+
+### 프로토콜 게이트웨이
+- 프로토콜 사이에 변환 기능
+- 클라이언트가 브라우저를 통해 명시할 수도 있고, 서버가 리버스 프록시로 사용할 수도 있다.
+<br/>
+
+1. HTTP/* : 서버 측 웹 게이트웨이
+2. HTTP/HTTPS : 서버 측 보안 게이트웨이
+3. HTTPS/HTTP : 클라이언트 측 보안 가속 게이트웨이
+<br/>
+
+### 리소스 게이트웨이
+- 애플리케이션 서버는 게이트 웨이와 목적지 서버를 한 개의 서버로 결합하고 클라이언트와는 HTTP로 통신한다.<br/>
+Ex. 공용 게이트웨이 인터페이스(CGI), 서버 확장 API
+<br/>
+
+### 애플리케이션 인터페이스
+- 애플리케이션 간에 정보를 공유할 수 있게 하는 메커니즘. HTTP 같은 표준 웹 기술 위에서 개발한다.<br/>
+Ex. XML(eXtensible Markup Language), SOAP(Simple Object Access protocol)
+<br/>
+
+### 터널
+- HTTP를 사용하여 HTTP 프로토콜을 지원하지 않는 애플리케이션에 접근할 수 있게 한다.
+- HTTP CONNECT 메서드를 사용해서 커넥션을 맺고 Raw 데이터를 전송한다.
+- 터널 게이트웨이는 데이터를 감시할 수 없으므로 80이나 443과 같은 잘 알려진 포트로만 터널링할 수 있게 해야 한다.
+<br/>
+
+### 릴레이
+- HTTP 명세를 완전히 준수하지 않는 간단한 HTTP 프락시
+- HTTP 커넥션을 맺고, 바이트를 전달한다.
+- Connection 헤더를 제대로 처리하지 못해서 keep-alive 커넥션이 행(hang)에 걸리는 문제점이 있다.