TCP 세그먼트 구조편집자 확인

TCP 세그먼트 구조는 전송 제어 프로토콜(TCP)이 데이터를 전송하기 위해 사용하는 기본 단위인 TCP 세그먼트의 내부 구성 방식을 설명한다. TCP는 인터넷 프로토콜 스위트의 핵심 프로토콜 중 하나로, 신뢰성 있는 연결형 통신을 제공한다. 이 신뢰성 있는 데이터 전송은 모든 정보가 정해진 구조를 가진 세그먼트에 담겨 교환됨으로써 이루어진다.

TCP 세그먼트는 크게 헤더와 데이터 부분으로 나뉜다. 헤더에는 연결 관리, 데이터 정렬, 오류 검출, 흐름 제어, 혼잡 제어 등에 필요한 다양한 제어 정보가 포함되어 있다. 데이터 부분은 실제로 상위 계층(예: HTTP, FTP)에서 내려받은 애플리케이션 데이터, 즉 페이로드가 위치한다. 세그먼트 구조는 RFC 793을 비롯한 표준 문서에 정의되어 있으며, 모든 TCP 구현체는 이 구조를 준수한다.

이 구조는 TCP가 제공하는 핵심 서비스인 신뢰적 전송, 순서 보장, 흐름 제어, 혼잡 제어의 기반이 된다. 예를 들어, 헤더 내의 시퀀스 번호와 확인 응답 번호는 데이터의 순서와 누락을 관리하며, 윈도우 크기 필드는 수신자의 처리 능력에 맞춘 흐름 제어를 가능하게 한다. 따라서 TCP 세그먼트 구조를 이해하는 것은 TCP 프로토콜의 동작 원리를 파악하는 첫걸음이다.

TCP 세그먼트의 TCP 헤더는 데이터 전송을 제어하는 데 필요한 모든 정보를 담고 있으며, 일반적으로 20바이트의 기본 헤더와 최대 40바이트의 옵션 필드로 구성된다. 이 구조는 RFC 793에 정의되어 있으며, 네트워크를 통해 전송되는 모든 TCP 세그먼트의 시작 부분에 위치한다. 헤더의 각 필드는 송신자와 수신자 간의 연결 상태 관리, 데이터의 순서 보장, 흐름 제어, 오류 검출 등의 기능을 수행하는 데 사용된다.

기본 헤더는 다음과 같은 고정된 20바이트의 필드들로 이루어져 있다.

데이터 오프셋 필드 뒤에는 가변 길이의 옵션 필드가 올 수 있다. 이 필드는 기본 헤더 기능을 확장하는 데 사용되며, 최대 세그먼트 크기 협상, 선택적 확인응답, 타임스탬프 사용과 같은 고급 기능을 지원한다. 옵션 필드의 길이는 32비트 경계에 맞추기 위해 필요한 경우 패딩으로 끝나며, 전체 TCP 헤더 길이는 데이터 오프셋 값에 4를 곱한 바이트 수가 된다.

TCP 세그먼트의 헤더에는 출발지 포트 번호 필드와 목적지 포트 번호 필드가 각각 16비트로 포함되어 있다. 이 두 필드는 전송 계층에서 호스트 내의 특정 프로세스나 서비스를 식별하는 데 사용되는 주소 역할을 한다.

포트 번호는 0부터 65535까지의 값을 가질 수 있다. 이 범위는 잘 알려진 포트(0-1023), 등록된 포트(1024-49151), 동적/사설 포트(49152-65535)로 구분된다. 예를 들어, HTTP는 80번, HTTPS는 443번, DNS는 53번과 같은 잘 알려진 포트를 사용한다. 하나의 IP 주소와 포트 번호의 조합은 네트워크 소켓을 고유하게 정의한다.

TCP 연결은 출발지 IP 주소, 출발지 포트, 목적지 IP 주소, 목적지 포트라는 네 가지 요소로 구성된 4-튜플에 의해 식별된다. 따라서 동일한 두 호스트 간에 동일한 포트 쌍을 사용하는 복수의 동시 연결은 일반적으로 불가능하다. 포트 번호는 TCP 헤더의 가장 앞부분에 위치하여, 패킷이 목적지 호스트에 도착했을 때 운영체제가 해당 세그먼트를 올바른 응용 프로그램에 전달할 수 있도록 한다.

시퀀스 번호는 송신 스트림 내에서 전송되는 데이터의 첫 번째 바이트 위치를 식별하는 32비트 값이다. 각 TCP 세그먼트는 자신이 담고 있는 데이터의 시작 바이트 번호를 시퀀스 번호 필드에 명시한다. 이를 통해 수신 측은 세그먼트들이 올바른 순서로 도착했는지 확인하고, 중복되거나 손실된 데이터를 감지할 수 있다. 연결이 시작될 때 초기 시퀀스 번호는 무작위 값으로 설정되며, 이후 전송된 데이터 바이트 수만큼 증가한다[2].

