Merge branch 'main' of github.com:Java-Entrance/Network-study

Author: Eojoonhyuk

README.md

@@ -27,3 +27,7 @@
 ### 6주차 (23.06.28 ~ 23.07.04)
 - 8장 : 누가 엑세스하고 있는지를 확인하는 인증
 - 9장 : HTTP에 기능을 추가한 프로토콜
+
+### 7주차 (23.07.05 ~ 23.07.11)
+- 10장 : 웹 콘텐츠에서 사용하는 기술
+- 11장 : 웹 공격 기술

문희조/8장/누가_엑세스하고_있는지를_확인하는_인증.md

@@ -0,0 +1,57 @@
+## 🤷‍♂️ 누가 액세스하고 있는지를 확인하는 인증
+
+### 8.1 인증이란?
+
+-   실제로 누가 접근하려고 하는건지 알 수가 없다.
+-   따라서, `등록한 본인만 아는 정보`, `등록한 본인만 가진 정보`로 확인해야 한다.
+-   이런 정보는 보통 `비밀번호`, `일회성 토큰`, `전자 증명서`, `바이오 매트릭스`, `IC 카드`를 사용한다.
+-   앞으로 설명할 인증 방법 외에도 Windows 인증 등도 존재한다.
+
+### 8.2 BASIC 인증
+
+-   HTTP/1.0에서 구현된 인증 방식이다.
+-   웹 서버와 대응하는 클라이언트 사이에서 이루어지는 인증 방식이다.
+-   `Base64`라는 인코딩을 사용하지만 `암호화` 자체는 아니기에 보안성이 떨어진다.
+
+#### 8.2.1 인증 절차
+
+1.  요청에 인증이 필요하면 서버는 `401 상태코드로` 응답한다.
+2.  클라이언트는 `아이디:패스워드`를 `Base64`로 인코딩하고 `Authorization` 헤더에 담아 서버에 전송한다.
+3.  서버는 인증에 성공하면 `200`과 리소스를, 실패하면 `401` 상태코드로 응답한다.
+
+### 8.3 DIGEST 인증
+
+-   `챌린지 리스폰스`를 사용하는 인증 방식이다.
+-   `챌린지 리스폰스`: 인증 요청 > 챌린지 코드 수신 > 챌린지 코드로 계산 후 응답
+-   `챌린지 코드(nonce)`는 `401`응답마다 다르다. (매번 생성된다.)
+-   계산 결과를 보내기 때문에 BASIC 인증보다는 낫지만 이외의 위장에 대한 보안이 떨어진다.
+
+#### 8.3.1 인증 절차
+
+1.  요청에 인증이 필요하면 서버는 `401`상태코드와 `WWW-Authenticate` 헤더에 `챌린지 코드(nonce)`를 담아 응답한다.
+2.  클라이언트는 `챌린지 코드`와 비밀번호를 `MD5`로 계산한 리스폰스 코드를 `Authorization` 헤더에 담아 서버에 전송한다.
+3.  서버는 인증에 성공하면 `200`과 리소스를, 실패하면 `401` 상태코드로 응답한다.
+
+### 8.4 SSL 클라이언트 인증
+
+-   HTTPS의 클라이언트 인증서를 이용한 인증 방식이다.
+-   (복습) 클라이언트 증명서를 인증할 때만 사용하는 방식으로 사전에 등록된 클라이언트에서의 액세스인지 확인한다.
+-   단독으로 사용되지 않고, 폼 베이스 인증과 같이 진행한다. (2-factor 인증)
+-   `7장`에서 다룬 것처럼 추가적인 비용을 동반한다. (증명서 발급 등)
+
+#### 8.4.1 인증 절차
+
+1.  요청에 인증이 필요하면 서버는 증명서를 요청하는 `Certificate Request` 메시지를 보낸다.
+2.  클라이언트는 증명서를 보내고, 인증에 성공하면 공개키를 얻는다.
+
+### 8.5 폼 베이스 인증
+
+-   HTTP 정식 인증 방식은 아니다. 서버에서 사용하는 `Credential`을 통해서 인증하는 방식이다.
+-   인증은 대부분 폼 베이스 인증 방식을 사용한다. (보안성 이슈, 비용 이슈)
+-   `세션 관리`와 `쿠키`를 통해서 HTTP에 없는 상태 관리 기능을 보충하는 방식으로 구현한다.
+
+#### 8.5.1 인증 절차
+
+1.  `POST`메소드로 `Credential`를 바디에 담아서 보낸다. 통신은 HTTPS를 사용한다.
+2.  인증에 성공하면 서버는 `세션 ID`를 발행하고 `Set-Cookie`헤더에 담아 응답한다.
+3.  클라이언트는 받은 `세션 ID`를 쿠키에 저장한다.

