💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

1. OSI 7계층 vs TCP/IP 4계층

네트워크를 이해하려면 먼저 **계층 모델**을 파악해야 한다. 실무에서는 OSI 7계층보다 TCP/IP 4계층을 더 자주 사용한다.

OSI 7계층 구조

| 계층 | 이름 | 역할 | 프로토콜 예시 |

|------|------|------|--------------|

TCP/IP 4계층 구조

| TCP/IP 계층 | OSI 매핑 | 프로토콜 |

|------------|---------|---------|

| 응용(Application) | 5-7 | HTTP, DNS, SSH, FTP |

| 전송(Transport) | 4 | TCP, UDP |

| 인터넷(Internet) | 3 | IP, ICMP, ARP |

| 네트워크 액세스(Network Access) | 1-2 | Ethernet, Wi-Fi |

캡슐화(Encapsulation) 과정

데이터가 네트워크를 통해 전송될 때 각 계층에서 **헤더**를 추가한다.

[Application Data]

↓ 응용 계층

[TCP Header | Application Data]

↓ 전송 계층

[IP Header | TCP Header | Application Data]

↓ 인터넷 계층

[Ethernet Header | IP Header | TCP Header | Application Data | Ethernet Trailer]

↓ 네트워크 액세스 계층

실무에서는 `tcpdump`이나 Wireshark로 각 계층의 헤더를 직접 확인할 수 있다.

패킷 캡처 - 각 계층의 헤더를 확인

sudo tcpdump -i eth0 -vvv -c 10

2. TCP 3-way Handshake와 4-way Teardown

TCP는 **신뢰성 있는 연결 지향** 프로토콜이다. 연결 수립과 해제 과정을 정확히 이해하자.

3-way Handshake (연결 수립)

Client Server

| |

|--- SYN (seq=x) ------->| 1단계: 클라이언트가 SYN 전송

| |

|<-- SYN-ACK (seq=y, | 2단계: 서버가 SYN-ACK 응답

| ack=x+1) ------------|

| |

|--- ACK (ack=y+1) ----->| 3단계: 클라이언트가 ACK 전송

| |

|===== 연결 수립 완료 =====|

4-way Teardown (연결 해제)

Client Server

| |

|--- FIN ---------------->| 1단계: 클라이언트가 FIN 전송

| |

|<-- ACK ----------------| 2단계: 서버가 ACK 응답

| |

|<-- FIN ----------------| 3단계: 서버가 FIN 전송

| |

|--- ACK ----------------->| 4단계: 클라이언트가 ACK 응답

| |

|== TIME_WAIT (2*MSL) ===|

TCP 상태 전이

`ss` 명령어로 현재 TCP 상태를 확인할 수 있다.

TCP 연결 상태 확인

ss -tan

상태별 연결 수 카운트

ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn

주요 TCP 상태:

- **LISTEN**: 서버가 연결 요청을 대기

- **SYN_SENT**: 클라이언트가 SYN을 보내고 대기

- **ESTABLISHED**: 연결이 수립된 상태

- **TIME_WAIT**: 연결 해제 후 대기 (보통 60초)

- **CLOSE_WAIT**: 원격에서 FIN을 받고 대기

흐름 제어(Flow Control)

TCP는 **슬라이딩 윈도우** 방식으로 흐름을 제어한다.

현재 TCP 윈도우 크기 확인

ss -ti | grep -A 1 "ESTAB"

TCP 윈도우 스케일링 설정 확인

sysctl net.ipv4.tcp_window_scaling

혼잡 제어(Congestion Control)

리눅스에서 사용하는 주요 혼잡 제어 알고리즘:

현재 혼잡 제어 알고리즘 확인

sysctl net.ipv4.tcp_congestion_control

사용 가능한 알고리즘 목록

sysctl net.ipv4.tcp_available_congestion_control

BBR로 변경 (고대역폭, 고지연 네트워크에 효과적)

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

주요 알고리즘:

- **Cubic**: 리눅스 기본 알고리즘, 대부분 환경에서 양호

- **BBR**: 구글이 개발, 대역폭과 RTT를 기반으로 최적화

- **Reno**: 고전적 알고리즘, 패킷 손실 기반

3. HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP/1.1

HTTP/1.1은 **텍스트 기반** 프로토콜이다.

GET /api/users HTTP/1.1

Host: example.com

