핵심 인사이트 (3줄 요약)

1. 본질: SCTP는 TCP의 "무거운 신뢰성(1차선 도로)"과 UDP의 "빠르지만 개판인 순서(무질서)" 사이에서 딜레마에 빠진 엔지니어들이, TCP의 신뢰성을 유지하면서도 여러 개의 데이터 흐름을 동시에 쏴버리는 멀티 스트림(Multi-stream) 기능과, 랜선 두 개를 묶어 쓰는 멀티 호밍(Multi-homing)을 집어넣어 만든 4계층의 혼종 끝판왕이다.
2. 멀티 스트림 (Head-of-line Blocking 타파): TCP는 1차선이라 앞차가 사고 나면 뒷차가 싹 다 막히지만, SCTP는 터널 안에 여러 개의 독립된 차선(스트림)을 파놓고 달리기 때문에 2번 차선에서 사고가 나도 1, 3, 4번 차선은 멈춤 없이 쾌속 질주할 수 있는 구조적 쾌적함을 자랑한다.
3. 4-Way Handshake와 쿠키 (보안성): 통신을 시작할 때 TCP(3-way)의 치명적 약점인 'SYN Flooding 해킹'을 원천 봉쇄하기 위해, 서버가 자리를 안 내어주고 대신 암호화된 '쿠키(Cookie)'를 던져서 4번의 핑퐁(4-way Handshake)을 거쳐야만 진짜 손님으로 인정해 주는 강력한 방어 체계를 쓴다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: IP 네트워크 상에서 다중 스트림(Multi-stream)과 다중 홈(Multi-homing)을 지원하며 메시지 지향성(Message-oriented)과 신뢰성을 동시에 제공하는 IETF 표준 전송 계층 프로토콜 (RFC 4960). IP 프로토콜 번호 132번을 사용한다.

• 필요성: 통신사 백본망에서 전화망(SS7) 신호 데이터를 IP망 위로 얹어 나르려고(SIGTRAN) 했다. TCP를 쓰자니 패킷 1개 잃어버릴 때마다 뒤에 오던 전화 신호들이 통째로 다 멈춰버리는 끔찍한 현상(Head-of-Line Blocking)이 터졌다. UDP를 쓰자니 신호가 다 유실돼서 통화가 안 걸렸다. "야! TCP처럼 완벽하게 배달은 해주되, 패킷을 종류별로 1차선, 2차선, 3차선으로 찢어서 보내! 1차선(음성) 패킷이 죽어서 멈춰도 2차선(화면) 패킷은 영향받지 않고 계속 달리게 만들어!!"

• 💡 비유: SCTP의 멀티 스트림은 **"고속도로 톨게이트 차선"**과 같습니다.

  • TCP (단일 스트림): 1차선 도로입니다. 맨 앞의 똥차가 퍼져서 멈추면(패킷 유실), 뒤에 따라오던 수백 대의 벤츠와 페라리가 모조리 서서 기다려야 합니다 (HOL Blocking).
  • SCTP (멀티 스트림): 왕복 8차선 고속도로입니다. 1차선에서 트럭이 엎어져도, 2차선, 3차선에 있는 차들은 1차선 사고와 1도 상관없이 시속 100km로 쌩쌩 달릴 수 있습니다.

📢 섹션 요약 비유: SCTP는 TCP의 **"정확도(신뢰성)"**와 UDP의 **"메시지 경계 유지(독립성)"**라는 장점만 쏙쏙 빼먹은 하이브리드 명품입니다. 한 바구니에 계란을 다 담아 앞사람이 넘어지면 다 박살 나는 TCP와 달리, 계란을 여러 바구니(스트림)에 나눠 담아 한 바구니를 떨어뜨려도 나머지는 무사히 배달되는 궁극의 안전 배송 시스템입니다.

Ⅱ. SCTP의 3대 혁신 메커니즘 (Deep Dive)

현대 5G 코어 통신망이나 통신사 백본에서 없어서는 안 될 핵심 프로토콜이다.

1. 멀티 호밍 (Multi-homing) - 생존의 극대화

앞서 배운 MPTCP와 비슷한 개념이지만, SCTP가 원조다.

