데이터 통신과 네트워킹 TCP-IP프로토콜 기반

[데이터 통신과 네트워킹-TCP/IP프로토콜 기반] 9장 전송층

studyingalone 2025. 3. 6. 18:27

9.1 전송층 서비스

  • 전송층은 응용층에 서비스를 제공하는 책임이 있다. 

9.1.1 프로세스-대(to)-프로세스 통신

메시지를 적절한 프로세스로 전달하는 역할은 전송 계층이 수행


9.1.2 주소 지정: 포트 번호

 

  • IP 주소: 통신할 호스트(컴퓨터)를 식별
  • 포트 번호: 호스트 내 특정 프로세스를 식별
  • 클라이언트는 일시적인(ephemeral) 포트 번호(1024~65,535)를 사용
  • 서버는 잘 알려진(well-known) 포트 번호(0~1023)를 사용
  • 포트 번호 범위:
    • 0~1023: ICANN이 관리하는 잘 알려진(well-Known) 포트
    • 1024~49,151: 등록 가능하지만 관리되지 않는 등록(registered) 포트
    • 49,152~65,535: 완전히 자유롭게 사용 가능한 동적(dynamic) 포트
  • 소켓 주소(Socket Address): IP 주소 + 포트 번호

소켓 주소


 

9.1.3 캡슐화와 디캡슐화

  • 캡슐화(Encapsulation): 송신 프로세스가 메시지를 전송 계층에 전달하면, 전송 계층은 헤더를 추가하여 패킷을 만든다.
  • 역캡슐화(Decapsulation): 수신 측 전송 계층이 헤더를 제거하고, 메시지를 응용 계층의 해당 프로세스에 전달한다.

캡슐화와 역캡슐화


9.1.4 다중화(Multiplexing)와 역다중화(Demultiplexing)

  • 다중화(Multiplexing): 여러 클라이언트 프로세스(P1, P2, P3)의 메시지를 하나의 전송 계층이 처리하여 송신
  • 역다중화(Demultiplexing): 수신 측 전송 계층이 해당 메시지를 올바른 프로세스에 전달

다중화와 역다중화


9.1.5 흐름 제어(Flow Control)

  • 생산 속도소비 속도의 균형이 필요
  • 푸시(Push) 방식: 송신자가 수신자의 요청 없이 데이터를 보냄 → 흐름 제어 필요
  • 풀(Pull) 방식: 수신자가 필요할 때만 요청 → 흐름 제어 불필요

밀기, 끌기

  • 흐름 제어는 두 가지 경우에서 필요
    1. 송신 애플리케이션 ↔ 송신 전송 계층
    2. 송신 전송 계층 ↔ 수신 전송 계층
  • 버퍼(Buffer) 사용:
    • 송신/수신 전송 계층에 메시지를 임시 저장할 메모리 공간을 둬서 흐름 제어 수행
    • 버퍼가 가득 차면 데이터를 더 이상 보내지 않도록 신호 전달
    • 단일 슬롯 버퍼(1개 패킷만 저장)는 비효율적

9.1.6 오류 제어 (Error Control)

IP 계층이 신뢰할 수 없기 때문에, 신뢰성이 필요한 애플리케이션을 위해 전송 계층에서 오류 제어 기능을 추가

  1. 손상된 패킷을 감지하고 폐기
  2. 손실되거나 폐기된 패킷을 추적하고 재전송
  3. 중복 패킷을 감지하고 폐기
  4. 순서가 어긋난 패킷을 임시 저장하여 누락된 패킷을 기다림

9.1.7 흐름 제어와 오류 제어의 결합 (Combination of Flow and Error Control)

흐름 제어는 송신자와 수신자 각각의 버퍼를 사용하며, 오류 제어는 패킷의 순서 번호(Sequence Number)와 확인 응답(ACK)을 활용한다.

  • 송신자는 패킷을 전송할 때 해당 패킷을 버퍼에 저장하고, 확인 응답이 오면 해당 패킷을 삭제하여 버퍼를 확보한다.
  • 수신자는 패킷이 도착하면 해당 순서 번호 위치에 저장하고, 애플리케이션이 이를 받을 준비가 되면 전달한다.

미닫이 창(Sliding Window) 기법을 사용하여 제한된 범위의 순서 번호를 순환적으로 사용하면서, 패킷 송수신 상태를 관리한다.

원형 형태의 미닫이 창
션형 형태의 미닫이 창


9.1.8 혼잡 제어 (Congestion Control)

네트워크에서 패킷이 처리 능력을 초과하면 혼잡(congestion)이 발생한다.

  • 네트워크의 라우터와 스위치에는 패킷을 저장하는 큐(queue)가 있으며, 패킷이 빠르게 도착하지만 처리 속도가 따라가지 못하면 혼잡이 발생한다.
  • 전송 계층에서 혼잡 제어 기법을 사용하여 네트워크의 부하를 조절한다.

9.1.9 비연결형 및 연결형 프로토콜 (Connectionless and Connection-Oriented Protocols)

전송 계층 프로토콜은 비연결형(connectionless)연결형(connection-oriented) 방식으로 나뉜다.

 

1. 비연결형 서비스 (Connectionless Service)

  • 메시지를 작은 청크(chunk)로 나누어 개별적으로 전송
  • 패킷 간에 관계가 없으므로 순서가 뒤바뀌거나 손실될 가능성이 있음
  • 흐름 제어, 오류 제어, 혼잡 제어가 효과적으로 이루어지지 않음

비연결형 서비스

 

2. 연결형 서비스 (Connection-Oriented Service)

  • 송신자와 수신자가 먼저 **논리적 연결(logical connection)**을 설정한 후 데이터 전송
  • 데이터 전송 후 연결을 해제
  • 흐름 제어, 오류 제어, 혼잡 제어 기능을 효과적으로 구현 가능

연결형 서비스

 

유한 상태 기계 (Finite State Machine, FSM)

  • 전송 계층 프로토콜의 동작을 유한 상태 기계(FSM)로 표현할 수 있다
  • 비연결형 프로토콜: 하나의 established(설정됨) 상태만 유지
  • 연결형 프로토콜: 연결 설정 → 데이터 전송 → 연결 해제 과정에서 여러 상태를 거침
    • 연결 설정: Closed → Open-Wait-I → Open-Wait-II → Established
    • 연결 해제: Established → Close-Wait-I → Close-Wait-II → Closed

