[네트워크] 11. 전송 계층 (L4: 3-way handshake, TCP, UDP, RTP)

1. 전송 계층 정의와 역할

 

전송계층(L4)는 데이터링크 계층(L2)와 유사하다.

• 데이터링크 계층(L2): 물리적으로 직접 연결된 호스트 간(Node-to-Node)의 전송을 담당한다.
• 전송 계층(L4): 네트워크 끝단에 있는 호스트 간(End-to-End)의 논리적인 연결을 담당한다.

 

[전송계층의 주요 기능]

• 흐름 제어 (Flow Control): 송신 속도가 수신 속도보다 빠를 경우 수신 버퍼 오버플로우가 발생할 수 있으므로, 수신 측이 송신 측의 윈도우 크기(보낼 수 있는 패킷 수)를 제어하여 속도를 조절한다(슬라이딩 윈도우). 전송 계층은 논리적 연결마다 별도의 흐름 제어를 수행함.
• 오류 제어 (Error Control): 데이터의 변형이나 분실 시 재전송을 통해 복구한다.
  (재전송에 기반한 오류제어: CRC 체크섬 → ARQ)
• 분할과 병합: 상위 계층의 데이터를 전송 가능한 크기로 나누거나(분할), 수신 후 다시 원래대로 합치는(병합) 과정을 수행한다.

 

 

[전송계층의 주소 표현]

• 전송 계층의 주소는 TSAP(Transport Service Access Point)라고 한다.
• 네트워크 계층의 IP 주소 + 전송계층의 포트 번호의 조합으로 구성된다.

---

2. 연결 설정 및 연결 해제 (3-Way Handshake)

(1) 연결 설정 (3-Way Handshake)

 

• 연결 설정은 일반적으로 3단계 절차(3-Way Handshake)를 따른다.
• 과정: Conn_Req(요청) → Conn_Ack(수락 및 응답) → Data_Req(데이터 전송 및 확인).
• 세 번째 단계에서는 ACK를 별도로 보내지 않고 데이터에 포함(Piggybacking)하여 전송 효율을 높일 수 있다.

 

 

(2) 연결 해제

[일방적 연결 해제]	[점진적 연결 해제]

• 일방적 해제: 한쪽이 Disc_Req를 보내면 즉시 연결이 끊긴다. 전송 중인 데이터가 유실될 위험이 있음.
• 점진적 해제: 양쪽 모두 Disc_Req를 보내야 연결이 완전히 해제된다. 한쪽이 해제 요청을 해도 다른 쪽은 데이터를 계속 보낼 수 있어 데이터 손실을 방지함.

---

3. TCP 프로토콜 구조 및 헤더

 

TCP 프로토콜: 인터넷 환경에서 가장 널리 쓰이는 신뢰성 있는 프로토콜

 

[TCP 특징]

• 연결형 서비스 제공
• 전이중(Full Duplex) 방식의 양방향 가상 회선을 제공(즉, 데이터 송신과 수신이 동시에 발생할 수 있음)
• 신뢰성 있는 데이터 전송을 보장
• 피기배킹 지원
• 데이터를 세그먼트라는 블록 단위로 분할해 전송 (전송되는 블록은 가변크기를 지원)

---

[TCP 헤더 필드]

• Source/Dest Port: 송수신 프로세스 식별.
• Sequence Number: 데이터의 순서 번호 (바이트 단위로 증가).
• Acknowledgement Number: 다음에 수신하기를 기대하는 바이트 번호 (누적 ACK).
• Data Offset: 헤더의 크기.
• Window: 수신 버퍼의 여유 공간을 알려주어 흐름 제어에 사용.
• Checksum: 헤더와 데이터의 오류 검출.
• Urgent Pointer: 긴급 데이터의 위치 표시.

---

[플래그 비트]

• 주요 플래그: SYN(연결 요청), ACK(응답 유효), FIN(연결 종료), RST(리셋), URG(긴급), PSH(즉시 전달).
• 혼잡 제어용 플래그(ECN): CWR(윈도우 줄임 통지), ECE(혼잡 경고), NS(Nonce Sum) 등이 RFC 업데이트를 통해 추가됨.

---

4. TCP 데이터 전송과 오류 제어

