-
Notifications
You must be signed in to change notification settings - Fork 0
EN_Net_Packet_Analysis
somaz edited this page Jun 2, 2026
·
1 revision
Q19. Explain the header structures of an Ethernet Frame, IP Packet, and TCP Segment, and how to analyze actual packets.
Per-Layer Encapsulation Structure:
┌─────────────────────────────────────────────────────────┐
│ Ethernet Frame (Layer 2) │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ IP Packet (Layer 3) │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ TCP Segment (Layer 4) │ │ │
│ │ │ ┌─────────────────────────────────────────────┐ │ │ │
│ │ │ │ Application Data (Layer 7) │ │ │ │
│ │ │ └─────────────────────────────────────────────┘ │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
Ethernet Frame Structure (minimum 64 bytes ~ maximum 1518 bytes total):
┌──────────┬─────┬──────────┬──────────┬──────┬─────────┬─────┐
│ 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... (synchronization signal)
SFD: 10101011 (Start Frame Delimiter)
Dst MAC: Destination MAC address (e.g., aa:bb:cc:dd:ee:ff)
Src MAC: Source MAC address
Type: 0x0800 (IPv4), 0x0806 (ARP), 0x86DD (IPv6)
Payload: Upper-layer data (minimum 46 bytes - including padding)
FCS: CRC-32 error detection (Frame Check Sequence)
IP Packet Structure (IPv4, minimum 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, max 15 = 60 bytes)
TOS/DSCP: Quality of Service (priority)
Total Len: Total length of header + data
ID: Packet identification during fragmentation
Flags: bit 0: Reserved (0)
bit 1: DF (Don't Fragment)
bit 2: MF (More Fragments)
TTL: Packet lifetime (decremented by 1 at each hop, discarded when it reaches 0)
Protocol: 6 (TCP), 17 (UDP), 1 (ICMP)
Checksum: IP header error detection
TCP Segment Structure (minimum 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: Position of the first byte of data
Ack Number: Position of the next data to be received
Flags:
- CWR (Congestion Window Reduced): congestion window reduced
- ECE (ECN-Echo): congestion notification
- URG (Urgent): urgent data
- ACK (Acknowledgment): acknowledgment
- PSH (Push): immediate delivery
- RST (Reset): force connection termination
- SYN (Synchronize): start connection
- FIN (Finish): terminate connection
Window Size: Receive buffer size (Flow Control)
Actual Packet Analysis (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 = 7210Wireshark Display Filters:
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. What are the packet fragmentation problems caused by MTU/MSS mismatch, and how does PMTUD work?
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
Formula: MSS = MTU - IP Header(20) - TCP Header(20)
Common MTU Values:
Ethernet: 1500 bytes
802.1Q VLAN: 1504 bytes (VLAN tag 4 bytes)
PPPoE: 1492 bytes (PPPoE header 8 bytes)
VPN (IPsec): 1400 bytes (encryption overhead about 100 bytes)
GRE Tunnel: 1476 bytes (GRE header 24 bytes)
VXLAN: 1450 bytes (VXLAN header 50 bytes)
Jumbo Frame: 9000 bytes (data center)
Packet Fragmentation Problem:
Scenario: Client MTU=1500, intermediate path MTU=1400
Client → Router1 (MTU 1500) → Router2 (MTU 1400) → Server
1. Client: sends a 1500-byte packet
2. Router2: MTU exceeded, fragmentation needed
DF Flag = 0 (fragmentation allowed):
Original: [IP Header | 1480 bytes data]
Fragment1: [IP Header | 1380 bytes | MF=1]
Fragment2: [IP Header | 100 bytes | MF=0]
DF Flag = 1 (fragmentation prohibited):
Router2: sends ICMP "Fragmentation Needed"
packet discarded
PMTUD (Path MTU Discovery) Operation:
1. Client: sends a 1500-byte packet with the DF flag set
2. Reaches the MTU 1400 router:
→ ICMP Type 3 Code 4 (Fragmentation Needed and DF set) response
→ Next-Hop MTU: 1400
3. Client: adjusts MTU to 1400
→ retransmits a 1400-byte packet
4. Successfully passes all segments along the path
→ Path MTU = 1400 confirmed
5. Adjusts MSS for the TCP Connection:
MSS = 1400 - 20(IP) - 20(TCP) = 1360 bytes
PMTUD Practice:
# 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 Problem:
Problem: a firewall blocks ICMP "Fragmentation Needed"
Client ─── Router (MTU 1400, ICMP blocked) ─── Server
│ │
└──── 1500 bytes (DF=1) ────X (discarded) │
│ │
└──── waits for ICMP response ────X (timeout)│
│ │
└──── retransmit ────X (repeat) │
Result: connection fails or is extremely slow
Solutions:
1. TCP MSS Clamping (recommended):
# 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. Manual MTU Adjustment:
# 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 14003. PLPMTUD (Packetization Layer PMTUD):
TCP's own PMTUD (RFC 4821):
- Does not rely on ICMP
- Discovers MTU using probe packets
- More reliable but slower
MSS Calculation in VPN Environments:
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
Monitoring:
# 단편화된 패킷 확인
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.mssScenario 1: Slow Website Response
Symptom: Web page loading takes more than 5 seconds
tcpdump Capture:
# 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 Analysis:
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" 경고 확인
→ 서버 윈도우 크기 부족 (수신 버퍼 작음)
Cause: Insufficient server TCP Window Size (16KB) Solution: Increase the server receive buffer
sysctl -w net.ipv4.tcp_rmem='4096 87380 6291456'Scenario 2: Intermittent Packet Loss
Symptom: Degraded VoIP call quality, dropouts
tcpdump Capture:
# 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 Analysis:
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" 경고 다수
Additional Root-Cause Analysis:
# 네트워크 인터페이스 에러 확인
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 overflowSolution:
# 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:1Scenario 3: Surge in TCP Retransmissions
Symptom: Application response delays, CPU usage normal
tcpdump Pattern Analysis:
# 재전송 패킷 캡처
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.102Wireshark 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 공격 의심
Attack Confirmation:
# 반쯤 열린 연결 수 확인
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 DROPScenario 4: DNS Query Failure
tcpdump DNS Analysis:
# 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 Analysis:
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" 수신
Problem Diagnosis:
# 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 정상Solution:
# 방화벽 규칙 수정
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.8Useful tcpdump Filters:
# 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'Advanced Wireshark Filters:
# 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
TCP Flow Control vs Congestion Control:
Flow Control:
- Purpose: prevent receiver buffer overflow
- Mechanism: TCP Window Size (Receiver Advertised Window)
- Scope: Point-to-Point (sender ↔ receiver)
Congestion Control:
- Purpose: prevent network congestion
- Mechanism: Congestion Window (cwnd)
- Scope: End-to-End (entire path)
TCP Congestion Control State Machine:
┌─────────────────────────────────────────────────────────┐
│ 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 │ │ │
└─────────────┘ └──────────────────┘
Concrete Example:
초기 상태:
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 진입
Major Congestion Control Algorithms:
1. Reno (Classic):
- Fast Retransmit: 3 Duplicate ACK → 즉시 재전송
- Fast Recovery: cwnd를 절반으로 줄이고 Congestion Avoidance
- Timeout: cwnd = 1, Slow Start 재시작
2. Cubic (Linux default):
- 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):
Problem:
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만 활용
Solution: 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)
Checking 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_scalefactorPractical Settings (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 >= BDPPerformance Measurement:
# 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 WindowDiagnosing Performance Problems with 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 활성화
- 애플리케이션 처리 속도 개선
BPF (Berkeley Packet Filter) Syntax:
Basic Structure:
[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
Practical Examples:
1. Communication Between Specific Hosts:
# 양방향
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.202. Network Range:
# 서브넷
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. Port Filtering:
# 단일 포트
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 Flag Filtering:
# 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 Header Filtering:
# 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. Payload Search:
# 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. Compound Filters:
# 외부 → 내부 웹 트래픽 (포트 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)Performance Optimization:
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. Snapshot Length Optimization:
# 헤더만 필요한 경우 (기본값 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. Buffer Size Adjustment:
# 기본 버퍼: 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. Using a Ring Buffer (File Rotation):
# 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. Leveraging Multiple Cores:
# 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 채널 16. Real-Time Analysis vs File Storage:
# 실시간 분석 (화면 출력)
tcpdump -i eth0 -l 'port 80' | grep "GET"
# -l: Line Buffered (즉시 출력)
# 파일 저장 후 분석 (권장)
tcpdump -i eth0 -w capture.pcap 'port 80'
wireshark capture.pcap7. Sampling:
# 1/10 패킷만 캡처 (통계 목적)
tcpdump -i eth0 -w capture.pcap \
'tcp and (tcp[13] & 0x17 = 0x02) and (rand() % 10 = 0)'Advanced BPF Examples:
Web Traffic Analysis:
# 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)'Security Analysis:
# 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'Performance Testing:
# 고속 네트워크 (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)💡 Term Explanation:
- For detailed explanations of the terms used in the packet analysis questions (Q19-Q23) — Ethernet Frame, IP Packet, TCP Segment, MTU/MSS, PMTUD, TCP Window Scaling, BPF, etc. —
- refer to the Consolidated Key Terms > Packet Analysis & Troubleshooting section at the top of the document.