패킷 분석
tcpdump와 Wireshark로 트래픽을 캡처·필터링하고 프로토콜 필드와 패킷 순서를 따라 실제 통신 장애를 분석합니다.
지금까지 ping, traceroute, curl 같은 도구로 네트워크 상태를 확인했습니다.
이 도구들은 연결이 되는가, 응답이 오는가를 알려주지만, 실제로 어떤 패킷이 오가는지는 보여주지 않습니다.
패킷 분석은 캡처된 프레임과 프로토콜 필드를 기준으로 통신 흐름을 직접 확인하는 진단 방법입니다.
tcpdump — 커맨드라인 패킷 캡처
tcpdump는 Linux/macOS에서 사용하는 커맨드라인 패킷 캡처 도구입니다.
# 80번 포트의 모든 트래픽 캡처
sudo tcpdump -i eth0 port 80
# 특정 호스트와의 통신만 캡처
sudo tcpdump -i eth0 host 192.168.1.100
# 캡처 내용을 파일로 저장 (Wireshark로 열기 가능)
sudo tcpdump -i eth0 -w capture.pcap port 443
# 저장된 파일 읽기
tcpdump -r capture.pcap유용한 필터 조합들이 있습니다.
# SYN 플래그가 켜진 패킷 캡처 (SYN, SYN-ACK 모두 포함)
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'
# ACK 없이 SYN만 있는 패킷 (ECN 플래그가 붙어도 최초 연결 시도에 가까움)
sudo tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'
# DNS 관련 53번 트래픽 캡처 (질의와 응답 모두 포함)
sudo tcpdump -i eth0 port 53
# UDP DNS 질의 방향만 좁혀 보기
sudo tcpdump -i eth0 'udp dst port 53'
# 특정 서브넷의 트래픽만 캡처
sudo tcpdump -i eth0 net 10.0.0.0/24
# RST 패킷 캡처 (연결 거부/리셋)
sudo tcpdump -i eth0 'tcp[tcpflags] & tcp-rst != 0'
# 패킷 내용을 ASCII로 표시 (HTTP 디버깅)
sudo tcpdump -i eth0 -A port 80
# 패킷 내용을 헥스+ASCII로 표시
sudo tcpdump -i eth0 -X port 80Wireshark — GUI 패킷 분석
Wireshark는 세계에서 가장 널리 사용되는 패킷 분석 도구입니다.
capture filter는 캡처 단계에서 저장할 패킷을 줄이고, display filter는 저장된 패킷 중 화면에 보일 항목을 고릅니다. Wireshark도 capture filter를 지원하며, tcpdump의 필터는 -r로 파일을 읽을 때도 적용할 수 있습니다. 두 문법을 섞지 않아야 합니다.
디스플레이 필터로 원하는 패킷만 골라볼 수 있습니다.
| 목적 | 표시 필터와 범위 |
|---|---|
| POST | http.request.method == "POST" — HTTP로 해석된 요청 |
| SYN | tcp.flags.syn == 1 — SYN-ACK도 포함 |
| IPv4 주소 | ip.addr == 192.168.1.100 — 양방향 IPv4 주소 일치; IPv6는 별도 필드 |
| TCP 443 | tcp.port == 443 — 양방향 TCP 포트; QUIC의 UDP 443은 제외 |
| DNS 이름 | dns.qry.name contains "example" — 해당 문자열이 든 질의 이름 |
| 재전송 추정 | tcp.analysis.retransmission — 분석기가 추정한 재전송 표시 |
| 제로 윈도 | tcp.analysis.zero_window — 광고된 수신 윈도 0 |
| HTTP 오류 | http.response.code >= 400 — HTTP로 해석된 오류 응답 |
실전 패킷 분석 예시
HTTP 요청 추적: 평문 HTTP/1.x 연결에서 "Follow → TCP Stream"으로 양방향 바이트 내용을 따라갈 수 있습니다. 개별 패킷의 재전송·정확한 시각은 패킷 목록에서 따로 확인합니다. HTTP/2·QUIC은 해당 프로토콜의 Follow 기능과 하위 스트림 선택을 사용해야 여러 스트림을 구분하기 쉽습니다.
단, HTTPS 트래픽은 복호화 키가 없으면 HTTP 본문이 아니라 TLS 레코드만 보입니다.
TLS 문제 진단: HTTPS는 암호화되어 있어 내용을 볼 수 없지만, TLS 핸드셰이크의 일부 메타데이터는 볼 수 있습니다.
Client Hello의 지원 버전과 암호 스위트, SNI(단 ECH가 없을 때), Server Hello의 선택 결과를 확인할 수 있습니다.
TLS 1.3에서는 인증서 메시지도 핸드셰이크 보호 구간에 들어가므로, 모든 인증서 내용이 항상 평문으로 보인다고 생각하면 안 됩니다.
자주 만나는 문제 사례
| 관측 | 해석과 다음 확인 |
|---|---|
| SYN 뒤 RST | 리스너 부재 또는 거부 정책 등의 단서입니다. ss -tlnp와 대상·중간 장비 로그를 확인합니다. |
| SYN만 반복 | 캡처 지점에서 응답을 보지 못했습니다. DROP·손실·라우팅·호스트·반환 경로를 비교합니다. |
| 재전송 표시 다수 | 전송 손실 후보이지만 순서 뒤바뀜·캡처 누락·분석 추정도 구분해야 합니다. |
| 502와 상위 RST | 해당 실패에서 상위 연결 리셋을 대조합니다. 모든 502가 RST에서 생기는 것은 아닙니다. |
| DNS 응답 지연 | 질의·재시도·응답 시각으로 서버 처리와 경로 손실 등의 후보를 좁힙니다. |
| 윈도 0 광고 | 수신자가 추가 데이터를 받을 여유가 없다고 알립니다. 버퍼·애플리케이션 읽기·부하를 조사하며 CPU 문제로 단정하지 않습니다. |
네트워크 트러블슈팅의 핵심은 추측하지 않고 확인하는 것입니다.
아마 방화벽 문제일 거야가 아니라, 패킷을 캡처하여 SYN이 나갔는데 응답이 없으니 방화벽 DROP, 라우팅 문제, 호스트 다운, 반환 경로 문제를 순서대로 의심해야 한다고 판단하는 것입니다.
캡처는 인터페이스·방향·시각·필터·손실 통계를 함께 기록해야 비교할 수 있습니다. 암호화된 페이로드나 캡처 지점 밖의 사건을 추정과 섞지 말고, 공유 파일에 인증 정보·개인 데이터가 포함됐는지도 확인합니다.