네트워크 기본 정리

네트워크 기본 정리 ko posts network devops IP, 서브넷, DNS, TCP/UDP, HTTP, 포트, 방화벽, 프록시, 로드밸런서를 정리합니다.

개요

서버를 운영하면 네트워크 문제를 피할 수 없습니다. 서비스가 응답하지 않을 때 프로세스는 살아있는데 접속이 안 되면, 네트워크를 확인해야 합니다.

이 글은 DevOps 관점에서 자주 다시 보게 되는 네트워크 기본 개념을 정리합니다.

1. IP 주소와 서브넷

정리 보기

IP 주소란

IP (Internet Protocol) 주소는 네트워크에서 장치를 식별하는 고유 번호입니다.

IPv4: 192.168.1.100 (32비트, 약 43억 개)
IPv6: 2001:0db8:85a3::8a2e:0370:7334 (128비트)

운영 환경에서는 아직 대부분 IPv4를 사용합니다.

공인 IP vs 사설 IP

공인 IP: 인터넷에서 직접 접근 가능 (ex: 54.180.12.34)
사설 IP: 내부 네트워크에서만 사용 (외부 접근 불가)

사설 IP 대역:

10.0.0.0 ~ 10.255.255.255     (10.0.0.0/8)
172.16.0.0 ~ 172.31.255.255   (172.16.0.0/12)
192.168.0.0 ~ 192.168.255.255 (192.168.0.0/16)

AWS VPC, 사내망 등은 사설 IP를 사용하고, 외부 통신은 NAT Gateway나 공인 IP를 통합니다.

서브넷과 CIDR

서브넷은 큰 네트워크를 작은 단위로 나눈 것입니다. CIDR (Classless Inter-Domain Routing) 표기법으로 범위를 표현합니다.

192.168.1.0/24
         └── 24비트가 네트워크 주소, 나머지 8비트가 호스트 주소
         → 호스트 수: 2^8 - 2 = 254개

자주 쓰는 CIDR:

CIDR	호스트 수	용도
/32	1개	특정 IP 하나 지정
/28	14개	소규모 서브넷
/24	254개	일반적인 서브넷
/16	65,534개	대규모 VPC

예시

VPC: 10.0.0.0/16 (전체 네트워크)
  ├── Public Subnet: 10.0.1.0/24 (웹 서버, 로드밸런서)
  ├── Private Subnet: 10.0.2.0/24 (앱 서버)
  └── DB Subnet: 10.0.3.0/24 (데이터베이스)

2. TCP vs UDP

정리 보기

TCP (Transmission Control Protocol)

연결 지향: 데이터 전송 전에 연결을 먼저 맺음 (3-way handshake)
신뢰성 보장: 패킷 순서 보장, 유실 시 재전송
느리지만 정확함

3-way handshake:
1. 클라이언트 → 서버: SYN
2. 서버 → 클라이언트: SYN + ACK
3. 클라이언트 → 서버: ACK
→ 연결 성립

UDP (User Datagram Protocol)

비연결: 연결 없이 바로 전송
신뢰성 없음: 순서 보장 안 됨, 유실돼도 재전송 안 함
빠름

비교

항목	TCP	UDP
연결	있음 (3-way handshake)	없음
신뢰성	순서 보장, 재전송	없음
속도	상대적으로 느림	빠름
용도	HTTP, SSH, DB 연결	DNS 조회, 스트리밍, 게임

참고

웹 서비스, API, DB: TCP
DNS 쿼리: UDP (53번 포트)
모니터링 메트릭 전송 (StatsD): UDP
실시간 영상/음성: UDP

TCP와 UDP의 차이를 구분하고, 3-way handshake까지 설명할 수 있으면 충분합니다.

3. DNS 동작 원리

정리 보기

DNS란

DNS (Domain Name System)는 도메인 이름을 IP 주소로 변환하는 시스템입니다.

sckwon.dev → 104.21.32.5 (예시)

DNS 조회 흐름

1. 브라우저 캐시 확인
2. OS 캐시 확인 (/etc/hosts)
3. DNS Resolver (ISP 또는 8.8.8.8)에 질의
4. Root DNS → TLD DNS (.dev) → 권한 DNS 서버 순으로 찾아감
5. IP 주소 반환 → 캐시에 저장 (TTL 동안)

레코드 종류

레코드	용도	예시
A	도메인 → IPv4	`sckwon.dev → 104.21.32.5`
AAAA	도메인 → IPv6	`sckwon.dev → 2606:4700::6812`
CNAME	도메인 → 다른 도메인	`www.sckwon.dev → sckwon.dev`
MX	메일 서버 지정	`sckwon.dev → mail.google.com`
TXT	텍스트 정보 (인증 등)	SPF, DKIM 레코드
NS	네임서버 지정	`sckwon.dev → ns1.cloudflare.com`

