10주차 [Network] Cookie와 Session

Java/다익스트라(Dijkstra) 알고리즘.md

@@ -0,0 +1,51 @@
+# 다익스트라(Dijkstra) 알고리즘
+
+## 요약
+
+>다익스트라 알고리즘이란 하나의 정점에서 그래프 상에 존재하는 다른 모든 정점, 즉 **두 정점 사이의 최단거리**를 구하는 알고리즘이다.
+
+## 정의
+
+- 다이나믹 프로그래밍을 활용한 대표적인 **최단 경로(Shortest Path) 탐색 알고리즘**
+  - 최단 경로란 **간선의 가중치가 있는 그래프**에서 두 정점 사이의 경로들 중에 **간선의 가중치 합이 최소**인 경로
+- 하나의 정점에서 **다른 모든 정점으로 가는 최단 경로**를 구하는 알고리즘
+  - 즉, **두 정점 사이의 최단거리를 구하는 알고리즘**
+- 음의 가중치를 허용하지 않는다. (오로지 **양의 가중치**)
+- 현실 세계에 사용하기 매우 적합한 알고리즘 중 하나<br/>
+  ex) 인공위성 GPS 소프트웨어
+
+- **그리디 기법을 사용**한 알고리즘으로 **<u>MST의 프림 알고리즘과 유사</u>**하다.
+
+- 의사코드
+
+  ```
+  s: 시작 정점, A: 인접 행렬, D: 시작정점에서의 거리
+  V: 정점 집합, U: 선택된 정점 집합
+
+  Dijkstra(s, A, D)
+  	U = {s};
+      FOR 모든 정점 v
+  		D[v] = A[s][v]
+  	WHILE U != V
+  		D[w]가 최소인 정점 w ∈ V-U를 선택
+  		U = U ∪ {w}
+  		FOR w에 인접한 모든 미방문 정점 v
+  			D[v] = min(D[v], D[w] + A[w][v])
+  ```
+
+
+
+## 프림과 다익스트라 차이
+
+![프림과_다익스트라_차이](img/프림과_다익스트라_차이.jpg)
+
+- **프림은 다익스트라와 달리 두 노드 사이가 최단거리가 아닐 수도 있다.**
+- 프림이 다익스트라를, 다익스트라가 프림을 보장해주지 않는다.
+
+| 프림 알고리즘                                          | 다익스트라 알고리즘                                    |
+| ------------------------------------------------------ | ------------------------------------------------------ |
+| 최소 신장 트리                                         | 최단경로 알고리즘                                      |
+| 전체 그래프 관점에서의 모든 정점들을 최소비용으로 연결 | 정점 간의 최단 거리 연결                               |
+| 정점 간의 최소 비용을 보장X                            | 정점 간 최소 비용을 보장                               |
+| 무향그래프에서만 사용                                  | 무향,유향 그래프에서 모두 사용(단, 양의 가중치인 경우) |
+

Java/최소비용 신장트리(MST).md