FSM을 이용하면 전송 계층의 동작을 체계적으로 설계할 수 있다.


9.2 전송 계층 프로토콜

9.2.1 서비스

  • UDP: 신뢰성이 없는 비연결형 프로토콜로, 오류 제어는 애플리케이션에서 처리해야 한다.
  • TCP: 신뢰성이 있는 연결형 프로토콜로, 데이터의 정확성과 순서를 보장
  • SCTP: UDP와 TCP의 기능을 혼합한 새로운 전송 계층 프로토콜

9.3 사용자 데이터그램 프로토콜(UDP)

UDP는 비연결형, 신뢰성이 없는 전송 계층 프로토콜입니다.


9.3.1 UDP 서비스

  • 프로세스 간 통신: IP 주소 + 포트 번호를 조합한 소켓 주소를 사용하여 통신
  • 비연결형 서비스: 데이터그램 간 관계 없이 독립적으로 전송되며, 흐름 제어나 오류 제어 기능이 없다.
  • 흐름 제어 없음: 송신자가 과도한 데이터를 보내면 수신 측이 감당하지 못할 수 있다.
  • 오류 제어 없음: 체크섬 기능만 제공하며, 오류가 발생하면 해당 데이터그램을 단순 폐기
  • 혼잡 제어 없음: UDP는 트래픽을 조절하지 않으며, 대량의 데이터 전송 시 네트워크 혼잡을 일으킬 수 있다.
  • 캡슐화 및 역캡슐화: 송신 측에서 데이터를 UDP 헤더에 추가하고, 수신 측에서 이를 제거
  • 다중화 및 역다중화: 여러 애플리케이션이 UDP를 사용할 수 있도록 포트 번호를 활용하여 데이터를 구분

9.3.2 UDP 응용

UDP 사용이 적합한 경우

  • 간단한 요청-응답 형태의 통신(DNS, SNMP 등)
  • 멀티캐스트(여러 수신자에게 동시에 데이터 전송)
  • 경로 업데이트(RIP)
  • 실시간 스트리밍(오디오/비디오)

UDP는 간단하고 효율적이지만, 신뢰성이 보장되지 않으므로 애플리케이션에서 추가적인 오류 제어를 수행해야 한다.


9.4 TCP (전송 제어 프로토콜)

9.4.1 TCP 서비스

  • 프로세스 간 통신: TCP는 UDP처럼 포트 번호를 이용해 프로세스 간 통신을 제공
  • 스트림 기반 전송: TCP는 데이터를 바이트 스트림으로 전송하며, 수신 프로세스는 연속적인 바이트 스트림을 받는다.
  • 송·수신 버퍼: 송신 및 수신 속도가 다를 수 있기 때문에 TCP는 데이터를 저장하는 버퍼를 사용한다.
  • 세그먼트화: 네트워크 계층은 패킷 단위로 데이터를 처리하므로, TCP는 데이터를 세그먼트로 나누고 헤더를 추가하여 전송한다.
  • 전이중(Full-Duplex) 통신: 데이터가 양방향으로 동시에 전송 가능하다.
  • 다중화 및 역다중화: 여러 애플리케이션이 동일한 네트워크 연결을 공유할 수 있도록 한다.
  • 연결 지향 서비스: 통신 전 연결을 설정하고, 데이터 전송 후 연결을 종료한다.
  • 신뢰성 제공: 데이터 전송의 신뢰성을 보장하기 위해 확인 응답(ACK) 및 오류 제어 기능을 사용한다.

9.4.2 TCP 특징

  • 번호 매기기 시스템: TCP는 데이터 바이트마다 고유한 번호를 부여하여 데이터의 순서를 유지한다.
  • 바이트 번호: 전송되는 각 바이트에는 고유 번호가 매겨지며, 첫 번째 바이트의 번호는 무작위로 선택된다.
  • 순서 번호(Sequence Number): 세그먼트 내 첫 번째 바이트의 번호를 나타내며, 연결 설정 시 랜덤한 초기 번호(ISN)를 사용한다.
  • 확인 응답 번호(Acknowledgment Number): 수신 측에서 다음으로 기대하는 바이트 번호를 나타내며, 누적 확인 응답 방식을 사용한다.

9.4.3 TCP 세그먼트 구조

  • 세그먼트 포맷: TCP 세그먼트는 20~60 바이트의 헤더와 데이터로 구성된다.
  • 주요 헤더 필드:
    • 출발지/목적지 포트: 송·수신 프로세스를 식별한다.
    • 순서 번호: 세그먼트 내 첫 번째 바이트의 번호를 나타낸다.
    • 확인 응답 번호: 수신된 마지막 바이트의 다음 번호를 나타낸다.
    • 헤더 길이: TCP 헤더의 길이를 나타낸다.
    • 제어 플래그: 연결 설정, 종료, 흐름 제어 등의 역할을 한다.
    • 윈도우 크기: 송신자가 수신자로부터 받을 수 있는 데이터 크기를 지정한다.
    • 체크섬: 데이터 오류를 감지하는 필드로, UDP와 달리 사용이 필수적이다.
    • 긴급 포인터: 긴급 데이터가 포함된 경우 위치를 나타낸다.
    • 옵션 필드: 확장 기능을 위한 옵션 정보가 포함될 수 있다.

TCP 세그먼트 형식

 


9.4.4 TCP 연결

  • TCP는 연결 지향형 프로토콜로, 송신자와 수신자 간 논리적 경로를 설정하여 데이터 전송.
  • IP는 비연결형이지만, TCP는 IP의 서비스를 이용해 개별 세그먼트를 전달하고 연결을 제어.
  • 데이터가 손실되거나 손상되면 재전송, 순서가 어긋나면 순서 정렬.

연결 설정

TCP 연결은 3방향 핸드셰이킹(three-way handshaking)을 통해 이루어짐.

  1. 클라이언트 → 서버 : SYN 패킷 전송 (초기 시퀀스 번호 포함).
  2. 서버 → 클라이언트 : SYN + ACK 패킷 응답 (서버의 초기 시퀀스 번호 및 클라이언트의 SYN 확인).
  3. 클라이언트 → 서버 : ACK 패킷 응답 (연결 완료).

