TCP handshake는 양방향 바이트 스트림의 시작 순서 번호와 상대가 그 번호를 받았다는 사실을 맞추는 전송 계층 절차입니다. 연결이 성립했다는 관찰과 TLS·인증·애플리케이션 요청이 성공했다는 관찰을 분리해야 패킷 캡처를 과대해석하지 않습니다.
추적 표에는 각 방향의 SEQ, 상대 방향의 ACK, 그리고 SYN/데이터가 소비한 순서 공간을 별도 열로 둡니다. 이 방식으로 보면 C의 SYN 100은 C→S 공간에서 101을 기대하게 만들고, S의 SYN 300은 S→C 공간에서 301을 기대하게 만듭니다. ACK 값은 패킷 자체를 확인하는 번호가 아니라 다음 바이트 번호라는 점이 핵심입니다.
양방향 시작 순서 번호와 ACK 기준
TCP는 양방향 바이트 흐름이며 각 방향의 순서 번호가 독립적입니다. 클라이언트가 시작 번호 100, 서버가 300을 선택했다고 합시다. SYN은 연결 시작을 알리면서 순서 공간에서 1을 소비합니다. 순수 ACK는 데이터를 담지 않으면 순서 번호를 소비하지 않습니다.
ACK는 “방금 받은 패킷 번호”가 아니라 다음에 기대하는 순서 번호입니다. 따라서 SEQ=100인 SYN을 확인하는 ACK는 101입니다. 실제 초기 번호는 이 예처럼 고정하는 것이 아니며 여기서는 계산을 보여 주기 위한 숫자입니다.
TCP 3단계 Handshake의 메시지 순서
| 단계 | 송신 | 받는 쪽이 알게 되는 것 |
|---|---|---|
| 1 | C→S: SYN, SEQ=100 | 클라이언트 시작 번호 |
| 2 | S→C: SYN+ACK, SEQ=300, ACK=101 | 서버 시작 번호와 클라이언트 SYN 수신 확인 |
| 3 | C→S: ACK, SEQ=101, ACK=301 | 클라이언트가 서버 SYN을 받았음 |
그림을 글로 읽기
- C의 SYN · SEQ 100
- S의 SYN+ACK: SEQ 300 · ACK 101
- C의 ACK: SEQ 101 · ACK 301
- C의 SYN · SEQ 100 → S의 SYN+ACK: 클라이언트 SYN 확인
- S의 SYN+ACK → C의 ACK: 서버 SYN 확인
클라이언트가 SYN+ACK를 받고 마지막 ACK를 보낸 시점과 서버가 그 ACK를 받아 ESTABLISHED가 되는 시점은 다릅니다. 한쪽 캡처만 보고 양쪽 상태가 동시에 완료됐다고 판단하지 않습니다.
마지막 ACK 유실과 SYN-RECEIVED 재전송
서버는 SYN+ACK 후 확인을 못 받으면 SYN-RECEIVED 상태에서 재전송 타이머에 따라 SYN+ACK를 다시 보낼 수 있습니다. 이미 연결된 클라이언트는 다시 ACK로 응답할 수 있습니다. 클라이언트가 보낸 후속 데이터 세그먼트에 올바른 ACK가 실리면 서버의 마지막 확인 역할을 할 수도 있습니다.
확인이 계속 오지 않으면 서버는 제한 시간과 재시도 정책에 따라 반쯤 열린 연결을 정리합니다. timeout 횟수·간격을 모든 OS의 같은 상수로 외우지 말고 실제 스택 설정을 확인합니다. SYN 재전송은 상위 HTTP·주문 재시도와 다른 계층의 동작입니다.
동시 오픈의 SYN-SENT·SYN-RECEIVED 전이
동시 오픈에서는 두 끝점이 모두 능동 오픈해 SYN-SENT에 있을 수 있습니다. 상대의 SYN을 받으면 각자 SYN-RECEIVED로 넘어가 자신의 SYN을 다시 포함한 SYN+ACK로 응답하고, 서로의 시작 번호를 확인해 ESTABLISHED로 진행합니다. 일반적인 passive server의 LISTEN 경로만 TCP의 유일한 시작 방식은 아닙니다.
| 끝점 | 처음 | 상대 SYN 수신 | 자기 SYN 확인 수신 |
|---|---|---|---|
| A | SYN-SENT | SYN-RECEIVED, SYN+ACK | ESTABLISHED |
| B | SYN-SENT | SYN-RECEIVED, SYN+ACK | ESTABLISHED |
중복·재전송 SYN은 현재 상태와 순서 번호를 기준으로 처리해야 합니다. 같은 주소·포트 조합의 과거 세그먼트를 새 연결에 무작정 합치지 않습니다. 실제 도달성은 NAT·방화벽과 스택 지원에도 영향을 받으므로 상태 규칙만으로 모든 네트워크에서 동시 오픈이 성공한다고 보장하지 않습니다.
TCP 연결 수립과 애플리케이션 성공의 경계
handshake는 전송 계층의 순서 동기화입니다. TLS 인증·사용자 인가·요청 프레이밍·DB 커밋을 수행하지 않습니다. 연결 직후 서버 프로세스가 준비되지 않았거나 다음 TLS 검증에서 실패할 수 있습니다.
반쯤 열린 연결은 서버 자원을 사용하므로 SYN 관련 방어·큐·타이머 상한이 필요합니다. 하지만 SYN 큐를 늘리는 것과 애플리케이션 처리 용량을 늘리는 것은 다릅니다. 연결 수립과 수락·실제 요청 완료를 각각 측정합니다.
재현 연습으로 C의 SYN 100, S의 SYN+ACK 300/101, C의 ACK 101/301을 순서대로 기록하면 양 끝이 ESTABLISHED를 관찰하는 시점이 다를 수 있습니다. 마지막 ACK를 버리면 서버는 SYN-RECEIVED에서 SYN+ACK를 재전송하고, 후속 데이터에 올바른 ACK가 있으면 연결이 진행될 수 있습니다. 이 결과를 TLS ClientHello와 분리해 기록해야 handshake 성공을 애플리케이션 성공으로 잘못 진단하지 않습니다.
양 끝 상태와 패킷 캡처의 대조
SYN의 SEQ, 양쪽 ACK, 재전송 시각과 소켓 상태를 연결합니다. 마지막 ACK 유실·중복 SYN·후속 데이터·한쪽 즉시 종료·동시 오픈을 격리된 테스트에서 재현하고, 어떤 시점에 애플리케이션이 연결을 관찰했는지도 기록합니다.
순서 번호 wrap과 실제 스택의 세부 수락 규칙은 프로토콜 구현의 별도 계약입니다. 위 작은 표는 핵심 의미를 설명하는 모형이며 단일 패킷의 관찰을 전체 요청 성공으로 확대하지 않는 것이 중요합니다.