TCP 프로토콜 - TCP 헤더 구조

TCP(Transport Control Protocol)는 IP 프로토콜 위에서 연결형 서비스를 지원하는 전송 계층 프로토콜이다.

 

주요 기능
• 연결형 서비스 제공
• 전이중 (full-duplex) 방식의 양방향 가상 회선 제공
• 신뢰성 있는 데이터 전송 보장

TCP/IP 구조

일반적으로 전송 계층 프로토콜은 운영체제 내부 기능으로 구현 (상위 계층에서 시스템 콜로 프로그램 호출하여 이용)
TCP에서는 데이터를 세그먼트 (segment)라는 블록 단위로 분할하여 전송
• 전송되는 블록 크기는 네트워크 부하 정도, 윈도우 크기 등에 영향을 받음
• 가변 크기
• 세그먼트당 순서 번호를 부여하지 않고, 세그먼트에 실어 보내는 데이터 바이트 수를 순서 번호에 반영
• 세그먼트 전송 예시
• 세그먼트 1
• 데이터: "Hello, World!" (13바이트)
• 시작 바이트: 1
• 데이터 바이트 수: 13
• 세그먼트 2
• 데이터: "This is a test." (15바이트)
• 시작 바이트: 14
• 데이터 바이트 수: 15

 

TCP 헤더 구조

TCP 헤더 구조

TCP의 세그먼트는 위와 같은 헤더 구조로 시작하고, 전송 데이터가 이어진다. (그림 상단의 숫자는 비트 수)

마지막 줄의 옵션과 패딩은 생략 가능하므로 TCP 헤더의 최소 크기는 20 바이트이다.

Options 필드는 다양한 종류의 부가 정보를 전달하는 데 사용하며 최대 40 바이트의 크기를 지원한다.

Padding은 헤더의 크기를 4바이트 단위로 맞추려고 사용한다.

 

TCP 헤더 필드

Source Port/Destination Port(송신 포트/ 수신 포트) : 

TCP로 연결되는 가상 회선 양단의 송수신 프로세스에 할당된 네트워크 포트 주소

포트 : 송수신 호스트에서 실행되는 프로세스에 할당되는 네트워크 자원

IP 주소 => 호스트 구분, 포트 주소 => 호스트 내 프로세스 구분

포트 번호는 TCP와 UDP가 별도의 주소 공간을 갖기 때문에 같은 번호를 독립적으로 사용할 수 있다.

송수신 포트 번호 범위 : 0 ~ 2^16 -1

 

Sequence Number(순서 번호) : 

송신 프로세스가 지정하는 순서 번호

세그먼트 전송과정에서 전송되는 바이트의 수를 기준으로 증가

범위 : 0 ~ 2^32 -1

최초 데이터를 전송 시에는 임의의 순서 번호를 선택해 전송 =>. 전송 연결이 끊겼을 떄 순서 번호가 혼서되는 것 방지

 

Acknowledgement Nubmer(응답 번호) :

수신 프로세스가 제대로 수신한 바이트의 수를 응답하기 위해 사용

ACK 프래그 비트가 지정된 경우에 유효 : 다음에 수신을 기대하는 데이터의 순서 번호

ACK 응답을 받은 송신 프로세스는 Acknowledgement Number - 1 까지의 모든 데이터가 올바로 전송되었음을 확인함

연결 설정이나 연결 해제 처럼 데이터 세그먼트가 없는 경우에도 순서 번호가 1씩 증가함

 

Data Offset(데이터 옵셋) :

TCP 세그먼트가 시작되는 위치를 기준으로 데이터의 시작 위치를 나타내므로 TCP 헤더의 크기가 됨

32비트 워드 단위로 표시

 

Reserved(예약) : 예약 필드

 

플래그 비트 8개 : 아래에서 세부적으로 다룸

 

Window(윈도우) :

슬라이딩 윈도우 프로토콜의 수신 윈도우의 버퍼 크기

수신 프로세스가 수신 가능한 바이트의 수를 표시

수신 프로세스의 버퍼 용량 초과 등으로 인해 데이터를 더 이상 수신할 수 없다면 Window 필드 값을 0으로 지정

=> 0인 경우 송신 프로세스는 데이터를 추가로 전송하면 안됨

 