세-방향 핸드세이크 연결 설정

데이터 전송

  • 연결 후 양방향 데이터 전송 가능.
  • PSH (Push) 플래그: 즉시 데이터를 애플리케이션으로 전달.
  • URG (Urgent) 플래그: 특정 데이터가 긴급함을 표시.

데이터 전송

연결 종료 (Three-Way Handshaking)

  • Three-Way 종료
    • 클라이언트 → 서버 : FIN 패킷 전송.
    • 서버 → 클라이언트 : FIN + ACK 전송.
    • 클라이언트 → 서버 : 최종 ACK 전송 (연결 종료).

세-방향 핸드셰이킹을 사용한 연결 종료


9.4.5 상태천이도 (State Transition Diagram)

  • TCP는 유한 상태 기계(FSM, Finite State Machine) 로 표현되며, 연결 설정, 해제 및 데이터 전송 중 발생하는 이벤트를 관리한다.
  • FSM 다이어그램에서는 클라이언트와 서버의 상태 전이 과정이 함께 표현되며,
    • 클라이언트의 일반적인 전이는 실선
    • 서버의 일반적인 전이는 점선으로 표시된다.
  • 특정 상황에서는 클라이언트가 점선을, 서버가 실선을 따라 전이할 수도 있음.
  • ESTABLISHED 상태는 실제로 클라이언트와 서버 각각의 상태 집합을 포함하며, 흐름 제어 및 오류 제어 기능을 수행한다.

상태 천이도


9.4.6 TCP의 창(Window)

TCP는 송신 윈도우(Send Window)수신 윈도우(Receive Window) 를 사용하여 흐름 제어 및 오류 제어를 수행함.

 

송신 창(Send Window)

  • 현재 전송할 수 있는 데이터의 크기
  • 송신창의 크기는 수신자(흐름 제어) 하부 네트워크의 혼잡(혼잡 제어)에 의해 조절됨

수신 창(Receive Window)

  • 수신창은 수신자가 수신할 수 있는 데이터 크기를 결정하며, 흐름 제어를 담당함.
  • 수신창의 크기는 항상 버퍼의 크기보다 작거나 같다.
    • 수신창이 송신창으로부터 넘치지 않고(흐름제어) 수신할 수 있는 바이트의 개수를 결정

9.4.7 흐름 제어(Flow Control)

  • 흐름 제어는 송신자가 데이터를 보내는 속도와 수신자가 데이터를 받는 속도를 균형 있게 맞추는 기법이다.
  • TCP에서는 오류 제어와 흐름 제어가 분리되어 있다.

TCP에서 데이터 흐름과 흐름 제어 피드백

 

창 열기와 닫기

  • 수신 윈도우 조정: 수신자가 데이터를 처리한 후, 수신 윈도우는 열리고, 데이터를 더 받기 위해 공간을 확보합니다.
  • 송신 윈도우 조정: 송신자는 수신자가 광고한 윈도우 크기에 따라 자신의 송신 윈도우를 조정합니다. 수신자의 버퍼 크기와 상태에 맞춰 윈도우 크기가 결정됩니다.

 

시나리오: 클라이언트에서 서버로의 단방향 데이터 전송

흐름 제어 예

 

더보기

1. 첫 번째 세그먼트 (클라이언트 -> 서버)

  • 클라이언트는 연결 요청을 위해 SYN 세그먼트를 보냅니다.
  • 클라이언트는 seqNo = 100을 지정하고, 서버는 800 바이트의 버퍼를 할당하여 수신 윈도우(rwnd)를 800으로 설정합니다.
  • 이때 다음에 올 데이터의 바이트 번호는 101입니다.

2. 두 번째 세그먼트 (서버 -> 클라이언트)

  • 서버는 ACK + SYN 세그먼트를 보내며, ackNo = 101로 클라이언트가 101번 바이트부터 데이터를 받을 것임을 알립니다.
  • 서버는 클라이언트가 800 바이트의 버퍼를 설정했다고 광고합니다.

3. 세 번째 세그먼트 (클라이언트 -> 서버)

  • 클라이언트는 ACK 세그먼트를 보내며, rwnd = 2000을 정의하지만, 현재 단방향 통신이므로 이 값은 그림에 표시되지 않습니다.

4. 클라이언트에서 200 바이트 전송 (클라이언트 -> 서버)

  • 클라이언트는 101번부터 300번까지의 데이터를 전송합니다.
  • 클라이언트 윈도우는 200 바이트 전송 후 200 바이트가 대기 상태임을 반영하여 크기가 조정됩니다.
  • 서버는 데이터를 수신하고, 301번부터 데이터를 받을 것임을 알려주며 윈도우를 갱신합니다 (수신 윈도우는 600).

5. 서버에서 ACK 전송 (서버 -> 클라이언트)

  • 서버는 300번까지의 데이터를 수신했다고 ACK하며, rwnd = 600을 광고합니다.
  • 클라이언트는 ACK을 받은 후, 윈도우를 600으로 갱신합니다.

6. 클라이언트에서 300 바이트 전송 (클라이언트 -> 서버)

  • 클라이언트는 301번부터 600번까지의 데이터를 전송합니다.
  • 서버는 데이터를 수신하고, 100 바이트를 처리한 후 윈도우 크기를 400으로 조정합니다.

7. 서버에서 ACK 전송 (서버 -> 클라이언트)

  • 서버는 600번까지의 데이터를 수신했다고 ACK하고, rwnd = 400을 광고합니다.
  • 클라이언트는 서버의 윈도우 크기(400)에 맞춰 윈도우를 조정합니다.

8. 서버에서 200 바이트 처리 후 윈도우 확장 (서버 -> 클라이언트)

  • 서버는 200 바이트를 더 처리하여 수신 윈도우 크기가 600으로 확장됩니다.
  • 서버는 클라이언트에게 다음 바이트가 601번부터 시작될 것임을 알리며, 윈도우 크기를 600으로 확장했다고 광고합니다.
  • 클라이언트는 수신한 세그먼트를 바탕으로 윈도우 크기를 600으로 확장합니다.

 

