네트워크 패킷 분석 & 트러블슈팅 (Q19-Q23)

패킷 분석 & 트러블슈팅 (19~25번)

Q19. Ethernet Frame, IP Packet, TCP Segment의 헤더 구조를 설명하고 실제 패킷 분석 방법은?

계층별 캡슐화 구조:

┌─────────────────────────────────────────────────────────┐
│ Ethernet Frame (Layer 2)                                │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ IP Packet (Layer 3)                                 │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ TCP Segment (Layer 4)                           │ │ │
│ │ │ ┌─────────────────────────────────────────────┐ │ │ │
│ │ │ │ Application Data (Layer 7)                  │ │ │ │
│ │ │ └─────────────────────────────────────────────┘ │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘

Ethernet Frame 구조 (총 최소 64 bytes ~ 최대 1518 bytes):

┌──────────┬─────┬──────────┬──────────┬──────┬─────────┬─────┐
│ Preamble │ SFD │ Dst MAC  │ Src MAC  │ Type │ Payload │ FCS │
│ 7 bytes  │1 byte│ 6 bytes │ 6 bytes  │2 bytes│46-1500 │4 bytes│
└──────────┴─────┴──────────┴──────────┴──────┴─────────┴─────┘

Preamble: 10101010... (동기화 신호)
SFD:      10101011 (Start Frame Delimiter)
Dst MAC:  목적지 MAC 주소 (예: aa:bb:cc:dd:ee:ff)
Src MAC:  출발지 MAC 주소
Type:     0x0800 (IPv4), 0x0806 (ARP), 0x86DD (IPv6)
Payload:  상위 계층 데이터 (최소 46 bytes - 패딩 포함)
FCS:      CRC-32 오류 검출 (Frame Check Sequence)

IP Packet 구조 (IPv4, 최소 20 bytes):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
┌───────┬───────┬───────────────┬───────────────────────────────┐
│Version│  IHL  │   TOS/DSCP    │         Total Length          │
│ (4)   │ (4)   │   (8 bits)    │         (16 bits)             │
├───────────────────────────────┼───┬───────────────────────────┤
│        Identification         │Flg│    Fragment Offset        │
│         (16 bits)             │(3)│       (13 bits)           │
├───────────────┬───────────────┼───────────────────────────────┤
│      TTL      │   Protocol    │      Header Checksum          │
│   (8 bits)    │   (8 bits)    │         (16 bits)             │
├───────────────┴───────────────┴───────────────────────────────┤
│                    Source IP Address                          │
│                      (32 bits)                                │
├───────────────────────────────────────────────────────────────┤
│                 Destination IP Address                        │
│                      (32 bits)                                │
├───────────────────────────────────────────────────────────────┤
│                Options (if IHL > 5)                           │
└───────────────────────────────────────────────────────────────┘

Version:    4 (IPv4)
IHL:        Header Length (5 = 20 bytes, 최대 15 = 60 bytes)
TOS/DSCP:   Quality of Service (우선순위)
Total Len:  헤더 + 데이터 전체 길이
ID:         단편화 시 패킷 식별
Flags:      bit 0: Reserved (0)
            bit 1: DF (Don't Fragment)
            bit 2: MF (More Fragments)
TTL:        패킷 수명 (홉마다 1 감소, 0이 되면 폐기)
Protocol:   6 (TCP), 17 (UDP), 1 (ICMP)
Checksum:   IP 헤더 오류 검출

TCP Segment 구조 (최소 20 bytes):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
┌───────────────────────────────┬───────────────────────────────┐
│         Source Port           │      Destination Port         │
│         (16 bits)             │         (16 bits)             │
├───────────────────────────────┴───────────────────────────────┤
│                      Sequence Number                          │
│                        (32 bits)                              │
├───────────────────────────────────────────────────────────────┤
│                  Acknowledgment Number                        │
│                        (32 bits)                              │
├───────┬───────┬─┬─┬─┬─┬─┬─┬─┬─┬───────────────────────────────┤
│ Offset│ Res.  │C│E│U│A│P│R│S│F│        Window Size            │
│ (4)   │ (3)   │W│C│R│C│S│S│Y│I│         (16 bits)             │
│       │       │R│E│G│K│H│T│N│N│                               │
├───────┴───────┴─┴─┴─┴─┴─┴─┴─┴─┴───────────────────────────────┤
│           Checksum            │      Urgent Pointer           │
│         (16 bits)             │         (16 bits)             │
├───────────────────────────────┴───────────────────────────────┤
│                    Options (if Offset > 5)                    │
│                       (variable)                              │
└───────────────────────────────────────────────────────────────┘

Seq Number:   데이터의 첫 바이트 위치
Ack Number:   다음에 받을 데이터의 위치
Flags:
  - CWR (Congestion Window Reduced): 혼잡 윈도우 감소
  - ECE (ECN-Echo): 혼잡 알림
  - URG (Urgent): 긴급 데이터
  - ACK (Acknowledgment): 확인 응답
  - PSH (Push): 즉시 전달
  - RST (Reset): 연결 강제 종료
  - SYN (Synchronize): 연결 시작
  - FIN (Finish): 연결 종료
Window Size: 수신 버퍼 크기 (Flow Control)

실제 패킷 분석 (tcpdump):

# HTTP GET 요청 캡처
sudo tcpdump -i eth0 -nn -X 'tcp port 80 and host example.com'

출력:
14:30:15.123456 IP 192.168.1.10.54321 > 93.184.216.34.80: Flags [S], seq 1234567890
        0x0000:  4500 003c 1c46 4000 4006 b1e6 c0a8 010a  E..<.F@.@.......
        0x0010:  5db8 d822 d431 0050 499d 162a 0000 0000  ]..".1.PI..*....
        0x0020:  a002 7210 e32d 0000 0204 05b4 0402 080a  ..r..-..........
        
