diff --git a/README.md b/README.md index 4253b8c..9af0650 100644 --- a/README.md +++ b/README.md @@ -115,7 +115,7 @@ | 3 | Ch.7 | IO 병목, 어떻게 해결하지 | 손주선 | | 4 | Ch.8 | 실무에서 꼭 필요한 보안 지식 | | | 5 | Ch.9 | 최소한 알고 있어야 할 서버 지식 | | -| 5 | Ch.10 | 모르면 답답해지는 네트워크 기초 | | +| 5 | Ch.10 | 모르면 답답해지는 네트워크 기초 | 임재인 | | 6 | Ch.11 | 자주 쓰는 서버 구조와 설계 패턴 | | --- diff --git "a/ch10-\353\204\244\355\212\270\354\233\214\355\201\254/img.png" "b/ch10-\353\204\244\355\212\270\354\233\214\355\201\254/img.png" new file mode 100644 index 0000000..3413117 Binary files /dev/null and "b/ch10-\353\204\244\355\212\270\354\233\214\355\201\254/img.png" differ diff --git "a/ch10-\353\204\244\355\212\270\354\233\214\355\201\254/network-basics.html" "b/ch10-\353\204\244\355\212\270\354\233\214\355\201\254/network-basics.html" new file mode 100644 index 0000000..0be0276 --- /dev/null +++ "b/ch10-\353\204\244\355\212\270\354\233\214\355\201\254/network-basics.html" @@ -0,0 +1,882 @@ + + + + + + 네트워크 기초 — 주니어 백엔드 개발자 필수 지식 + + + + + + +
+
+
+
+
📡 주니어 백엔드 개발자 필수 지식
+

네트워크 기초

+

노드부터 프로토콜까지
실무에서 반드시 알아야 할 핵심 개념 정리

+
+ 10장 + 8개 챕터 +
+
+
+ + +
+
+
CHAPTER 01
+

네트워크의 기본 구성요소

+
+
+
+
🖥️
+
노드 (Node)
+
데이터를 송수신하는 모든 장치. 휴대폰, 노트북, 서버 등 네트워크에 연결된 모든 기기가 노드입니다.
+
+
+
📦
+
패킷 (Packet)
+
전송 데이터의 기본 단위. 헤더(발신자·수신자 정보)와 페이로드(실제 데이터)로 구성됩니다.
+
+
+
🔀
+
라우터 (Router)
+
서로 다른 네트워크 간 패킷을 전달하는 장치. 목적지 주소에 따라 다음 라우터를 선택해 전달합니다.
+
+
+ +
+ +
+ +
+ 헤더 (IP Header) + 출발지 IP: 192.168.0.10 + 목적지 IP: 223.130.192.248 +
+ +
+
페이로드 (Payload)
+ +
+ +
+ TCP 헤더 + 출발지 포트: 54321 + 목적지 포트: 443 + 순서 번호: 1 +
+ +
+
페이로드 (HTTP)
+
GET /search?q=뭐먹지 HTTP/1.1
+
Host: www.naver.com
+
+
+
+
+
+
+
+ + +
+
+
CHAPTER 02
+

IP 주소와 도메인

+

노드끼리 통신하려면 서로를 구분할 주소가 필요합니다. 그 주소 체계가 IP이고, 사람이 기억하기 쉽게 이름을 붙인 것이 도메인입니다.

+
+
+
+
📍 IP 주소
+
    +
  • IPv4: 1바이트 × 4 블록 (예: 223.130.192.248), 각 블록 0~255
    • +
  • IPv6: 32비트 → 128비트 확장, IPv4 주소 고갈 대응
    • +
  • IPv4 아직 주류 → 사설IP + NAT 덕분에 고갈 지연
    • +
+
+
+
🌐 도메인 & DNS
+
    +
  • DNS: 도메인명 → IP 변환 (인터넷 전화번호부)
    • +
  • 계층 구조: www.naver.com = com(1) > naver(2) > www(3)
    • +
  • hosts 파일이 DNS보다 우선 적용
    • +
  • 도메인 하나 → 여러 IP → 부하 분산 가능
    • +
+
+
+
+

+ 💡 hosts 파일 위치 — Linux: /etc/hosts  |  Windows: C:\Windows\System32\drivers\etc\hosts +

+
+
+
+ + +
+
+
CHAPTER 03
+

고정 IP vs 동적 IP

+

IP 주소는 어떻게 할당될까요? 서버처럼 항상 같은 주소가 필요한 경우도 있고, 가정용 기기처럼 접속할 때마다 자동으로 받는 경우도 있습니다.