확인 명령어

# A 레코드 조회
dig sckwon.dev A +short
nslookup sckwon.dev

# 특정 DNS 서버로 조회
dig @8.8.8.8 sckwon.dev

# 모든 레코드 조회
dig sckwon.dev ANY

# TTL 확인
dig sckwon.dev A
# ANSWER SECTION에 남은 TTL 초 단위로 표시

자주 겪는 문제

증상	원인	해결
도메인 접속 안 됨	DNS 전파 안 됨	TTL 대기 (보통 5분~48시간)
간헐적 접속 실패	DNS 캐시 불일치	`dig`로 여러 DNS 서버에서 확인
서브도메인 안 됨	CNAME/A 레코드 누락	DNS 설정에 레코드 추가

4. HTTP 기본

정리 보기

HTTP 요청 구조

GET /posts/linux-os-basics HTTP/1.1
Host: sckwon.dev
User-Agent: Mozilla/5.0
Accept: text/html

메서드: GET, POST, PUT, PATCH, DELETE
경로: /posts/linux-os-basics
헤더: 메타 정보 (인증, 콘텐츠 타입 등)
바디: POST/PUT 요청 시 데이터

HTTP 응답 구조

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 5432

<html>...</html>

상태 코드

범위	의미	자주 보는 것
2xx	성공	200 OK, 201 Created, 204 No Content
3xx	리다이렉트	301 Moved Permanently, 302 Found, 304 Not Modified
4xx	클라이언트 에러	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xx	서버 에러	500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

자주 보는 상태 코드

502 Bad Gateway: 로드밸런서 뒤의 서버가 응답하지 않음
503 Service Unavailable: 서버 과부하 또는 점검 중
504 Gateway Timeout: 백엔드 서버 응답 시간 초과

HTTPS

HTTP + TLS (암호화) = HTTPS
포트: HTTP 80, HTTPS 443
.dev 도메인은 HTTPS가 강제됨 (HSTS preload)
SSL/TLS 인증서는 Let’s Encrypt (무료) 또는 Cloudflare에서 자동 발급

curl로 확인

# 기본 GET 요청
curl -v https://sckwon.dev

# 상태 코드만
curl -o /dev/null -s -w "%{http_code}" https://sckwon.dev

# POST 요청
curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' https://api.example.com

# 응답 헤더 확인
curl -I https://sckwon.dev

5. 포트와 Well-Known 포트

정리 보기

포트란

포트는 하나의 IP에서 여러 서비스를 구분하기 위한 번호입니다. IP가 아파트 주소면, 포트는 호수입니다.

sckwon.dev:443
         └── 포트 번호

포트 범위

0 ~ 1023:    Well-Known 포트 (시스템 서비스, root 권한 필요)
1024 ~ 49151: Registered 포트 (일반 앱)
49152 ~ 65535: Dynamic/Private 포트 (임시 연결용)

자주 쓰는 포트

포트	서비스	프로토콜
22	SSH	TCP
53	DNS	UDP/TCP
80	HTTP	TCP
443	HTTPS	TCP
3000	Node.js 개발 서버	TCP
3306	MySQL	TCP
5432	PostgreSQL	TCP
6379	Redis	TCP
8080	앱 서버 (대체 HTTP)	TCP
9090	Prometheus	TCP

확인 명령어

# 현재 리슨 중인 포트 (t: TCP, l: LISTEN, n: 숫자, p: 프로세스)
ss -tlnp

# 특정 포트 사용 프로세스
lsof -i :8080

# 외부에서 포트 열려있는지 확인
nc -zv server-ip 443

6. 방화벽과 보안그룹

정리 보기

방화벽이란

방화벽은 네트워크 트래픽을 규칙에 따라 허용하거나 차단하는 장치/소프트웨어입니다.

Linux 방화벽 (iptables / nftables)

# 현재 규칙 확인
iptables -L -n

# 특정 포트 허용
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# 특정 IP에서만 SSH 허용
iptables -A INPUT -p tcp -s 10.0.1.0/24 --dport 22 -j ACCEPT

# 나머지 차단
iptables -A INPUT -j DROP

클라우드 보안그룹 (AWS Security Group)

보안그룹은 인스턴스 단위의 가상 방화벽입니다.

인바운드 규칙:
  HTTP  (80)  → 0.0.0.0/0 (모든 곳에서 허용)
  HTTPS (443) → 0.0.0.0/0
  SSH   (22)  → 10.0.0.0/16 (내부망에서만)

