요약

  • TCP Data Offset는 헤더 전체를 32비트 단위로 세기 때문에 첫 데이터 옥텟의 위치를 권위 있게 알려줍니다.
  • End of Option List는 옵션 해석을 멈추고, 남은 헤더 옥텟은 모두 0으로 채워진 패딩입니다. EOL도 패딩도 애플리케이션 데이터가 아닙니다.
  • NOP은 정렬에 도움을 줄 수 있지만, 수신자는 옥텟 경계 어느 위치에서든 옵션을 해석할 준비가 되어 있어야 하며 모든 발신자가 정렬했다고 가정할 수 없습니다.

가장 작은 TCP 헤더는 32비트 단위 5개를 차지합니다. 포트, 시퀀스 및 확인 응답 번호, 플래그, 윈도우, 체크섬, 긴급 포인터가 20옥텟을 채웁니다. 옵션이 있으면 헤더 길이가 가변적으로 변합니다. 옵션이 존재하는 순간, 수신자는 옵션 영역 내부의 모든 기능을 이해하지 못하더라도 모호하지 않은 외부 경계를 필요로 합니다.

RFC 793은 이 역할에 4비트를 배정했습니다. Data Offset는 바이트 위치가 아니며 옵션만 세지도 않습니다. 오히려 TCP 헤더 전체의 32비트 단위 수를 나타냅니다. 이 값에 4를 곱하면 데이터가 시작되는 옥텟 위치가 됩니다. 값이 5이면 기본 20옥텟 헤더를 의미합니다. 더 큰 값은 옵션과 32비트 단위를 완성하는 데 필요한 패딩을 포함합니다.

이 단위는 컴팩트한 절충안이었습니다. 4비트는 최대 15개 단위까지 표현할 수 있으므로, 직접 표현되는 헤더는 최대 60옥텟에 도달할 수 있습니다. 이 필드는 공간을 거의 소모하지 않으면서, 단위 기반 의미 덕분에 데이터 경계가 헤더 형식에 맞춰 정렬됩니다. 수신자는 페이로드가 어디서 시작되는지 알아내기 위해 옵션의 길이를 더할 필요가 없습니다.

이러한 분리가 중요한 이유는 옵션 목록에 자체적인 끝이 있기 때문입니다. End of Option List는 더 이상 옵션이 뒤따르지 않는다고 알리는 1옥텟 옵션입니다. 이는 Data Offset이 보고하는 헤더 끝과 반드시 일치할 필요가 없습니다. 공간이 남으면 RFC 9293에 따라 EOL 이후의 옥텟은 0으로 채워진 헤더 패딩이어야 합니다. 데이터는 EOL 바이트 바로 다음이 아니라 Data Offset 경계에서만 시작됩니다.

No-Operation은 다른 파싱 요구에 답합니다. 역시 1옥텟이며, 예를 들어 이후의 옵션을 단위 경계에 맞추기 위해 옵션 사이에 나타날 수 있습니다. 하지만 정렬은 편의 사항이지 보장이 아닙니다. 옵션은 임의의 옥텟 경계에서 시작할 수 있으며, 수신자는 그 위치에서 옵션을 처리할 준비가 되어 있어야 합니다. 정렬을 가정하고 건너뛰는 파서는 프로토콜이 절대 보장하지 않은 관행을 읽고 있는 것입니다.

다른 대부분의 옵션은 종류(kind)와 길이(length)를 모두 담고 있습니다. 길이는 종류 바이트, 길이 바이트, 옵션 데이터를 모두 포함하여 셉니다. 이 자기 서술 덕분에 수신자는 길이가 합법적이라면 구현하지 않은 옵션을 건너뛸 수 있습니다. RFC 9293은 임의의 세그먼트에서 옵션을 수신하는 것을 지원할 것을 요구하고, 알려지지 않은 형식이 올바른 옵션은 오류 없이 무시할 것을 요구합니다. 확장성은 의미가 낯설더라도 문법을 보존하는 데 달려 있습니다.

Data Offset는 그 순회의 상한선을 제공합니다. RFC 9293은 DOffset이 5를 초과할 때 옵션 영역을(DOffset-5)*32비트로 표현하며, 이 수치에 뒤따르는 패딩이 포함된다고 명시합니다. 옵션 길이는 그 외부 경계를 넘어 읽을 권한을 합법적으로 부여할 수 없습니다. 반대로 EOL은 경계 이전에 옵션 해석을 멈출 수 있으며, 남은 바이트는 여전히 헤더의 일부입니다.

옵션과 패딩을 포함한 그 모든 헤더 옥텟은 TCP 체크섬에 참여합니다. 따라서 패딩은 보이지 않는 필러가 아니지만, 여전히 애플리케이션 데이터는 아닙니다. 이 구분은 파싱과 무결성을 모두 보호합니다. 수신자는 어떤 옥텟이 헤더 계산에 속하고 어떤 옥텟이 TCP 위로 전달되는 바이트 스트림의 시작인지 알 수 있습니다.

이 설계는 오류 처리도 분담시킵니다. 유효한 길이를 가진 지원되지 않는 옵션은 건너뛸 수 있습니다. 불법적인 길이는 파서가 안전하게 진행할 수 있는 능력을 위협합니다. RFC 9293은 구현체가 이를 처리할 것을 요구하며, 연결 재설정과 원인 기록을 제안 절차로 제시합니다. 표준은 정확한 대응 방식에 관한 구현 선택의 여지를 남기면서 요구 사항을 보존합니다.

Data Offset의 지속적인 역할은 소박하지만 기초적입니다. 옵션을 협상하지도, 애플리케이션 레코드를 설명하지도, 어떤 기능이 중요한지 말하지도 않습니다. 모든 구현체에 동일한 외부 경계를 제공합니다. 그 안에서는 옵션의 종류와 길이가 진화를 지원하고, 그 이후에는 애플리케이션 바이트 스트림이 시작됩니다. 덕분에 TCP는 데이터의 위치를 찾는 능력을 잃지 않고 헤더에 의미를 추가할 수 있었습니다.

출처