@@ -0,0 +1,88 @@
+# 최소비용 신장트리(MST)
+
+## 요약
+
+>신장 트리를 구성하는 간선들의 가중치의 합이 최소가 되는 트리를 최소 신장 트리라 하며 , 대표적으로 크루스칼 알고리즘, 프림 알고리즘이 있다.
+>
+>크루스칼 알고리즘은 **간선 선택 기반 알고리즘**으로, 가중치가 최소인 간선을 하나씩 선택해서 MST를 만드는 알고리즘이다. 
+>
+>프림 알고리즘은 정점 선택 기반 알고리즘으로, 하나의 정점에서 연결된 간선들 중 가중치가 최소인 간선을 가진 정점을 하나씩 선택해서 MST를 만드는 알고리즘이다.
+
+## 정의
+
+- 신장 트리
+
+  N개의 정점으로 이루어진 무향 그래프에서 N개의 정점과 N-1개의 간선으로 이루어진 트리
+
+- **최소 신장 트리 (Minimum Spanning Tree)**
+
+  무향 가중치 그래프에서 신장 트리를 구성하는 **간선들의 가중치의 합이 최소**인 신장 트리<br/>EX) 크루스칼 알고리즘, 프림 알고리즘
+
+## 크루스칼 알고리즘
+
+- 매 차례마다 **가중치가 최소인 간선을 선택**하면서 MST를 만드는 알고리즘
+  1. 간선을 **오름차순으로 정렬**하여 선택한다.
+  2. 사이클이 생성되지 않게 매번 **사이클 생성 여부를 판단**하면서 가중치가 가장 낮은 간선을 선택한다.
+     - 사이클이란 A, B, C 정점이 있을 때 A-B, B-C, A-C로 그래프가 서로 연결되어 있는 상태를 의미
+  3. N-1개의 간선이 선택될 때까지 2번 과정 반복
+- **서로소(union-find) 알고리즘**과 **그리디 알고리즘 방법** 이용
+
+- 의사코드
+
+  ```groovy
+  MST-KRUSKAL(G, w)
+  	FOR vertex v int G.V	//G.V: 그래프의 정점 집합
+  		Make_Set(v)			//G.E: 그래프의 간섡 집합
+
+  	G.E에 포함된 간선들을 가중치 w에 의해 오름차순 정렬
+
+  	FOR 가중치가 가장 낮은 간선 (u, v) ∈ G.E 선택 (n-1개만큼)
+  		IF Find_Set(u) != Find_Set(v) // 사이클 생성 여부 판단
+  			A = A ∪ {(u, v)}
+  			Union(u, v) 	// 간선 연결
+  ```
+
+- 시간복잡도
+  - 사실상 정렬 알고리즘과 Union-Find 알고리즘의 합이기 때문에 정렬 알고리즘의 시간 복잡도와 동일하다고 판단 가능
+  - 가중치순으로 정렬하는데 E * logE 만큼의 시간이 소요되었으므로<br/> **시간복잡도는 O(ElogE)**
+
+## 프림 알고리즘
+
+- **하나의 정점**에서 연결된 간선들 중에 하나씩 선택하면서 MST를 만들어 가는 방식
+
+  1. 임의의 정점 하나 선택
+  2. 선택한 정점과 인접하는 선택되지 않은 정점들 중 **가중치가 최소인 간선**으로 연결된 정점을 새로 선택
+  3. 모든 정점이 선택될 때까지 2번 과정 반복
+
+- 이미 선택된 정점을 다시 선택하지 않기 때문에, 사이클 생성 여부 판단하지 않음
+
+- 의사코드
+
+  ```groovy
+  MST_PRIM(G, r)				//G: 그래프, r: 시작 정점
+  	result = 0, cnt = 0;	//result: 신장트리 최소비용, cnt:처리한 정점수
+  	FOR u in G.V
+  		miniEdge[u] =  MAX_VALUE		// miniEdge[]: 각 정점기준으로 다른 정점과의 간선 중 최소비용
+  	miniEdge[r] = 0						//시작 정점 r의 최소 비용 0처리
+  	WHILE true
+  		u = Extract_MIN( )				//방문하지 않은(최소신장트리에 포함되지 않는 정점) 최소비용 정점 찾기
+  		visited[u] = true
+  		result = result + miniEdge[u];	//비용 누적
+  		if(++cnt == N) break;
+  		FOR v in G.Adj[u] 				//u의 인접 정점들
+  			IF visited[v] == false AND w(u, v) < miniEdge[v]	//u에서 v로의 비용이 v의 최소비용보다 작다면 갱신
+  				miniEdge[v] = w(u, v)
+  	return result
+  end MST_PRIM
+  ```
+
+- 시간복잡도
+
+  - 우선순위 큐를 어떻게 구현하느냐에 따라 다르지만 <br/>일반적으로 **binary heap**으로 구현했을 경우 **O(ElogV)**<br/>**unsorted arrary**로 구현헀을경우 **O(|V²|)**
+
+## 크루스칼 vs 프림 알고리즘 차이점
+
+**크루스칼 알고리즘**은 정렬을 반드시 동반하기 때문에 **간선의 개수가 증가**하먼 정렬 소요 시간이 증가한다.
+
+> 즉, **크루스칼 알고리즘은 간선의 개수가 많지 않은 경우에 적합하며, 간선의 개수가 많을 때는 프림 알고리즘을 사용한다.**
+

Network/Cookie,Session.md