확인 응답 번호는 32비트 필드로, 수신 측이 성공적으로 수신한 데이터의 다음 바이트 번호를 송신 측에 알리는 데 사용된다. 이는 '다음에 수신을 기대하는 시퀀스 번호'를 의미하며, 신뢰성 있는 데이터 전송의 핵심 메커니즘인 긍정 확인 응답을 구현한다. 예를 들어, 수신 측이 시퀀스 번호 1000으로 시작하는 200바이트의 세그먼트를 받았다면, 확인 응답 번호로 1200을 설정하여 송신 측에 1199번 바이트까지 정상 수신되었음을 통보한다.

두 필드는 3방향 핸드셰이크 과정에서도 중요한 역할을 한다. 연결 설정 시, 양측은 자신의 초기 시퀀스 번호를 상대방에게 알리고, 상대방의 시퀀스 번호에 대한 확인 응답을 보낸다. 이 과정을 통해 양방향 통신 채널의 초기 동기화가 이루어진다.

이러한 번호 체계는 슬라이딩 윈도우 프로토콜과 결합되어 흐름 제어 및 혼잡 제어의 기반을 제공한다. 또한, 시퀀스 번호의 예측 불가능한 초기화는 TCP 스푸핑과 같은 보안 공격을 어렵게 만드는 요소 중 하나이다.

데이터 오프셋 필드는 TCP 헤더의 길이를 4바이트 단위로 나타내는 4비트 필드이다. 이 값은 TCP 세그먼트의 시작 지점에서 실제 데이터가 시작되는 위치까지의 오프셋을 지정한다.

데이터 오프셋의 최소값은 5이며, 이는 기본 헤더 길이인 20바이트(5 * 4바이트)에 해당한다. 최대값은 15로, 헤더의 최대 길이는 60바이트(15 * 4바이트)까지 가능하다. 이 60바이트 제한은 TCP 옵션 필드가 최대 40바이트까지 사용될 수 있음을 의미한다[3].

수신 측은 이 필드의 값을 읽어 TCP 헤더의 정확한 종료 지점과 데이터 페이로드의 시작 지점을 식별한다. 옵션 필드의 존재 여부와 길이에 따라 헤더의 전체 크기가 가변적이므로, 데이터 오프셋은 페이로드의 위치를 결정하는 데 필수적인 정보이다.

제어 비트 필드는 TCP 헤더의 6번째 16비트 워드에 위치한 9비트(기본 6비트 + 확장 3비트) 공간으로, TCP 연결의 상태를 관리하고 데이터 전송의 특성을 제어하는 데 사용된다. 이 비트들은 각각 독립적으로 설정될 수 있으며, 특정 비트가 1로 설정되면 해당 기능이 활성화됨을 의미한다.

기본 �어더에 포함된 6개의 주요 플래그는 다음과 같다.

확장된 플래그로는 ECN(Explicit Congestion Notification) 관련 비트인 ECE와 CWR이 있다. ECE 비트는 상대방이 ECN을 지원함을 나타내거나 혼잡을 경고하는 데 사용되며, CWR 비트는 혼잡 윈도우 크기가 감소되었음을 송신 측이 알릴 때 사용된다[4]. NS 비트는 실험적 용도로 정의되어 있다. 이 플래그들을 조합하여 3방향 핸드셰이크 및 4방향 핸드셰이크와 같은 연결 설정 및 종료 절차가 수행된다.

윈도우 크기 필드는 16비트로 구성되어 있으며, 흐름 제어를 수행하는 핵심 매커니즘이다. 이 필드의 값은 송신자가 현재 수신할 수 있는 데이터의 양, 즉 수신 윈도우의 크기를 바이트 단위로 상대방에게 알린다. 이를 통해 수신 측의 버퍼 상태에 따라 데이터 전송 속도를 동적으로 조절하여, 버퍼 오버플로우를 방지하고 효율적인 데이터 전송을 가능하게 한다.

윈도우 크기의 값은 슬라이딩 윈도우 프로토콜의 기반이 된다. 송신 측은 수신 측으로부터 확인 응답을 받지 않은 상태에서도, 수신 측이 통보한 윈도우 크기만큼의 데이터를 연속적으로 전송할 수 있다. 수신 측이 데이터를 처리하고 버퍼 공간이 생기면, 새로운 ACK 세그먼트에 업데이트된 윈도우 크기 값을 담아 보내며, 이에 따라 송신 측의 전송 가능 윈도우가 이동하고 확장된다.

16비트 필드의 한계로 인해 최대 윈도우 크기는 65,535바이트로 제한되었으나, 대역폭이 높은 현대 네트워크에서는 이 크기로는 효율적인 전송이 어려웠다. 이 문제를 해결하기 위해 윈도우 스케일 옵션이 도입되었다. 이 옵션을 사용하면 셰이크핸드 과정에서 협상된 스케일 팩터를 통해 윈도우 크기 값을 좌측으로 시프트하여 최대 1기가바이트에 가까운 매우 큰 윈도우 크기를 지원할 수 있게 되었다.