아웃바운드 규칙:
  All traffic → 0.0.0.0/0 (모든 곳으로 허용)

NACL vs Security Group (AWS)

항목	Security Group	NACL
적용 단위	인스턴스	서브넷
상태	Stateful (응답 자동 허용)	Stateless (인/아웃 별도 설정)
규칙	허용만 가능	허용 + 차단 가능
평가	모든 규칙 평가	번호 순서대로 평가

참고

서비스 포트 안 열리면: Security Group 인바운드 확인
특정 IP만 차단하고 싶으면: NACL 사용
서버 간 통신 안 되면: 양쪽 Security Group + 라우팅 테이블 확인

7. 프록시와 로드밸런서

정리 보기

프록시란

클라이언트와 서버 사이에 중간 서버를 두는 것입니다.

Forward Proxy: 클라이언트 → [프록시] → 서버
  - 클라이언트 IP를 숨김
  - 사내 인터넷 접근 제어에 사용

Reverse Proxy: 클라이언트 → [프록시] → 서버(들)
  - 서버 IP를 숨김
  - SSL 종단, 캐싱, 라우팅에 사용
  - nginx, HAProxy, Cloudflare

로드밸런서란

트래픽을 여러 서버에 분산하는 장치/서비스입니다.

클라이언트 → [로드밸런서] → 서버1
                          → 서버2
                          → 서버3

로드밸런서 종류 (AWS)

종류	동작 계층	용도
ALB (Application Load Balancer)	L7 (HTTP)	웹 앱, 경로/호스트 기반 라우팅
NLB (Network Load Balancer)	L4 (TCP/UDP)	고성능, 낮은 지연시간
CLB (Classic)	L4/L7	구세대, 사용 지양

분산 알고리즘

알고리즘	설명
Round Robin	순서대로 분배
Least Connection	연결 수 적은 서버로
IP Hash	같은 IP는 같은 서버로

헬스체크

로드밸런서가 서버 상태를 주기적으로 확인합니다.

GET /health → 200 OK: 정상
GET /health → 5xx 또는 타임아웃: 비정상 → 트래픽 제외

/health 엔드포인트를 만들어두는 것이 기본입니다.

8. 네트워크 디버깅 실전

정리 보기

장애 상황별 확인 순서

"서비스 접속이 안 됩니다"

1. 서버에서 프로세스 살아있나?     → ps, systemctl status
2. 포트 리슨하고 있나?            → ss -tlnp
3. 로컬에서 접속 되나?            → curl localhost:8080
4. 같은 네트워크에서 되나?         → curl 10.0.1.50:8080
5. 외부에서 되나?                 → curl public-ip:8080
6. 안 되면 방화벽/보안그룹 확인    → iptables -L, AWS SG
7. DNS 문제인가?                  → dig, nslookup
8. 경로 문제인가?                 → traceroute, mtr

자주 쓰는 명령어 모음

# 연결 테스트
ping -c 4 google.com              # ICMP 연결 확인
nc -zv server 443                 # TCP 포트 연결 확인
curl -v https://sckwon.dev        # HTTP 전체 흐름 확인

# DNS 확인
dig sckwon.dev A +short           # A 레코드 조회
dig @8.8.8.8 sckwon.dev           # 특정 DNS 서버로 조회
nslookup sckwon.dev               # 간단 조회

# 경로 추적
traceroute sckwon.dev             # 어디서 막히는지
mtr sckwon.dev                    # 실시간 경로 추적

# 패킷 캡처 (고급)
# -i: 인터페이스, port: 필터, -c: 패킷 수 제한
tcpdump -i eth0 port 80 -c 50

# 열린 연결 상태
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn

참고

접속 안 되면 안쪽에서 바깥으로 확인 (프로세스 → 포트 → 로컬 → 네트워크 → 외부)
curl -v는 가장 많이 쓰는 디버깅 도구 (SSL, 리다이렉트, 헤더 모두 확인 가능)
tcpdump는 최후의 수단 — 패킷 레벨에서 뭐가 오가는지 확인
AWS에서 Security Group + NACL + 라우팅 테이블 세 가지를 동시에 확인해야 할 때가 많음

정리

네트워크는 서버 운영의 두 번째 축입니다. Linux 기본을 알고 있으면 프로세스 문제는 잡을 수 있지만, 네트워크를 모르면 “서버는 살아있는데 접속이 안 되는” 상황에서 막힙니다.

IP, DNS, TCP, HTTP, 포트, 방화벽 — 이 흐름을 이해하고 있으면 대부분의 네트워크 장애를 더 빠르게 좁혀갈 수 있습니다.