Checksum(체크섬) : 

TCP 세그먼트에 포함하는 프로토콜 헤더와 데이터 모두에 대한 변형 오류 검출

IP 프로토콜에서 사용하는 오류 검출 방식 이용

 

Urgent Pointer(긴급 포인터) :

URG 플래그 비트가 지정된 경우에 유효

송신 프로세스가 긴급히 처리하려는 데이터를 전송할 수 있음

ex) Sequence Number = 2000, Urgent Pointer = 100 으로 지정한 세그먼트 전송시

  - 순서 번호 2000~2099번 데이터 긴급 데이터로 전송, 2100번 이후는 다시 정상 데이터로 전송

RFC 6093에서 비사용 권장

 

TCP 헤더 플래그 비트

TCP 헤더에는 플래그 비트 8개가 지정되어 있고, 처음 2개 비트는 혼잡 제어 용도로 사용되고 나머지 6개 필드의 값이 1인 경우는 다음과 같은 의미를 갖는다.

TCP 헤더의 제어 플래그 비트(노란 색 부분)

URG :

Urgent Pointer 필드가 유효한지 나타냄

수신 프로세스의 응용 계층에 긴급 데이터가 도착했음을 알리는 것으로, 데이터가 응용 계층에 전달되지 전에 긴급 데이터가 왔음을 미리 알려주어 대비할 수 있게 함. 수신 프로세스는 Urgent Pointer 값을 읽어보고 얼마나 많은 긴급 데이터가 오는지 알 수 있음.

 

ACK : 

Acknowledgement Number 필드가 유효한지 나타냄

정상적인 피기배킹 방식의 양방향 통신 환경에서, 양단 프로세스가 쉬지 않고 데이터를 전송한다고 가정하면 최초 연결 설정 과정에서 전송되는 첫 번째 세그먼트(Conn_Req(SYN 패킷))를 제외한 모든 세그먼트의 ACK 비트가 1로 지정됨.

 

PSH :

현제 세그먼트에 포함된 데이터를 상위 계층에 즉시 전달하도록 지시할 때 사용

수신 프로세스로부터 PSH 세그먼트에 대한 응답 프레임이 도착하면, 프레임의 Acknowledgement Number 필드에 표시한 숫자까지의 모든 데이터가 상대 프로세스의 상위 계층에 전달되었음을 의미

수신 프로세스의 TCP 계층에 버퍼링된 데이터를 즉시 상위 계층에 전송함으로써 전송 지연도 감소하는 효과가 있음

 

RST :

연결의 리셋이나 유효하지 않은 세그먼트에 대한 응답

송신 프로세스가 전송을 마쳤으나 수신 프로세스에 아직 도착하지 못한 세그먼트 혹은 수신 프로세스가 아직 긍정 응답하지 않은 세그먼트는 연결이 재설정되었을 때 재전송 되어야함

 

SYN :

연결 설정 요구를 의미하는 프래그 비트로 가상 회선 연결을 설정하는 과정에서 사용

 

FIN :

점진적 방식의 연결 해제 요청 (전송 과정에 있는 데이터는 계속 처리 가능하고, 상대편 프로세스 데이터 전송에 장애가 발생하지 않음)

상대에게 연결을 종료하고 싶다는 의사를 알림

양쪽 프로세스 모두 FIN 플래그를 전송해야 연결이 해제됨

 

점진적 연결 종료 과정
TCP 연결 종료는 일반적으로 4-way handshake 방식으로 이루어짐
1. FIN 패킷 전송
연결을 종료하려는 쪽 (예: 클라이언트)이 FIN 플래그가 설정된 TCP 세그먼트를 전송
"나는 더 이상 데이터를 전송하지 않을 것"이라는 의미
2. ACK 패킷 수신
상대방 (예: 서버)은 클라이언트의 FIN 패킷을 수신하고, 이를 확인하기 위해 ACK 패킷을 전송
클라이언트는 서버가 FIN 패킷을 수신했음을 알게 됨
3. 서버의 FIN 패킷 전송
서버가 더 이상 데이터를 전송하지 않겠다고 결정하면, 서버는 자신의 FIN 패킷을 클라이언트에게 전송
"나도 연결을 종료하겠다"는 의미
4. 클라이언트의 ACK 수신
클라이언트는 서버의 FIN 패킷을 수신하고, 이를 확인하기 위해 ACK 패킷을 전송
양쪽 모두 연결이 정상적으로 종료되었음을 확인

 