분석:
0x4500: Version=4, IHL=5, TOS=00
0x003c: Total Length = 60 bytes
0x1c46: Identification
0x4000: Flags=DF (Don't Fragment)
0x40:   TTL = 64
0x06:   Protocol = TCP (6)
0xc0a8010a: Source IP = 192.168.1.10
0x5db8d822: Dest IP = 93.184.216.34
0xd431: Source Port = 54321
0x0050: Dest Port = 80
0xa002: Flags = SYN, Window Size = 7210

Wireshark 디스플레이 필터:

TCP 3-Way Handshake:
tcp.flags.syn==1 && tcp.flags.ack==0    # SYN
tcp.flags.syn==1 && tcp.flags.ack==1    # SYN-ACK
tcp.flags.syn==0 && tcp.flags.ack==1 && tcp.seq==1  # ACK

HTTP 요청:
http.request.method == "GET"
http.response.code == 200

재전송 패킷:
tcp.analysis.retransmission

느린 응답:
tcp.time_delta > 0.1

패킷 손실:
tcp.analysis.lost_segment

Q20. MTU/MSS 불일치로 인한 패킷 단편화 문제와 PMTUD 동작 원리는?

MTU vs MSS:

MTU (Maximum Transmission Unit):
┌─────────────────────────────────────────────┐
│ Ethernet Header (14) │ IP Packet (1500) │ FCS (4) │
└─────────────────────────────────────────────┘
                        ↑
                   MTU = 1500 bytes

MSS (Maximum Segment Size):
┌──────────────────────────────────────────────────────┐
│ IP Header (20) │ TCP Header (20) │ TCP Data (1460) │
└──────────────────────────────────────────────────────┘
                                    ↑
                               MSS = 1460 bytes

공식: MSS = MTU - IP Header(20) - TCP Header(20)

일반적인 MTU 값:

Ethernet:           1500 bytes
802.1Q VLAN:        1504 bytes (VLAN tag 4 bytes)
PPPoE:              1492 bytes (PPPoE header 8 bytes)
VPN (IPsec):        1400 bytes (암호화 오버헤드 약 100 bytes)
GRE Tunnel:         1476 bytes (GRE header 24 bytes)
VXLAN:              1450 bytes (VXLAN header 50 bytes)
Jumbo Frame:        9000 bytes (데이터센터)

패킷 단편화 문제:

시나리오: Client MTU=1500, 중간 경로 MTU=1400

Client → Router1 (MTU 1500) → Router2 (MTU 1400) → Server

1. Client: 1500 bytes 패킷 전송
2. Router2: MTU 초과, 단편화 필요
   
DF Flag = 0 (단편화 허용):
   Original: [IP Header | 1480 bytes data]
   Fragment1: [IP Header | 1380 bytes | MF=1]
   Fragment2: [IP Header | 100 bytes | MF=0]
   
DF Flag = 1 (단편화 금지):
   Router2: ICMP "Fragmentation Needed" 전송
   패킷 폐기

PMTUD (Path MTU Discovery) 동작:

1. Client: DF 플래그 설정하여 1500 bytes 패킷 전송
   
2. MTU 1400 라우터 도달:
   → ICMP Type 3 Code 4 (Fragmentation Needed and DF set) 응답
   → Next-Hop MTU: 1400
   
3. Client: MTU를 1400으로 조정
   → 1400 bytes 패킷 재전송
   
4. 경로상 모든 구간 통과 성공
   → Path MTU = 1400 확정
   
5. TCP Connection에 MSS 조정:
   MSS = 1400 - 20(IP) - 20(TCP) = 1360 bytes

PMTUD 실습:

# Ping으로 MTU 테스트
ping -M do -s 1472 8.8.8.8
# -M do: DF 플래그 설정
# -s 1472: 1472 bytes 데이터 (1500 - 20 IP - 8 ICMP)

성공: 1472 bytes 전송 가능 → MTU 1500
실패: ICMP "Frag needed" → MTU < 1500

# Binary Search로 Path MTU 찾기
ping -M do -s 1400 8.8.8.8  # 성공
ping -M do -s 1450 8.8.8.8  # 성공
ping -M do -s 1470 8.8.8.8  # 실패
ping -M do -s 1460 8.8.8.8  # 성공
→ Path MTU = 1488 (1460 + 20 IP + 8 ICMP)

PMTUD Black Hole 문제:

문제: 방화벽이 ICMP "Fragmentation Needed" 차단
      
Client ─── Router (MTU 1400, ICMP 차단) ─── Server
  │                                           │
  └──── 1500 bytes (DF=1) ────X (폐기)       │
  │                                           │
  └──── ICMP 응답 기다림 ────X (타임아웃)    │
  │                                           │
  └──── 재전송 ────X (반복)                  │

결과: 연결 불가 또는 극도로 느림

해결 방법:

1. TCP MSS Clamping (권장):

# iptables로 MSS 강제 조정
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
         -j TCPMSS --set-mss 1360

# Cisco 라우터
interface GigabitEthernet0/0
 ip tcp adjust-mss 1360

원리:
SYN 패킷의 MSS 옵션을 강제로 낮춤
→ 양쪽 모두 작은 세그먼트 사용
→ 단편화 발생 안 함

2. MTU 수동 조정:

# Linux
ip link set dev eth0 mtu 1400

# Windows
netsh interface ipv4 set subinterface "Ethernet" mtu=1400

# 영구 설정 (Linux /etc/network/interfaces)
auto eth0
iface eth0 inet dhcp
    mtu 1400

3. PLPMTUD (Packetization Layer PMTUD):

TCP의 자체 PMTUD (RFC 4821):
- ICMP에 의존하지 않음
- Probe 패킷으로 MTU 탐색
- 더 안정적이지만 느림

VPN 환경 MSS 계산:

IPsec VPN:
Physical MTU:     1500
IPsec Overhead:   ~100 (ESP header, IV, Padding, Auth)
Effective MTU:    1400
TCP MSS:          1400 - 20(IP) - 20(TCP) = 1360

VXLAN:
Physical MTU:     1500
VXLAN Overhead:   50 (Outer Ethernet 14 + Outer IP 20 + Outer UDP 8 + VXLAN 8)
Effective MTU:    1450
TCP MSS:          1450 - 20 - 20 = 1410

모니터링:

# 단편화된 패킷 확인
tcpdump -i eth0 'ip[6:2] & 0x3fff != 0'

# Path MTU 확인 (Linux)
ip route get 8.8.8.8 | grep mtu

# TCP MSS 확인 (Wireshark)
tcp.options.mss

Q21. tcpdump와 Wireshark를 활용한 네트워크 트러블슈팅 실전 시나리오는?

시나리오 1: 느린 웹사이트 응답

증상: 웹페이지 로딩이 5초 이상 소요

tcpdump 캡처:

# 80 포트 HTTP 트래픽 캡처, 타임스탬프 마이크로초 단위
sudo tcpdump -i eth0 -nn -tttt -s 65535 'tcp port 80' -w slow-web.pcap

# 실시간 분석 (타임스탬프 포함)
sudo tcpdump -i eth0 -nn -tttt 'host example.com and tcp port 80'

출력:
2024-01-15 14:30:00.123456 IP 192.168.1.10.54321 > 93.184.216.34.80: Flags [S]
2024-01-15 14:30:00.323456 IP 93.184.216.34.80 > 192.168.1.10.54321: Flags [S.]
                           ↑ 200ms 지연 (SYN-ACK)
2024-01-15 14:30:00.323789 IP 192.168.1.10.54321 > 93.184.216.34.80: Flags [.]
2024-01-15 14:30:00.324567 IP 192.168.1.10.54321 > 93.184.216.34.80: ... HTTP GET
2024-01-15 14:30:05.123456 IP 93.184.216.34.80 > 192.168.1.10.54321: ... HTTP 200
                           ↑ 4.8초 지연 (서버 응답)

Wireshark 분석:

1. Statistics → Conversations → TCP
   → Duration 4.8초, Bytes 확인

2. Statistics → I/O Graph
   → 시간대별 트래픽 시각화
   → 응답 대기 구간 확인

3. Display Filter:
   tcp.time_delta > 1.0
   → 1초 이상 지연 패킷만 필터링

4. Expert Info (Analyze → Expert Information)
   → "TCP Window Full" 경고 확인
   → 서버 윈도우 크기 부족 (수신 버퍼 작음)

원인: 서버 TCP Window Size 부족 (16KB) 해결: 서버 수신 버퍼 증가

sysctl -w net.ipv4.tcp_rmem='4096 87380 6291456'

시나리오 2: 간헐적인 패킷 손실

증상: VoIP 통화 품질 저하, 끊김 현상

tcpdump 캡처:

# RTP 트래픽 캡처 (일반적으로 UDP 10000-20000 포트)
sudo tcpdump -i eth0 -nn -s 65535 'udp portrange 10000-20000' -w voip.pcap

# Packet Loss 계산
sudo tcpdump -i eth0 -nn 'udp port 10000' | \
  awk '{print $NF}' | \
  awk -F. '{if (prev && $1-prev!=1) print "Lost:", prev+1, "to", $1-1; prev=$1}'

Wireshark 분석:

1. Telephony → RTP → RTP Streams
   → Packet Loss: 3.5% (정상 < 1%)
   → Jitter: 50ms (정상 < 30ms)

2. Display Filter:
   rtp
   → RTP Sequence Number 확인
   → 증가 패턴에서 누락 탐지

3. I/O Graph:
   Y Axis: SUM(rtp.timestamp)
   → 균일하지 않은 패턴 = Jitter

4. Expert Info:
   → "Out-of-Order" 경고 다수

원인 추가 분석:

# 네트워크 인터페이스 에러 확인
ethtool -S eth0 | grep -E 'err|drop|fifo'
rx_dropped: 12345  ← 수신 버퍼 오버플로우
tx_errors: 678     ← 송신 에러

# 인터페이스 통계
ip -s link show eth0
RX errors 12345

# 시스템 로그
dmesg | grep -i 'network\|eth0'
[  123.456] eth0: RX buffer overflow

해결:

# Ring Buffer 크기 증가
ethtool -G eth0 rx 4096 tx 4096

# QoS 설정 (VoIP 우선순위)
tc qdisc add dev eth0 root handle 1: prio bands 3
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
   match ip dport 10000 0xffff flowid 1:1

시나리오 3: TCP 재전송 폭증

증상: 애플리케이션 응답 지연, CPU 사용률 정상

tcpdump 패턴 분석:

# 재전송 패킷 캡처
sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 or \
  (tcp[13] & 0x07 != 0)' -w retrans.pcap

# SYN Flood 감지
sudo tcpdump -i eth0 -nn 'tcp[tcpflags] == tcp-syn' | \
  awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -nr | head
  
출력:
  5432 192.168.1.100  ← 비정상적으로 많은 SYN
   234 192.168.1.101
   123 192.168.1.102

Wireshark Expert Analysis:

1. Statistics → TCP StreamGraph → Time-Sequence (Stevens)
   → 수평 라인 다수 = 재전송 대기

2. Display Filter:
   tcp.analysis.retransmission
   tcp.analysis.fast_retransmission
   tcp.analysis.duplicate_ack

3. 재전송 비율:
   Statistics → Protocol Hierarchy
   → TCP Retransmission: 15% (정상 < 3%)

4. Follow TCP Stream:
   → 3-Way Handshake 후 RST
   → SYN Flood 공격 의심

공격 확인:

# 반쯤 열린 연결 수 확인
netstat -an | grep SYN_RECV | wc -l
12345  ← 비정상 (정상 < 100)

# SYN Cookie 활성화 (임시 방어)
sysctl -w net.ipv4.tcp_syncookies=1

# 연결 타임아웃 단축
sysctl -w net.ipv4.tcp_synack_retries=1

# iptables Rate Limiting
iptables -A INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

시나리오 4: DNS 쿼리 실패

tcpdump DNS 분석:

# DNS 쿼리/응답 캡처
sudo tcpdump -i eth0 -nn -s 65535 'udp port 53' -w dns-issue.pcap

# 실시간 모니터링
sudo tcpdump -i eth0 -nn 'port 53'

출력:
14:30:00.123 IP 192.168.1.10.54321 > 8.8.8.8.53: 12345+ A? example.com
14:30:05.123 IP 192.168.1.10.54321 > 8.8.8.8.53: 12345+ A? example.com
                                                 ↑ 5초 후 재시도
(응답 없음)

Wireshark 분석:

1. Display Filter:
   dns.flags.response == 0 && !dns.flags.response == 1
   → 응답 없는 쿼리만 필터링

2. Statistics → DNS
   → Query Rate: 100/s
   → Response Rate: 0/s
   → 100% 손실

3. Follow UDP Stream:
   → DNS 서버 방화벽 차단 확인
   → ICMP "Port Unreachable" 수신

문제 진단:

# DNS 서버 연결 테스트
dig @8.8.8.8 example.com +trace

# 방화벽 확인
sudo iptables -L -n -v | grep -i dns
0     0 DROP       udp  --  *      *       0.0.0.0/0    8.8.8.8     udp dpt:53

# 대체 DNS 테스트
dig @1.1.1.1 example.com  # Cloudflare DNS 정상

해결:

# 방화벽 규칙 수정
iptables -D OUTPUT -p udp --dport 53 -d 8.8.8.8 -j DROP
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

# /etc/resolv.conf 업데이트
nameserver 1.1.1.1
nameserver 8.8.8.8

유용한 tcpdump 필터:

# HTTP 요청만
tcpdump -i eth0 -A 'tcp port 80 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420)'
                                    # GET 문자열 (0x47455420)

# SYN 패킷만
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

# RST 패킷만
tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'

# 특정 MAC 주소
tcpdump -i eth0 ether host aa:bb:cc:dd:ee:ff

# VLAN 태그
tcpdump -i eth0 'vlan and host 192.168.1.10'

# 큰 패킷 (1400 bytes 이상)
tcpdump -i eth0 'ip[2:2] > 1400'

# ICMP Redirect
tcpdump -i eth0 'icmp[icmptype] == 5'

Wireshark 고급 필터:

# TCP Window가 0인 패킷 (흐름 제어)
tcp.window_size == 0

# TCP Zero Window Probe
tcp.analysis.zero_window_probe

# Delayed ACK
tcp.analysis.ack_rtt > 0.2

# TCP Out-of-Order
tcp.analysis.out_of_order

# HTTP 특정 User-Agent
http.user_agent contains "bot"

# SSL/TLS Handshake 실패
ssl.alert_message.desc == 40  # Handshake Failure

Q22. TCP Congestion Control 알고리즘과 Window Scaling의 동작 원리는?

TCP Flow Control vs Congestion Control:

Flow Control (흐름 제어):
- 목적: 수신자 버퍼 오버플로우 방지
- 메커니즘: TCP Window Size (Receiver Advertised Window)
- 범위: Point-to-Point (송신자 ↔ 수신자)

Congestion Control (혼잡 제어):
- 목적: 네트워크 혼잡 방지
- 메커니즘: Congestion Window (cwnd)
- 범위: End-to-End (전체 경로)

TCP Congestion Control 상태 머신:

┌─────────────────────────────────────────────────────────┐
│                    Slow Start                           │
│  cwnd: 1 MSS → 2 → 4 → 8 → 16 ... (Exponential)        │
│  매 ACK마다 cwnd += 1 MSS                               │
└────────────────┬────────────────────────────────────────┘
                 │ cwnd >= ssthresh (Slow Start Threshold)
                 ↓
┌─────────────────────────────────────────────────────────┐
│              Congestion Avoidance                       │
│  cwnd 증가: Linear (매 RTT마다 1 MSS)                  │
│  매 ACK마다 cwnd += MSS * MSS / cwnd                    │
└────────────────┬────────────────────────────────────────┘
                 │ Packet Loss 감지
                 ↓
         ┌───────┴────────┐
         │                │
    3 Dup ACK        Timeout
         │                │
         ↓                ↓
┌─────────────┐  ┌──────────────────┐
│ Fast        │  │ Slow Start       │
│ Recovery    │  │ (처음부터 재시작)│
│ ssthresh=   │  │ ssthresh=        │
│  cwnd/2     │  │  cwnd/2          │
│ cwnd=       │  │ cwnd= 1 MSS      │
│  ssthresh+3 │  │                  │
└─────────────┘  └──────────────────┘

구체적인 예시:

초기 상태:
cwnd = 1 MSS (1460 bytes)
ssthresh = 64 KB
RTT = 100ms

Round 1 (Slow Start):
- 1 MSS 전송 → ACK 수신 → cwnd = 2 MSS

Round 2:
- 2 MSS 전송 → 2 ACK 수신 → cwnd = 4 MSS

Round 3:
- 4 MSS 전송 → 4 ACK 수신 → cwnd = 8 MSS

...

Round 7:
- cwnd = 64 MSS = 93,440 bytes
- cwnd >= ssthresh → Congestion Avoidance 전환

Round 8 (Congestion Avoidance):
- 64 MSS 전송 → 64 ACK 수신
- cwnd += 64 * 1460 / 93440 = 1 MSS
- cwnd = 65 MSS

Round 9:
- cwnd = 66 MSS (Linear 증가)

Round 15:
- Packet Loss (3 Duplicate ACK)
- Fast Retransmit 실행
- ssthresh = cwnd / 2 = 36 MSS
- cwnd = ssthresh + 3 = 39 MSS
- Fast Recovery 진입

주요 Congestion Control 알고리즘:

1. Reno (Classic):

- Fast Retransmit: 3 Duplicate ACK → 즉시 재전송
- Fast Recovery: cwnd를 절반으로 줄이고 Congestion Avoidance
- Timeout: cwnd = 1, Slow Start 재시작

2. Cubic (Linux 기본값):

- Window 증가가 Cubic 함수 따름
- Loss 발생 지점(Wmax)을 기억
- Wmax 근처에서 신중하게 증가
- 고속 네트워크(Long Fat Network)에 최적화

K = cubic_root((Wmax - cwnd) / C)
cwnd = C * (t - K)³ + Wmax

장점: RTT가 길어도 빠른 대역폭 활용

3. BBR (Bottleneck Bandwidth and RTT):

- Google 개발 (2016)
- Loss 기반이 아닌 Bandwidth와 RTT 측정 기반
- 4가지 상태: Startup, Drain, ProbeBW, ProbeRTT

장점:
- 버퍼 블로트(Bufferbloat) 해결
- Packet Loss 환경에서도 안정적
- YouTube, Google Cloud 등에서 사용

sysctl -w net.ipv4.tcp_congestion_control=bbr

TCP Window Scaling (RFC 1323):

문제:

TCP Window Size 필드: 16 bits → 최대 65,535 bytes
고속 네트워크 (1 Gbps, RTT 100ms):
- BDP (Bandwidth-Delay Product) = 1Gbps * 100ms = 12.5 MB
- 기본 Window Size로는 처리량 제한
  Throughput = Window Size / RTT = 65KB / 0.1s = 650 KB/s
  → 1 Gbps 회선에서 5 Mbps만 활용

해결: Window Scale Option

TCP SYN 패킷에 포함:
┌────────────────────────────────┐
│ Option Kind: 3 (Window Scale)  │
│ Option Length: 3               │
│ Shift Count: 7                 │  ← 2^7 = 128 배 확장
└────────────────────────────────┘

실제 Window Size = (TCP Header Window) << (Shift Count)
예: Header Window = 65,535
    Shift Count = 7
    Actual Window = 65,535 * 128 = 8,388,480 bytes (8 MB)

Window Scaling 확인:

# tcpdump로 SYN 패킷 확인
sudo tcpdump -i eth0 -nn -vv 'tcp[tcpflags] & tcp-syn != 0'

출력:
IP 192.168.1.10.54321 > 93.184.216.34.80: Flags [S], seq 123, win 65535,
  options [mss 1460,nop,wscale 7,nop,nop,TS val 123 ecr 0,sackOK,eol]
                        ↑ wscale 7 = 128배 확장

# Wireshark 분석
tcp.options.wscale.shift
tcp.window_size_scalefactor

실무 설정 (Linux):

# TCP 수신 버퍼 크기
sysctl -w net.ipv4.tcp_rmem='4096 87380 6291456'
            # min   default   max (6 MB)

# TCP 송신 버퍼 크기
sysctl -w net.ipv4.tcp_wmem='4096 16384 4194304'
            # min   default   max (4 MB)

# Window Scaling 활성화 (기본값 1)
sysctl -w net.ipv4.tcp_window_scaling=1

# SACK (Selective Acknowledgment) 활성화
sysctl -w net.ipv4.tcp_sack=1

# Timestamps 활성화 (RTT 측정)
sysctl -w net.ipv4.tcp_timestamps=1

# 처리량 계산
# BDP = Bandwidth * RTT
# 1 Gbps * 100ms = 125 MB/s * 0.1s = 12.5 MB
# Window Size >= BDP

성능 측정:

# iperf3로 처리량 테스트
iperf3 -c server.example.com -t 60 -P 4

출력 (최적화 전):
[  5]   0.00-60.00  sec  5.12 GBytes  734 Mbits/sec  receiver
                                      ↑ Window Size 부족

# Window Scaling 후:
[  5]   0.00-60.00  sec  65.3 GBytes  9.35 Gbits/sec  receiver
                                      ↑ 거의 전체 대역폭 활용

# cwnd 모니터링
ss -i | grep -i cwnd
cubic wscale:7,7 rto:204 rtt:3.5/2 cwnd:10 send 33.1Mbps
      ↑ Window Scale  ↑ Congestion Window

Wireshark로 성능 문제 진단:

1. TCP Window Full:
   → 수신자 윈도우 크기 부족
   → 송신자가 대기해야 함
   tcp.analysis.window_full

2. TCP Zero Window:
   → 수신자 버퍼 가득 참
   → 송신 중단
   tcp.window_size == 0

3. TCP Window Update:
   → 수신자가 윈도우 확장 알림
   tcp.analysis.window_update

해결:
- 수신 버퍼 크기 증가
- Window Scaling 활성화
- 애플리케이션 처리 속도 개선

Q23. 패킷 캡처 시 BPF 필터 작성과 성능 최적화 방법은?

BPF (Berkeley Packet Filter) 문법:

기본 구조:

[protocol] [direction] [type] [value]

protocol: ip, ip6, arp, tcp, udp, icmp
direction: src, dst, src and dst, src or dst
type: host, net, port, portrange

실전 예제:

1. 특정 호스트 간 통신:

# 양방향
tcpdump host 192.168.1.10

# 출발지만
tcpdump src host 192.168.1.10

# 목적지만
tcpdump dst host 192.168.1.10

# 두 호스트 간 통신
tcpdump host 192.168.1.10 and host 192.168.1.20

2. 네트워크 범위:

# 서브넷
tcpdump net 192.168.1.0/24
tcpdump net 192.168.1.0 mask 255.255.255.0

# 여러 서브넷
tcpdump 'net 192.168.1.0/24 or net 10.0.0.0/8'

3. 포트 필터링:

# 단일 포트
tcpdump port 80
tcpdump dst port 443

# 포트 범위
tcpdump portrange 10000-20000

# 여러 포트
tcpdump 'port 80 or port 443 or port 8080'

# 특정 포트 제외
tcpdump 'not port 22'

4. TCP 플래그 필터:

# SYN 패킷만
tcpdump 'tcp[tcpflags] & tcp-syn != 0'
tcpdump 'tcp[13] & 2 != 0'  # 동일 (13번째 바이트, bit 1)

# SYN-ACK
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)'
tcpdump 'tcp[13] == 18'  # SYN(2) + ACK(16) = 18