Connection: keep-alive

Accept: application/json

주요 특징:

- **Keep-Alive**: 연결 재사용 가능

- **파이프라이닝**: 응답을 기다리지 않고 요청 전송 (실제로는 잘 안 씀)

- **Head-of-Line Blocking**: 앞 요청이 지연되면 뒤 요청도 대기

HTTP/2

HTTP/2는 **바이너리 프레이밍 계층**을 도입했다.

단일 TCP 연결 위에서:

Stream 1: GET /index.html ─────> [HEADERS frame] [DATA frame]

Stream 3: GET /style.css ─────> [HEADERS frame] [DATA frame]

Stream 5: GET /script.js ─────> [HEADERS frame] [DATA frame]

주요 개선점:

- **멀티플렉싱**: 하나의 TCP 연결로 여러 요청/응답을 동시 처리

- **HPACK 헤더 압축**: 헤더 크기를 대폭 줄임

- **서버 푸시**: 클라이언트가 요청하기 전에 리소스를 선제적으로 전송

- **스트림 우선순위**: 중요한 리소스를 먼저 전송

curl로 HTTP/2 요청

curl -v --http2 https://example.com

nghttp2로 HTTP/2 프레임 확인

nghttp -v https://example.com

HTTP/3 (QUIC)

HTTP/3는 TCP 대신 **QUIC**(UDP 기반)를 사용한다.

HTTP/1.1: TCP + TLS (별도 핸드셰이크)

HTTP/2: TCP + TLS (멀티플렉싱, 하지만 TCP의 HOL 블로킹)

HTTP/3: QUIC (UDP 기반, 스트림별 독립적 흐름 제어)

QUIC의 장점:

- **0-RTT 연결**: 이전 연결 정보를 재사용하여 즉시 데이터 전송

- **독립적 스트림**: 한 스트림의 패킷 손실이 다른 스트림에 영향 없음

- **연결 마이그레이션**: IP 주소가 변경되어도 연결 유지 (모바일 환경에 유리)

curl로 HTTP/3 요청

curl --http3 https://example.com

QUIC 연결 확인

curl -v --http3 https://cloudflare-quic.com

성능 비교

|------|---------|--------|--------|

| 전송 프로토콜 | TCP | TCP | QUIC (UDP) |

| 멀티플렉싱 | X | O | O |

| 서버 푸시 | X | O | O |

| HOL 블로킹 | O | TCP 레벨 | X |

| 0-RTT | X | X | O |

4. DNS 동작 원리

DNS(Domain Name System)는 도메인 이름을 IP 주소로 변환하는 분산 데이터베이스 시스템이다.

DNS 질의 과정

브라우저

|-- 1. 로컬 캐시 확인

로컬 DNS 리졸버 (예: 192.168.1.1)

|-- 2. 캐시에 없으면 재귀 질의 시작

루트 DNS 서버 (.)

|-- 3. "com 네임서버는 a.gtld-servers.net입니다"

TLD DNS 서버 (.com)

|-- 4. "example.com 네임서버는 ns1.example.com입니다"

권한 DNS 서버 (example.com)

|-- 5. "example.com의 IP는 93.184.216.34입니다"

로컬 DNS 리졸버 (캐시에 저장)

브라우저 (IP 주소로 연결)

재귀 질의 vs 반복 질의

- **재귀 질의(Recursive)**: 리졸버가 최종 답을 찾을 때까지 대신 질의

- **반복 질의(Iterative)**: 각 서버가 다음 질의할 서버 주소만 알려줌

DNS 레코드 타입

| 레코드 | 용도 | 예시 |

|--------|------|------|

| A | IPv4 주소 매핑 | example.com -> 93.184.216.34 |

| AAAA | IPv6 주소 매핑 | example.com -> 2606:2800:220:1:... |

| CNAME | 도메인 별칭 | www.example.com -> example.com |

| MX | 메일 서버 | example.com -> mail.example.com (priority 10) |

| TXT | 텍스트 정보 | SPF, DKIM, 도메인 소유 증명 |

| NS | 네임서버 지정 | example.com -> ns1.example.com |

| SOA | 존 정보 | 시리얼 번호, 갱신 주기 |

| SRV | 서비스 위치 | 특정 서비스의 호스트와 포트 |

| PTR | 역방향 DNS | IP -> 도메인 이름 |