@@ -0,0 +1,105 @@
+# 쿠키와 세션의 차이
+## 요약
+> **쿠키**
+> - 클라이언트의 로컬에 저장되는 키와 값의 작은 데이터
+> - 텍스트 형식으로 저장된다. 
+> - 브라우저 종료시에도 로컬에 남아있을 수 있으며 보안에 민감한 데이터는 저장하면 안된다.
+>
+> **세션**
+> - 일정시간동안 같은 브라우저로 들어오는 일련의 요구사항을 하나의 상태로 보고 그 상태를 유지하는 기능
+> - 서버에 Object 형식으로 저장된다. 
+> - 브라우저 종료 시 무조건 삭제되며 쿠키보다 보안이 좋다.
+
+## 왜 쿠키와 세션을 사용할까?
+HTTP 프로토콜은 `Stateless, Connectionless`한 특징을 가지기 때문에 **데이터 유지가 안돼서 서버는 클라이언트가 누구인지 매번 확인**해야한다. 
+
+따라서, 상태 유지(Stateful) 경우를 대처하기 위해서 쿠키와 세션을 사용한다.
+
+- **Stateless 프로토콜**
+   - 클라이언트의 상태 정보를 가지지 않는 서버 처리 방식
+   - 클라이언트와 첫번째 통신에서 데이터를 주고 받았다 해도, 두번째 통신에서 이전 데이터를 유지하지 않는다.
+
+- **Connectionless 프로토콜**
+   - 클라이언트가 서버에 요청(Request)을 했을 때,그 요청에 맞는 응답(Response)을 보낸 후 연결을 끊는 처리방식
+   - HTTP 1.1 버전에서 연결을 유지하고, 재활용 하는 기능이 Default 로 추가되었다. (keep-alive 값으로 변경 가능)
+
+## 쿠키(Cookie)
+### 쿠키란?
+- 웹 서버가 브라우저에게 지시하여 **클라이언트의 로컬 컴퓨터**에 파일 또는 메모리에 저장하는 **작은 데이터 txt 파일**
+- 파일에 담긴 정보는 인터넷 사용자가 같은 웹사이트를 방문할 때마다 읽히고 수시로 새로운 정보로 바뀔 수 있다.
+- 사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다. (Permanent 쿠키)
+- 최대 파일 크기는 4KB, 로컬에 최대 300개 저장 가능, 하나의 도메인 당 20개의 값만 가질 수 있음
+- **보안에 민감한 데이터는 저장하면 안됨** (주민번호, 신용카드 번호 등)
+- 쿠키에 대한 정보를 매 헤더에 추가하여 보내기 때문에 **상당한 트래픽을 발생**시킴
+- HTTP cookie, web cookie, internet cookie 라고도 부른다.
+
+### 쿠키의 구성 요소
+|  요소           | 정의 |
+|-----------------|------|
+|이름(Name)       |각각의 쿠키를 구별하는데 사용되는 이름|
+|값(Value)        |쿠키에 저장된 값|
+|유효시간(Expires)|쿠키의 유지시간<br/> `Expires=Wed, 21 Oct 2015 07:28:00 GMT;`|
+|도메인(Domain)   | 쿠키를 전송할 도메인|
+|경로(Path)       | 쿠키를 전송할 요청 경로|
+
+### 쿠키 동작 방식
+1. 클라이언트가 HTTP 요청을 함
+2. 서버는 응답과 함께 `Set-Cookie` 헤더를 전송
+3. 웹 브라우저 내부에 있는 **쿠키 저장소**에 저장됨. 
+   <br/>유효시간이 명시되어 있다면 브라우저가 종료되어도 보관하고 있음
+4. 같은 서버로 요청 할 경우, 쿠키는 `HTTP 헤더`안에 **포함**되어 보내짐.
+5. 서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트 하여 변경된 쿠키를 `HTTP 헤더`에 포함시켜 응답
+![cookie동작방식](img/cookie동작방식.jpg)
+
+### 사용 예시
+- 쇼핑몰 장바구니
+- 방문 사이트 로그인 시, "아이디와 비밀번호를 저장하시겠습니까? (세션 관리)
+- 광고 정보 트래킹 (사용자 행동을 기록하고 분석하기 위해)
+
+## 세션(Session)
+### 세션이란?
+- 웹 사이트의 여러 페이지에 걸쳐 사용될 수 있도록 사용자 정보를 저장하는 방법을 의미
+- 클라이언트를 구별하기 위해 `HTTP Session ID` 부여
+- **데이터**는 서비스가 돌아가는 **서버DB에 저장**하고, **세션의 키값** (`HTTP Session ID`)만 클라이언트의 **쿠키**형태로 **메모리에 저장**
+- 메모리에 저장하기 때문에 브라우저가 종료되면 사라지게 된다.
+- 물론 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능
+- 보안에 취약한 **쿠키를 보완**해주는 역할 (사용자 정보를 서버에 두기 때문)
+- 그러나, 동접자 수가 많은 웹 사이트인 경우 **서버 메모리를 많이 차지**하게 되므로 **성능 저하의 요인**이 된다.
+   - 이러한 이유로 쿠키가 유리한 경우는 쿠키를 사용한다.
+
+### 세션 동작 방식
+1. 클라이언트가 서버에 접속 시 `Session ID` 발급 받음
+2. 클라이언트는  `Session ID`에 대해 쿠키를 사용해서 저장하고 가지고 있음
+3. 클라리언트는 서버에 요청할 때, 이 쿠키의 `Session ID`를 같이 서버에 전달해서 요청
+4. 서버는 `Session ID`를 전달 받아서 별다른 작업없이 `Session ID`로 세션에 있는 클라언트 정보를 가져와서 사용
+5. 클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답
+![session동작방식](img/session동작방식.jpg)
+
+### 사용 예시
+- 로그인 같이 보안상 중요한 작업을 수행할 때 사용
+
+## 쿠키와 세션의 차이
+- 쿠키와 세션은 비슷한 역할을 하며, 동작원리도 비슷함
+- 세션도 결국 쿠키를 사용하기 때문이다.
+
+|        | 쿠키(Cookie) | 세션(Session)|
+|--------|--------------|--------------|
+|저장위치|클라이언트    |서버|
+|저장형식|텍스트        |Object|
+|만료시점|쿠키 저장시 설정<br/>설정 없으면 브라우저 종료 시 소멸|정확한 시점 모름<br/>만료시간 설정을 하더라도 브라우저 종료 시 소멸|
+|용량제한|한 도메인 당 20개<br/>한 쿠키당 4kb<br/> 최대 300개|용량제한 없음|
+|속도    |서버에 요청 시 빠름|서버 처리가 필요해 쿠키보단 느림|
+|보안    |낮음|비교적 좋음|
+
+> 세션은 사용자의 수 만큼 서버 메모리를 차지하기 때문에 요즘은 이런 문제들을 보완한 토큰 기반의 인증방식을 사용하는 추세 (JWT)
+
+## 캐시란?
+- 리소스 파일들의 임시 저장소
+   - **이미지, 비디오 오디오, CSS/JS, 배너 등 변경 사항이 크지 않고, 용량이 큰 파일**
+- 첫 번째 요청 시, WAS에 접근한 후 요청 결과를 로컬 PC의 캐시에 저장<br/>
+  두번째 요청 시, 바로 로컬 PC의 캐시를 꺼냄 
+- 즉, 같은 웹 페이지에 접속할 때는 사용자의 PC에서 로드하므로 서버를 거치지 않아도 된다. 
+- 왜냐하면 이전에 사용되었던 데이터는 **다시 사용될 가능성이 높기 때문**이다. 
+
+=> 페이지 로딩 속도를 개선함
+