# FIN 패킷
tcpdump 'tcp[tcpflags] & tcp-fin != 0'

# RST 패킷
tcpdump 'tcp[tcpflags] & tcp-rst != 0'

# PSH-ACK (데이터 전송)
tcpdump 'tcp[tcpflags] & (tcp-push|tcp-ack) == (tcp-push|tcp-ack)'

# ACK만 (SYN, FIN, RST 제외)
tcpdump 'tcp[tcpflags] == tcp-ack'

5. IP 헤더 필터:

# TTL 특정 값
tcpdump 'ip[8] == 64'  # TTL = 64

# TTL < 10 (의심스러운 패킷)
tcpdump 'ip[8] < 10'

# IP 옵션이 있는 패킷
tcpdump 'ip[0] & 0x0f > 5'  # IHL > 5 (옵션 존재)

# DF (Don't Fragment) 플래그
tcpdump 'ip[6] & 0x40 != 0'

# MF (More Fragments) 플래그
tcpdump 'ip[6] & 0x20 != 0'

# 단편화된 패킷
tcpdump 'ip[6:2] & 0x1fff != 0'

# ToS/DSCP 값
tcpdump 'ip[1] & 0xfc == 0xb8'  # EF (Expedited Forwarding)

6. 페이로드 검색:

# HTTP GET 요청
tcpdump -A 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'
                                            # "GET " ASCII