창 축소

  • 수신자는 송신 윈도우 축소를 방지하려면, new ackNo + new rwnd ≥ last ackNo + last rwnd 조건을 만족해야 합니다.

창 폐쇠

  • 수신자는 일정 조건 하에 수신 윈도우 크기를 0으로 설정하여 송신자가 더 이상 데이터를 보내지 않도록 할 수 있다.
  • 탐침(probing): 수신 윈도우가 0인 상태에서도 송신자는 1바이트의 데이터를 보내면서 수신자에게 윈도우 상태를 확인.

어리석은 윈도우 신드롬 (Silly Window Syndrome)

  • 어리석은 윈도우 증후군은 너무 작은 데이터 세그먼트가 전송되어 네트워크 효율이 떨어지는 문제이다.
  • 송신자가 1바이트씩만 보내거나, 수신자가 1바이트씩만 데이터를 처리하는 경우

9.4.8 TCP 오류 제어

TCP는 신뢰성 있는 전송 계층 프로토콜로, 데이터의 순서 보장, 오류 없는 전송, 손실 없이 데이터를 전달하는 기능을 제공한다. 

  1. 검사합(Checksum): 세그먼트가 손상되었는지 확인하는 필드로, 손상된 세그먼트는 폐기되고 재전송
  2. 누적 확인 응답(ACK): 데이터 세그먼트의 수신을 확인하는 메커니즘으로, ACK 세그먼트는 순서대로 도달한 데이터만을 확인합니다. ACK는 원래의 세그먼트가 손상되거나 중복되었을 경우 이에 대한 어떤 피드백도 제공하지 않는다.
  3. 선택 확인 응답(SACK): ACK를 대치하는 것이 아니라 송신측에게 부가 정보를 알려주기 위해 사용된다. 순서에 맞지 않게 들어온 데이터 블록과 중복 세그먼트 블록을 알려준다.
  4. 재전송: 재전송 타이머가 만료되거나 송신측 버퍼에 있는 첫 번째 세그먼트에 대한 3개의 중복 ACK를 수신하는 경우 세그먼트가 재전송된다.

순서가 맞지 않는 세그먼트:

  • TCP는 순서가 맞지 않는 세그먼트를 폐기하지 않고 임시로 저장하며, 누락된 세그먼트가 도착할 때까지 기다린다. 하지만 처리 중인 애플리케이션에는 순서대로만 전달

 

TCP가 동작하는 동안 발생 가는한 시나리오

 

1. 정상 작동 (Normal Operation)
클라이언트와 서버 간의 양방향 데이터 전송. 클라이언트는 ACK 세그먼트를 보내고, 서버는 데이터를 전송한다.

  • 규칙 1: 서버는 데이터를 보내면, 클라이언트는 다음 바이트 번호를 예상하여 ACK을 보낸다.
  • 규칙 2: 클라이언트는 데이터가 더 이상 없으면, ACK을 지연시킵니다. 이때, 500ms 지연 후 ACK을 전송
  • 규칙 3: 서버에서 세그먼트를 수신하면 ACK을 보내고, 클라이언트는 데이터가 없으면 ACK을 보낸다.
    RTO 타이머는 설정되지만, 세그먼트 손실이나 지연이 없으면 타이머가 발동하지 않는다.

정상적인 동작

 

2. 손실된 세그먼트 (Lost Segment)
세그먼트가 손실되거나 손상된 경우

  • 송신자는 1번과 2번 세그먼트를 전송하고, 수신자는 이들을 확인한 후 ACK을 보낸다.
  • 3번 세그먼트가 손실되었을 경우, 수신자는 4번 세그먼트를 받지만 순서가 맞지 않기 때문에 이를 버퍼에 저장합니다.
  • 수신자는 기대하는 바이트 번호를 포함한 ACK을 송신자에게 보내, 데이터의 순서를 알립니다.
  • 송신자는 RTO 타이머가 만료되면 손실된 3번 세그먼트를 재전송합니다.

손실 세그먼트

 

3. 빠른 재전송 (Fast Retransmission)
RTO 타이머가 만료되기 전에 손실된 세그먼트를 빠르게 재전송하는 과정

  • 3번 세그먼트가 손실되고, 수신자는 4번, 5번 세그먼트를 받지만 중복된 ACK을 보낸다.
  • 3개의 중복된 ACK을 받으면, 송신자는 RTO 타이머가 만료되기 전에 3번 세그먼트를 재전송한다.
  • 재전송 후, RTO 타이머는 다시 설정된다.

빠른 재전송

 

4. 지연된 세그먼트 (Delayed Segment)
지연된 세그먼트는 IP 프로토콜을 통해 전송되는 동안 다양한 경로를 거쳐 도착하는 데 시간차가 발생할 수 있다.

  • 세그먼트가 지연되어 수신자가 세그먼트를 늦게 받게 되면, 그 세그먼트는 중복으로 간주되어 버려진다.
  • 이 경우, 송신자는 타이머가 만료되어 재전송된 세그먼트를 보내며, 지연된 세그먼트는 더 이상 유효하지 않다.

 

5. 중복된 세그먼트 (Duplicate Segment)
송신자가 세그먼트를 지연시키고 손실된 것으로 간주할 때 중복된 세그먼트가 발생할 수 있다.

  • 수신자는 중복된 세그먼트를 수신하면 이를 버리고, 예상되는 다음 바이트 번호를 포함한 ACK을 송신자에게 보낸니다.

 

6. 자동으로 수정된 손실된 ACK (Automatically Corrected Lost ACK)
손실된 ACK을 수정하는 방식

  • TCP는 누적 ACK 방식을 사용하여, 손실된 ACK이 발생해도 다음 ACK이 그 정보를 자동으로 포함하여 송신자에게 전달된다.
  • 송신자는 손실된 ACK을 알지 못하고, 정상적인 데이터 흐름을 유지할 수 있다.

확인 응답 손실

 