+
+
+
+
🔒 고정 IP
+
    +
  • IP 주소가 변하지 않음
    • +
  • 직접 수동 지정
    • +
  • 주 사용처: 서버
    • +
  • 외부에서 항상 같은 주소로 접근 가능
    • +
  • 관리 비용이 동적 IP 대비 높음
    • +
+
+
+
🔄 동적 IP와 DHCP
+
    +
  • 네트워크 연결 시마다 IP 자동 할당
    • +
  • 주 사용처: 가정용 공유기
    • +
  • IP 주소 효율적 재활용 가능
    • +
+
+

📋 DHCP 서버 (Dynamic Host Configuration Protocol)

+

IP 설정을 자동으로 배포하는 서버. 가정용 공유기가 이 역할을 담당합니다.

+
+
▸IP 주소
+
▸게이트웨이
+
▸서브넷 마스크
+
▸DNS 서버 주소
+
+
+
+
+
+
+ + +
+
+
CHAPTER 04
+

공인 IP vs 사설 IP

+

그런데 IP 주소라고 다 같은 게 아닙니다. 전 세계에서 접근 가능한 주소와, 특정 네트워크 안에서만 쓰는 주소가 따로 존재합니다.

+
+
+
+
🌍 공인 IP (Public IP)
+
    +
  • 인터넷에서 접속 가능한 전 세계 유일한 주소
    • +
  • 방화벽 없으면 누구나 접근 가능
    • +
  • ISP(Internet Service Provider)가 할당
    • +
  • 클라우드 서버, 웹 서버에 사용
    • +
+
+
+
🏠 사설 IP (Private IP)
+
    +
  • 특정 네트워크 내부에서만 유효
    • +
  • 외부에서 직접 접근 불가
    • +
  • 사설 IP 대역:
    • +
  • 192.168.x.x
    • +
  • 10.x.x.x
    • +
  • 172.16.x.x ~ 172.31.x.x
    • +
  • 다른 네트워크에서 같은 사설 IP → 충돌 없음
    • +
+
+
+
+
+ + +
+
+
CHAPTER 05
+

NAT — 네트워크 주소 변환

+

사설 IP는 외부 인터넷으로 직접 나갈 수 없습니다. 나가려면 공인 IP로 변환이 필요하고, 반대로 외부 요청이 내부 서버에 도달하려면 다시 사설 IP로 되돌려야 합니다.

+

사설 IP ↔ 공인 IP 간 주소를 변환하는 기술. IPv4 고갈 문제를 해결하는 핵심 메커니즘입니다.

+ + +
+ SNAT — Source NAT +

내부 → 외부: 사설 IP를 공인 IP로 변환. 공유기(라우터)가 담당.

+
+
📱 휴대폰
192.168.1.10
+
→
+
🔀 공유기
SNAT 적용
+
→
+
📡 공인 IP
218.39.xx.xxx
+
→
+
🌐 인터넷
+
+
+ + +
+ DNAT — Destination NAT +

외부 → 내부: 공인 IP를 사설 IP로 변환. 로드밸런서·방화벽이 담당.

+
+
🧑‍💻 클라이언트
58.221.x.x
+
→
+
⚖️ 로드밸런서
DNAT 적용
+
→
+
🖥️ 서버 1
10.1.1.101
+
/
+
🖥️ 서버 2
10.1.1.102
+
+
+ +
+

+ 💡 실무 예시 — musinsa.com 로 들어온 요청을 로드밸런서가 DNAT으로 여러 내부 서버에 트래픽을 분배합니다. +

+
+
+
+ + +
+
+
CHAPTER 06
+

VPN — 가상 사설 네트워크

+

사설 IP는 외부에서 직접 접근할 수 없습니다. 그럼 개발자가 집에서 회사 서버에 안전하게 접속하려면 어떻게 해야 할까요?

+
+

공용 네트워크에서 서로 다른 네트워크 간 암호화된 연결(터널)을 제공하는 기술

+ +
+

📌 VPN이 필요한 이유

+
    +
  • ▸서버 네트워크의 노드들은 사설 IP → 외부에서 직접 접근 불가
    • +
  • ▸모든 서버에 공인 IP를 매핑하면 심각한 보안 위험
    • +
  • ▸집·카페 등 외부 환경에서도 사무실 내부 네트워크처럼 안전하게 접근
    • +
+
+ +
+
🧑‍💻 개발자 PC
외부 환경
+
→
+
🔐 VPN 클라이언트
+
+ 🔒 암호화 터널 + ──────→ +
+
🏢 VPN 장비
사내 네트워크
+
→
+
🖥️ 서버 네트워크
내부 접근
+
+
+
+ + +
+
+
CHAPTER 07 — 1/2
+

TCP vs UDP

+