• TCP 프로토콜: 전이중 방식의 양방향 통신을 지원 (= 양방향으로 동시 전송 가능)
• 전송데이터와 응답데이터를 함께 전송하는 피기배킹 기능을 사용할 수 있다

 

(1) 연결 설정 (3-Way Handshake)

• A(SYN, Seq=10) → B(SYN+ACK, Seq=50, Ack=11) → A(ACK, Seq=11, Ack=51) 순서로 연결이 수립된다.

---

(2) 데이터 전송 및 흐름 제어

• 슬라이딩 윈도우: 수신 측이 Window 필드 값을 통해 송신 측 전송량을 조절한다.
• 피기배킹: ACK만 따로 보내지 않고 전송할 데이터가 있다면 함께 묶어서 보낸다.

---

(3) 오류 제어

• TCP는 부정 응답(NAK)을 쓰지 않고, 타임아웃(Timeout)을 통해 패킷 분실이나 변형을 처리함.
• 특정 패킷(Seq=31) 응답이 오지 않으면 타임아웃 후 해당 패킷을 재전송한다.

---

(4) 연결 해제

• 점진적 해제 방식을 사용하여, FIN을 보내도 상대방이 FIN으로 응답할 때까지 연결을 유지하며 잔여 데이터를 모두 받는다.
• 양방향으로 fin, fin이 되어야 연결이 해제된다.

---

5. TCP 혼잡 제어

: 흐름 제어(송수신자 간 문제)와 달리 네트워크 전체의 혼잡(패킷 분실(라우터 오버플로우), 전송지연시간 증가(라우터에서 패킷 스위칭이 처리되는데 걸리는 시간 증가) 등)을 해결한다.

 

[용어]

• cwnd (Congestion Window): 송신 측이 ACK 없이 보낼 수 있는 최대 바이트 수로, 이를 조절해 전송 속도를 제어함.
• MSS (Maximum Segment Size): 한 개의 세그먼트의 최대 크기
• RTT (Round Trip Time): 송신 호스트 입장에서 세그먼트를 보낸 시간부터 ACK를 수신한 시간의 차이

[혼잡 감지의 2가지 경우]

• [timeout]: 전송한 세그먼트에 대해 타임아웃 발생
• [3 duplicate ACK]: 동일한 ACK를 3번 수신 (이때 ACK는 누적 ACK)

---

(1) 종단간 혼잡 제어 (end to end)

• AIMD (Additive Increase Multiplicative Decrease):
  혼잡이 없으면 매 RTT마다 cwnd 윈도우를 1씩 증가(AI), 혼잡 감지시 cwnd를 한번에 반으로 감소(MD)시킨다.
• TCP 전송률은 대략적으로 cwnd의 크기라고 볼 수 있다. 왜냐하면 ACK를 기다리지 않고 보낼 수 있는 수이기 때문.

 

[혼잡제어 알고리즘]

TCP에서 기본적으로 사용하는 종단간 혼잡 제어 기법은 세가지 주요 컴포넌트로 구성된다.

1. Slow Start (SS): 초기에는 윈도우 크기(cwnd)를 1부터 시작하여 매 RTT마다 2배씩 지수적으로 증가시킴.
2. Congestion Avoidance (CA): 윈도우(cwnd)가 임계치(ssthresh)에 도달하면 선형적으로(1씩) 증가시켜서 혼잡을 사전에 예방함 
3. Fast Recovery (FR): 혼잡 탐시시 cwnd를 1이 아닌 cwnd/2로 감소시켜 혼잡에 대처하면서 동시에 빠르게 원래 전송 속도로 복귀할 수 있게 준비

 

[파생되는 여러가지 버전들]

• Tahoe: 타임아웃이나 3 dup ACK 발생 시 무조건 cwnd를 1로 줄이고 Slow Start에 따라 cwnd 값을 증가시킴.
• Reno: 타임아웃 시에는 혼잡이 명확하므로 cwnd를 1로 줄이지만, 3 dup ACK 시에는 혼잡이 아닐수도 있으므로 Fast Recovery를 수행하여 cwnd를 절반으로만 줄인 후 그 지점부터 다시 증가시킨다(효율적).

---

(2) 네트워크 지원형 혼잡 제어 (ECN)

