요약

  • TCP는 항상 32비트 확인 응답 번호 저장 공간을 담고 있지만, ACK 플래그가 해당 필드의 유효성을 결정합니다.
  • ACK가 설정되면 이 숫자는 다음에 기대되는 시퀀스 번호를 가리키며, 이전의 모든 시퀀스 위치를 누적적으로 확인 응답합니다.
  • 3방향 핸드셰이크는 이 규칙을 눈에 보이는 전환으로 만듭니다. 최초의 SYN에는 유효한 확인 응답이 없지만, 돌아오는 SYN,ACK의 확인 응답 번호는 의미를 갖습니다.

필드는 존재하면서도 말하지 않을 수 있다

TCP 헤더는 연결 상태마다 새로 조립되지 않습니다. 확인 응답 번호 필드는 최초 SYN, 데이터 세그먼트, 종료 교환 모두에서 동일한 32비트를 차지합니다. 그러나 RFC 793과 그 현대적 대체 규격인 RFC 9293은 수신 측에 이 비트들을 무조건 해석하라고 지시하지 않습니다. 두 규격 모두 검사 조건을 붙입니다. ACK 제어 비트가 설정되어 있다면, 그 필드는 송신 측이 수신을 기대하는 다음 시퀀스 번호를 담고 있습니다.

이 조건부 구조가 바로 메커니즘입니다. 필드의 위치는 숫자를 어디에서 찾을 수 있는지를 알려주고, ACK 비트는 그 숫자가 현재 의미를 갖는지를 알려줍니다. RFC 9293은 ACK를 "확인 응답 필드가 유효하다"로 정의함으로써 이 관계를 특히 간결하게 표현합니다. 이 비트는 단순히 패킷에 어렴풋한 확인 응답 관련성 라벨을 붙이는 것이 아니라, 이웃한 고정 폭 필드에 의미적 힘을 부여합니다.

이 구분은 피어들이 시퀀스 공간을 동기화하기 전에 가장 중요합니다. 능동 개시를 시작하는 호스트는 피어의 것을 받기 전에 자신의 초기 시퀀스 번호를 알릴 수 있습니다. 헤더에는 여전히 확인 응답 번호 공간이 있지만, 아직 확인 응답할 피어 시퀀스가 없습니다. 따라서 TCP는 더 짧은 별도의 SYN 헤더나 특별한 확인 응답 값이 필요하지 않고, ACK를 설정하지 않은 채로 둡니다.

핸드셰이크는 유효성을 관찰 가능하게 만든다

RFC 9293의 기본 3방향 핸드셰이크 추적은 한 피어가SEQ=100과CTL=SYN을 보내는 것으로 시작합니다. 첫 세그먼트에는 ACK 플래그가 없습니다. 피어는SEQ=300,ACK=101,CTL=SYN,ACK으로 답합니다. 101이라는 숫자가 의미를 갖는 이유는 ACK가 설정되어 있기 때문입니다. 즉, 시퀀스 100이 수신되었고 다음으로 101이 기대된다는 뜻입니다.

이 1의 증가는 TCP 회계의 또 다른 부분을 드러냅니다. SYN은 응용 데이터 옥텟이 아니더라도 시퀀스 공간에서 한 위치를 소비합니다. 초기 시퀀스 번호 100을 받은 피어는 101을 요청함으로써 이를 확인 응답합니다. 세 번째 단계는 증거의 방향을 뒤집습니다.SEQ=101,ACK=301,CTL=ACK을 담아 상대 피어의 SYN을 확인하고 양쪽을 확립 상태로 옮깁니다.

하나의 고정 헤더 레이아웃이 이제 의미적 경계를 넘었습니다. 첫 세그먼트에서 확인 응답 번호 비트는 유효하지 않습니다. 답신에서는 단 하나의 플래그가 이를 피어 상태의 근거로 활성화합니다. 마지막 단계와 확립 이후에는 확인 응답이 더 이상 예외가 아닙니다. 규격은 연결이 확립되면 항상 전송된다고 말합니다.

숫자는 영수증이 아니라 경계선을 가리킨다