dig 명령어 활용

A 레코드 조회

dig example.com A

특정 DNS 서버로 조회

dig @8.8.8.8 example.com

MX 레코드 조회

dig example.com MX

TXT 레코드 조회 (SPF 확인)

dig example.com TXT

역방향 DNS 조회

dig -x 93.184.216.34

전체 DNS 추적 (+trace)

dig +trace example.com

짧은 출력

dig +short example.com

DNSSEC 검증

dig +dnssec example.com

DNS 캐시 관리

리눅스 systemd-resolved 캐시 확인

resolvectl statistics

DNS 캐시 플러시

sudo resolvectl flush-caches

/etc/resolv.conf 확인

cat /etc/resolv.conf

nsswitch.conf에서 DNS 해석 순서 확인

grep hosts /etc/nsswitch.conf

5. TLS/SSL 핸드셰이크

HTTPS는 HTTP에 TLS(Transport Layer Security)를 결합한 것이다.

TLS 1.3 핸드셰이크 과정

Client Server

| |

|--- ClientHello ------------------> | 지원하는 암호화 스위트, 키 공유

| (+ key_share) |

| |

|<-- ServerHello ------------------- | 선택된 암호화 스위트, 키 공유

| (+ key_share) |

|<-- EncryptedExtensions ----------- |

|<-- Certificate ------------------- | 서버 인증서

|<-- CertificateVerify ------------- | 서명 검증

|<-- Finished ---------------------- |

| |

|--- Finished ---------------------> |

| |

|==== 암호화된 통신 시작 ===========|

TLS 1.3의 주요 개선점:

- **1-RTT 핸드셰이크**: TLS 1.2의 2-RTT에서 1-RTT로 단축

- **0-RTT 재개**: 이전 연결의 PSK를 사용하여 즉시 데이터 전송

- **안전하지 않은 알고리즘 제거**: RC4, DES, MD5 등 제거

- **Perfect Forward Secrecy 필수**: ECDHE만 허용

인증서 체인

Root CA (자체 서명)

|-- Intermediate CA (Root CA가 서명)

|-- 서버 인증서 (Intermediate CA가 서명)

인증서 체인 확인

openssl s_client -connect example.com:443 -showcerts

인증서 상세 정보

openssl x509 -in cert.pem -text -noout

인증서 만료일 확인

echo | openssl s_client -connect example.com:443 2>/dev/null | \

openssl x509 -noout -dates

TLS 버전 및 암호화 스위트 확인

openssl s_client -connect example.com:443 -tls1_3

Let's Encrypt로 인증서 발급

certbot 설치 (Ubuntu)

sudo apt install certbot python3-certbot-nginx

인증서 발급 (Nginx)

sudo certbot --nginx -d example.com -d www.example.com

인증서 갱신 테스트

sudo certbot renew --dry-run

자동 갱신 타이머 확인

systemctl list-timers | grep certbot

6. 리눅스 네트워크 스택

소켓(Socket) 기초

소켓은 네트워크 통신의 종단점이다. 리눅스에서 소켓은 **파일 디스크립터**로 관리된다.

열린 소켓 확인

ss -tuln

프로세스별 소켓 확인

ss -tulnp

소켓 통계

ss -s

epoll - 고성능 I/O 멀티플렉싱

리눅스의 `epoll`은 대량의 파일 디스크립터를 효율적으로 모니터링한다.

select/poll: O(n) - 모든 fd를 순회하여 확인

epoll: O(1) - 이벤트가 발생한 fd만 반환

epoll의 동작:

1. epoll_create() - epoll 인스턴스 생성

2. epoll_ctl() - 모니터링할 fd 등록/수정/삭제

3. epoll_wait() - 이벤트 대기 (블로킹 또는 논블로킹)

Nginx, Redis, Node.js 등 고성능 서버는 모두 epoll을 기반으로 동작한다.

iptables / nftables

iptables는 리눅스 커널의 **netfilter** 프레임워크를 사용하는 패킷 필터링 도구다.

iptables 체인 구조

PREROUTING

[라우팅 결정]

/ \

INPUT FORWARD

| |

[로컬 프로세스] [다른 인터페이스]

| |

OUTPUT POSTROUTING

\ /

POSTROUTING

iptables 기본 명령어

현재 규칙 확인

sudo iptables -L -n -v

특정 포트 허용

sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

특정 IP 차단

sudo iptables -A INPUT -s 10.0.0.100 -j DROP

SSH 접속 제한 (분당 3회)

sudo iptables -A INPUT -p tcp --dport 22 -m state --state NEW \

-m recent --set --name SSH

sudo iptables -A INPUT -p tcp --dport 22 -m state --state NEW \

-m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP

NAT 설정 (마스커레이드)

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

규칙 저장

sudo iptables-save > /etc/iptables/rules.v4

nftables (iptables 후속)

nft로 현재 규칙 확인

sudo nft list ruleset

테이블 생성

sudo nft add table inet my_filter

체인 생성

sudo nft add chain inet my_filter input \

'{ type filter hook input priority 0; policy drop; }'

규칙 추가

sudo nft add rule inet my_filter input tcp dport 80 accept

sudo nft add rule inet my_filter input tcp dport 443 accept

규칙 저장

sudo nft list ruleset > /etc/nftables.conf

라우팅 테이블

라우팅 테이블 확인

ip route show

기본 게이트웨이 확인

ip route | grep default

특정 목적지에 대한 경로 확인

ip route get 8.8.8.8

정적 라우트 추가

sudo ip route add 10.10.0.0/24 via 192.168.1.1 dev eth0

라우팅 테이블에 정책 기반 라우팅

sudo ip rule add from 10.0.1.0/24 table 100

sudo ip route add default via 10.0.1.1 table 100

7. systemd 완벽 가이드

유닛 파일 구조

systemd는 **유닛 파일**로 서비스, 타이머, 마운트 등을 관리한다.

유닛 파일 위치:

- `/etc/systemd/system/` - 관리자가 생성한 유닛 (최우선)

- `/run/systemd/system/` - 런타임 유닛

- `/usr/lib/systemd/system/` - 패키지가 설치한 유닛

서비스 유닛 파일 예시

/etc/systemd/system/myapp.service

[Unit]

Description=My Application Server

After=network.target postgresql.service

Requires=postgresql.service

Documentation=https://example.com/docs

[Service]

Type=notify

User=myapp

Group=myapp

WorkingDirectory=/opt/myapp

Environment=NODE_ENV=production

EnvironmentFile=/etc/myapp/env

ExecStartPre=/opt/myapp/scripts/check-deps.sh

ExecStart=/usr/bin/node /opt/myapp/server.js

ExecReload=/bin/kill -HUP $MAINPID

Restart=on-failure

RestartSec=5

StartLimitBurst=3

StartLimitIntervalSec=60

보안 강화

NoNewPrivileges=true

ProtectSystem=strict

ProtectHome=true

ReadWritePaths=/var/lib/myapp /var/log/myapp

PrivateTmp=true

[Install]

WantedBy=multi-user.target

서비스 관리 명령어

서비스 상태 확인

systemctl status myapp.service

서비스 시작/중지/재시작

sudo systemctl start myapp.service

sudo systemctl stop myapp.service

sudo systemctl restart myapp.service

설정 변경 후 재로드 (PID 유지)

sudo systemctl reload myapp.service

부팅 시 자동 시작 설정

sudo systemctl enable myapp.service

sudo systemctl enable --now myapp.service # 즉시 시작 + 자동 시작

유닛 파일 수정 후 데몬 리로드

sudo systemctl daemon-reload

실패한 서비스 확인

systemctl --failed

서비스 의존성 확인

systemctl list-dependencies myapp.service

journalctl - 로그 관리

특정 서비스 로그 확인

journalctl -u myapp.service

실시간 로그 모니터링

journalctl -u myapp.service -f

최근 1시간 로그

journalctl -u myapp.service --since "1 hour ago"

특정 시간 범위

journalctl --since "2026-04-12 10:00:00" --until "2026-04-12 12:00:00"

에러 레벨 이상만 표시

journalctl -u myapp.service -p err

부팅별 로그

journalctl -b -1 # 이전 부팅

journalctl -b 0 # 현재 부팅

디스크 사용량 확인

journalctl --disk-usage

오래된 로그 삭제

sudo journalctl --vacuum-time=7d

sudo journalctl --vacuum-size=500M

systemd 타이머 (cron 대체)

/etc/systemd/system/backup.timer

[Unit]

Description=Daily Backup Timer

[Timer]

OnCalendar=*-*-* 02:00:00

