diff --git "a/2\354\243\274\354\260\250/ddingmin/2, 3 way handshake\354\235\230 \354\260\250\354\235\264.md" "b/2\354\243\274\354\260\250/ddingmin/2, 3 way handshake\354\235\230 \354\260\250\354\235\264.md"
new file mode 100644
index 0000000..0accad7
--- /dev/null
+++ "b/2\354\243\274\354\260\250/ddingmin/2, 3 way handshake\354\235\230 \354\260\250\354\235\264.md"	
@@ -0,0 +1,20 @@
+# 2, 3 way handshake의 차이
+- 두 방법 모두 네트워크에서 연결 설정을 하기 위한 방법이다.
+
+### 2-way handshake
+1. 클라이언트가 서버에게 패킷과 함께 연결을 요청한다.
+2. 서버는 클라이언트에게 연결을 수립하고, 확인하는 패킷은 전송한다.
+
+### 3 way handshake
+1. 클라이언트는 서버에게 패킷과 함께 연결을 요청한다.
+2. 서버는 클라이언트에게 연결 요청을 확인하고, 확인 패킷을 전송한다.
+3. 클라이언트는 연결 확인 패킷을 확인하고, 확인 패킷을 전송한다.
+
+### 차이점
+- 2way 에서는 연결을 확인하는 과정을 ***서버 -> 클라이언트*** 에서만 이루어진다. 신뢰적인 연결을 수립하기 위해서는 다음 두 가지 조건을 만족해야 한다.
+    >1. 상대방에게 패킷을 전달할 수 있다.
+    >2. 상대방으로 부터 패킷을 전달 받을 수 있다.
+
+- 위 과정에서 서버는 1번의 과정을 확인할 수 없다. 따라서 추가적인 전송을 위해 신뢰적인 연결 상태를 수립하는 것이다.
+- 신뢰성 있는 연결을 위해서 한 번의 확인 절차를 더 거치게 되기 때문에 속도적 측면에서는 더 느리다고 할 수 있다. 또한 데이터 전송이 요청시 마다 한 번 더 이루어지기 때문에 간단한 설정만 필요로 하는 경우에는 2way handshake를 사용하기도 한다.
+> 그렇다면 UDP를 사용하는게 더 나은 방법이 아닌가? 라고 생각할 수 있다. 하지만 연결 지향을 원하고, 어느정도 신뢰를 원하지만 연결 시간을 줄여야 하는 경우가 존재한다. 즉, 신속성과 연결 지향성을 모두 챙기고 싶을 경우 선택지가 될 수 있다.
\ No newline at end of file
diff --git "a/2\354\243\274\354\260\250/ddingmin/DHCP.md" "b/2\354\243\274\354\260\250/ddingmin/DHCP.md"
new file mode 100644
index 0000000..950701e
--- /dev/null
+++ "b/2\354\243\274\354\260\250/ddingmin/DHCP.md"
@@ -0,0 +1,24 @@
+# DHCP
+
+## DHCP란?
+- Dynamic Host Configuration Protocol
+- 네트워크에 연결된 디바이스에게 IP주소와 기타 통신 정보들을 연결된 장치들에게 할당해 주는 프로토콜이다.
+- 가정용 네트워크에서는 라우터가 DHCP 서버의 역할을 한다.
+
+## 동작 방식
+- 내 PC가 인터넷 네트워크에 연결하기 위해서는 IP 주소가 필요하다. 
+1. IP 주소를 할당받기 위해 DHCP 서버에게 요청해야 하지만 어디에 존재하는지 모르기 때문에 나의 MAC 주소를 담아 브로드 캐스팅 방식으로 DHCP 서버에게 할당을 요청한다.
+2. DHCP 서버는 누군가의 요청을 받고, 할당할 IP와 DHCP 서버의 IP, 사용할 수 있는 IP 시간을 전달한다.
+3. 클라이언트는 전송받은 IP 주소를 사용하겠다는 요청을 다시 한 번 보낸다.
+4. DHCP 서버는 할당해 주겠다는 응답 메시지와 추가적인 통신 정보들을 보내주며 IP 할당을 마친다.
+
+## 장점
+- 네트워크 할당을 각 PC 클라이언트가 담당하지 않기에 중복 관리가 쉽고, 효율적이다.
+- IP 주소를 DHCP가 할당해 주기 때문에 주소 풀 관리가 쉽다.
+- IP 할당 시간을 두기 때문에 사용하지 않는 주소를 정리하기 쉽다.
+
+## 단점
+- DHCP 서버에 의존하기 때문에 DHCP 서버가 다운되면 전체적으로 마비가 된다.
+- 크게 확장된 네트워크에서 IP 추적이 어려울 수 있다.
+- 기본적으로 인증 메커니즘이 없기 때문에 악의적으로 해커가 DHCP 서버로 위장할 수 있다.
+- 마찬가지로 DHCP 서버가 보낸 정보를 해커 클라이언트가 탈취할 수 있다. (DHCP 스푸닝)
\ No newline at end of file
diff --git "a/2\354\243\274\354\260\250/ddingmin/DNS Server\354\235\230 \352\263\204\354\270\265 \352\265\254\354\241\260.md" "b/2\354\243\274\354\260\250/ddingmin/DNS Server\354\235\230 \352\263\204\354\270\265 \352\265\254\354\241\260.md"
new file mode 100644
index 0000000..684b741
--- /dev/null
+++ "b/2\354\243\274\354\260\250/ddingmin/DNS Server\354\235\230 \352\263\204\354\270\265 \352\265\254\354\241\260.md"	
@@ -0,0 +1,17 @@
+# DNS
+- Domain name server
+- 외우기 힘든 숫자로 이루어진 IP를 사람이 읽고, 기억하기 쉬운 도메인 이름을 사용하도록 도메인와 IP를 서로 변환해주고, 찾을 수 있도록 하는 전화번호부와 같은 서비스이다.
+
+# DNS Server의 계층 구조
+- DNS는 계층적 트리 구조로 이루어져 있으며, URL의 뒤에서부터 읽어 탐색하여 들어간다.
+- 루트 이후 1단계는 TLD (Top Level Domain)라 부른다.
+    - .com, .net과 같은 일반적인 도메인을 gTLDs 라고한다.
+    - 그외에도 국가적 최상위 도메인의 .kr 과 같은 도메인을 ccTLDs 라고 부른다.
+- 2단계는 SLD (Second Level Domain)이라고 부른다.
+    - .co.kr 의 .co 와 같은 부분이 해당한다.
+- 3단계는 주로 도메인명이 위치한다.
+    - .naver , .google 등등
+- 4단계는 www 이 위치하는 부분으로 호스트명이라고도 부른다.
+
+> 위와 같은 계층 구조를 역트리 (Inverted tree) 구조라고 한다. <br>
+> 계층적 구조를 바탕으로 체계적인 주소관리가 가능하며, 서버의 트래픽을 나누어 처리할 수 있기 때문에 분산 처리가 가능해진다.
\ No newline at end of file
diff --git "a/2\354\243\274\354\260\250/ddingmin/DNS\354\235\230 Round robin \353\260\251\354\213\235.md" "b/2\354\243\274\354\260\250/ddingmin/DNS\354\235\230 Round robin \353\260\251\354\213\235.md"
new file mode 100644
index 0000000..dde5ce8
--- /dev/null
+++ "b/2\354\243\274\354\260\250/ddingmin/DNS\354\235\230 Round robin \353\260\251\354\213\235.md"	
@@ -0,0 +1,16 @@
+# DNS의 Round Robin 방식
+- 라운드 로빈 DNS는 별도의 소프트웨어 혹은 하드웨어 로드밸런싱 장비를 사용하지 않고 DNS만을 이용해서 도메인 레코드 정보를 조회하는 시점에서 트래픽을 분산하는 기법이다.
+
+## 원리
+- 먼저 특정 사이트에는 여러개의 웹 서버가 있다고 가정한다. 따라서 각각의 웹서버는 각기 다른 공인 IP를 가지고 있고, 그 정보는 DNS서버가 알 고 있다.
+1. 클라이언트가 DNS서버에게 IP를 요청한다.
+2. DNS서버는 실제 사이트의 서버의 여러개의 IP를 특정 순서나 시간 단위로 번갈아가면서 하나를 선정해 클라이언트에게 전송한다.
+3. 특정 시간마다 다른 IP를 제공하기 때문에 서버는 한 IP의 웹 서버에 몰리는 현상을 방지할 수 있다.
+
+### 장점
+- 로드밸런서 없이 서비스가 가능하다. 로드밸런서는 굉장히 cost가 높다!!
+- 간단하다.
+### 단점
+- 서버의 수 만큼 공인 IP가 필요하다. 사이트 내에서 관리하지 않고 DNS에서 관리하기 때문!
+- 특정 웹 서버에 장애가 발생해도 헬스 체크 기능이 없기 때문에 클라이언트를 해당 웹 서버로 보낼 위험이 있다.
+- 사용자는 매번 DNS요청을 하지 않기 때문에 균등하게 분산시킬 수는 없다.
\ No newline at end of file
diff --git "a/2\354\243\274\354\260\250/ddingmin/HTTP\354\231\200 HTTPS.md" "b/2\354\243\274\354\260\250/ddingmin/HTTP\354\231\200 HTTPS.md"
new file mode 100644
index 0000000..e846bc1
--- /dev/null
+++ "b/2\354\243\274\354\260\250/ddingmin/HTTP\354\231\200 HTTPS.md"	
@@ -0,0 +1,38 @@
+# HTTP, HTTPS
+- Hypertext Transfer Protocol
+- HTTP는 클라이언트와 서버 간 통신을 위한 통신 규칙으로 사용자가 웹 사이트를 방문하면 사용자 브라우저가 웹 서버에 HTTP 요청을 전송하고, HTTP 응답을 받게된다. 간단히 네트워크 통신을 작동하게 하는 기술이다.
+- HTTPS는 HTTP의 보안 취약점을 해결하기 위해 등장한 기술로 SSL, TLS 프로토콜을 이용해서 세션 데이터를 암호화해 통신하는 방식이다. 서버와 클라이언트 사이의 모든 통신이 암호화되어 안전한 통신을 보장한다.
+# TLS/SSL
+- 웹에서 데이터를 가로채면 누구나 읽을 수 있는 일반 텍스트로 전송되기 때문에 개인정보 보호, 인증, 데이터의 무결성을 보장하기 위해 개발된 방법이다.
+- (1995년에 Netscape가 처음으로 SSL을 개발하였으며, SSL 3.0 이후 업데이트가 중단되어 이를 업데이트 한 버전이 TLS이다. Netscape가 업데이트에 참여하지 않게 되어 소유권 변경을 위한 명칭 변경으로 이름만 다를 뿐 같다고 생각해도 된다.)
+
+## 작동 방식
+- 공개키 암호화 방식과 공개키의 느리다는 단점을 보완한 대칭킹 암호호 방식을 함께 사용한다. 공개키 방식으로 대칭키를 전달하고, 서로 공유된 대칭키를 가지고 통신하게 된다.
+
+### 공개키 방식
+- A와 B 키가 존재하며 둘은 서로 다르다. A로 암호화하면 B로 복호화할 수 있고, 마찬가지로 B로 암호화하면 A로 복호화 할 수 있다.
+- 둘 중 하나를 비공개키, 개인키라고 하며, 자신만 가지고 있고, 공개되지 않는다.
+- 나머지 하나를 공개키라고 하며 타인에게 제공한다. 공개키는 유출되어도 비공개키를 모르면 복호화 할 수 없기 때문에 안전한다.
+
+### 대칭키 방식
+- 동일한 키로 암호화, 복호화가 가능하다.
+- 대칭키는 매번 랜덤으로 생성되어 유출되어도 다음에 사용할 때는 다른 키가 사용되기 떄문에 안전하다.
+- 공개키보다 빠르게 통신할 수 있다.
+
+### CA
+- SSL 방식을 적용하기 위해서는 신뢰성있는 제 3자인 CA가 필요하다. CA는 인증서를 발급하는 기관으로 생각하면 된다.
+
+### 동작 과정 (서버)
+1. 서버는 공개키와 개인키를 만들고, CA에 자신의 정보와 공개키를 관리해달라는 요청을 한다.
+2. CA는 CA의 공개키와 개인키를 가지고 있고, 서버가 제출한 데이터를 검증하고, CA의 개인키로 서버가 제출한 정보들을 암호화해서 인증서를 만들어 제공한다.
+3. 서버는 인증서를 받는다.
+### 동작 과정 (클라이언트)
+4. 사용자는 CA의 공개키를 언제든 발급 받을 수 있다.
+5. 사용자는 사이트에 접속을 하면 서버는 자신의 인증서를 사용자에게 보낸다.
+6. 사용자는 CA의 공개키로 인증서를 복호화하여 서버의 정보와 서버의 공개키를 얻는다.
+7. 얻어낸 서버의 공개키로 대칭키를 암호화해서 다시 서버에게 보낸다.
+8. 서버는 개인키로 복호화를 통해 대칭키를 얻고, 해당 대칭키로 통신할 수 있도록 한다.
+
+## HTTPS의 장단점
+- HTTPS는 웹사이트의 무결성을 보호해준다. 웹사이트와 사용자 브라우저 사이의 통신을 침입자가 건드리지 못하도록 한다.
+- 동작 과정에서 속도가 느려진다. 보안이 중요한 사이트에서는 HTTPS, 그렇지 않은 사이트에서는 HTTP를 사용하기도 한다.
\ No newline at end of file
diff --git "a/2\354\243\274\354\260\250/ddingmin/README.md" "b/2\354\243\274\354\260\250/ddingmin/README.md"
new file mode 100644
index 0000000..2ac8a1b
--- /dev/null
+++ "b/2\354\243\274\354\260\250/ddingmin/README.md"
@@ -0,0 +1,29 @@
+## 2주차
+
+## 📃면접 리스트 
+### 강성민 -> 김종원
+1. OSI 7 계층 모델에 대해 설명해주세요.
+
+2. IPv4와 IPv6의 주요 차이점은 무엇인가요?
+  - IPv4와 IPv6 간의 호환성 문제는 어떻게 해결되나요?
+
+3. HTTP와 HTTPS의 차이점을 설명해주세요.
+
+4. 로드 밸런서에 대해서 설명해주세요.
+
+5. ARP에 대해 설명해주세요.
+
+6. NAT에 대해 설명해주세요
+
+7. www.google.com에 접속하였을 때 일어나는 일을 설명해주세요.
+    - mac 주소를 어떻게 알아낼 수 있을까요?
+
+## 📕TODO 리스트 
+
+### 강성민
+- [ ] HTTP와 HTTPS의 차이
+- [ ] TLS / SSL
+- [ ] DNS Server의 계층 구조
+- [ ] DHCP
+- [ ] 3way handshake의 이점은?
+- [ ] DNS의 Round Robin 방식
\ No newline at end of file
diff --git "a/2\354\243\274\354\260\250/ddingmin/TLS\354\231\200 SSL.md" "b/2\354\243\274\354\260\250/ddingmin/TLS\354\231\200 SSL.md"
new file mode 100644
index 0000000..e69de29