7. 세그먼트 재전송으로 수정된 손실된 ACK (Lost Acknowledgment Corrected by Resending a Segment)
손실된 ACK을 수정하는 또 다른 방식으로, 세그먼트가 재전송되며 손실된 ACK을 보상하는 경우이다.

  • ACK이 지연되거나 손실되면, RTO 타이머가 발동하고 세그먼트가 재전송된다.
  • 수신자는 중복 세그먼트를 폐기하고, 마지막 ACK을 보내서 송신자에게 데이터를 안전하게 받았음을 알린다.

세그먼트를 재전송함으로써 교정되는 손실된 확인응답

 

 

8. 확인응답의 손실로 인해 발생하는 교착상태 (Deadlock Created by Lost Acknowledgment)
교착 상태는 수신자가 윈도우 크기를 0으로 설정한 후 ACK을 보내고, 이를 손실되면 송신자와 수신자가 서로 대기하게 되어 발생한다.

  • 수신자가 데이터를 보내지 않고 ACK을 보내는 상황에서 ACK이 손실되면, 송신자는 ACK을 기다리고 수신자는 데이터를 기다리게 된다.
  • 이 상태는 교착 상태에 빠지게 되고, 이를 방지하기 위해 지속 타이머(persistence timer)가 설계되었다.

9.4.9 TCP 혼잡 제어

혼잡창(Congestion Window)

  • TCP는 수신 측의 흐름 제어(rwnd) 외에 혼잡창(cwnd)를 사용하여 네트워크 혼잡을 처리한다.
  • 혼잡 윈도우는 네트워크 내의 혼잡 상황에 따라 크기가 조정된다.
  • 송신자는 실제 윈도우 크기를 rwnd와 cwnd의 최소값으로 결정한다.

혼잡 감지

TCP 송신자는 시간 초과(time-out)와 중복 ACK 3개를 통해 네트워크 혼잡을 감지한다.

  • 시간 초과: 송신자가 세그먼트에 대한 ACK을 정해진 시간 내에 받지 못하면, 해당 세그먼트가 손실되었고 이는 혼잡으로 간주한다.
  • 중복 ACK 3개: 세그먼트가 손실되면 수신자가 중복된 ACK을 보내는데, 3개의 중복 ACK을 받으면 네트워크에서 세그먼트 손실이 발생했음을 나타내며, 이는 가벼운 혼잡을 의미한다.

 

혼잡 정책

1. 느린 시작 (Slow Start)

  • 초기 cwnd는 1 MSS로 시작되며, 매 ACK마다 cwnd가 1씩 증가한다.
  • 성장 속도는 지수적(exponential)으로 증가하므로, 매우 공격적인 방식으로 윈도우 크기가 커진다.
  • 임계값(ssthresh)에 도달하면, 느린 시작은 중지되고 혼잡 회피로 전환된다.

느린 시작, 지수 증가

 

2. 혼잡 회피 (Congestion Avoidance)

  • cwnd느린 시작 임계치(ssthresh)에 도달하면 혼잡 회피로 전환된다.
  • 성장 속도는 가법적(additive)으로 증가하며, 매 RTT마다 1/cwnd만큼 증가합니다. 이는 더 보수적인 방식으로, 네트워크 혼잡을 피할 수 있다.

혼잡 회피, 가산 증가

 

3. 빠른 회복 (Fast Recovery)

  • 세그먼트 손실이 발생하고 중복 ACK 3개가 수신되면, 혼잡을 가볍게 처리하려는 알고리즘입니다.
  • 중복 ACK을 받을 때마다 cwnd1/cwnd만큼 증가합니다.

 

TCP 처리량

  • TCP의 처리량(throughput)은 혼잡 윈도우(cwnd)의 동작 기반이다.
  • cwnd가 일정하다면 처리량은 Throughput = cwnd / RTT
  • 최대값이 최소값의 두 배인 경우 Throughput = 0.75 * Wmax / RTT (Wmax는 혼잡이 발생했을 때의 혼잡 윈도우 크기의 평균)

예시:

MSS = 10 kbytes, RTT = 100 ms일 경우

  • Wmax = (10 + 12 + 10 + 8 + 8) / 5 = 9.6 MSS
  • 처리량 = (0.75 × 9.6 MSS) / 100 ms = 7.2 Mbps

9.4.10 TCP 타이머

1. 재전송 타이머 (Retransmission Timer)

TCP는 재전송 타이머를 사용하여 손실된 세그먼트를 재전송

  1. 세그먼트 전송 시 타이머 시작: 전송 대기 큐에서 세그먼트를 전송할 때 타이머를 시작한다.
  2. 타이머 만료 시 재전송: 타이머가 만료되면 큐에서 첫 번째 세그먼트를 재전송하고 타이머를 재시작한다.
  3. 세그먼트가 확인되면 큐에서 제거: 세그먼트가 확인되면 큐에서 제거된다.
  4. 큐가 비어있으면 타이머 중지: 큐가 비어있으면 타이머가 중지된다.

 

RTT(왕복시간) 계산

  • 측정된 RTT (RTTM): 세그먼트가 목적지에 도달하고 응답을 받을 때까지의 시간.
  • 부드러운(Smoothed) RTT (RTTS): 과거 RTT 값을 고려하여 현재 RTT 값을 평균화한다. 보통 1/8 비율로 업데이트된다.
    • RTTS = (1 - α) * RTTS + α * RTTM
    • 여기서 α는 보통 1/8
  • RTT 편차 (RTTD): RTT의 변화량을 추적합니다
    • RTTD = (1 - β) * RTTD + β * |RTTS - RTTM|
    • β는 보통 1/4
  • 재전송 타임아웃 (RTO)
    • RTO는 RTTSRTTD를 기반으로 계산된다
      • RTO = RTTS + 4 * RTTD
      • RTO는 TCP 연결의 세그먼트를 재전송하기 위한 시간 초과 시간이다.

예제 9.13

예제 9.13

더보기

초기 상태:

  • SYN 세그먼트 전송 시:
    • 초기에는 RTTM, RTTS, RTTD 값이 없다. 첫 번째 SYN 세그먼트를 보낼 때는 RTO가 6초로 설정
    • RTO = 6초 (초기값)