Persistent=true

RandomizedDelaySec=300

[Install]

WantedBy=timers.target

/etc/systemd/system/backup.service

[Unit]

Description=Daily Backup

[Service]

Type=oneshot

ExecStart=/opt/scripts/backup.sh

타이머 활성화

sudo systemctl enable --now backup.timer

모든 타이머 확인

systemctl list-timers --all

타이머 다음 실행 시간 확인

systemctl status backup.timer

8. 프로세스 관리

fork/exec 모델

리눅스에서 새 프로세스는 `fork()`로 현재 프로세스를 복제한 후, `exec()`로 새 프로그램을 실행한다.

Parent Process (PID 100)

|-- fork() --> Child Process (PID 101)

|-- exec("/bin/ls") --> ls 프로그램 실행

프로세스 트리 확인

pstree -p

특정 프로세스의 상세 정보

cat /proc/PID/status

프로세스가 사용하는 파일 디스크립터

ls -la /proc/PID/fd/

좀비 프로세스와 고아 프로세스

좀비 프로세스 확인

ps aux | awk '$8 ~ /Z/'

고아 프로세스는 init(PID 1)이 자동으로 입양

좀비 프로세스는 부모가 wait()를 호출해야 제거됨

좀비 프로세스의 부모 찾기

ps -eo pid,ppid,stat,cmd | grep -w Z

좀비 프로세스 해결 방법:

1. 부모 프로세스에 SIGCHLD 시그널 전송

2. 부모 프로세스 종료 (init이 좀비를 정리)

3. 애플리케이션 코드에서 `wait()` 또는 `waitpid()` 호출

cgroups (Control Groups)

cgroups는 프로세스 그룹의 **리소스 사용량을 제한**한다.

cgroup v2 확인

mount | grep cgroup2

현재 cgroup 확인

cat /proc/self/cgroup

CPU 사용량 제한 예시

50%로 CPU 제한하는 cgroup 생성

sudo mkdir /sys/fs/cgroup/my_limited_group

echo "50000 100000" | sudo tee /sys/fs/cgroup/my_limited_group/cpu.max

메모리 제한 (512MB)

echo "536870912" | sudo tee /sys/fs/cgroup/my_limited_group/memory.max

프로세스를 cgroup에 할당

echo PID | sudo tee /sys/fs/cgroup/my_limited_group/cgroup.procs

namespaces (네임스페이스)

네임스페이스는 프로세스를 **격리된 환경**에서 실행한다. Docker 컨테이너의 핵심 기술이다.

| 네임스페이스 | 격리 대상 | 플래그 |

|------------|---------|--------|

| PID | 프로세스 ID | CLONE_NEWPID |

| Network | 네트워크 스택 | CLONE_NEWNET |

| Mount | 파일시스템 마운트 | CLONE_NEWNS |

| UTS | 호스트네임 | CLONE_NEWUTS |

| IPC | IPC 리소스 | CLONE_NEWIPC |

| User | 사용자/그룹 ID | CLONE_NEWUSER |

| Cgroup | cgroup 루트 | CLONE_NEWCGROUP |

네임스페이스 확인

lsns

새 네트워크 네임스페이스 생성

sudo ip netns add test_ns

네임스페이스 내에서 명령 실행

sudo ip netns exec test_ns ip addr

unshare로 격리된 환경 생성

sudo unshare --pid --fork --mount-proc bash

네임스페이스 목록

ip netns list

9. 리눅스 파일 시스템

VFS (Virtual File System)

VFS는 다양한 파일 시스템을 **동일한 인터페이스**로 접근하게 해주는 추상화 계층이다.

사용자 프로세스

|-- open(), read(), write() ...

VFS (Virtual File System)

├── ext4

├── XFS

├── btrfs

├── NFS

├── procfs (/proc)

└── sysfs (/sys)

inode (아이노드)

모든 파일은 **inode**로 메타데이터를 관리한다.

파일의 inode 번호 확인

ls -i file.txt

inode 상세 정보

stat file.txt

파일 시스템의 inode 사용량 확인

df -i

하드링크 vs 심볼릭링크

하드링크: 같은 inode를 공유

ln original.txt hardlink.txt

심볼릭링크: 별도 inode, 경로를 가리킴

ln -s original.txt symlink.txt

파일 시스템 비교

| 특성 | ext4 | XFS | btrfs |

