SYN → SYN-ACK → ACK 는 머리로는 알겠죠? 근데 캡처 화면에서 그 세 줄을 바로 집어내는 건 또 다른 감각이에요.
TCP 3-way handshake는 왜 세 번이나 주고받을까요?에서는 왜 세 번이나 주고받는지를 큰 그림으로 먼저 봤고, tcpdump 한 줄은 어떻게 읽어야 할까요?에서는 한 줄을 어디부터 읽어야 하는지를 먼저 잡았어요.
근데 막상 캡처 화면을 열면 이런 생각이 들죠.
“좋아요, handshake 자체는 알아요. 근데 이 수많은 줄 중에서 어느 세 줄이 그 handshake고, 어디서부터 읽어야 하죠?”근데 이 글이 진짜 필요한 순간은 캡처를 열고도 handshake를 못 집어낼 때예요.
- 지금 이 세 줄이 정상 연결 시작인지
- 아니면
SYN만 반복되는 재전송 장면인지 - 아니면
SYN-ACK까지는 오는데 마지막 ACK가 안 보여서 어디선가 끊기는지
tcpdump 화면에서 SYN, SYN-ACK, ACK가 실제로 어떻게 찍히는지, 그리고 어디서 끊기면 무엇을 의심해야 하는지까지 같이 볼게요.
여기서는 핸드셰이크 장면을 캡처 위에서 읽는 감각에 집중해요.
tcpdump 명령 옵션 전체를 다시 설명하거나, TCP 헤더의 모든 칸을 다시 해부하지는 않을 거예요. 한 줄 읽기 감각은 tcpdump 한 줄은 어떻게 읽어야 할까요?에서, 헤더 칸 자체는 TCP 헤더는 왜 이렇게 칸이 많을까요?에서 이미 봤으니까요. 여기서는 그걸 실제 장면으로 다시 묶어볼게요.그래서 이 장면은 대체 뭘 보고 있는 걸까요?
이 글에서 보는 건 새로운 프로토콜이 아니에요. 이미 알고 있는 TCP handshake를 캡처 로그 위에서 다시 읽는 장면이에요. 즉 핵심은 이거예요.SYN이 먼저 보이면 누가 먼저 문을 두드렸는지SYN-ACK이 보이면 상대가 그 시작 번호를 어떻게 받았는지- 마지막
ACK이 보이면 이제 데이터가 올라갈 준비가 됐는지
먼저 장면부터 볼까요?
실제 캡처에서는 대개 이런 줄을 만나게 돼요.이 장면에서 먼저 읽어야 할 신호 네 가지
장면 해석형 글에서는 “뭘 먼저 봐야 하지?” 가 제일 중요하잖아요. 이 handshake 장면에서는 우선 이 네 가지부터 보면 돼요.- 누가 먼저 시작했는지 —
Flags [S]를 누가 먼저 보냈는지 ack가 왜 1 늘어나는지 —SYN이 sequence 공간을 1칸 쓰기 때문- 옵션이 무엇을 같이 협상하는지 —
mss,wscale,sackOK,TS - 세 줄 사이 간격이 자연스러운지 — 재전송인지, 응답 지연인지
한 줄씩 뜯어보면 이렇게 읽어요
같은 세 줄을 표로 펼치면 더 또렷해져요.
여기서 숫자는 일부러 상대 번호(relative sequence number) 느낌으로 단순화해서 썼어요. 실제 환경에서는 절대 sequence 번호가 훨씬 크게 보일 수도 있지만, 초반에는
SYN 뒤엔 ack 가 1 늘어난다는 흐름만 읽혀도 충분해요. 이 감각은 RFC 9293 3.4절과 3.5절에서 설명하는 핵심이기도 해요.
ack = 1 은 왜 이렇게 자주 보일까요?
이건 초심자가 handshake 캡처에서 가장 자주 멈추는 지점이에요.
기본편에서도 봤지만, 다시 한 번 연결해볼게요.
- 클라이언트가
SYN을 보냄 SYN자체가 sequence 공간을 1칸 차지함- 그래서 서버는
ack 1로 답함
ACK 는 단순히 “받았어요” 가 아니라, “나는 다음엔 그다음 번호를 기대해요” 에 더 가까워요. 이 해석이 바로 캡처 읽기의 중심이에요.
여기서는 범위를 한 번만 나눠둘게요.
여기서는seq,ack의 캡처 위 해석에 집중할게요. 그 숫자 칸이 TCP 헤더 몇 번째 줄에 있는지는 TCP 헤더는 왜 이렇게 칸이 많을까요?에서 다시 펼쳐볼 수 있어요.
옵션은 왜 첫 두 줄에 몰려 있을까요?
핸드셰이크 줄을 보면mss 1460, sackOK, TS, wscale 7 같은 옵션이 유난히 눈에 띄죠.
이건 단순 장식이 아니에요. 앞으로 데이터를 어떤 규칙으로 주고받을지 초반에 같이 맞추는 과정이거든요.
mss 1460— 한 세그먼트에 어느 정도까지 실을지wscale 7— 윈도우 값을 나중에 얼마나 크게 해석할지sackOK— 중간에 빠진 조각을 더 똑똑하게 복구할 수 있는지TS— 타임스탬프 옵션을 쓸지
Window Scale 은 핸드셰이크에서만 합의되기 때문에, 이 세 줄을 놓치면 나중에 캡처에서 보이는 윈도우 값을 잘못 읽기 쉬워요.
다만 여기서도 한 가지는 꼭 같이 기억하면 좋아요.
어떤 옵션을 실제로 붙이는지는 운영체제와 구현마다 조금씩 달라질 수 있어요. 그러니까 옵션 목록이 완전히 같지 않다고 해서 곧장 이상하다고 읽지는 않아요.그리고
wscale 값은 양쪽이 똑같아야 하는 공용 숫자라고 생각하면 안 돼요. 클라이언트와 서버가 각자 자기 방향 Window를 어떻게 키워 읽어달라는지 따로 알릴 수도 있어요.
어디서 끊기면 무엇을 의심할까요?
핸드셰이크 캡처가 진짜 빛나는 순간은, 연결이 안 열릴 때 어디서 멈췄는지 보여줄 때예요.1. SYN 만 반복해서 보이고 SYN-ACK 가 안 와요
- 서버가 진짜 응답을 못 했을 수도 있고
- 중간 방화벽이나 네트워크가 막았을 수도 있고
- 캡처 위치상 돌아오는 패킷을 못 보고 있을 수도 있어요
2. SYN-ACK 까지는 보이는데 마지막 ACK 가 안 보여요
- 클라이언트가 응답을 못 받았을 수도 있고
- 중간 경로에서 마지막 ACK가 사라졌을 수도 있고
- 내가 보는 캡처 위치가 한쪽 방향만 담고 있을 수도 있어요
3. 세 줄은 끝났는데 바로 RST 가 보여요
핸드셰이크는 열렸지만, 그다음 애플리케이션이나 중간 장비가 즉시 연결을 접어버리는 장면일 수 있어요. 즉 “연결 열기 실패” 와 “열리긴 했지만 곧장 끊김” 은 완전히 다른 문제예요.
이 차이를 읽으려면 TCP 플래그는 어떻게 읽어야 할까요?에서 봤던 RST 감각이 같이 필요해져요.
근데 왜 handshake를 캡처 위에서 이렇게까지 읽어야 할까요?
1. 누가 먼저 시작했는지 바로 보여줘요
기본편에서는 클라이언트가 먼저SYN 을 보낸다고 배웠죠. 캡처에서는 그게 실제 어느 IP와 어느 포트였는지까지 바로 보여줘요. 즉 이야기의 주어가 훨씬 선명해져요.
2. 연결이 안 되는 문제를 좁히기 쉬워져요
SYN 만 가는지, SYN-ACK 까지는 오는지, 마지막 ACK 까지 끝나는지에 따라 막힌 위치 후보가 꽤 달라져요.
3. 뒤에서 보는 재전송, 윈도우, 종료 장면의 출발점이 돼요
재전송,TIME-WAIT, RST, 윈도우 크기 해석도 결국은 이 연결이 처음 어떻게 열렸는지 위에 서 있어요. 그래서 핸드셰이크를 캡처에서 읽는 감각은 뒤의 모든 TCP 장면 해석의 출발점이 돼요.
잘못 읽기 쉬운 함정 다섯 가지
하나,SYN 만 보이면 무조건 서버 장애라고 단정하기.아니에요. 서버, 방화벽, 라우팅, NAT, 캡처 위치 문제까지 다 가능해요. 둘,
ack = 1 을 “패킷 한 개 받았어요” 로 읽기.더 정확히는 sequence 공간에서 다음으로 기대하는 번호예요. 셋, 옵션이 많이 붙으면 이상한 트래픽이라고 생각하기.
오히려 MSS, Window Scale, Timestamp 같은 건 아주 흔한 handshake 옵션이에요. 넷,
length 0 이면 아무 일도 없다고 생각하기.핸드셰이크의 핵심 신호는 오히려
length 0 인 경우가 많아요.
다섯, 캡처에 안 보이면 실제로도 안 일어났다고 믿기.캡처는 어디서 잡았는지에 따라 빠진 방향이나 빠진 패킷이 있을 수 있어요. 그래서 보이는 장면과 실제 전체 장면을 늘 같은 것으로 놓으면 안 돼요.
자, 정리해볼까요?
tcpdump위의 handshake는 결국Flags [S]→Flags [S.]→Flags [.]세 줄로 읽히는 경우가 많아요.- 이 장면에서는 누가 먼저 시작했는지,
ack가 왜 1 늘어나는지, 어떤 옵션을 같이 협상하는지, 세 줄 사이 간격이 자연스러운지를 먼저 보면 좋아요. SYN만 반복되는지,SYN-ACK까지만 보이는지, 세 줄 뒤 바로RST가 붙는지에 따라 문제 해석이 달라져요.length 0은 “빈 패킷”이 아니라, 제어 신호만 오가는 중요한 장면일 수 있어요.- 캡처 해석은 플래그만 보는 일이 아니라, 방향 · 숫자 · 옵션 · 위치를 같이 읽는 일이에요.
이어서 보면 좋은 글
SYN,SYN-ACK,ACK자체를 큰 그림으로 다시 보고 싶다면 — TCP 3-way handshake는 왜 세 번이나 주고받을까요?Flags [S],Flags [S.],Flags [R]같은 표기를 장면별로 더 읽고 싶다면 — TCP 플래그는 어떻게 읽어야 할까요?- 핸드셰이크에서 보였던
wscale옵션이 뒤 Window 해석에 어떤 뜻이 되는지 이어서 보고 싶다면 — TCP 윈도우와 흐름 제어는 왜 같이 읽어야 할까요? - 한 줄 자체를 시간, 방향, 주소 순서로 먼저 읽는 감각을 다시 잡고 싶다면 — tcpdump 한 줄은 어떻게 읽어야 할까요?
SYN-SENT,SYN-RECEIVED,ESTABLISHED같은 내부 상태 변화까지 같이 보고 싶다면 — TCP 상태 머신: 연결의 탄생부터 소멸까지의 일대기