# HTTP POST
tcpdump -A 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354'
                                            # "POST"

# HTTP 응답 200
tcpdump -A 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450'
                                            # "HTTP"

# SSH 프로토콜 식별
tcpdump -A 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x5353482d'
                                            # "SSH-"

7. 복합 필터:

# 외부 → 내부 웹 트래픽 (포트 80, 443)
tcpdump 'dst net 192.168.0.0/16 and (port 80 or port 443)'

# SSH를 제외한 모든 트래픽
tcpdump 'not port 22'

# 특정 호스트로의 DNS 쿼리
tcpdump 'src host 192.168.1.10 and dst port 53'

# ICMP Echo Request/Reply
tcpdump 'icmp[icmptype] == 8 or icmp[icmptype] == 0'

# ARP 요청만
tcpdump 'arp[6:2] == 1'  # ARP opcode = 1 (request)

성능 최적화:

1. Capture Filter vs Display Filter:

# 좋음: Capture Filter (BPF, 커널 레벨)
tcpdump -i eth0 'host 192.168.1.10'
→ 불필요한 패킷은 캡처 안 함
→ CPU/메모리 절약

# 나쁨: 모든 패킷 캡처 후 필터링
tcpdump -i eth0 -w all.pcap
wireshark all.pcap  # Display Filter 사용
→ 디스크 I/O 과다
→ 대용량 파일 생성

