-
Notifications
You must be signed in to change notification settings - Fork 11
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[0주차/수콩] 워크북 제출합니다.
- Loading branch information
Showing
2 changed files
with
326 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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: 비지니스 로직과 데이터베이스 연동으로 인해 상대적으로 요청 처리 속도가 느리고 서버의 부하가 많다. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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"> |