1단계: SYN + ACK 세그먼트 도착 시

  • SYN + ACK 세그먼트가 도착하면 RTTM이 측정된다. 이 시점에서 RTTM은 1.5초로 측정
  • RTTS (부드러운 RTT)는 처음 측정된 RTTM 값과 동일하게 설정된다.
    • RTTS = RTTM = 1.5초
  • RTTD (RTT 편차)는 최초 측정 값의 절반으로 설정된다.
    • RTTD = RTTM / 2 = 1.5 / 2 = 0.75초
  • RTO는 다음 공식에 따라 계산
    • RTO = RTTS + 4 × RTTD = 1.5 + 4 × 0.75 = 4.5초
    • 이때 RTO = 4.5초

2단계: 첫 번째 데이터 세그먼트 전송 시

  • 첫 번째 데이터 세그먼트가 전송되면 새로운 RTT 측정이 시작된다. 이 시점에서는 이미 RTT 측정이 진행 중이기 때문에, 두 번째 데이터 세그먼트 전송 시에는 새로운 RTT 측정이 시작되지 않는다. 대신 첫 번째 데이터 세그먼트의 ACK 세그먼트가 도착하여 RTTM을 계산
  • RTTM = 2.5초로 새로 측정됩니다.
  • RTTS는 이전의 RTTS 값(1.5초)과 새로운 RTTM 값(2.5초)을 반영하여 계산됩니다. RTTS는 가중 평균 방식으로 업데이트
    • RTTS = (7/8) × 1.5 + (1/8) × 2.5 = 1.625초
  • RTTDRTTSRTTM의 차이를 고려하여 계산.
    • RTTD = (3/4) × 0.75 + (1/4) × |1.625 - 2.5| = 0.78초
  • 새로운 RTO는 다음과 같이 계산:
    • RTO = RTTS + 4 × RTTD = 1.625 + 4 × 0.78 = 4.74초

 