|------|------|-----|-------|

| 최대 파일 크기 | 16TB | 8EB | 16EB |

| 최대 볼륨 크기 | 1EB | 8EB | 16EB |

| 스냅샷 | X | X | O (CoW) |

| 압축 | X | X | O |

| RAID 지원 | 외부 | 외부 | 내장 |

| 온라인 리사이즈 | 확장만 | 확장만 | 확장+축소 |

파일 시스템 타입 확인

df -Th

파일 시스템 상세 정보

sudo tune2fs -l /dev/sda1 # ext4

sudo xfs_info /dev/sda1 # XFS

sudo btrfs filesystem show # btrfs

/proc 파일 시스템

`/proc`는 커널과 프로세스 정보를 파일로 노출하는 가상 파일 시스템이다.

CPU 정보

cat /proc/cpuinfo

메모리 정보

cat /proc/meminfo

로드 평균

cat /proc/loadavg

커널 버전

cat /proc/version

네트워크 연결 정보

cat /proc/net/tcp

특정 프로세스 정보

cat /proc/PID/status # 프로세스 상태

cat /proc/PID/maps # 메모리 맵

cat /proc/PID/cmdline # 실행 명령

/sys 파일 시스템

`/sys`는 커널의 장치 모델 정보를 노출한다.

블록 장치 정보

ls /sys/block/

네트워크 인터페이스 정보

ls /sys/class/net/

CPU 주파수 정보

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

디스크 스케줄러 확인

cat /sys/block/sda/queue/scheduler

10. 트러블슈팅 도구 모음

ss (Socket Statistics)

`ss`는 `netstat`의 현대적 대체 도구다.

모든 TCP 연결 (수신 대기 포함)

ss -tuln

ESTABLISHED 상태인 연결만

ss -t state established

특정 포트로의 연결 수 확인

ss -tn dport = :443 | wc -l

프로세스 정보 포함

ss -tulnp

소켓 메모리 사용량

ss -tm

TIME_WAIT 상태 연결 확인

ss -t state time-wait

tcpdump

특정 인터페이스에서 패킷 캡처

sudo tcpdump -i eth0

특정 호스트와의 통신만 캡처

sudo tcpdump -i eth0 host 10.0.0.1

특정 포트 캡처

sudo tcpdump -i eth0 port 80

DNS 쿼리 캡처

sudo tcpdump -i eth0 port 53

패킷을 파일로 저장

sudo tcpdump -i eth0 -w capture.pcap

저장된 파일 읽기

tcpdump -r capture.pcap

HTTP 요청/응답 내용 보기

sudo tcpdump -i eth0 -A port 80

SYN 패킷만 캡처 (새 연결 모니터링)

sudo tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0'

strace

시스템 콜 추적

strace -p PID

특정 시스템 콜만 추적

strace -e trace=network -p PID

파일 관련 시스템 콜

strace -e trace=file ls

시간 정보 포함

strace -T -p PID

자식 프로세스도 추적

strace -f -p PID

출력을 파일로 저장

strace -o output.txt -p PID

lsof (List Open Files)

특정 포트를 사용하는 프로세스 확인

sudo lsof -i :80

특정 프로세스가 열고 있는 파일

lsof -p PID

특정 파일을 사용하는 프로세스

lsof /var/log/syslog

삭제되었지만 열려있는 파일 (디스크 공간 회수 안 됨)

lsof +L1

네트워크 연결 확인

lsof -i -P -n

특정 사용자의 열린 파일

lsof -u username

perf (Performance Counters)

CPU 프로파일링 (10초)

sudo perf record -g -p PID -- sleep 10

결과 확인

sudo perf report

실시간 상위 함수 확인

sudo perf top -p PID

시스템 전체 통계

sudo perf stat -a -- sleep 5

플레임 그래프 생성

sudo perf record -g -p PID -- sleep 30

sudo perf script > out.perf

FlameGraph 도구로 변환

./stackcollapse-perf.pl out.perf > out.folded

./flamegraph.pl out.folded > flamegraph.svg

종합 트러블슈팅 체크리스트

네트워크 문제가 발생했을 때 순서대로 확인하는 체크리스트:

1. 인터페이스 상태 확인

ip addr show

ip link show

2. 라우팅 확인

ip route show

traceroute TARGET_HOST

3. DNS 확인