2. 스냅샷 길이 최적화:

# 헤더만 필요한 경우 (기본값 262144)
tcpdump -i eth0 -s 96 'tcp'
# Ethernet(14) + IP(20) + TCP(20) + 옵션(42) = 96 bytes

# 전체 패킷 (페이로드 분석 필요)
tcpdump -i eth0 -s 65535 'port 80'

# 최소 크기 (헤더만)
tcpdump -i eth0 -s 0 'tcp'  # 0 = 전체

3. 버퍼 크기 조정:

# 기본 버퍼: 2 MB
tcpdump -i eth0 -B 16384 'port 80'
# 16 MB 버퍼 (고속 네트워크)

# 드롭 패킷 확인
tcpdump -i eth0 -vv 'port 80'
^C
1000 packets captured
950 packets received by filter
50 packets dropped by kernel  ← 버퍼 부족

4. Ring Buffer 사용 (파일 로테이션):

# 10MB 파일 5개 순환 (총 50MB)
tcpdump -i eth0 -C 10 -W 5 -w capture.pcap 'port 80'
# capture.pcap0, capture.pcap1, ..., capture.pcap4

# 시간 기반 로테이션 (5분마다)
tcpdump -i eth0 -G 300 -w 'capture-%Y%m%d-%H%M%S.pcap'