혼잡 제어

TCP 프로토콜에 추가된 ECN(Explicit Congestion Notification) 기능은

라우터가 송신 프로세스에 명시적으로 혼잡 발생을 알려주어 송신 프로세스 스스로 트래픽을 완화하는 기술이다.

TCP는 ECN 기능을 지원하지 위해 CWR 필드와 ECE 필드를 정의한다.

CWR(Congestion Window Reduced) :

ECE 비트를 수신한 송신 프로세스가 송신 윈도우 크기를 줄였음을 통지하고 더이상 ECE를 전송하지 말라는 의미 

ECE(Explicit Congestion Notification Echo, ECN-Echo) :

네트워크 트래픽이 많아질 때 라우터가 송신 프로세스에 명시적으로 혼잡을 알림

**송신 프로세스에 직접 전달하지 않고, IP 헤더의 ECN 필드에 CE 값을 지정하여 간접적으로 수신 프로세스에 알려준 후,

수신 프로세스의 중개 Echo를 거쳐 송신 프로세스에 통지됨

ECN 동작 원리

라우터가 IP 프로토콜을 이용하여 수신 프로세스의 중개를 통해 간접적으로 통지하는 이유 : 라우터가 TCP 프로토콜을 지원하지 않기 때문

 

관련 IP 헤더 플레그

ECN(2비트)

필드 값	의미
00	IP 패킷이 ECN 기능을 사용하지 않음
01(ECT 1) 또는 10(ECT 0)	TCP 프로토콜도 ECN 기능을 지원함
11(CE : Congestion Experienced)	라우터가 송신 호스트에 혼잡을 통지

 

ECN 기능 지원 여부 확인

연결 설정 과정에서 SYN, CWR, ECE 설정하여 전송 응답

ECN 기능을 사용하는 경우

(a) 와 같이 SYN, ACK, ECE 플래그를 지정하여 응답

 

ECN 기능을 사용하지 않는 경우

(b) 처럼 SYN, ACK 플래그만 지정하여 응답

 

 

TCP 세그먼트의 캡슐화

상위 계층에서 내려온 전송 데이터는 TCP 헤더 뒤에 추가되어 TCP 세그먼트를 구성하고,

TCP 세그먼트는 다시 IP 프로토콜로 보내져, IP 헤더뒤에 캡슐화되어 데이터 링크 계층으로 보내진다.  

TCP 세그먼트의 캡슐화

 

포트 번호

포트 번호는 TCP, UDP가 상위 계층에 제공하는 주소 표현 방식이다.

Unix 환경에서는 소켓으로 포트를 구현하므로, TCP/UDP 프로토콜을 사용하려면 소켓 시스템 콜의 인터페이스를 알아야 한다.

소켓 시스템 콜을 이용해 TCP 연결 설정이 되면 통신 양단의 프로세스가 사용하는 고유 주소는

해당 호스트의 IP 주소와 호스트 내부의 포트 번호가 조합된 형태이다.

 

클라이언트-서버 방식에서 클라이언트는 서버의 IP 주소와 포트번호를 알아야 통신이 가능함

(서버가 먼저 실행되고, 클라이언트가 서버와 연결을 시도)

 

Well-known 포트 : 인터넷 환경에서 많이 사용하는 네트워크 응용 서비스의 서버 프로세스에 할당된 포트 번호

FTP, 전자메일(SMTP), DNS 처럼 인터넷에서 자주 사용하는 응용 서비스는 모두 고정된 포트 번호를 사용한다.

Well-known 포트

 

TCP와 UDP는 별도의 포트 주소 공간을 관리하므로 동일한 포트 번호를 사용할 수 있다.

즉, 두 프로토콜에서 동일한 포트 번호를 할당해도 서로 다른 포트로 간주된다.

 

 

 

 

참고 자료 :

쉽게 배우는 데이터 통신과 컴퓨터 네트워크 3판 - 박기현 지음