문희조/9장/HTTP에_기능을_추가한_프로토콜.md

@@ -0,0 +1,57 @@
+## 📞 HTTP에 기능을 추가한 프로토콜
+
+### 9.1 HTTP를 기본으로 하는 프로토콜
+
+-   최초에는 단순히 문서를 전송하는 프로토콜로 생각했었다,
+-   너무 널리 HTTP가 퍼졌기 때문에 새로운 프로토콜을 만들기는 어렵다.
+-   따라서, 기능을 추가하는 형태로 다양한 요구사항을 만족하고 있다.
+
+### 9.2 HTTP의 병목 현상을 해소하는 SPDY
+
+-   Google이 발표한 프로토콜이다. 웹 페이지 로딩을 50% 단축하게 목표이다.
+-   병목 현상을 해결하는 좋은 기술이지만 웹의 문제는 그 외에서도 발생한다.
+
+#### 9.2.1 HTTP의 병목 현상
+
+-   SNS와 같이 큰 트래픽에 대해서 HTTP는 잘 처리할 수 없다.
+-   다음 HTTP의 사양이 병목 현상의 원인이다.
+    1.  1개의 커넥션에는 1개의 리퀘스트.
+    2.  리퀘스트는 클라이언트에서만 시작할 수 있다. (리스폰스만 받는 게 불가능)
+    3.  헤더를 압축하지 않는다.
+    4.  장황한 헤더를 보낸다. (매번 같은 헤더)
+    5.  데이터 압축을 임의로 선택할 수 있다. 또한, 압축을 강제하지 않는다.
+-   `Ajax`는 DOM을 조작해서 페이지의 일부만 갱신한다.
+-   `Comet`은 갱신 요청에 대한 응답을 보류해서 실제로 갱신이 될 때 응답을 보낸다.
+
+#### 9.2.2 SPDY 설계와 기능
+
+-   TCP/IP의 애플리케이션 계층과 트랜스포트 계층 사이에 **새로운 세션 계층을 추가**하는 형태이다.
+-   보안 **표준으로 SSL을 사용**한다. 단순히 추가된 것으로 HTTP 커넥션은 그대로이다.
+-   `다중화 스트림` 지원 : 단일 커넥션으로 여러 요청을 처리할 수 있다.
+-   `리퀘스트 우선 순위` 지원 : 요청에 우선순위를 할당한다. 처리가 늦어지는 현상을 해결할 수 있다.
+-   `헤더 압축` 지원 : 헤더의 압축을 강제한다. 적은 자원으로 통신할 수 있다.
+-   `서버 푸시` 지원 : 서버에서 클라이언트로 데이터를 푸시하는 기능. 요청을 기다리지 않아도 된다.
+-   `서버 힌트` 지원 : 서버가 클라이언트에게 요청할 리소스를 제안하는 기능이다. 불필요한 요청을 방지한다.
+
+### 9.3 브라우저에서 양방향 통신을 하는 WebSocket
+
+-   `Ajax`와 `Comet`을 통해서 웹 브라우징이 고속화되지만 완벽한 병목 현상 해결은 어렵다.
+-   `WebSocket`은 웹 브라우저와 서버를 위한 **양방향 통신 규격으로 새로운 프로토콜**이다.
+
+#### 9.3.1 WebSocket 프로토콜
+
+-   한번 접속되면 **양방향 모두 마음대로 통신**할 수 있고 전용 프로토콜을 사용한다.
+-   JSON, XML, HTML 등 임의의 데이터를 활용할 수 있다.
+-   `서버 푸시` 기능을 제공하고, 한번 접속을 확립하기 위해서 `핸드쉐이크` 절차를 밟는다.
+-   핸드쉐이크/요청 : `Upgrade` 헤더로 프로토콜 변경을 요청하고, `Sec-WebSocket-Key`에 필요한 키를 담아 보낸다.
+-   핸드쉐이크/응답 : `Sec-WebSocket-Key`에 값을 `Sec-WebSocket-Accept`에 저장 담고 `101`로 응답한다.
+
+## 9.4 등장이 기다려지는 HTTP/2.0
+
+-   지금 HTTP/1.1은 웹에 적합하다고 할 수는 없다.
+-   다음 프로토콜은 `SPDY`, `HTTP Spped+Mobility`, `Network-Friendly HTTP Upgrade`을 기반으로 한다.
+
+## 9.5 웹 서버 상의 파일을 관리하는 WebDAV
+
+-   웹 서버의 콘텐츠에 대해서 직접 파일 복사나 편집 작업 등을 할 수 있는 분산 파일 시스템이다.
+