---

▪️ 네트워크 ▪️

---

💡 컴퓨터들은 어떻게 서로 통신할까?
초기에는 물리적인 형태(usb)였다. 통신할 컴퓨터가 멀리있다면? 인터넷 사용!

✔️ 인터넷 (Internet)

• TCP / IP 기반으로 연결된 컴퓨터 네트워크 통신망
• 해저 광케이블(물리적 연결) / 인공위성 (무선 통신)
  ➝ World Wide Web(www)구축

---

📖 IP (Internet Protocol)

💡 데이터 통신에 대한 규약 - 숫자는 IP 자체가 아닌 주소임
(데이터를 안전하게 전달하기위해 최소한의 인터넷 프로토콜이 필요하다)

📌 Packet

• 소스IP출발지 + 대상IP도착지를 포함 ➝ 어떤 컴퓨터에 전송할 지 판별 가능
• 구분 : 헤더 ,페이로드, 트레일러(수신여부 포함)
• 단지 데이터를 주기만 하는게 아니라 받고 응답한다

📌 IP 방식의 문제점

• ❶ 애플리케이션 구분 (어떤 프로그램에 사용하지? 구분이 어렵다)

• ❷ 비연결성 (수신 대상의 상태에 상관없이 데이터를 전송 - 컴퓨터가 꺼져 있어도)

• ❸ 비신뢰성
  - 패킷이 소실되는 경우, 손상여부를 양측 모두 알 수 없다.
  - 데이터가 큰 경우에는 여러개로 나눠 전송되고, 순서가 섞여버림
  ➝ 이런 경우에도 데이터를 재전송 하지 않는다

---

📖 TCP (Transmission Control Protocol)

💡 데이터를 신뢰성있게 전달 (IP방식의 문제점 보완)

📌 3 Way HandShake

📍 최소한의 논리적 연결로 연결되었다고 가정하는것 !

✔️ SYN , ACK

SYN (Synchronize)	ACK (Acknowledge)
클라이언트 ➝ 서버	서버 ➝ 클라이언트
접속 요청	요청 수락
SYN 플래그 + 시퀀스 번호	SYN 플래그 + ACK 플래그 + (시퀀스 번호+1)
	데이터 전송 가능

✔️ 특징

• IP 방식의 단점 보완 (데이터가 잘 전송되었는지 응답 반환)
• 패킷이 나뉘어져 오더라도 순서를 보장한다 ➝ 느리다

---

📖 UDP (User Datagram Protocol)

💡 비연결형이고 신뢰성이 없는 프로토콜 ➝ 증말로 빠르당 ( 실시간성 보장 )
( 인터넷 전화, 스트리밍, 온라인 게임 등 )

📌 UDP의 특징

1. IP 방식과 비슷하다 - 3 way handshake 하지 않는다 (비신뢰성)
2. 추가적인 기능이 거의 없다 - 하지만 빨랐죠?
3. PORT가 존재한다
4. 잘못된 데이터가 전송되지 않도록 체크섬(Checksum)을 포함

📌 PORT

• 같은 IP 내에서 프로세스 구분을 함
  ➝ IP의 단점 (애플리케이션 구분)을 보완

• Packet에 포함되어 있다

  ✔️ 자주 사용되는 PORT

  1. 0~65535 까지 할당 가능
  2. 0~1023 : 이미 사용되고 있는 포트 애지간하면 쓰지말자
     💡 HTTP 80 (TCP) / HTTPS 443 (TCP)

---

▪️ Web 기초 ▪️

---

📖 DNS(Domain Name System)

IP주소는 유동적이기도 하고, 변경될 수도 있고, 외우기가 힘들다
💡 사람이 읽을 수 있는 도메인 주소를 컴퓨터가 읽을 수 있는 IP 주소로 변환한다

📌 DNS 동작 순서

1. 원하는 도메인 구매후 DNS 서버에 등록한다
2. 도메인 명을 입력하면 DNS는 IP주소를 반환한다
3. IP가 변경되면 DNS는 그대로, dns에 등록된 IP주소만 바꾸면 댐
   ➝ 대표적인 예시 : URL

---

📖 URI (Uniform Resource Identifier)

💡 인터넷 자원(데이터)을 나타내는 고유식별자

• 자원 : 페이지, 텍스트, 이미지, 동영상, 파일 등
  ➝ URI는 URL, URN을 포함하는 개념

📌 URL(Uniform Resource Locator)

💡 자원의 위치를 나타낸다

✔️ URL의 구조

💡 예시
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
https://www.google.com:443/search?q=스파르타+코딩클럽

