Revert "Reapply "archive 삭제""

This reverts commit aec9ae8c43.
2026-04-09 10:45:31 +09:00
parent 7225e53760
commit 4510784946
245 changed files with 3799 additions and 0 deletions
@@ -0,0 +1,12 @@
+클라이언트의 요청을 성공적으로 처리
+주로 사용되는 코드는 아래와 같으며 더 많은 코드들이 존재한다.
+
+- 200 OK
+  : 요청 성공,  메시지 구조-> ([[GET]])
+- 201 Created (클라이언트의 요청으로 리소스가 생성되었을 때 )
+  : 요청 성공해서 새로운 리소스가 생성됨.  메시지 구조 -> ([[POST]])
+- 202 Accepted
+  : 요청이 접수되었으나 처리가 완료되지 않음.
+  ( 요청의 처리가 서버에서 오래걸릴 경우 Accepted를 내리기도 한다고 함. )
+- 204 No Content
+  : 서버가 요청을 성공적으로 수행했지만 응답 페이로드 본문에 보낼 데이터가 없음.
@@ -0,0 +1,11 @@
+
+
+Client    <   ----   >    Server
+1.              SYN >
+2.         <  SYN + ACK
+3.              ACK >
+4.            데이터 > 
+
+SYN: 접속 요청
+ACK: 요청 수락
+![[Pasted image 20240305174904.png]]
@@ -0,0 +1,15 @@
+요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
+
+리다이렉션?
+: 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면 Location 위치로 자동 이동(리다이렉트)
+
+- 300 Multiple Choices
+  : 거의 안씀
+- 301 Moved Permanently
+  : 리다이렉트시 요청 메서드가 GET으로 변경되어 본문이 제거될 수 있음
+- 302 Found
+- 303 See Other
+- 304 Not Modified
+- 307 Temporary Redirect
+- 308 Permanent Redirect
+  : 리다이렉트 요청 시 메서드와 본문 유지
@@ -0,0 +1,17 @@
+클라이언트 오류
+: 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음
+: 오류의 원인이 클라이언트에게 있음
+
+- 400 Bad Request
+  : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
+- 401 Unauthorized
+  : 클라이언트가 해당 리소스에 대한 인증이 필요함
+  ( Authentication: 본인이 누구인지 확인, 로그인 )
+  ( Authorization: 인가, 권한부여 접근권한이 있어야 한다. )
+- 403 Forbidden
+  : 서버가 요청을 이해했지만 승인을 거부함.
+  ( 주로 인증 자격 증명은 있지만 접근 권한이 불충분했을 때 )
+- 404 Not Found
+  : 요청 리소스를 찾을 수 없음
+  ( 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 리소스를 숨기고 싶을 떄 사용 )
+  
@@ -0,0 +1,14 @@
+서버 오류
+: 서버 문제로 오류 발생
+: 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음
+
+- 500 Internal Server Error
+  : 서버 문제로 오류 발생, 애매하면 500으로 발생시키면 됨.
+- 503 Service Unavailable
+  : 서비스 이용 불가, 서버가 일시적인 과부호 또는 다른 작업처리로 잠시 요청을 처리할 수 없음.
+
+
+서버 오류는 가능한 한 발생 시키지 않는 게 좋다.
+
+서버에 문제가 있을 때 사용하는 코드이지 서버가 처리하지 못한,  
+사용자의 요청을 처리하지 못했다고 해서 사용하는 코드가 아님.
@@ -0,0 +1,13 @@
+API URI 설계 시
+- ==리소스에 집중하라.== 조회, 등록, 수정, 삭제는 리소스가 아니다.
+	( 위의 행동을 하는 요소 자체가 리소스이다. )
+
+URI는 말그대로 Resource 의 ID가 되어야한다.
+URI에 search, delete 등의 행동이 들어가는건 좋지 않다.
+
+- **URI는 리소스만 식별**
+- 리소스와 해당 리소스를 대상으로 하는 **행위**를 분리
+		- 리소스: 회원
+		- 행위: 조회, 등록, 삭제, 변경
+- 리소스는 명사, 행위는 동사
+- 행위(메서드)는 어떻게 구분하는가? : [[HTTP Methods]]로 구분한다.
@@ -0,0 +1,11 @@
+( 참고로 HTML FORM은 GET, POST만 사용 가능하다. )
+( HTML FORM은 GET, POST밖에 쓰지 못하기 때문에 PUT, PATCH, DELETE 등의 다른 메서드를 대체하기 위해 [[Control URI]]를 사용한다. )
+
+
+#### 회원 관리 시스템
+- 회원 목록 /members -> GET
+- 회원 등록 폼 /members/new -> GET  (회원 등록 form 자체를 반환)
+- 회원 등록 /members/new, /members -> POST  (/new라는 동사를 붙이는 방법도 있음)
+- 회원 조회 /members/{id} -> GET
+- 회원 수정 폼 /members/{id}/edit -> GET (회원 수정 form 자체를 반환)
+- 회원 삭제 /members/{id}/delete -> POST (DLETE를 못쓰기 때문에 uri path에 delete를 사용)
@@ -0,0 +1,7 @@
+#### 회원 관리 시스템
+- 회원 목록 /members -> [[GET]]  (members 전체에 Get을 요청했으므로)
+  ( 필터링이나 정렬 등의 부가기능은 query parameter로 받아서 처리 )
+- 회원 등록 /members -> [[POST]] (body에 있는 데이터를 회원으로 등록)
+- 회원 조회 /members/{id} -> [[GET]]  (members의 특정ID만 조회)
+- 회원 수정 /members/{id} -> [[PATCH]], [[PUT]], [[POST]] 
+- 회원 삭제 /members/{id} -> [[DELETE]]
@@ -0,0 +1,6 @@
+#### 파일 관리 시스템
+- 파일 목록 /files -> GET
+- 파일 조회 /files/{filename} -> GET
+- 파일 등록 /files/{filename} -> PUT
+- 파일 삭제 /files/{filename} -> DELETE
+- 파일 대량 등록 /files -> POST
@@ -0,0 +1,5 @@
+##### 동사로 된 리소스 경로를 사용하는 것을 의미
+( HTTP Methods 만으로 해결하기 어려운 경우엔 POST 기반 설계에서도 사용 )
+
+- 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 필요 시 사용한다.
+- Control URI는 동사를 써야한다. 
@@ -0,0 +1,4 @@
+- DELETE도 body가 없음.
+
+DELETE /members/100 HTTP/1.1
+Host: localhost:8080
@@ -0,0 +1,5 @@
+**D**omain **N**ame **S**ystem
+
+IP는 외우기 힘드니까 문자열로 된 Domain Name을 IP로 매핑해서 사용한다.
+
+Domain Name에 매핑되는 IP를 뱉어내주는 역할을 전담하는 서버를 DNS Server라고 한다.
@@ -0,0 +1,6 @@
+Entity Tag, If-None-Match
+
+- 캐시용 데이터에 임의의 고유한 버전 이름을 다는 방법
+  ( ETag: "v1.0", ETag:"a2jewfawe" )
+- ETag는 같으면 304 Redirection, 다르면 200 OK
+- **케시 제어 로직을 서버에서 완전히 관리**
@@ -0,0 +1,16 @@
+GET은 일반적으로 body 메시지가 없다. 
+( 사용할 수는 있는데 GET 메시지에 body가 허용되지 않는 서버들이 있음. )
+
+##### 요청
+GET /members/100 HTTP/1.1
+Host: localhost:8080
+
+
+##### 응답
+HTTP/1.1 200 OK
+Content-Type: application/json
+Content-Length: 34
+{
+ "username": "young",
+ "age": 20
+}
@@ -0,0 +1,13 @@
+- From: 유저 에이전트의 이메일 정보
+- Referer: 이전 웹 페이지 주소
+- User-Agent: 유저 에이전트 애플리케이션 정보
+- Server: 요청을 처리하는 [[오리진 서버]]의 소프트웨어 정보
+- Date: 메시지가 생성된 날짜
+- **Host: 요청한 호스트 정보(도메인)** - ==필수==, 매우 중요함
+  ( 하나의 IP주소에 여러 도메인이 적용되어 있을 때 구분하는데 필요함 )
+- Location: 페이지 리다이렉션 ([[3xx (Redirection)]])
+- Allow: 허용 가능한 HTTP 메서드 ( 잘 안씀 )
+- Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
+- Authorization: 클라이언트 인증 정보를 서버에 전달
+- WWW-Authenticate: 리소스 접근 시 필요한 인증 방법 정의
+  ( 401 Unauthorized 응답과 함께 사용 )
@@ -0,0 +1,23 @@
+: 클라이언트가 서버에게 바라는 행동을 의미
+
+##### HTTP Method의 종류
+- [[GET]]: ==리소스 조회== (GET에도 메시지 바디를 넣을수는 있지만 권장되지 않음)
+  
+- [[POST]]: ==요청 데이터 처리, 메시지 body를 통해 서버로 요청 데이터 전달==, 주로 신규 리소스 등록에 사용
+	( **POST 메서드는 데이터를 넘겨줄 수 있는 기능**이며 처리는 내부에서 정해진대로 수행된다. )
+	( 넘겨받은 데이터를 DB에 등록할것이다, 넘겨받은 데이터를 보고 어떠한 액션을 할것이다. )
+	
+- [[PUT]]: ==리소스를 대체== (update), 해당 리소스가 없으면 생성. **덮어쓰기**라고 생각하면 됨
+  클라이언트가 리소스의 URI를 알고서 사용하는 특징이 있음. (Post와 Put의 가장 큰 차이)
+	
+- [[PATCH]]: ==리소스 부분 변경== ( 지정한 필드만 변경되고 지정되지 않았던 필드는 그대로 남는다. )
+  서버에 따라서 PATCH를 지원하지 않는 곳도 있음. (그럴 땐 POST를 응용해서 쓰면 됨)
+	
+- [[DELETE]]: ==리소스 삭제==
+	 body가 없는 메시지
+
+기타 HTTP 메서드 (있다는 정도만 알자)
+- HEAD: GET과 동일하지만 메시지 부분을 제외하고 상태 줄과 헤더만 반환
+- OPTIONS: 대상 리소스에 대한 통신 가능 옵션을 설명 (CORS에서 주로 사용)
+- CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정 (잘 안씀)
+- TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 (잘 안씀)
@@ -0,0 +1,3 @@
+![[Pasted image 20240308112312.png]]
+
+- HTTP도 SOCKET을 사용한다.
@@ -0,0 +1,9 @@
+- 1xx (Information): 요청이 수신되어 처리중 -> 거의 사용하지 않음.
+- [[2xx (Successful)]]: 요청 정상 처리
+- [[3xx (Redirection)]] 요청을 완료하려면 추가 행동이 필요
+- [[4xx (Client Error)]]: 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
+- [[5xx (Server Error)]]: 서버 오류, 서버가 정상 요청을 처리하지 못함
+
+상태코드를 정확하게 알지 못하더라도 100의자리 숫자만 확인해서 대충 파악하도록 처리하면 됨.
+                               (상위 상태코드)
+
@@ -0,0 +1,19 @@
+==H==yper==T==ext ==T==ransfer ==P==rotocol - HyperText를 전송하는 규약(규칙)
+
+- 모든 것이 HTTP
+	( HTTP 메시지에 모든 것을 담아서 전송할 수 있다. )
+- 클라이언트 <-> 서버 구조
+  ( 예전에는 이렇게 분리되어있지 않았다. )
+  ( 비즈니스로직, 데이터는 서버에 집중, 클라이언트는 렌더링,드로잉에만 집중 )
+  ( 서버, 클라이언트 양측이 독립적으로 개발되어질 수 있게 됨. )
+- Stateful, [[Stateless]]
+- [[비연결성]](connectionless)
+- HTTP 메시지
+- 단순함, 확장 가능
+
+HTTP는 Socket을 사용함. [[HTTP 메시지 전송]]
+
+![[Pasted image 20240308142813.png]]
+
+![[Pasted image 20240308142749.png]]
+![[Pasted image 20240308142802.png]]
@@ -0,0 +1,17 @@
+- IP 주소 부여
+- 지정한 IP 주소에 데이터 전달 ( Packet 이라는 데이터 통신 단위로 전달 )
+  ( IP Packet에는 출발지IP, 목적지IP, 데이터, 등이 포함된다. )
+
+IP의 한계
+- 비연결성: 상대방이 online인지 out of service인지 확인하지 않는다.
+- 비신뢰성: 패킷이 소실되거나 패킷의 순서가 뒤바뀌어 전달될 경우?
+- 프로그램 구분: IP주소의 어떤 프로그램에 데이터를 줘야하는가?
+, 이 한계들을 극복하기 위해 [[TCP]] 프로토콜이 생겼다.
+
+- IP는 기억하기 어렵다.
+- IP는 변경될 수 있다.
+, 이 한계들을 극복하기 위해 DNS 가 생겼다.
+
+패킷은 보통 1500바이트 크기 단위로 잘개 분해되어 전송된다.
+
+
@@ -0,0 +1,14 @@
+If-Modified-Since
+
+마지막 수정시간이 변경된게 있는가?
+
+있다: 200 OK, 요청한 데이터를 응답한다.
+
+없다: 304 Not Modified, 3xx 응답이므로 캐시저장소의 데이터로 Redirection 한다.
+
+
+다만, 이 검증 방법은 다음의 단점들이 있다.
+- 1초 미만 단위로 캐시 조정 불가능
+- 날짜 기반의 로직 사용
+   ( 데이터 수정은 되지 않았어도 마지막 수정날짜만 바뀌면 다른 데이터로 간주한다. )
+- 데이터 말고 주석이나 파일정보만 수정되어도 수정날짜가 바뀜.
@@ -0,0 +1,5 @@
+PATCH /members/100 HTTP/1.1
+Content-Type: application/json
+{
+ "age": 50
+}
@@ -0,0 +1,20 @@
+스펙: POST 메서드는 대상 리소스가 리소스의 고유 한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청합니다. (구글 번역)
+
+정리: 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함 -> 정해진 것이 없음
+##### 요청
+POST /members HTTP/1.1
+Content-Type: application/json
+{
+ "username": "young",
+ "age": 20
+}
+
+##### 응답
+HTTP/1.1 201 Created
+Content-Type: application/json
+Content-Length: 34
+==Location: /members/100 ==
+{
+ "username": "young",
+ "age": 20
+}
@@ -0,0 +1,18 @@
+
+PUT /members/100 HTTP/1.1
+Content-Type: application/json
+{
+ "username": "old",
+ "age": 50
+}
+
+
+
+PUT /members/100 HTTP/1.1
+Content-Type: application/json
+{
+ "age": 50
+}
+이렇게 주면 기존의 username은 사라지게됨.
+
+age만 변경하고 싶으면 PUT말고 [[PATCH]]를 쓰자.
@@ -0,0 +1,17 @@
+==리소스 URI를 서버가 관리하느냐(POST) 클라이언트가 지정해주느냐(PUT)==
+
+POST - 신규 자원 등록 특징
+: 클라이언트는 새롭게 등록될 리소스의 URI를 알지 못한다.
+1. 클라이언트 요청 /members -> POST
+2. 서버가 새로 등록된 리소스 URI를 생성해준다.
+   HTTP/1.1 201 Created
+   Location: /members/100
+3. 컬렉션(서버가 관리하는 리소스 디렉토리, /members )
+   서버가 리소스의 URI를 생성하고 관리한다.
+
+PUT - 신규 자원 등록 특징
+: 클라이언트가 리소스 URI를 알고 있어야 한다.
+1. 파일 등록 /files/{filename} -> PUT , {filename}을 클라이언트가 지정해주니까 알고 있다.
+2. 클라이언트가 직접 리소스의 URI를 지정해준다.
+3. 스토어(클라이언트가 관리하는 리소스 저장소, /files )
+   클라이언트가 리소스의 URI를 알고 관리한다.
@@ -0,0 +1,14 @@
+#### 무상태 프로토콜
+스테이트리스(Stateless)
+- 서버가 클라이언트의 상태를 보존하지 않음
+- 장점: **서버 확장성** 높음(스케일 아웃, 수평 확장에 유리)
+- 단점: 클라이언트가 추가 데이터 전송
+
+Stateful: 진행 상태를 서버가 가지고 있음
+Staetless: 진행 상태를 클라이언트가 가지고 있음
+
+상태유지는 항상 같은 서버가 유지되어야 한다.
+(유지하기 싫으면 서버간에 상태를 주고받아야 한다.)
+
+모든것을 무상태로 만들 수는 없기 때문에
+최소한으로 상태유지를 사용해야한다.
@@ -0,0 +1,16 @@
+: 전송 제어 프로토콜 ( Transmission Control Protocol )
+TCP/IP 패킷에는 IP패킷 데이터에 아래의 데이터가 추가된다.
+- 출발지 Port, 목적지 Port
+- 전송 제어
+- 순서
+- 검증 정보 등등
+
+IP의 한계점을 극복하기 위한 정보들이 추가되어진다.
+
+TCP 특징
+- 연결 지향 ( [[3 way handshake]], 가상 연결.  실제로 연결된건 아니지만 연결된것을 가장함. )
+- 데이터 전달 보증  ( 송신한 데이터에 대한 200 ok 같은 수신상태에 대한 응답을 받음 )
+- 순서 보장 ( 패킷 순서를 매겨서 순서를 확인함. )
+
+을 통해 IP에선 없었던 신뢰성을 확보함.
+현재는 대부분 TCP를 사용.
@@ -0,0 +1,9 @@
+사용자 데이터그램 프로토콜 (User Datagram Protocol)
+
+- TCP에 비해 별다른 기능이 없음.
+- IP 에 Port, Checksum만 추가했다고 생각하면 편함.
+- 즉 프로그램 구분, 데이터에 노이즈가 있는지 확인하는 기능정도가 추가됨.
+
+별다른 기능이 없어서 빠르다.
+사용자 커스터마이징에 유리하다. ( 애초에 별 기능이 없어서 수정이 편하다나.. )
+
@@ -0,0 +1,20 @@
+**U**niform **R**esource **I**dentifier
+
+Uniform: 리소스 식별하는 통일된 방식
+Resource: 자원, URI로 식별할 수 있는 모든 것 ( 제한 없음 )
+Identifier: 다른 항목과 구분하는데 필요한 정보
+
+URI는 로케이터(==L==ocator), 이름(Name) 또는 둘 다 추가로 분류될 수 있다.
+URL: Uniform Resource Locator -> 리소스가 있는 위치를 지정, 변할 수 있음.
+URN: Uniform Resource Name -> 리소스의 이름을 부여, 이름은 변하지 않음.
+    ( 하지만 URN을 사용할 방법이 보편적으로 제공되지 않음.  그래서 URN은 안씀 )
+
+URI = URL(Resource ==L==ocator) - 리소스의 위치 **+** URN(Resource ==N==ame) - 리소스의 이름
+![[Pasted image 20240305173626.png]]
+
+
+URL
+scheme
+![[Pasted image 20240305174050.png]]
+userinfo@는 거의 안씀
+fragment도 거의 안씀
@@ -0,0 +1,25 @@
+- 모든것이 HTTP 기반으로 동작
+: 그래서 모두(백엔드,프론트앤드 등)가 잘 알아야 한다.
+
+##### 인터넷 네트워크
+- [[인터넷 통신]]
+- [[IP]]
+- [[TCP]]
+- [[UDP]]
+##### URI와 웹브라우저 요청 흐름
+- [[URI]]
+##### HTTP
+- [[HTTP]]
+- [[HTTP Methods]]
+- [[API URI]]
+##### HTTP API 설계
+- [[API 설계 - POST 기반 등록]]
+- [[API 설계 - PUT 기반 등록]]
+- [[API 설계 - HTML FORM 기반 등록]]
+- [[Post와 Put의 차이점]]
+##### HTTP 상태코드
+- [[HTTP 상태코드]]
+##### HTTP 헤더, 쿠키, 캐시
+- [[HTTP Header 정보]]
+- [[쿠키]]
+- [[프록시 캐시 서버]]
@@ -0,0 +1,15 @@
+connectionless
+
+클라이언트 <-> 서버간의 연결 유지를  하지 않는다. 리소스 사용 최소화에 유리
+
+- HTTP는 기본적으로 연결을 유지하지 않는 모델
+- 일반적으로 초 단위 이하의 빠른 속도로 응답
+- 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 적음. ( 웹 브라우저에서 계속 연속해서 검색을 하지는 않는다. )
+- 서버 자원을 매우 효율적으로 사용할 수 있음.
+
+
+비연결성의 한계와 극복
+- TCP/IP 연결을 새로 맺어야함. (그때그때마다) - 3 way handshake 시간 추가
+- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등등 수많은 자원이 함께 다운로드됨.
+- HTTP 지속 연결(Persistent Connections)로 문제 해결
+- HTTP2, HTTP3에서 최적화가 많이 됨.
@@ -0,0 +1,2 @@
+나의 HTTP 요청에 실제로 응답을 해준 서버를 의미
+( 프록시 서버 등등 다 제외하고 )
@@ -0,0 +1,14 @@
+서로 다른 두대의 PC가 데이터를 주고받고자 한다,
+만약 PC 두대 사이의 물리적인 거리가 가깝다면?
+통신선을 서로 연결하고 데이터를 직접 주고받으면 된다.
+
+만약 둘 사이의 거리가 물리적으로 연결하기 힘든 먼거리에 있다면?
+ ( 랜선으로 서로를 연결할 수 없는 상황 )
+상호간의 물리적인 연결은 불가능하다. 그럼 서로 통신을 하지 않을 것인가?
+
+이 둘 사이를 직접 연결할 순 없지만, 
+이 둘 모두 인터넷망에 연결되어있다는 공통점이 있다. ( 인터넷이 정확히 뭔진 모른다 셈 쳐도 )
+먼 거리에 있는 두 PC가 인터넷망을 통해서 데이터를 주고 받을 수 있지 않을까??
+
+가능하다! 인터넷을 통해 데이터를 주고받는 규약을 IP ( Internet Protocol )라고 하며,
+이 IP 를 지키면 인터넷에 연결된 터미널간의 데이터 통신이 가능하다.
@@ -0,0 +1,12 @@
+- 인터넷 네트워크는 느리고 비싼 작업이다.
+- 브라우저는 속도가 느리다.
+
+사용자 브라우저에 캐시 설정한 데이터를 저장해놓는다.
+( 브라우저 캐시, 브라우저 내부에 캐시 데이터를 저장해놓을 공간 )
+
+캐시에서 먼저 데이터를 찾아보고 있으면 캐시 저장소에서 꺼내고 없으면
+서버로부터 받는다.
+
+캐시는 별도의 작업이 없으면 유효시간이 경과되면 서버에게 다시 요청해서 갱신한다.
+-> 데이터는 변하지 않았는데 유효시간이 경과되었단 것 때문에 다시 받는 것은 비효율적이다.
+: 이를 해결하기 위해 검증 헤더를 사용한다. ([[Last-Modified]], [[ETag]])
@@ -0,0 +1,22 @@
+- Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
+- Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고 HTTP 요청시 서버로 전달
+- 사용자 로그인 세션 관리에 진짜 많이 쓰임
+- 쿠키 정보는 항상 서버에 전송됨
+	-> 네트워크 트래픽 추가 유발
+	-> 최소한의 정보만 사용 (세션 id, 인증 토큰)
+	-> 서버에 전송하지 않고 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹스토리지 사용
+- 보안에 민감한 데이터는 저장하면 안됨
+
+##### 쿠키 생명주기
+- Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
+  : 만료일이 되면 쿠키 삭제
+- Set-Cookie: max-age=3600 (3600초)
+  : 0이나 음수를 지정하면 쿠키 삭제
+
+세션 쿠키: 만료 날짜를 생략하면 브라우저가 종료되기 전까지만 유지
+영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지
+
+##### 쿠키 보안
+- Secure: https 요청에만 Cookie를 실어보냄
+- HttpOnly: 자바스크립트에서 Cookie접근을 막음
+- SameSite: 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키 전송
@@ -0,0 +1,4 @@
+- Origin Server가 먼 곳에 있을 경우, 매번 Origin Server와의 통신을 하게 될 경우 딜레이가 있을 수 있다.
+- Origin Server와 웹 브라우저 사이에 캐시 서버 역할의 프록시 서버를 두고 사용하면 빠른 응답속도를 기대할 수 있다.
+
+예를들어 유튜브 영상의 경우 사람들이 많이 보는 컨텐츠는 로딩속도가 빠르고 정말 잘 안보는 동영상은 로딩이 느린데 이게 캐시서버 덕분이다.