TCP 연결에서 클라이언트가 SYN+ACK을 받은 뒤 마지막 ACK을 보냅니다. 양쪽은 이 과정으로 무엇을 확인하며 마지막 ACK이 유실되면 어떻게 되나요?

TCP 3-way handshake는 양쪽이 서로의 초기 순서 번호를 알고, 양방향으로 세그먼트를 주고받을 수 있음을 확인하는 절차입니다. 클라이언트의 SYN, SEQ=100은 초기 순서 번호를 알리면서 sequence space를 1 소비하고, 서버가 SYN+ACK, SEQ=300, ACK=101을 보내면 자신의 번호와 클라이언트 SYN 수신을 함께 알립니다. 클라이언트의 마지막 ACK=301은 서버 SYN을 확인하며, 데이터가 없는 ACK 자체는 순서 번호를 소비하지 않습니다.

ACK는 다음 기대 번호다

ACK 101은 100번 세그먼트라는 뜻이 아니라 다음에 받고 싶은 번호가 101이라는 뜻입니다. SYN이 sequence space에서 1을 차지하므로 클라이언트의 SYN을 확인하는 값은 101입니다. 서버의 SYN 번호가 300이므로 클라이언트는 301을 확인합니다. 양방향 순서 공간은 독립적이어서 클라이언트가 서버의 SEQ를 ACK했다고 해서 서버가 클라이언트 데이터까지 확인한 것은 아닙니다. 이를 양방향 순서 번호 확인(bidirectional sequence acknowledgment)이라고 설명하겠습니다.

서버는 SYN+ACK를 보낸 뒤 마지막 ACK를 받아야 클라이언트가 자신의 초기 순서 번호를 알고 있다는 것을 확인하고 연결을 Established 상태로 완성합니다. 마지막 ACK가 유실되면 서버는 재전송 타이머에 따라 SYN+ACK를 다시 보낼 수 있고, 클라이언트가 이어서 데이터를 보내면 그 세그먼트의 ACK가 사실상 마지막 확인 역할을 할 수 있습니다. ACK가 계속 오지 않으면 반쯤 열린 상태를 정리합니다. 클라이언트가 SYN을 재전송하면 서버는 현재 상태와 순서 번호를 기준으로 중복을 처리하며, 오래된 세그먼트를 새로운 연결로 무작정 합치지 않습니다.

handshake의 범위를 넘지 않는다

3-way handshake가 끝났다는 것은 전송 계층 연결이 만들어졌다는 뜻이지 애플리케이션 인증, 요청 처리, DB 커밋이 끝났다는 의미가 아닙니다. SYN flood처럼 서버가 많은 반쯤 열린 상태를 보유하게 만드는 공격은 backlog·SYN cookie 같은 별도 방어 문제입니다. 동시 오픈이나 재전송을 분석할 때는 양방향 SEQ·ACK와 TCP 상태 전이를 따로 그리겠습니다.

패킷 캡처에서는 SYN의 SEQ, SYN+ACK의 SEQ와 ACK, 마지막 ACK의 ACK를 각각 확인하고 재전송 타이머와 연결 상태를 함께 봅니다. 마지막 ACK 유실 뒤 서버가 계속 SYN+ACK를 재전송하는지, 클라이언트가 이미 데이터를 보냈는지, 애플리케이션이 연결 직후 닫았는지를 분리합니다. 이후 데이터의 손실·혼잡 제어는 handshake와 별도의 TCP 동작으로 검증하겠습니다.

마지막 ACK가 유실됐을 때 서버가 SYN+ACK를 재전송할 수 있다는 사실은 서버 애플리케이션이 이미 요청을 받을 준비가 됐다는 뜻과 다릅니다. 서버는 반쯤 열린 상태에 타이머와 자원을 사용하고, 클라이언트가 보낸 후속 데이터가 현재 상태·순서 번호에 맞는지 확인합니다. 캡처에서 ACK 번호를 다음 기대 번호로 읽고 SYN의 sequence space 소비를 반영해야 재전송을 중복 데이터로 오해하지 않습니다. SYN flood 방어는 이 handshake 자원 문제를 애플리케이션 인증과 별도의 계층에서 다루겠습니다.

handshake 패킷의 재전송은 상위 메시지 재시도와 다른 수준의 동작입니다. 서버는 SYN backlog와 반쯤 열린 연결의 자원을 제한하고, 연결이 Established가 된 뒤에야 애플리케이션 프레임을 해석합니다. 따라서 장애 분석에서 SYN 재전송 수와 Established 이후 데이터 재전송·응답 지연을 분리해 집계하겠습니다.