scheme	user[:password]	host[:port]	[/path]	[?query]	[#fragment]
프로토콜	사용자 정보	도메인 or IP주소	리소스의 경로	key=value	html 내부 북마크
주로 http, https, ftp 사용	URL은 사용 X	일반적으로 생략	계층 구조	?로 시작되고 &로 구분	특정위치로 이동

💡 URL, URN 비교 (예시 참고)

URL(Locator)	URN(Name)
자원의 위치	자원의 이름
프로토콜 O	프로토콜 X
위치 변경시 사용불가	위치 변경시에도 사용 가능
	(이름으로 검색하기 때문에)
대중화 O	대중화 X

---

▪️ 용어 모음집 ▪️

---

📖 프로그램 명명 규칙 (casing)

1️⃣ snake_case

• 데이터 베이스에서 주로 사용
  - 사용법 : 소문자 or 대문자
  - 단어연결 : 언더바 _ 사용

2️⃣ camelCase

• Java, JavaScript, TypeScript에서 변수, 함수, 메서드 이름
  - 사용법 : 첫 글자 소문자
  - 단어연결 : 연결시에만 대문자

3️⃣ PascalCase

• 클래스 이름
  - 사용법 : 첫 글자 대문자
  - 단어연결 : 대문자로 연결

4️⃣ kebab-case

• 거의 사용 안함
  - 사용법 : 모든 단어 소문자
  - 단어연결 : 대시 - 로 연결

---

📖 JSON

💡 클라이언트, 서버가 통신할 때 사용하는 데이터 양식

• 통일된 양식 : 언어와 관계없이 데이터를 주고 받을 수 있다
• 이해가 쉽고 용량이 작다 ➝ XML 대체
• 클라이언트 to 서버 서버 to 클라이언트 서버 to 서버 모두 사용
• 예시 - MSA(MicroService Architecture)
  : JSON 형태로 데이터 통신을 하기 때문에 애플리케이션 별 언어가 달라도 서로 통신가능

📌 JSON의 구조

{
  "user": [
    {
      "first_name": "wonuk",
      "last_name": "Hwang",
      "age": 100,
      "phone_agree": false,
      "hobby": ["Java", "Spring"]
    },
    {
      "firstName": "sparta",
      "lastName": "Team",
      "age": 200,
      "phone_agree": true,
      "hobby": ["React", "Spring", "Node"]
    },
  ]
}

• snake_case, camelCase 모두 사용 가능
• key - value 형태

---

📖 서버 성능향상

💡 서버의 성능향상을 위한 두가지 방법

📌 Scale Up (수직적 확장)

• 단일 서버의 하드웨어의 사용을 높인다 ➝ 비용 증가
  (cpu나 메모리의 스펙을 올린다)

• 요청에 대한 처리가 빨라진다

  ---

📌 Scale Out (수평적 확장)

• 같은 사양의 서버를 여러대 배치한다 ➝ 비용 증가 크지 않음
• 동시에 더 많은 사용자 요청을 처리할 수 있다

---

📖 통신상태 유지 여부

💡 클라이언트와 서버간의 통신상태 유지 여부에 따라 나뉘는 특성
*예시 - 수강생 (클라이언트) / 상담원 (서버)

📌 Stateful(상태 유지)

• 수강생 1명 : 상담원 1명 ➝ 클라이언트의 요청을 기억(상태 유지)한다

✔️ 문제점

• ① 같은 서버가 유지되어야 한다 (같은 상담원에게 요청해야~)

• ② 서버는 다양한 이유로 동작하지 않을 수 있음

• ③ 요청 트래픽이 많아지면 상태를 유지하는데에 리소스가 소모된다

  ---

📌 Stateless (무상태)

- 수강생 1명 : 여러명의 상담원 ➝ **요청 기억 불가!** - **수강생이 이전 요청을 함께 전달한다 ➡︎ 상담원이 기억할 필요가 없음**

✔️ 장점

• 모든 요청을 하나의 서버에 보낼 필요가 없음 ➝ 수평적 확장 Scale Out

✔️ 단점

• 클라이언트가 데이터를 추가로 전송해야한다 ➝ 데이터양 증가 (비용이 증가될 수도)

✔️ 🌟 한계점

• 원칙
  : 항상 서버의 확장성을 고려해 최대한 Stateless하게 만들어야 한다
• 한계
  : but 전부 다 Stateless하게 만들 수는 없다 (상태유지가 필요한 로그인)
• 한계 극복
  : Cookie, Session, Token등으로 극복하며 상태유지는 최소화 하면 된다

---

📖 연결 유지 여부

💡 클라이언트-서버간 연결 유지 여부에 따른 특성

📌 Connection (연결)

• 클라이언트 수만큼 연결횟수가 늘어남 ➝ 자원 소모된다
• 클라이언트가 아무 요청이 없어도 연결은 유지한다
  (수많은 사람들이 서비스를 이용해도 실제 서버에서 동시에 요청이 들어올 경우는 적다!)

✔️ 장점

• 새로운 연결을 안해도 된다, 그만큼 응답속도가 빨라진다

✔️ 단점

• 클라이언트가 지속적으로 요청을 보낸단 보장이 없는데도 해야함,, 자원 낭비!

  ---

📌 Connectionless (비연결)

• TCP/IP 연결 ➝ 요청-응답 ➝ 연결 해제
  🌟 서버는 최소한의 자원만 사용하게 된다
  ( 예를들어,, 인터넷이 끊겨도 보던 페이지는 그대로 보인다!)

✔️ 장점

• 당연! 자원 효율적 사용된다

✔️ 단점

• 요청이 추가될 때마다 연결(3 Way Handshake)을 새로 해야한다 ➝ 응답시간 증가
• 연결할 때마다 웹페이지의 정적자원을 전부! 다시 다운로드해야한다
  ➝캐시, 브라우저 캐싱으로 해결 (쉽게말해 임시저장)
  🌟해결방법 : 현재는 HTTP 지속연결(Persistent Connections)로 문제를 해결한다.

💡 HTTP 지속연결(Persistent Connections)

• 모든 요청을 전부 응답한 후에 연결을 해제한다
• 연결 횟수는 Connectionless보다 적고, 속도는 더 빠르다!