5. 멀티코어 활용:

# CPU Affinity 설정
taskset -c 0 tcpdump -i eth0 -w cpu0.pcap 'port 80'
taskset -c 1 tcpdump -i eth1 -w cpu1.pcap 'port 443'

# PF_RING (고성능 패킷 캡처)
tcpdump -i eth0@1 -w capture.pcap  # PF_RING 채널 1

6. 실시간 분석 vs 파일 저장:

# 실시간 분석 (화면 출력)
tcpdump -i eth0 -l 'port 80' | grep "GET"
# -l: Line Buffered (즉시 출력)

# 파일 저장 후 분석 (권장)
tcpdump -i eth0 -w capture.pcap 'port 80'
wireshark capture.pcap

7. 샘플링:

# 1/10 패킷만 캡처 (통계 목적)
tcpdump -i eth0 -w capture.pcap \
  'tcp and (tcp[13] & 0x17 = 0x02) and (rand() % 10 = 0)'

고급 BPF 예제:

웹 트래픽 분석:

# HTTP 헤더만 (첫 1024 bytes)
tcpdump -i eth0 -s 1024 -A 'tcp port 80 and (
  (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420) or
  (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450)
)'

# HTTPS ClientHello (TLS Handshake)
tcpdump -i eth0 '(tcp[((tcp[12:1] & 0xf0) >> 2)] = 0x16) and
  (tcp[((tcp[12:1] & 0xf0) >> 2) + 1] = 0x03) and
  (tcp[((tcp[12:1] & 0xf0) >> 2) + 5] = 0x01)'

