📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 130편
이전 글: 129. Sequence Number 분석 · 다음 글: 131. TCP Retransmission
1. 개념
ACK Number가 "다음에 받을 바이트 번호"라는 정의와 Sequence Number와의 관계는 46. 시퀀스 번호·ACK·윈도우 — TCP가 데이터를 빠짐없이 전달하는 방법에서 다뤘습니다. 이 글은 Wireshark 화면에서 ACK Number를 읽고, 그 ACK가 무엇을 확인했는지 추적하는 방법에 집중합니다.
| Wireshark 필드 | 의미 | 분석 시 쓰임 |
|---|---|---|
tcp.ack | 상대 번호(relative) ACK 값 | 기본 표시값, 흐름을 읽기 쉬움 |
tcp.ack_raw | 헤더에 실제로 들어 있는 32비트 값 | 다른 캡처·장비 로그와 대조 |
tcp.flags.ack | ACK 플래그 | 1일 때만 ACK 필드가 유효 |
tcp.nxtseq | 상대가 보낸 세그먼트의 "다음 seq" 계산값 | 정상 ACK는 이 값과 일치 |
Wireshark가 추가로 계산해 주는 [SEQ/ACK analysis] 항목도 함께 봅니다.
| 계산 필드 | 의미 |
|---|---|
tcp.analysis.acks_frame | 이 ACK가 확인한 세그먼트의 프레임 번호 |
tcp.analysis.ack_rtt | 그 세그먼트 전송부터 이 ACK까지 걸린 시간 |
tcp.analysis.initial_rtt | Handshake 기준 초기 RTT(iRTT) |
tcp.analysis.ack_lost_segment | 캡처에 없는 세그먼트를 확인한 ACK ("ACKed unseen segment") |
2. 동작 원리
Wireshark가 ACK를 해석하는 순서입니다.
세그먼트 수신 (tcp.flags.ack == 1)
↓
같은 tcp.stream의 반대 방향 세그먼트 목록 조회
↓
tcp.ack 값 == 어떤 세그먼트의 tcp.nxtseq ?
├─ 예 → acks_frame = 그 프레임, ack_rtt = 두 시각의 차
├─ 이전 ACK와 같은 값 → Dup ACK 후보 (132편)
└─ 캡처에 없는 범위까지 확인 → ACKed unseen segment
↓
Info 열과 Expert Info에 결과 표시- ACK는 누적 확인입니다.
tcp.ack= 5001이면 1~5000바이트를 모두 받았다는 뜻이므로, 세그먼트 두 개를 한 번에 확인하는 경우가 흔합니다. 이때acks_frame은 마지막 세그먼트를 가리킵니다. - 수신 측은 ACK를 바로 보내지 않고 잠시 모았다 보내는 지연 ACK를 사용할 수 있습니다. 지연 시간과 규칙은 OS마다 다르므로
ack_rtt가 네트워크 지연만을 뜻하지는 않습니다. - 상대 번호는 Handshake(SYN)를 봐야 0 기준을 잡을 수 있습니다. 연결 중간부터 캡처하면 첫 패킷 기준으로 계산됩니다.
3. 주요 특징
상황별 ACK 값의 모습 (상대 번호 기준)
| 상황 | seq | ack | 읽는 법 |
|---|---|---|---|
| SYN | 0 | 0 (ACK 플래그 없음) | 확인할 대상이 아직 없음 |
| SYN/ACK | 0 | 1 | SYN이 번호 1개를 소비 |
| 요청 100바이트 후 서버 ACK | 1 | 101 | 1~100 수신 완료 |
| FIN 수신 후 ACK | — | 상대 seq + 1 | FIN도 번호 1개를 소비 |
| 닫힌 포트의 RST/ACK | 0 | SYN의 seq + 1 | 연결 거부 응답 (127. RST Packet 분석) |
ACK 관련 Expert Info
| Info 표시 | 조건 | 흔한 원인 |
|---|---|---|
[TCP ACKed unseen segment] | 캡처에 없는 데이터를 확인 | 캡처 누락, 중간부터 캡처, 비대칭 경로 |
[TCP Dup ACK N#M] | 같은 ACK 반복 | 손실·순서 뒤바뀜 (132. Duplicate ACK) |
[TCP Window Update] | ACK 값은 같고 윈도우만 변경 | 수신 버퍼 여유 알림 (정상) |
| ACK 플래그 없이 ACK 필드가 0이 아님 | 헤더 조합 불일치 | 도구로 만든 패킷일 가능성 |
4. 예시
실습 예시 — 본인 소유 VM 두 대(클라이언트 192.168.10.20, 서버 192.168.10.10)에서 짧은 HTTP 요청을 캡처합니다. 명령과 출력은 예시(값은 환경마다 다름)입니다.
sudo tcpdump -i ens33 -nn -w /tmp/ack.pcapng 'tcp port 80' &
curl -s http://192.168.10.10/ -o /dev/null
sudo pkill -INT tcpdump
# ACK가 확인한 프레임과 RTT
tshark -r /tmp/ack.pcapng -Y 'tcp.analysis.acks_frame' -T fields -E header=y \
-e frame.number -e ip.src -e tcp.seq -e tcp.ack -e tcp.ack_raw \
-e tcp.analysis.acks_frame -e tcp.analysis.ack_rtt
# 캡처 누락 의심 ACK만
tshark -r /tmp/ack.pcapng -Y 'tcp.analysis.ack_lost_segment' -T fields \
-e frame.number -e tcp.stream -e ip.src -e tcp.ack(tshark 패키지: Rocky wireshark-cli, Ubuntu tshark)
형식 예시입니다.
frame.number ip.src tcp.seq tcp.ack tcp.ack_raw acks_frame ack_rtt
2 192.168.10.10 0 1 3150211437 1 0.000412
3 192.168.10.20 1 1 2847716002 2 0.000233
5 192.168.10.10 1 79 3150211515 4 0.000187| 확인 포인트 | 읽는 법 |
|---|---|
| 프레임 5의 ack 79 | 클라이언트 요청 78바이트(seq 1~78)를 모두 받음 |
acks_frame 4 | 확인 대상이 프레임 4의 요청 세그먼트 |
ack_raw | 실제 헤더 값. 다른 캡처 파일과 대조할 때 사용 |
📷 [실습 화면 삽입 위치] 서버 응답 패킷의 Details에서 Acknowledgment number와
[SEQ/ACK analysis](This is an ACK to the segment in frame, The RTT to ACK the segment was)를 펼친 화면
5. 보안 관점
| 관찰 | 가능한 해석 | 확인할 것 |
|---|---|---|
| ACK 플래그만 단독으로 여러 포트에 도착, Handshake 없음 | ACK 스캔 등 필터링 여부 탐색 (222. ACK Scan) | 응답 RST의 유무와 출발지 분포 |
| ACK 값이 흐름과 동떨어진 RST·데이터 | 경로상 삽입 패킷 가능성 | ip.ttl, ip.id가 앞뒤 패킷과 같은가 |
ack_rtt가 특정 목적지에서만 급증 | 경로 장비 지연, 인라인 장비 검사 지연 | 같은 시간대 다른 목적지와 비교 |
| ACKed unseen segment 대량 | 미러링 누락 → 분석 근거 약화 | 캡처 지점 드롭 통계 |
6. SOC 관점
| 흔적 위치 | 확인할 수 있는 것 |
|---|---|
| 패킷 캡처 | ACK 값, 확인 대상 프레임, RTT |
| 방화벽 세션 로그 | 세션 생성 없이 들어온 ACK 차단(상태 불일치) 기록 |
| IDS | 상태 없는 ACK·비정상 플래그 이벤트 |
관제자가 확인할 질문
- 이 ACK가 확인한 데이터가 캡처에 실제로 존재하는가?
- ACK 값이 같은 스트림의 seq 흐름과 연속되는가?
- 응답 지연(
ack_rtt)이 네트워크 문제인지, 서버 처리 지연인지?
오탐 주의: 중간부터 시작된 캡처, 비대칭 라우팅, SPAN 과부하에서는 ACKed unseen segment가 대량으로 보여도 공격이 아닙니다. 방화벽의 상태 불일치 차단 로그도 세션 타임아웃 이후 도착한 정상 ACK인 경우가 많으므로 먼저 세션 종료 시각과 비교합니다.
7. 핵심 정리
tcp.ack는 상대 번호,tcp.ack_raw는 헤더 실제 값이며, ACK 플래그가 있을 때만 의미가 있습니다.- 정상 ACK는 반대 방향 세그먼트의
tcp.nxtseq와 일치하고, Wireshark는 이를acks_frame·ack_rtt로 보여 줍니다. - ACK는 누적 확인이고 지연 ACK가 있으므로, 한 ACK가 여러 세그먼트를 확인하는 것은 정상입니다.
- ACKed unseen segment는 대부분 캡처 누락이므로 캡처 지점과 드롭 여부를 먼저 확인합니다.
- Handshake 없는 단독 ACK, 흐름과 맞지 않는 ACK 값은 스캔·삽입 패킷 판단의 단서가 됩니다.