확인 응답 번호는 다음에 기대되는 시퀀스 번호입니다. RFC 9293 용어집에서 이는 ACK가 누적적임을 의미합니다. 즉, 이전의 모든 시퀀스 번호의 수신을 확인 응답합니다. 이 필드는 수신된 모든 세그먼트를 열거하지 않으며, 응용 프로그램이 바이트를 처리했음을 증명하지도 않습니다. 이 필드는 이 세그먼트의 TCP 송신 측이 표현하는 수신 측의 연속적 시퀀스 경계선을 표시합니다.

이 경계는 간결합니다. 하나의 32비트 값이 목록을 실지 않고도 이전 시퀀스 위치의 범위를 포괄할 수 있습니다. 그 범위도 의도적으로 제한되어 있습니다. ACK는 전송 계층의 시퀀스 상태를 보고할 뿐, 암호학적 인증도, 응용 수신 확인도, 이후 바이트의 도착을 약속하는 것도 아닙니다.

윈도우 필드가 이 논리 옆에 놓여 있습니다. 윈도우는 확인 응답 필드가 가리키는 옥텟부터 세그먼트 송신 측이 얼마나 많은 데이터 옥텟을 수용할 의사가 있는지를 설명합니다. 따라서 두 필드는 관련되지만 서로 다른 사실을 표현합니다. 하나는 다음 기대 시퀀스 위치를 식별하고, 다른 하나는 그 위치로부터의 수용 용량을 알립니다. ACK 플래그는 확인 응답 필드를 유효하게 만드는 명시적 스위치로 남습니다.

ACK가 ACK를 무한히 낳지 않는 이유

TCP의 시퀀스 공간은 데이터 옥텟을 세며, SYN과 FIN에 각각 한 위치를 부여합니다. ACK는 시퀀스 번호를 차지하지 않습니다. RFC 9293은 이 설계를 특유의 직설로 설명합니다. ACK가 시퀀스 공간을 소비한다면, 피어들은 결국 확인 응답에 대한 확인 응답을 하게 될 것입니다.

이 배제는 가능한 재귀를 끊습니다. 세그먼트는 자신이 전송되었다는 사실만으로 또 다른 시퀀스 공간 의무를 만들지 않으면서도 새로운 누적 확인 응답 근거를 실을 수 있습니다. 데이터 또는 SYN과 FIN은 시퀀스 회계를 진행할 수 있지만, ACK 플래그 자체는 그러하지 않습니다.

덕분에 확립된 TCP는 일반 트래픽에 확인 응답 상태를 결합할 수 있습니다. 데이터를 담은 세그먼트는 ACK도 함께 담을 수 있고, 데이터 없는 세그먼트도 피어의 수신 경계선 관점을 갱신할 수 있습니다. 확인 응답 정보는 플래그가 설정되어 있기 때문에 의미를 유지하지만, 그 전송이 자체 확인 응답을 요구하는 새로운 바이트나 제어 위치를 만들어내지는 않습니다.

1981년부터 현행 표준까지의 연속성

RFC 793은 1981년에 동일한 핵심 계약을 규정했습니다. 32비트 확인 응답 번호, ACK 설정 시에만 유효, 확립 이후 항상 전송, 그리고 ACK 자체는 시퀀스 공간을 차지하지 않음. RFC 9293은 TCP를 현행 인터넷 표준으로 재진술하면서 이 구조를 그대로 유지합니다.

이 연속성이 역사적으로 중요한 이유는, 이후의 확인 응답 알고리즘들이 그 아래에 있는 더 단순한 아키텍처적 선택을 가릴 수 있기 때문입니다. 지연 확인 응답은 근거가 언제 전송되는지를 다룹니다. 선택적 확인 응답은 불연속 수신에 대한 정보를 추가합니다. 재전송 로직은 송신 측이 어떻게 반응하는지를 결정합니다. 그러나 그 어떤 질문도 여기서 검토하는 헤더 수준의 규칙을 대체하지 않습니다. 기본 확인 응답 번호는 ACK가 그 유효성을 표시할 때만 권위를 갖습니다.

결과는 소박하지만 내구성이 있습니다. TCP는 필드의 존재만으로 유효한 상태를 흉내 내지 못하게 했습니다. 고정 폭 숫자에 명시적 유효성 비트를 결합하고, 피어가 보고할 시퀀스 상태를 갖는 정확한 시점에 확인 응답이 활성화되도록 핸드셰이크를 설계했습니다.

출처