주소 체계를 알았다면, 이제 데이터를 실제로 어떻게 주고받을지 규칙이 필요합니다. 연결을 맺고 신뢰성을 보장할 것인지, 아니면 빠른 속도를 선택할 것인지에 따라 프로토콜이 나뉩니다.

+
+
+ + +
+
🔗 TCP Transmission Control Protocol
+
    +
  • 연결 기반 — 전송 전 3-Way Handshake 필요
    • +
  • 패킷 순서 보장, 유실 시 재전송
    • +
  • 높은 신뢰성, 상대적으로 느림
    • +
  • HOL(Head-of-Line) 블로킹 문제
    • +
  • 사용: HTTP, SMTP, FTP
    • +
+
+

3-WAY HANDSHAKE

+ + + + + + + + + + 클라이언트 + 서버 + + + + + SYN + + + SYN-ACK + + + ACK + ✓ 연결 완료 — 데이터 전송 시작 + +
+
+ + +
+
⚡ UDP User Datagram Protocol
+
    +
  • 비연결 — 연결 과정 없이 즉시 전송
    • +
  • 순서·유실 보장 없음
    • +
  • 빠른 속도, 낮은 오버헤드
    • +
  • 사용: DNS, VoIP, 게임, 스트리밍
    • +
+
+

CONNECTIONLESS

+ + + + + + + 클라이언트 + 서버 + + + + + Data 1 + + + Data 2 + + + Data 3 + 💨 유실 + + + Data 4 + ⚡ 재전송 없음 — 속도 우선 + +
+
+
+
+
+ + +
+
+
CHAPTER 07 — 2/2
+

QUIC — HTTP/3의 기반

+

TCP는 신뢰성이 있지만 느리고, UDP는 빠르지만 신뢰할 수 없습니다. 둘의 장점만 합치면? 그것이 QUIC입니다.

+
+ + +
+
+
🔗 TCP에서
+
순서 보장 · 재전송
혼잡 제어
+
+
+
+
+
⚡ UDP에서
+
빠른 전송
낮은 오버헤드
+
+
→
+
+
🚀 QUIC
+
신뢰성 + 속도
TLS 1.3 내장
+
+
+ + +
+ + +
+

🔄 연결 수립 속도 개선

+

TCP는 3-Way Handshake (1 RTT)와 TLS 1.2 Handshake (2 RTT)를 따로따로 수행. QUIC는 둘을 한 번에 처리합니다.

+
+
+
HTTP/2 (TCP 3-Way + TLS 1.2)
+
+
+
+
+
+
+ 3 RTT +
+
+
+
QUIC (연결 + 암호화 동시)
+
+
+
+
+
+
+ 1 RTT +
+
+
+
+ + +
+

🚧 HOL (Head-of-Line) 블로킹 해결

+

HTTP/2는 TCP 위에서 멀티플렉싱을 구현했지만, TCP 레벨에서는 하나의 패킷 유실이 전체 스트림을 멈춥니다. QUIC는 스트림을 완전히 독립 처리합니다.

+ +
+ +
+
HTTP/2 (TCP)
+
+
+ S1 +
✓
+
+
+ S2 +
+ 🚫 +
+
+
+ S3 +
⏳ 대기
+
+
+
+ +
+
HTTP/3 (QUIC)
+
+
+ S1 +
✓
+
+
+ S2 +
+ 🚫 +
재전송
+
+
+ S3 +
✓ 독립!
+
+
+
+
+
+
+
+
+ + +
+
+
CHAPTER 07 — 보충
+

왜 빠른 TCP가 아닌 UDP 일까?

+

QUIC = Quick TCP UDP Internet Connections — 왜 TCP가 아닌 UDP일까?

+
+ +
+
+

❌ TCP 헤더 — 너무 복잡하다

+ +
+
+

✅ UDP 헤더 — 빈 도화지

+ +
+
+ +
+ 💡 +

TCP는 오랜 역사 동안 수많은 표준이 정의되고 다양한 OS·브라우저·하드웨어에 구현되어 있습니다. 각기 다른 이해관계자들의 요구사항을 동시에 충족하기도 어렵고, 수정이 사실상 불가능합니다. 그래서 하얀 도화지 같은 UDP가 선택되었고, 그 위에 혼잡 제어·흐름 제어·오류 제어 등 신뢰성 로직을 직접 구현한 것이 QUIC입니다.

+
+
+
+ + +
+
+
+
+
THANK YOU
+

감사합니다 🙌

+
+ 노드 · 패킷 · 라우터 + IP · DNS · NAT · VPN + TCP · UDP · QUIC +
+

주니어 백엔드 개발자 스터디 — 10장 네트워크

+
+
+ + + + +