• 라우터가 혼잡을 감지하면 IP 헤더에 표시(CE)하여 수신자에게 알리고, 수신자는 TCP 헤더(ECE)로 송신자에게 알린다. 송신자는 속도를 줄이고 CWR 플래그로 응답한다.

---

6. UDP 프로토콜

UDP 프로토콜: 인터넷에서 사용하는 전송계층 프로토콜 중 구조가 가장 간단한 프로토콜로 신속성이 중요하거나 데이터 손실이 허용되는 환경에서 사용하는 프로토콜

 

[특징]

• 비연결형 서비스(데이터그램)를 제공한다.
• 비신뢰성(Best Effort) 전달 방식을 지원한다. (최선을 다하지만, 결는 보장 못한다. 보내고 그냥 끝)
  • 최종 목적지에서 ACK를 보내지 않는다. (TCP는 보내줌)
• 단순한 헤더구조(헤더 8바이트)를 갖는다.
• DNS(단발성), 실시간 멀티미디어, 게임(빠른 반응 속도 필요) 등에서 사용된다.
• TCP는 3-way handshake를 통해 연결을 수립하는 과정이 있지만 UDP는 없다.
• 프로토콜 구조가 간단해서 TCP보다 데이터 처리가 빠르므로 전송 시간에 민감한 실시간 환경 등에서 사용하는 것이 유리
• 실시간으로 패킷이 도착하는 순서가 중요한 응용프로그램(VoIP 목소리) 등에 사용된다.
  • 음성채팅에서 TCP를 사용하면 재전송이 발생하는 경우 의미가 바뀔 수 있으므로 그냥 UDP로 구현하는 것이 좋다.

TCP를 음성 채팅에 쓰면 생길 수 있는 일

• 데이터 분실이나 순서 변경(도착 순서 바뀜)이 발생해도 UDP 자체적으로는 해결하지 않고 상위 계층에서 처리해야한다.

 

[TCP UDP 비교]

---

7. RTP 프로토콜 - (TCP + UDP 하이브리드 방식)

• 실시간 스트리밍은 약간의 데이터 손실보다 지연(Delay)과 지터(Jitter, 데이터그램이 불규칙하게 도착하는 정도) 해결이 더 중요했다. 
  (정해진 시간내에 도착하지 않은 데이터그램은 무용지물이기 때문)
• UDP 베이스에 순서 번호와 타임스탬프 기능을 추가해서 순서 정렬과 동기화를 지원하는 것이 RTP이다.

[지터 버퍼]

• 네트워크에서 데이터의 전송 시간 간격이 불규칙적으로 변할 수 있다.(jitter가 불규칙적)
• 수신 프로세스 측에 버퍼를 두어 불규칙하게 도착하는 패킷을 모았다가 일정한 간격으로 재생하고, 일정 데드라인을 넘긴 데이터는 버리는 방식으로 동작하게 한다.
• leaky bucket과 비슷한 느낌이다.

 

[지터 (Jitter)]

 

[RTP 구조]

 

• 실시간 서비스를 위해, 기능이 간결한 UDP 위에서 동작한다.
• 일부러 불완전한 형태의 라이브러리 형태로 구현되어있는데 어플리케이션마다 fine tuning을 유도한 것이다.
  (응용 프로그램 라이브러리 형태(ALF)로 구현)
• 믹서와 트랜스레이터는 두 종류의 RTP 릴레이를 지원한다. 믹서는 데이터그램 스트림의 믹싱에 관한 문제를 다루고, 트랜스레이터는 특정한 변환 작업을 수행한다.
  • Mixer: 여러 프로세스로부터 RTP 데이터그램 스트림을 받아 적절히 조합해 새로운 데이터그램 스트림 생성
    (예: 영상 스트림과 음성 스트림 믹싱 → 새로운 동영상 스트림 생성)
    
  • Translator: 고화질을 저화질로 변환해 수신프로세스가 능력이 부족해도 처리할 수 있게 도와줌, 입력된 멀티캐스트 RTP 데이터그램을 복사해 다수의 유니캐스트 수신 프로세스에 전송함.

 

[RTCP: RTP 제어 프로토콜]

: 데이터 전송 자체를 담당하지 않고, 패킷 손실률, 지터 등의 품질 정보(QoS)를 피드백하여 전송률을 조절하도록 돕는다.