• 내 컴퓨터에 KT 랜선 1개, SKT 랜선 1개 총 2개의 IP가 꽂혀있다.
• SCTP로 서버와 세션을 맺을 때 엽서에 이렇게 적는다. "나 IP 두 개(10.x, 20.x) 다 내 거야!"
• 평소엔 10.x 메인 랜선으로 통신한다.
• 갑자기 포크레인이 KT 선을 끊어먹었다!
• SCTP는 TCP처럼 세션이 터져서 다운로드가 취소되는 게 아니라, 0.1초 만에 살아있는 백업 랜선(20.x)으로 트래픽을 자동 스위칭하여 통신을 무중단으로 살려낸다. (서버 이중화에 미친 듯이 좋다).

2. 쿠키 기반 4-Way Handshake (해킹 방어)

TCP의 3-Way Handshake는 서버가 SYN을 받자마자 메모리에 '대기실'을 파놓고 손님을 기다리다 메모리가 꽉 차서 죽는 SYN Flooding 공격에 너무 취약했다. (TCP는 나중에 SYN Cookie라는 꼼수로 해결했다). SCTP는 애초에 태어날 때부터 이걸 완벽히 막아버렸다.

1. 클라이언트: "야 연결하자! (INIT)"
2. 서버: "그래? 근데 난 너 못 믿어서 내 메모리(대기실) 안 내어줄 거야. 대신 이 암호화된 State Cookie 덩어리나 받아라! (INIT ACK)" (서버는 엽서만 던지고 자기는 다 잊어버림).
3. 클라이언트: "아 치사하네... 옛다 네가 아까 준 쿠키 다시 가져왔다! 나 진짜 손님 맞어! (COOKIE ECHO)"
4. 서버: "오, 진짜 내 쿠키 맞네? 인증 완료! 이제야 내 메모리에 널 위한 방을 하나 파줄게. 들어와! (COOKIE ACK)" ▶ 이 4번의 핑퐁(4-Way) 덕분에 해커가 가짜 INIT 패킷을 수억 개 쏴도 서버는 쿠키만 던질 뿐 메모리를 1바이트도 쓰지 않아 절대 죽지 않는다.

 ┌─────────────────────────────────────────────────────────────┐
 │                TCP vs SCTP의 Handshake와 병목 차이              │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [ 통신 시작 방식의 차이 ]                                     │
 │   * TCP : SYN -> SYN/ACK -> ACK  (3-Way, 메모리 할당 일찍함)     │
 │   * SCTP: INIT -> INIT ACK(쿠키) -> COOKIE ECHO -> COOKIE ACK │
 │           (4-Way, 쿠키를 들고 와야만 메모리 할당해 줌. 해킹 방어 짱!)  │
 │                                                             │
 │   [ 데이터 전송 방식의 차이 ]                                   │
 │   * TCP (단일 차선): 앞 패킷 유실되면 뒷 패킷들 줄줄이 대기 (HOL 병목)│
 │   * SCTP (다중 차선): Stream 1 패킷 유실돼도, Stream 2, 3 패킷은   │
 │                     대기 없이 목적지 앱으로 쾌속 직행! (HOL 타파)  │
 └─────────────────────────────────────────────────────────────┘

3. 메시지 단위(Message-oriented) 전송

TCP는 물줄기(Stream) 방식이라 앱이 "안녕" "하세요"를 던져도 수신자는 "안녕하세" "요" 처럼 지 맘대로 썰어서 받는다. SCTP는 UDP처럼 "앱이 던진 덩어리(메시지)의 경계를 완벽하게 지켜서" 1번 박스와 2번 박스를 섞지 않고 정확히 분리해서 전달해 준다. (앱 개발자가 파싱하기 너무 편하다).

📢 섹션 요약 비유: SCTP의 쿠키(Cookie) 방식은 클럽 입구의 **"예약금 제도"**입니다. TCP 클럽은 손님이 "갈게요(SYN)" 전화만 해도 테이블(메모리)을 비워둬서 노쇼(해커)에 망합니다. 하지만 SCTP 클럽은 "갈게요" 전화하면 **"입금 계좌(쿠키)"**만 문자로 보내고 테이블을 안 비워둡니다. 손님이 진짜로 **"입금 완료(Cookie Echo)"**를 해야만 그제야 빈 테이블을 잡아줍니다. 절대 노쇼에 당하지 않습니다.