[2주차] 네트워크

2주차/kwYoohae/DNS_요청과정.md

@@ -0,0 +1,8 @@
+## DNS 요청 과정
+1. 사용자가 Browser에 www.naver.com과 같은 도메인 이름을 입력해서 요청을 합니다. 
+2. 우선 DNS 캐시에 www.naver.com의 주소가 있는지 확인합니다
+    - 캐시는 컴퓨터에도 있지만, 브라우저에도 존재합니다 `chrome://net-internals/#dns`로 확인이 가능합니다
+3. 만약 없으면 로컬 DNS서버에서도 DNS 쿼리를 보내서 확인을합니다. 
+4. 그럼에도 불구하고 없다면 이제 루트 DNS -> TLD DNS -> Domain Name Server순으로 반복 혹은 재귀적 쿼리를 보내서 IP 주소를 얻어옵니다
+     - 도메인서버까지 가기전에 TLD나 Root등은 어떤 DNS 서버가 알고있다고 알려주는 역학을 수행합니다
+5. IP 주소는 DNS 캐시에 저장되고, 이를 사용해서 통신을 합니다 

2주차/kwYoohae/HTTP2_Multiplexing.md

@@ -0,0 +1,17 @@
+## Multiplexing
+- 기존 HTTP1.1에서는 한 번의 TCP 연결에 하나의 요청과 응답만 처리가 가능하였습니다 
+    - 그렇기 때문에 여러 리소스에 대해서 처리를 한다면, 리소스간 대기 시간이 생겨서 로딩시간이 길어졌습니다
+- 이를 해결하기 위해서 Multiplexing이라는 매커니즘이 동작되었고 아래는 해당 매커니즘을 구성하는 설명입니다 
+
+### Frame
+- HTTP1.1에서는 Plain Text로 보내고 개행으로 메시지를 구별하였다
+    - 하지만 HTTP2.0부터는 Binary로 인코딩된 Message, Frame이 생기게 되었습니다. 
+    - HTTP2.0은 메시지를 Binary로 구성하고 더 작은 Frame으로 쪼개서 이를 관리합니다.
+- 이떄, Frame은 HTTP/2의 최소 통신단위로 모든 패킷에는 하나의 Frame Header가 존재합니다
+    - 헤더에 프레임에 대한 식별자, 우선순위등이 있어서 응답의 순서를 고려하지 않고 보내도 순서대로 정렬이 가능합니다
+    - 이런 헤더는 HPACK알고리즘을 통해 압축해서 대역폭을 절약합니다.
+### Stream
+- HTTP/2는 Stream을 사용해서 데이터를 병렬로 전송을 합니다
+- 이는 여러개의 요청과 응답을 병렬로 처리하는 기본적인 단위로 볼 수 있습니다.
+    - 각 스트림은 순서를 가져서 중요한 리소스 부터 처리할 수 있습니다.
+- HTTP/2는 이러한 스트림의 개수나 우선순위를 조절하면서 동시성을 해결하고 있습니다.

2주차/kwYoohae/README.md

@@ -0,0 +1,15 @@
+### TODO
+- [x] TCP/IP의 4계층
+- [X] DNS 주소를 찾을 때 어떤 과정을 거치는지 
+- [X] 흐름제어 혼잡제어가 뭔지
+- [X] HTTP/2에서의 Multiplexing이 뭐지 
+
+
+### 질문 사항 
+- DNS 레코드가 뭔가요? 
+- HTTP의 각버전의 차이는? 
+- HTTP의 메서드의 특징 (멱등성) 
+- HTTP 상태코드에서 400과 500의 차이 
+- HTTP에서 캐시를 적용하는 방법
+- 쿠키의 옵션에 대한 설명
+- 소켓의 동작방식 

2주차/kwYoohae/TCP_IP_4계층.md

@@ -0,0 +1,16 @@
+## TCP/IP 4계층
+### 링크 계층
+ - 링크 계층은 물리적인 네트워크 매체를 통한 신호 전송과 관련된 기능을 다룸
+    - LAN 등에 사용이 됩니다
+### 네트워크 계층
+- 데이터의 Routing 및 Packet 전달을 다루는 계층입니다
+- IP주소를 통해서 식별을 해서 목적지까지 패킷을 전달하는 역할을 합니다
+    - 순서가 없고, 패킷 전달 여부를 보증하지 않습니다. 
+### Transport 계층
+- 데이터의 전송을 관리하고, 두 컴퓨터간의 연결을 설정, 유지, 해제하는 역할을 담당합니다
+- TCP/UDP등이 이 계층에서 수행이됩니다
+    - 순서를 보장하고 손실된 패킷에 대해서 재전송등을 합니다
+### Application 께층
+- 실제 사용자나 응용 프로그램이 상호 작용하는 계층이비낟
+    - HTTP, SMTP, FTP과 같은 다양한 프로토콜이 사용이 됩니다. 
+

2주차/kwYoohae/흐름제어_혼잡제어.md

@@ -0,0 +1,25 @@
+## 흐름제어 
+- 만약, 송신측이 데이터를 수신측이 처리를 못하면 늦어지게된다 (데이터의 양)
+    - 만약, 늦어지면 패킷이 손실 될 수도 있다
+    - 이를 해결하기 위해 흐름제어를 사용해서 송신측과 수신측의 네트워크 데이터 처리 속도차이를 해결한다
+- TCP에서는 흐름제어에는 여러가지 방식이 있다 
+### Stop And Wait
+- TCP는 전송을 할 떄, 매번 전송한 패킷에 대해 ACK응답을 받아야만 그 다음 패킷을 전송하는 흐름제어 해결방법입니다
+### Sliding Window 
+- Stop And Wait와 다르게 ACK이 오기전에 패킷을 전송할 수 있는 방법이다. 
+- 윈도우 사이즈를 우선적으로 정하고 난 뒤에 ACK이 오기 전까지 데이터를 계속해서 보낸다
+    - 도착한 (수신측에서 보낸 ACK)에는 TCP 헤더에 window size를 담아서 보냅니다 
+    - 도착한 ACK을 온다면 윈도우를 옆으로 옮겨서 다시 다음 패킷을 전송한다
+    - 이는 데이터를 다 받을 때 까지 이 과정을 계속 반복을 한다
+<img width="817" alt="image" src="https://github.com/kwYoohae/CS-Study/assets/74089271/8eb8137c-f122-4108-87fa-b13ee7a7c530">
+
+
+## 혼잡제어
+- 혼잡 제어는 네트워크 내에서 발생하는 혼잡 현상을 관리하고 제어하여 패킷 손실 및 전송 지연을 최소화 하려는 것입니다
+    - 라우터가 데이터를 처리하는 속도보다 많은 양의 데이터가 들어온다면, 계쏙해서 데이터를 유실한것으로 생각하고 데이터를 보내 네트워크가 혼잡해집니다. 
+    - 우리는 혼잡제어 기술을 통해, 이러한 송신자의 데이터 전송속도를 조절합니다. 
+### Cogestion Window
+- window의 크기를 조절하면서, 우리는 이런 방식을 해결할 수 있습니다. 
+- 우선 Additive Increase로 패킷을 보냈는데 문제 없이 도착을한다면 window의 크기를 1씩 늘립니다
+    - 이러다 만약, 전송에 실패하게 된다면 Multiplicative Decrease를 통해서 Window의 크기를 **절반**으로 줄입니다. 
+- 이런방식이 아닌 SLow Start나 Fast Retransmit 방식도 존재합니다