보안 분석:

# Port Scan 감지 (SYN만 많은 경우)
tcpdump -i eth0 'tcp[tcpflags] == tcp-syn and src host 192.168.1.0/24'

# SYN Flood
tcpdump -i eth0 -nn -q 'tcp[tcpflags] == tcp-syn' | \
  awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | \
  awk '$1 > 100 {print "Possible SYN flood from", $2, "with", $1, "SYNs"}'

# DNS Amplification
tcpdump -i eth0 'udp port 53 and ip[2:2] > 512'

성능 테스트:

# 고속 네트워크 (10 Gbps)
# 일반 tcpdump: ~1 Gbps 처리 가능
# PF_RING: ~10 Gbps
# DPDK: ~40 Gbps

# tcpdump 성능 측정
time tcpdump -i eth0 -c 100000 -w /dev/null 'tcp'

real    0m2.345s
user    0m0.123s
sys     0m1.234s
→ ~42,000 pps (packets per second)

💡 용어 설명:

패킷 분석 관련 질문들(Q19-Q23)에서 사용된 용어들(Ethernet Frame, IP Packet, TCP Segment, MTU/MSS, PMTUD, TCP Window Scaling, BPF 등)에 대한

상세한 설명은 문서 상단의 주요 용어 통합 정리 > 패킷 분석 & 트러블슈팅 섹션을 참고하세요.

