diff --git a/keyword/chapter00/keyword.md b/keyword/chapter00/keyword.md
new file mode 100644
index 0000000..1c7490f
--- /dev/null
+++ b/keyword/chapter00/keyword.md
@@ -0,0 +1,273 @@
+# 🎯0주차 핵심 키워드
+
+ # IP
+> ### IP와 IP 주소
+
+**IP**
+
+- IP(Internet Protocol)는 인터넷에서 데이터를 전송할 때 사용하는 규칙과 형식이다.
+- 지정한 IP 주소에 '패킷'이라는 통신 단위로 데이터를 전달한다. 
+
+**IP 주소**
+
+- 인터넷에 연결된 장치의 고유 번호를 IP 주소(IP address)이다.
+- 기기 식별: 인터넷에 연결된 모든 기기를 구별할 수 있어, IP 주소를 통해 데이터를 전송할 대상을 정확히 찾을 수 있다.
+- 데이터 전송: 데이터를 패킷 단위로 나누어 전송하는 데 사용되며, 각 패킷에는 IP 주소가 포함되어있다.
+- 라우팅: 라우터는 IP 주소를 통해 패킷을 보내야하는 곳을 판단하고 최적의 경로를 찾아 전송한다.
+---
+> ### IP 주소 버전
+
+**IPv4**
+
+- 32비트로 구성된 주소 체계이다.
+- 4개의 10진수로 구성되며 각 숫자는 0~255의 범위를 가진다.
+- 약 43억개의 주소를 제공하지만, 사용자가 증가함에 따라 주소가 부족할 것으로 판단되었다.
+
+**IPv6**
+
+- 128비트로 구성된 주소 체계이다.
+- 8개의 4자리 16진수로 구성되며 각 16진수는 콜론으로 구분된다.
+- 수조개의 주소를 제공하여 주소 부족 문제를 해결한다.
+
+---
+> ### IP 주소 작동 방식
+
+
+**고정 IP 주소** 
+ 
+- 기기에 할당된 IP 주소가 변함 없이 항상 동일한 주소를 사용하는 것이다.
+- 안정적인 통신이 필요한 경우 사용된다.  
+ex) 웹 서버, 이메일 서버 등
+
+**유동 IP 주소**
+
+- 기기에 할당된 IP 주소가 일정 시간이 지나면 변경되는 것이다.
+- 인터넷 서비스 제공자(ISP)에 의해 임시로 할당된다.
+- IP 주소의 효율적인 관리와 부족한 IPv4 주소 자원의 활용을 위해 사용된다.  
+ex) 일반 가정이나 회사의 인터넷 접속
+
+---
+
+> ### IP의 한계
+
+**비연결성**
+
+- 패킷을 받는 대상이 없거나 불능 상태여도 패킷을 전송한다.
+
+**비신뢰성**
+
+- 패킷이 중간에 손실될 수 있다.
+- 나눠 보낸 패킷의 순서가 보장되지 않는다.
+
+**프로그램 구분 불가**
+
+- 한 장치에서 여러 프로그램들이 같은 IP 주소를 사용하면, 전송받은 패킷이 어떤 프로그램에 해당하는지 알 수 없다.
+
+---
+
+# PORT
+> #### PORT
+
+**PORT**
+- TCP나 UDP에서 동일한 IP 내의 프로세스를 구분하기 위해 사용하는 번호이다. 
+- 단순히 IP만을 목적지로 잡아 접속하려 시도하면 서버는 사용자의 목적과 용도를 모르기 때문에 서비스를 제공할 수 없다.
+- 사용자는 IP와 함께 PORT를 명시함으로써 서버에 접속 목적을 전달하여 해당 서비스를 제공하는 어플리케이션으로 안내받을 수 있다.
+- 16비트로 구성되며 0~65536번까지 존재한다.
+
+**PORT 0~1023번**
+
+- 이미 어떤 통신이 해당 포트를 사용할 것인지 정해져 잇다.
+- Well-Known Ports
+
+**PORT 1024~49151번**
+
+- 특정 어플리케이션에 등록된 포트이다.
+- Registered Ports
+
+**PORT 49152~65535번**
+
+- 임시로 사용되는 포트이며 사용자가 임의로 사용가능하다.
+- Dynamic/Private Ports
+
+---
+
+# CIDR
+
+> #### IP클래스와 CIDR
+
+**IP 클래스**
+
+IP 주소를 유형에 따라 분류하는 방법으로, 네트워크 규모와 사용에 따라 A~E 클래스로 나눠진다. 
+- A 클래스 : 대규모 네트워크에 적합하며 대형 기업이나 ISP에서 사용한다.
+- B 클래스 : 중간 규모의 네트워크에 적합하며 대학이나 대기업에서 사용한다.
+- C 클래스 : 소규모 네트워크에 적합하며 소기업이나 개인 네트워크에서 사용한다.
+- D 클래스 : 멀티 캐스트 그룹 주소로 사용되며 특정 그룹에 데이터를 전송할 때 사용된다.
+- E 클래스 : 연구 및 실험적인 목적으로 예약되어 있고 일반적으로는 사용되지 않는다.
+
+**CIDR (Classless Inter-Domain Routing)**
+
+- 기존 네트워크 클래스로 나눠 정의하던 IP 정보를 Class 없이 유연하게 나눌 수 있는 라우팅 기법이다.
+
+
+>#### CIDR 숫자
+**CIDR 숫자 이해하기**
+~~~
+ex) 0.0.0.0/24 = IP주소/mask할 비트
+
+0.0.0.0 이라는 IP주소 32비트(8*4) 중, 24비트를 mask한다는 뜻이다.
+즉, 맨 앞에서부터 0.0.0까지(24비트) 가리고, 나머지 0(8비트)만 보인다는 의미로,
+8비트 부분에 해당하는 부분만 바뀐다고 보고 경우의 수를 모두 따져 범위를 정하는 것이다.
+
+=> 0.0.0.0/24라면 범위는 0.0.0.0~0.0.0.255가 된다.
+~~~
+---
+
+# TCP와 UDP의 차이
+
+> #### TCP
+
+**TCP (Transmission Control Protocol)**
+
+- 인터넷 상에서 데이터를 메세지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜이다.
+- IP는 데이터의 전송을 처리, TCP는 패킷의 추적 및 관리를 담당한다.
+
+**TCP의 특징**
+
+- 연결 지향적: 데이터를 전송하기 전에 연결을 설정한다. (3-way handshake)
+- 신뢰성: 데이터가 손실되거나 패킷의 순서가 바뀌면 재전송을 요청하여 해결한다.
+- 흐름 및 혼잡 제어: 수신자가 처리할 수 있는 속도에 맞춰 데이터를 전송하여 네트워크 혼잡을 방지한다.
+- 데이터 순서 보장: 전송된 데이터 패킷을 시퀀스 번호를 기반으로 올바르게 재조립한다.
+
+**TCP의 한계**
+- 속도: 연결, 데이터 전송, 흐름 및 혼잡 제어 등의 프로세스로 인해 속도가 상대적으로 느리다.
+- 오버헤드: 신뢰성 보장을 위해 많은 정보가 담긴 패킷을 전송하므로 오버헤드가 증가한다.
+- 복잡성: 구현이 복잡하여 설정과 관리가 상대적으로 어렵다.
+- 연결 유지: 연결을 유지하는데 필요한 자원이 소모되므로 대규모 연결을 처리할 때 부담이 증가한다.
+
+---
+
+>#### UDP
+
+**UDP(User Datagram Protocol)**
+
+- 데이터를 데이터그램(독립적인 관계를 지니는 패킷) 단위로 처리하는 프로토콜이다.
+- 빠른 데이터 전송이 필요한 상황에서 사용된다.
+
+**UDP의 특징**
+
+- 비연결 지향적: 연결을 설정하지 않고 데이터그램을 전송하여 속도가 빠르다.
+- 비신뢰성: 데이터의 순서나 도착 여부가 보장되지 않는다.
+- 단순한 구조: 헤더가 작고 오버헤드가 적어 빠른 전송이 가능하다.
+
+**UDP의 한계**
+
+- 신뢰성 부족: 데이터 손실에 대한 처리 및 순서가 보장이되지 않으므로, 애플리케이션을 통해 직접 신뢰성을 처리해야 한다.
+- 흐름 및 혼잡 제어 불가: 흐름 및 혼잡 제어를 지원하지 않으므로, 데이터 전송이 과부하를 일으킬 수 있다.
+- 데이터그램 크기 제한: 큰 데이터 전송이 필요한 경우 여러 패킷으로 나누는데, 순서가 보장이 되지 않아 추가적인 문제가 발생할 수 있다.
+
+---
+
+>#### TCP와 UDP의 차이
+
+**연결방식**
+
+- TCP: 연결형 서비스 (패킷 교환 방식, 3-way handshake)
+- UDP: 비연결형 서비스 (데이터그램 방식)
+
+**전송 순서**
+
+- TCP: 전송 순서 보장 (패킷 재조립)
+- UDP :전송 순서 보장 X
+
+**수신 여부 확인**
+- TCP: 수신 여부 확인 (데이터 손실 및 손상에 대한 재전송 요청)
+- UDP: 수신 여부 확인 X
+
+**통신 방식**
+- TCP: 1:1 방식
+- UDP: 1:1 또는 1:N 또는 N:N 방식
+
+**신뢰성**
+- TCP: 높음
+- UDP: 낮음
+
+**속도**
+- TCP: 느림
+- UDP: 빠름
+
+**흐름 및 혼잡 제어**
+- TCP: 흐름 및 혼잡 제어 기능 O
+- UDP: 흐름 및 혼잡 제어 기능 X
+
+**오버헤드**
+- TCP: 오버해드가 상대적으로 큼
+- UDP: 오버헤드가 상대적으로 작음
+
+---
+# Web Server와 WAS의 차이
+
+>#### Static Contents와 Dynamic Contents
+
+**Static Contents**
+
+- 서버에 저장된 그래도 클라이언트에게 전달되는 콘텐츠이다.
+- 사용자가 요청할 때마다 동일한 내용이 제공된다.
+- 변경이 불가능하고, 응답 속도가 빠르며, 서버 부하가 상대적으로 적다.
+- ex) HTML 파일, CSS 파일, 이미지 파일, JavaScript 파일 등 
+
+**Dynamic Contents**
+
+- 사용자의 요청이나 특정 조건에 따라 생성되는 콘텐츠이다.
+- 사용자 요청에 따라 내용이 달라질 수 있다.
+- 변경이 가능하고, 비지니스 로직이 포함되어 있으며, 서버 부하가 상대적으로 많다.
+- ex) 사용자 프로필, 게시판 글 목록, 검색 결과 등
+
+>#### Web Server
+
+**Web Server의 개념**
+
+- 하드웨어적: Web 서버가 설치되어 있는 컴퓨터이다.
+- 소프트웨어적: 웹 브라우저 클라이언트로부터 HTTP 요청을 받아 정적인 컨텐츠를 제공하는 컴퓨터 프로그램이다.
+
+**Web Server의 기능 및 특징**
+
+- HTTP 요청을 받고 정적 콘텐츠를 클라이언트에게 제공한다.
+- 동적 컨텐츠 제공을 위한 요청을 WAS에 전달하고, WAS가 처리한 결과를 클라이언트에게 전달한다.
+- 정적 파일을 직접 제공하므로 응답속도가 빠르다.
+
+**WAS (Web Application Server)의 개념**
+
+- DB 조회나 다양한 비지니스 로직 처리를 요구하는 동적 컨텐츠를 제공하기 위해 만들어진 Application Server이다.
+- Web Container, Servlet Container라고도 불린다. (Container: JSP, Servlet을 실행시킬 수 있는 소프트웨어)
+
+**WAS의 기능 및 특징**
+
+- 데이터베이스와 연동하여 동적으로 생성된 콘텐츠를 클라이언트에게 제공한다.
+- 복잡한 비지니스 로직을 처리하고 세션 관리, 트랜잭션 관리 등의 기능을 제공한다.
+- 일반적으로 웹 서버와 함께 연동되어 사용되며, 웹 서버가 정적 콘텐츠를 제공하고 WAS가 동적 콘텐츠를 관리한다.
+
+
+**WebServer와 WAS를 함께 사용하는 이유**
+
+WAS에서도 정적 콘텐츠를 처리할 수 있지만 Web Server와 함께 사용하는 이유는 다음과 같다.
+
+- 성능 최적화: 웹 서버는 정적 콘텐츠를 제공하는 것에 최적화 되어 있으므로 웹 서버를 함께 이용하면 요청을 빠르게 처리하고 WAS가 동적 컨텐츠 생성에 집중 할 수 있게 한다.
+- 리소스 효율: WAS는 동적 컨텐츠 생성 및 비지니스 로직 처리를 위해 더 많은 리소스를 소모하므로, 웹 서버를 함께 이용하면 리소스를 효율적으로 사용할 수 있다.
+- 유연성: 웹 서버와 WAS를 분리하면 각 서버를 독립적으로 조정하거나 확장할 수 있다.
+- 보안 및 관리: 웹 서버의 보안 기능을 통해 WAS를 보호할 수 있고, 웹 서버가 요청 및 응답에 대한 로그를 관리하여 문재 해결에 유용하다.
+
+---
+
+>#### Web Server와 WAS의 차이
+
+**주요 기능**
+- Web Server: 정적 콘텐츠 제공
+- WAS: 동적 콘텐츠 처리
+
+**콘텐츠 처리**
+- Web Server: 정적 콘텐츠를 직접 제공하고, 동적 콘텐츠 요청을 다른 서버로 전달한다.
+- WAS: 동적 컨텐츠를 생성하고, 필요한 데이터를 처리하여 결과를 반환한다.
+
+**성능**
+- Web Server: 정적 콘텐츠 제공이 효율적이므로, 상대적으로 요청 처리 속도가 빠르고 서버의 부하가 적다.
+- WAS: 비지니스 로직과 데이터베이스 연동으로 인해 상대적으로 요청 처리 속도가 느리고 서버의 부하가 많다.
\ No newline at end of file
diff --git a/mission/chapter00/mission.md b/mission/chapter00/mission.md
new file mode 100644
index 0000000..c86eb78
--- /dev/null
+++ b/mission/chapter00/mission.md
@@ -0,0 +1,53 @@
+# 🔥  0주차 미션
+
+
+
+## 1. 너디너리 홈페이지 접속하는 과정
+
+---
+
+**1. URL 입력**
+
+- 사용자가  웹 브라우저에 https://demoday.neordinary.co.kr/ 를 입력한다.
+
+**2. Cache에서 DNS record 확인**
+
+- DNS 조회 전 브라우저는 캐시 계층을 먼저 확인하여 이전에 방문한 IP주소가 있다면 해당 주소를 사용한다.
+- IP주소를 찾지 못하면 DNS 서버에 DNS 쿼리를 보낸다.
+
+**3. DNS 조회**
+
+- 브라우저가 입력한 도메인을 IP주소로 변환하기 위해 DNS 서버에 요청을 보낸다.
+- DNS 서버는 쿼리에 따라 원하는 IP 주소를 찾을 때까지 재귀적으로 검색한다.
+
+**4. TCP 연결 설정**
+
+- 브라우저는 반환받은 IP주소로 TCP연결을 설정하기 이해 3-way handshake 과정을 수행한다.
+- 1단계: 클라이언트가 너디너리 서버에 SYN 패킷을 보내 새 연결 요청을 보낸다.
+- 2단계: 너디너리 서버에 새 연결이 가능한 포트가 있으면 서버는 SYN 패킷의 ACK로 응답하여 SYN/ACK 패킷을 전송한다.
+- 3단계: 클라이언트가 SYN/ACK 패킷을 받고 너디너리 서버로 ACK 패킷을 전송한다.
+- 이후 TCP 연결이 설정되며, 일반적으로 포트 80(HTTP) 또는 포트 443(HTTPS)를 사용한다. (직접 접속했을 때는 443 포트가 사용되었다.)
+
+<img src="https://velog.velcdn.com/images/isb040818/post/0f2bcaea-4f50-4af5-8a4d-7cab62e3ebcf/image.png">
+
+**5. HTTP 요청 전송**
+
+- 브라우저는 HTTP 요청(GET 요청)을 전송하여 너디너리 서버에 웹 페이지를 요청한다.
+
+**6. 서버 응답**
+
+- 너디너리 서버가 요청을 수신하여 요청된 페이지를 찾는다.
+- 너디너리 서버는 해당 페이지와 필요한 리소스를 포함한 HTTP 응답을 생성하여 클라이언트에게 전송한다.
+
+**7. 웹 브라우저 응답 처리**
+
+- 브라우저는 너디너리 서버로부터 받은 HTML 파일을 렌더링하고, 리소스는 웹 서버로부터 다시 요청되어 로드된다.
+- 모든 리소스가 로드되면 브라우저는 이를 조합하여 사용자에게 최종 웹 페이지를 표시한다.
+
+---
+
+## 2. 깃허브 clone 받아서 실행하고 나온 페이지 스크린샷 찍기
+
+---
+
+<img src="https://velog.velcdn.com/images/isb040818/post/451109c2-37fd-4097-9d68-21c1073ba4d4/image.png">
\ No newline at end of file