dig TARGET_DOMAIN

nslookup TARGET_DOMAIN

4. 연결 확인

ping TARGET_HOST

curl -v http://TARGET_HOST

5. 포트 확인

ss -tuln

sudo lsof -i :PORT

6. 방화벽 확인

sudo iptables -L -n

sudo nft list ruleset

7. 패킷 캡처

sudo tcpdump -i eth0 host TARGET_HOST

8. 시스템 리소스 확인

top

free -h

df -h

9. 로그 확인

journalctl -xe

dmesg | tail

마무리

이 글에서 다룬 내용을 요약하면:

- **네트워크 기초**: OSI/TCP/IP 계층 모델, TCP 핸드셰이크, 흐름/혼잡 제어

- **웹 프로토콜**: HTTP/1.1에서 HTTP/3까지의 발전, TLS 핸드셰이크

- **DNS**: 질의 과정, 레코드 타입, dig 활용

- **리눅스 네트워크**: 소켓, epoll, iptables/nftables, 라우팅

- **systemd**: 유닛 파일, 서비스 관리, journalctl, 타이머

- **프로세스**: fork/exec, 좀비/고아, cgroups, namespaces

- **파일 시스템**: VFS, inode, ext4/XFS/btrfs, /proc, /sys

- **트러블슈팅**: ss, tcpdump, strace, lsof, perf

이 지식은 서버 운영, 인프라 관리, DevOps 업무에서 매일 사용된다. 문제가 발생했을 때 **어떤 계층에서 문제가 생겼는지 빠르게 파악**하는 것이 핵심이다. 각 도구를 실제 환경에서 직접 실행해보면서 익히는 것을 권장한다.

목차

1. OSI 7계층 vs TCP/IP 4계층

OSI 7계층 구조

TCP/IP 4계층 구조

캡슐화(Encapsulation) 과정

패킷 캡처 - 각 계층의 헤더를 확인

2. TCP 3-way Handshake와 4-way Teardown

3-way Handshake (연결 수립)

4-way Teardown (연결 해제)

TCP 상태 전이

TCP 연결 상태 확인

상태별 연결 수 카운트

흐름 제어(Flow Control)

현재 TCP 윈도우 크기 확인

TCP 윈도우 스케일링 설정 확인

혼잡 제어(Congestion Control)

현재 혼잡 제어 알고리즘 확인

사용 가능한 알고리즘 목록

BBR로 변경 (고대역폭, 고지연 네트워크에 효과적)

3. HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP/1.1

HTTP/2

curl로 HTTP/2 요청

nghttp2로 HTTP/2 프레임 확인

HTTP/3 (QUIC)

curl로 HTTP/3 요청

QUIC 연결 확인

성능 비교

4. DNS 동작 원리

DNS 질의 과정

재귀 질의 vs 반복 질의

DNS 레코드 타입

dig 명령어 활용

A 레코드 조회

특정 DNS 서버로 조회

MX 레코드 조회

TXT 레코드 조회 (SPF 확인)

역방향 DNS 조회

전체 DNS 추적 (+trace)

짧은 출력

DNSSEC 검증

DNS 캐시 관리

리눅스 systemd-resolved 캐시 확인

DNS 캐시 플러시

/etc/resolv.conf 확인

nsswitch.conf에서 DNS 해석 순서 확인

5. TLS/SSL 핸드셰이크

TLS 1.3 핸드셰이크 과정

인증서 체인

인증서 체인 확인

인증서 상세 정보

인증서 만료일 확인

TLS 버전 및 암호화 스위트 확인

Let's Encrypt로 인증서 발급

certbot 설치 (Ubuntu)

인증서 발급 (Nginx)

인증서 갱신 테스트

자동 갱신 타이머 확인

6. 리눅스 네트워크 스택

소켓(Socket) 기초

열린 소켓 확인

프로세스별 소켓 확인

소켓 통계

epoll - 고성능 I/O 멀티플렉싱

iptables / nftables

iptables 체인 구조

iptables 기본 명령어

현재 규칙 확인

특정 포트 허용

특정 IP 차단

SSH 접속 제한 (분당 3회)

NAT 설정 (마스커레이드)

규칙 저장

nftables (iptables 후속)

nft로 현재 규칙 확인

테이블 생성

체인 생성

규칙 추가

규칙 저장

라우팅 테이블