참고 자료

← KR_네트워크.md로 돌아가기

KR_Net_Packet_Analysis - somaz94/DevOps-Engineer GitHub Wiki

네트워크 패킷 분석 & 트러블슈팅 (Q19-Q23)

패킷 분석 & 트러블슈팅 (19~25번)

Q19. Ethernet Frame, IP Packet, TCP Segment의 헤더 구조를 설명하고 실제 패킷 분석 방법은?

Q20. MTU/MSS 불일치로 인한 패킷 단편화 문제와 PMTUD 동작 원리는?

Q21. tcpdump와 Wireshark를 활용한 네트워크 트러블슈팅 실전 시나리오는?

Q22. TCP Congestion Control 알고리즘과 Window Scaling의 동작 원리는?

Q23. 패킷 캡처 시 BPF 필터 작성과 성능 최적화 방법은?

참고 자료

⚠️ GitHub.com Fallback ⚠️

KR_Net_Packet_Analysis - somaz94/DevOps-Engineer GitHub Wiki

네트워크 패킷 분석 & 트러블슈팅 (Q19-Q23)

패킷 분석 & 트러블슈팅 (19~25번)

Q19. Ethernet Frame, IP Packet, TCP Segment의 헤더 구조를 설명하고 실제 패킷 분석 방법은?

Q20. MTU/MSS 불일치로 인한 패킷 단편화 문제와 PMTUD 동작 원리는?

Q21. tcpdump와 Wireshark를 활용한 네트워크 트러블슈팅 실전 시나리오는?

Q22. TCP Congestion Control 알고리즘과 Window Scaling의 동작 원리는?

Q23. 패킷 캡처 시 BPF 필터 작성과 성능 최적화 방법은?

참고 자료

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️