Karn의 알고리즘 (Karn's Algorithm)

  • 재전송된 세그먼트에 대한 RTT 계산을 피한다. 세그먼트가 재전송된 경우, 원본 세그먼트의 RTT는 계산하지 않으며, 실제로 ACK가 재전송된 세그먼트에 대해 돌아올 때까지 RTT 값을 업데이트하지 않는다.

 

지수 백오프 (Exponential Backoff)

  • 재전송 시 RTO는 지수적으로 증가합니다. 재전송이 발생할 때마다 RTO가 두 배씩 증가한다.
    • 예를 들어, 첫 번째 재전송 시 RTO = 2 * 기존 RTO, 두 번째 재전송 시 RTO = 4 * 기존 RTO로 증가

9.5 스트림 제어 전송 프로토콜 (SCTP, Stream Control Transmission Protocol)

SCTP는 UDP와 TCP의 장점을 결합한 새로운 전송 계층 프로토콜

 

9.5.1 SCTP 서비스 (SCTP Services)

프로세스 간 통신 (Process-to-Process Communication)

  • TCP 및 UDP처럼 애플리케이션 프로세스 간의 데이터 전송을 제공

다중 스트림 (Multiple Streams)

  • TCP는 하나의 스트림으로 데이터를 전송하기 때문에 패킷 손실 시 전체 데이터 전송이 지연될 수 있다.
  • SCTP는 여러 개의 스트림을 하나의 연결(association)에서 제공하여 하나의 스트림이 지연되어도 다른 스트림은 정상적으로 전송될 수 있다.

다증 스트림

 

멀티호밍 (Multihoming)

  • TCP는 하나의 IP 주소만 사용하지만, SCTP는 여러 개의 IP 주소를 지정 가능하여 네트워크 장애 시 다른 경로로 자동 전환할 수 있다.
  • 아래 그림의 SCTP 구현에서는 로드 밸런싱(부하 분산)은 지원되지 않으며, 기본 경로가 실패했을 때만 대체 경로를 사용

멀티 호밍

 

전이중(full-duplex) 통신 지원

  • TCP처럼 양방향 데이터 전송이 가능하며, 송신 및 수신 버퍼를 갖는다.

연결 지향 서비스 (Connection-Oriented Service)

  • TCP처럼 연결을 설정한 후 데이터를 전송
  • SCTP에서는 이 연결을 association(연관)라고 한다.

신뢰성 있는 데이터 전송 (Reliable Service)

  • 데이터가 안전하게 전달되었는지 확인하는 확인 응답(ACK) 메커니즘을 사용하여 신뢰성을 보장

9.5.2 SCTP 특징

전송 시퀀스 번호 (TSN, Transmission Sequence Number)

  • SCTP는 데이터를 청크(chunk) 단위로 전송하며, 각 데이터 청크에는 TSN(32비트 숫자)이 할당된다.
  • TSN은 TCP의 시퀀스 번호와 유사한 역할을 하며, 흐름 제어 및 오류 제어에 사용된다.

스트림 식별자 (SI, Stream Identifier)

  • 하나의 SCTP 연결(association)에는 여러 개의 스트림이 존재할 수 있다.
  • 각 스트림은 SI(16비트 숫자)를 통해 구별되며, 데이터 청크는 헤더에 SI 값을 포함하여 해당 스트림으로 전달된다.

스트림 시퀀스 번호 (SSN, Stream Sequence Number)

  • 각 스트림 내에서 데이터의 순서를 보장하기 위해 사용된다.
  • TCP의 시퀀스 번호와 달리, SCTP는 스트림별로 별도의 SSN을 관리한다.

패킷

  • TCP는 하나의 세그먼트에 데이터와 제어 정보를 포함
  • SCTP는 패킷 내에서 데이터 청크(data chunk)와 제어 청크(control chunk)를 분리하여 전송
  • 하나의 SCTP 패킷은 여러 개의 데이터 청크와 제어 청크를 포함할 수 있다.

TCP세그먼트와 SCTP 패킷 비교

 

확인 응답(Acknowledgment) 번호

  • TCP의 확인 응답(ACK)은 바이트 단위로 이루어지지만, SCTP는 TSN(청크 단위) 기반으로 ACK를 수행한다.
  • TCP는 제어 정보도 시퀀스 번호를 사용해 ACK를 보내야 하지만, SCTP에서는 제어 청크는 별도의 ACK가 필요 없거나, 특정한 제어 청크로만 확인 응답을 수행한다.
    • 예: INIT 제어 청크 → INIT-ACK 제어 청크로 응답

패킷, 데이터 청크, 스트림

 


9.5.3 SCTP 패킷 형식

  • SCTP 패킷은 일반 헤더(General Header)청크(Chunks) 로 구성
  • 청크는 제어 청크(Control Chunks)데이터 청크(Data Chunks)

SCTP 패킷 형식

 

 

일반 헤더 (General Header)

SCTP 패킷의 헤더는 연결(association)을 식별하고 데이터의 무결성을 보장하는 역할을 한다.
헤더는 4개의 필드로 구성

일반 헤더

  • 출발지 및 목적지 포트 번호
    • UDP 및 TCP와 동일한 방식으로 송신 및 수신 포트를 지정
  • 검증 태그(Verification Tag)
    • 패킷이 특정 association에 속하는지 확인하는 32비트 필드
    • 이전 association의 패킷이 현재 association에서 잘못 처리되는 것을 방지
    • association이 유지되는 동안 모든 패킷에서 동일한 값 유지
  • 체크섬(Checksum)
    • 데이터 무결성을 확인하는 32비트 CRC-32 체크섬 사용

 

청크 (Chunks)

SCTP에서 모든 데이터와 제어 정보는 청크 단위로 전송된다.
각 청크는 공통적인 구조를 가지며, 일부 필드는 청크의 종류에 따라 달라진다.

  • 타입(Type): 청크의 유형을 나타내는 8비트 필드 (최대 256개 유형 정의 가능)
  • 플래그(Flag): 특정 청크에서 필요한 플래그 값 지정 (각 비트의 의미는 청크 타입에 따라 다름)
  • 길이(Length): 청크의 전체 크기를 바이트 단위로 지정 (패딩은 길이에 포함되지 않음)
  • 정보 필드(Information Field): 청크의 유형에 따라 포함되는 정보가 달라짐

청크 공통 형식


9.5.4 SCTP 결합 (Association)

SCTP에서는 연결을Association(연관)이라고 부른다.

 

결합 설정

SCTP는 4단계 핸드셰이크(four-way handshake) 를 통해 association을 설정

네-방향 핸드셰이킹

1. 클라이언트 → 서버 : INIT 전송

  • INIT 청크를 포함한 첫 번째 패킷 전송
  • 검증 태그(Verification Tag)는 0 (아직 정의되지 않음)
  • 클라이언트가 초기 TSN(전송 시퀀스 번호) 및 버퍼 크기(rwnd) 광고

2. 서버 → 클라이언트 : INIT ACK 응답

  • INIT ACK 청크를 포함한 두 번째 패킷 전송
  • 클라이언트가 보낸 INIT 태그 값을 검증 태그로 사용
  • 서버가 초기 TSN 및 자신의 버퍼 크기(rwnd) 광고
  • 현재 서버의 상태를 저장하는 쿠키(cookie) 포함

3. 클라이언트 → 서버 : COOKIE ECHO 전송

  • 서버가 보낸 쿠키를 그대로 반환하는 COOKIE ECHO 청크 전송
  • 이 패킷에는 DATA 청크 포함 가능

4. 서버 → 클라이언트 : COOKIE ACK 응답

  • COOKIE ACK 청크를 포함한 네 번째 패킷 전송
  • association 설정 완료, 데이터 전송 가능
  • DATA 청크 포함 가능

데이터 전송 (Data Transfer)

  • SCTP association이 설정된 후, 양방향 데이터 전송이 가능하다.
  • SCTP는 TCP와 달리 메시지 경계를 유지하는 특징이 있다.

TCP와 SCTP 데이터 전송 차이점

구분 TCP SCTP
데이터 형식 바이트 스트림 (경계 없음) 메시지 단위 (경계 유지)
메시지 처리 여러 메시지를 하나의 세그먼트에 포함 가능 메시지는 개별 DATA 청크로 처리됨
재전송 바이트 단위로 처리 TSN (전송 시퀀스 번호) 단위로 처리

 

DATA 청크의 특징

  • SCTP는 각 메시지를 독립된 DATA 청크로 처리
  • 각 DATA 청크는 TSN(전송 시퀀스 번호) 를 가짐
  • SACK 청크를 이용해 DATA 청크에 대한 확인 응답 전송

결합 종료 (Association Termination)

SCTP에서 결합 종료는 3단계 과정(three-way handshake) 을 따른다.

결합 종료

 

 

1. 클라이언트 → 서버 : SHUTDOWN 전송

  • SHUTDOWN 청크를 포함한 패킷 전송
  • 새로운 데이터 전송 불가, 기존 큐에 있는 데이터만 전송 가능

2. 서버 → 클라이언트 : SHUTDOWN ACK 응답

  • 클라이언트의 SHUTDOWN 요청 확인

3. 클라이언트 → 서버 : SHUTDOWN COMPLETE 전송

  • SHUTDOWN 완료 후 association 해제

SCTP는 TCP와 달리 "Half-Closed 상태"를 허용하지 않음

  • 한쪽에서 연결을 닫으면, 다른 쪽도 즉시 새로운 데이터 전송 중단
  • 큐에 남아 있는 데이터만 전송 후 완전히 종료됨

9.5.5 흐름 제어

  • SCTP의 흐름 제어는 TCP와 유사하지만, 바이트(byte)청크(chunk) 두 가지 단위를 다룬다는 점이 다르다.

수신기 사이트 (Receiver Site)

  • 버퍼(Queue): 수신된 데이터 청크를 저장하는 큐가 있음.
  • 변수 3개:
    1. cumTSN: 마지막으로 수신한 TSN (Transmission Sequence Number) 저장
    2. winSize: 사용 가능한 버퍼 크기
    3. lastACK: 마지막 누적 확인 응답(TSN)

흐음제어, 수신기 사이트

 

수신측의 데이터 처리 과정

 

  1. 데이터를 받으면 저장 → 새 데이터 청크를 버퍼에 저장하고, winSize를 줄인다.
  2. 데이터를 읽으면 공간 확보 → 읽은 데이터는 버퍼에서 제거하고, winSize를 복구한다.
  3. SACK(확인 응답) 전송 → 마지막으로 받은 TSN과 현재 winSize 정보를 포함한 SACK을 보내고, lastACK을 업데이트한다.

 

더보기
  1. 데이터를 받으면 저장
    • 새로운 데이터 청크(조각)를 받으면 버퍼(큐)의 끝에 저장한다.
    • 동시에, 사용 가능한 버퍼 크기(winSize)에서 해당 청크 크기만큼 빼준다.
    • 해당 데이터의 TSN 번호(전송 순서 번호)를 cumTSN 변수에 저장한다.
  2. 데이터를 읽으면 공간 확보
    • 프로세스가 데이터를 읽으면 버퍼(큐)에서 제거한다.
    • 제거한 데이터 크기만큼 다시 winSize에 더해 버퍼를 재활용할 수 있도록 한다.
  3. SACK(확인 응답) 전송
    • 수신 측이 SACK을 보내야 할 때, lastACK 값을 확인한다.
    • lastACK 값이 cumTSN보다 작다면, 현재까지 받은 가장 마지막 TSN 값을 포함한 SACK을 전송한다.
    • 이때, 현재 사용 가능한 창 크기(winSize)도 함께 보내어 송신 측이 참고하도록 한다.
    • SACK을 보낸 후, lastACK 값을 cumTSN으로 업데이트한다.

 

송신기 사이 (Sender Site)

  • 버퍼(Queue): 송신할 데이터 청크를 저장하는 큐가 있음.
  • 변수 3개:
    1. curTSN: 다음으로 전송할 데이터 청크의 TSN
    2. rwnd: 수신자가 광고한 창 크기
    3. inTransit: 아직 확인 응답을 받지 못한 전송 중인 바이트 수

흐름 제어, 송신기 사이트

 

송신측의 데이터 처리 과정

 

  1. 데이터 전송 조건 및 진행  → 수신 측 여유 공간 확인 후 전송, curTSN과 inTransit 조정
  2. SACK(확인 응답) 수신 시 처리    수신 확인된 데이터 삭제, inTransit 줄이기, 최신 창 크기 업데이트

 

더보기

 

  1. 데이터 전송 조건 및 진행
    • 현재 보낼 데이터 청크(조각)는 수신 측의 여유 공간(rwnd - inTransit)보다 작거나 같을 때만 전송할 수 있다.
    • 데이터를 보내면 curTSN 값을 다음 청크로 이동(1 증가) 시킨다.
    • 동시에, 방금 보낸 데이터 크기만큼 inTransit 값을 증가시켜 현재 전송 중인 데이터 크기를 반영한다.
  2. SACK(확인 응답) 수신 시 처리
    • SACK을 받으면, 그 안에 포함된 누적 TSN 값보다 작은 모든 청크는 성공적으로 도착한 것으로 간주하고 제거한다.
    • 즉, 더 이상 신경 쓸 필요가 없으므로 큐에서 삭제한다.
    • 삭제된 데이터 크기만큼 inTransit 값을 줄여 현재 전송 중인 데이터 크기를 다시 조정한다.
    • 또한, 수신 측에서 알려준 최신 창 크기(rwnd)로 업데이트한다.

 


9.5.6 오류 제어

SCTP는 TCP와 유사한 SACK(Selective Acknowledgment) 청크를 사용해 수신 상태를 송신자에게 알린다.

 

수신기 사이트 (Receiver Site)

  • 모든 수신된 청크를 큐에 저장하지만, 순서가 어긋난 청크는 빈 공간을 남겨둠.
  • 중복 청크는 폐기하지만, 보고를 위해 기록.
  • SACK 생성 시, 누락된 데이터 청크 정보를 포함하여 송신자에게 알림.

그림 9.55, 오류 제어, 수신기 사이트

 

송신기 사이트 (Sender Site)

  • 전송 큐: 아직 전송되지 않은 데이터 청크 저장
  • 재전송 큐: 손실된 청크 저장 후 우선 전송
  • 개별 패킷마다 타이머 설정 (일부 구현에서는 하나의 타이머 사용)

그림9.66, 오류 제어, 송신기 사이트

 

 

그림 9.65에서 SANK가 그림 9.66에 있는 송신 사이트에 도착한 결과

SANK 청크를 수신한 후 송신 사이트의 새로운 상태

 

 

  1. 확인된 데이터 삭제 → SACK에서 확인된 TSN 이하의 데이터 청크를 송신 및 재전송 큐에서 제거한다.
    • 청크 21, 22는 재전송 큐에서 삭제, 23은 송신 큐에서 삭제
  2. 갭 블록 내 데이터 삭제 → 수신 측에서 순서가 어긋난 데이터(갭 블록)를 받은 경우, 해당 데이터도 삭제한다.
    • 청크 26에서 28과 청크 31에서 34는 송신 큐에서 삭제
  3. 중복 데이터 무시 → 중복된 데이터 청크는 영향을 주지 않는다.
  4. 수신 창 크기(rwnd) 업데이트 → SACK에 표시된 창 크기(1000)로 업데이트한다.
  5. 재전송 큐로 이동 → 송신 타이머가 만료된 데이터(청크 24, 25)를 재전송 큐로 옮기고 새로운 재전송 타이머를 설정한다.
  6. 전송 중 데이터 크기 조정 → 현재 전송 중인 데이터 크기를 400으로 업데이트한다. (4개의 청크가 지금 전송중이기에 400이 됨).

데이터 청크 전송

  • 송신 큐(curTSN 이상) 또는 재전송 큐에 데이터가 있으면 전송 가능
  • 재전송 큐의 데이터가 우선적으로 전송됨
  • 전송할 데이터 크기는 (rwnd - inTransit) 및 MTU 제한을 초과할 수 없음

SACK 생성 규칙

  1. 새로운 DATA 청크를 송신할 때 SACK 청크 포함
  2. 데이터 수신 후 송신할 데이터가 없으면 500ms 이내에 SACK 전송
  3. 2개 패킷당 1개 이상의 SACK 전송 필수
  4. 순서가 맞지 않는 데이터를 받으면 즉시 SACK으로 보고
  5. 중복된 데이터 청크를 받으면 즉시 SACK으로 보고