체크섬 필드는 TCP 세그먼트의 무결성을 검증하기 위해 사용되는 16비트 필드이다. 이 필드는 세그먼트 헤더, 데이터 페이로드, 그리고 의사 헤더로 구성된 계산 범위에 대한 1의 보수 합의 결과값을 담는다. 수신 측은 동일한 알고리즘으로 체크섬을 다시 계산하고, 계산된 값이 0이 아니면 패킷이 손상되었다고 판단하여 해당 세그먼트를 폐기한다.

체크섬 계산에 포함되는 의사 헤더는 IP 헤더의 출발지 주소, 목적지 주소, 프로토콜 값, 그리고 TCP 세그먼트 전체 길이 정보로 구성된다. 이는 전송 중 IP 주소가 변경되거나 프로토콜이 변조되는 경우를 감지할 수 있게 해준다. 따라서 체크섬은 단순히 TCP 데이터의 오류뿐만 아니라, 네트워크 계층에서의 일부 오류도 함께 검출하는 역할을 수행한다.

체크섬 검사는 엔드 투 엔드 원리에 기반한 신뢰성 보장 메커니즘의 핵심 요소이다. 하드웨어 기반의 CRC 오류 검출이 링크 계층에서 일반적으로 사용되지만, TCP 체크섬은 라우터나 스위치와 같은 중간 노드에서 발생할 수 있는 소프트웨어 처리 오류까지 감지하는 추가적인 보호 계층을 제공한다[6].

긴급 포인터는 TCP 헤더 내의 16비트 필드로, 긴급 데이터의 위치를 가리킨다. 이 필드는 제어 비트 중 URG 플래그가 1로 설정되었을 때만 유효한 의미를 가진다. 긴급 포인터의 값은 시퀀스 번호에 더해져, 긴급 데이터의 마지막 바이트 위치를 나타낸다[7].

긴급 포인터의 주요 목적은 수신 측 TCP에 긴급한 처리가 필요한 데이터가 포함되어 있음을 알리고, 해당 데이터의 정확한 종료 지점을 식별하도록 하는 것이다. 예를 들어, 원격 터미널 세션에서 인터럽트 키(예: Ctrl+C)를 전송하는 경우에 활용될 수 있다. 그러나 현대 대부분의 네트워크 애플리케이션과 운영 체제는 이 메커니즘을 거의 사용하지 않거나, 다른 신호 처리 방식을 선호한다.

긴급 포인터의 해석과 관련하여 역사적으로 두 가지 모델이 존재했다. 하나는 긴급 포인터가 긴급 데이터의 마지막 바이트를 가리킨다는 RFC 793의 원래 정의이며, 다른 하나는 긴급 데이터의 마지막 바이트 다음 바이트를 가리킨다는 이후의 개정된 해석이다. 이 불일치는 호환성 문제를 일으킬 수 있어, 실제 구현과 사용을 제한하는 요인 중 하나가 되었다.

TCP 세그먼트의 데이터 페이로드는 TCP 헤더 뒤에 위치하며, 실제로 애플리케이션 계층에서 교환하려는 사용자 데이터를 담는 부분이다. 이 부분은 선택적이며, 연결 설정이나 종료와 같은 제어용 세그먼트의 경우 데이터 페이로드가 존재하지 않을 수 있다. 데이터 페이로드의 길이는 MSS에 의해 제한되며, 일반적으로 IP 패킷이 MTU를 초과하지 않도록 조정된다.

데이터 페이로드의 크기는 가변적이다. 세그먼트의 전체 길이에서 TCP 헤더 길이를 뺀 값으로 계산된다. 데이터가 없을 경우 시퀀스 번호는 증가하지 않지만, PSH 플래그가 설정된 데이터 페이로드는 수신 측 TCP에게 즉시 상위 계층으로 전달하도록 지시한다. 대용량 데이터를 전송할 때는 여러 개의 TCP 세그먼트로 분할되어 각각의 데이터 페이로드에 나누어 담기게 된다.

데이터 페이로드는 TCP의 핵심 서비스인 신뢰성 있는 전송의 대상이 된다. 모든 데이터 페이로드는 시퀀스 번호로 식별되며, 수신 측은 이에 대한 확인 응답을 반드시 보내야 한다. 전송 중 손실이나 오류가 발생하면 해당 세그먼트의 데이터 페이로드는 재전송된다. 따라서 애플리케이션 계층의 프로토콜(예: HTTP, FTP, SMTP) 메시지는 최종적으로 이 데이터 페이로드 영역을 통해 오류 없이 순서대로 전달된다.

• Wikipedia - Transmission Control Protocol

• Wikipedia - Transmission Control Protocol/세그먼트 구조

• IETF - RFC 9293: Transmission Control Protocol (TCP)

• GeeksforGeeks - TCP Header

• Khan Academy - Transmission Control Protocol (TCP)

• TechTarget - What is TCP (Transmission Control Protocol)?

• MDN Web Docs - Transmission Control Protocol (TCP)