Network/WebSocket.md

@@ -0,0 +1,73 @@
+# WebSocket
+
+## 요약
+
+> 웹소켓이란 서버와 클라이언트 간의 효율적인 양방향 통신이 가능한 방법으로, 기본적으로 stateful protocol 방식이다. 
+>
+> 정보를 실시간 교류할 수 있디 때문에 채팅, 주식과 같은 즉각적인 변화를 감지해야 하는 서비스에 좋다. 
+>
+> 그러나 개발이 복잡하고 서버와 클라이언트 간의 소켓 연결을 유지하는 것 자체가 비용이 크기 때문에 트래픽 양이 많은 서버의 경우 CPU에 부담을 줄 수 있다. 또한 HTML5 이전 브라우저에서는 지원되지 않아 작동하지 않는다. 마지막 문제를 해결하기 위해 나온 기술 중 하나가 node.js 기반으로 만들어진 socket.io라는 프레임워크이다.
+
+## Socket이란?
+
+- 프로그램이 네트워크 상에서 데이터를 송신과 수신을 하기 위한 연결부 (통신을 위한 일종의 통로)
+- 일반적으로 TCP/IP (또는 UDP) 프로토콜을 이용하거나, WebSocket을 이용한다.
+  - TCP/IP: **연결형 소켓**. 신뢰할 수 있는 통신
+  - UDP: **비연결형 소켓**. 몇가지 신뢰도는 포기하되 좀더 직접적인 통신을 한다
+
+## WebSocket이란?
+
+- HTML5의 표준 기술
+- Transport protocol의 일종으로 서버와 클라이언트 간의 효율적인 **양방향 통신**을 실현하기 위한 구조
+
+- 단순한 API로 구성
+- 웹소켓을 이용하면 **하나의 HTTP 접속**으로 **양방향 메시지**를 자유롭게 주고받을 수 있다.
+
+> 웹소켓 이전의 기존 HTTP 통신은 단방향 통신으로, 클라이언트의 요청이 없다면 서버로부터 응답을 받을 수 없는 구조였다. <br/>이 문제를 극복하기 위해 등장한 것이 WebSocket!!
+
+## 특징
+
+- **양방향 통신(Full-Duplex)**
+  - 데이터 송수신을 동시에 처리할 수 있는 통신 방법
+  - 클라이언트와 서버가 서로에게 원할 때 데이터를 주고 받는다
+- **실시간 통신/성능(Real Time-Networking)**
+  - 웹 환경에서 연속된 데이터를 빠르게 노출한다.
+  - 여러 단말기에 데이터를 빠르게 교환한다.
+  - ex) 채팅, 주식, 비디오 데이터
+
+## 작동 원리
+
+- 웹소켓 연결은 HTTP 프로토콜을 통해 이루어짐
+- handshake 과정이 성공적으로 끝나면 HTTP를 웹소켓 프로토콜로 바꾸는 protocol switching 과정이 진행됨
+- 이후 웹소켓을 위한 새로운 소켓이 만들어지고 이 소켓을 이요해 통신한다.
+
+![웹소켓_작동원리](img/웹소켓_작동원리.jpg)
+
+> 웹소켓 주소는 ws나 wss로 시작하는데 ws는 일반 웹소켓, wss는 SSL이 적용된 웹소켓
+
+## 문제점
+
+- 프로그램 구현에 보다 많은 복잡성 초래
+- Stateful Protocol 특성
+  - 웹소켓은 HTTP와 다르게 **항상 클라이언트와 서버 간의 연결을 유지**해야 함
+  - 비정상적으로 연결이 끊어졌을 경우에 대한 대응 필요
+- 서버와 클라이언트 간의 Socket 연결을 유지하는 것 자체가 자원 소모 (특히 트래픽 양이 많은 서버의 경우)
+- HTML5의 기술이기 때문에 이전 버전의 웹 브라우저에서 지원이 되지 않는다.
+  - 이 문제를 해결하기 위해 나온 기술 중 하나가 바로 `Socket.io` 라는 웹소켓 프레임워크
+  - 웹페이지가 열리는 브라우저가 웹 소켓을 지원하면 웹 소켓 방식으로 동작하고, 지원하지 않는다면 일반 HTTP를 이용하여 실시간 통신을 흉내 내는 것
+
+## 대표적인 사용 예
+
+- 페이스북, 인스타와 같은 SNS APP
+- 위치 기반 APP
+- 화상 채팅 APP
+- 증권 거래 정보 사이트 및 APP
+- 구글 Doc 같이 여러 명이 동시 접속해서 수정할 수 있는 Tool
+- LOL 같은 멀티플레이어 Game
+
+## 참고
+
+- https://choseongho93.tistory.com/266
+- https://kyleyj.tistory.com/59
+- https://d2.naver.com/helloworld/1336
+- https://dailyscat.gitbook.io/twis/network/undefined