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

  1. 본질: 동네 전체에 냅다 소리치는 브로드캐스트(Broadcast)나 특정 단톡방에만 뿌리는 멀티캐스트(Multicast) 통신은, 수천 명과 일일이 1:1로 손을 꽉 잡아야 하는 깐깐한 TCP로는 물리적으로 불가능하며, 오직 묻지도 따지지도 않고 허공에 툭툭 던져버리는 가벼운 UDP 프로토콜만이 수행할 수 있는 전매특허 기술이다.
  2. TCP의 치명적 결함 (왜 안 되나?): TCP는 데이터를 쏘기 전에 상대방과 3-Way Handshake(인사)를 해야 하고, 못 받았다는 놈이 있으면 다시 재전송을 해줘야 한다. 만약 10만 명에게 브로드캐스트로 쐈는데 1,000명이 동시에 "나 못 받았어 다시 줘(ACK 불일치)!"라고 징징대면 **서버는 영수증 폭탄에 맞아 그 자리에서 과로사(ACK Implosion)**하고 만다.
  3. UDP의 쿨한 단방향 살포: UDP는 "내가 뿌리긴 뿌릴 텐데, 너네가 받든 말든 난 알 바 아니야! 영수증(ACK) 따위 안 받을 거니까 못 받은 놈은 걍 포기해!"라는 마인드이기 때문에, 수십만 명에게 멀티캐스트로 영상(IPTV)을 쏟아부어도 서버에 단 1바이트의 부하도 되돌아오지 않는 완벽한 1:N 전송이 성립한다.

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

  • 개념: 송신자가 다수의 수신자(1:All 또는 1:N)에게 데이터를 동시에 전송하는 통신 기법으로, 상태 추적 및 신뢰성 보장이 불필요/불가능한 특성 때문에 전송 계층 프로토콜 중 오직 비연결 지향형인 UDP만을 기반으로 동작한다.

  • 필요성: 올림픽 축구 결승전을 인터넷 생중계한다 치자. 시청자가 10만 명이다. TCP를 쓰면 서버 1대가 10만 명과 각각 따로따로 TCP 세션 터널을 10만 개 파야 한다(1:1 유니캐스트). 그리고 10만 명에게 각기 다른 속도로 똑같은 영상을 10만 번 복사해서 쏜다. 서버는 터진다. "야! 내가 스피커로 한 번만 딱 방송(멀티캐스트)할 테니까 듣고 싶은 놈들만 라디오 켜서 들어라! 중간에 잡음 껴서 한 단어 못 들었다고 나한테 다시 말해달라고 태클 걸지 말고!!" 이 위대한 아이디어가 인터넷 생방송(IPTV)과 게임 로비 방송의 근간이 되었다.

  • 💡 비유: TCP가 **"1:1 과외"**라면, UDP 멀티캐스트는 **"대형 마이크 연설"**입니다.

    • 1:1 과외 (TCP): 선생님이 학생과 눈을 맞추며 "이해했니?(ACK)" 묻고, 학생이 "아니요" 하면 다시 설명해 줍니다. 100명을 이렇게 가르치면 선생님은 죽습니다.
    • 대형 마이크 연설 (UDP 멀티캐스트): 선생님이 운동장 단상에 서서 확성기로 떠듭니다. 학생이 1명이든 10만 명이든 선생님의 목 아픔(서버 부하)은 똑같습니다. 학생이 딴짓하다 한 단어를 놓쳐도 선생님은 절대 뒤로 돌아가서 다시 설명(재전송)해주지 않고 그냥 쭉 진도 나갑니다.

📢 섹션 요약 비유: 브로드캐스트와 멀티캐스트 통신은 비행기에서 삐라(전단지)를 살포하는 **"공중 투하 작전"**입니다. 비행기 조종사(UDP)는 그냥 하늘에서 수만 장을 툭 던질 뿐, 길바닥의 시민 1번이 전단지를 주웠는지, 바람에 날아갔는지(유실) 일일이 확인 도장을 받으러 다니지 않습니다.

Ⅱ. TCP 불가의 원리와 UDP 기반 서비스 (Deep Dive)

1. ACK 폭풍 (ACK Implosion)의 공포

만약 TCP로 멀티캐스트를 구현했다고 가정해 보자. (실제론 불가능하다).

  1. 서버가 멀티캐스트 IP(239.1.1.1)로 영상 패킷 1개를 훅 던진다.
  2. 전국에 있는 100만 대의 PC가 영상을 동시에 받는다.
  3. TCP의 룰: "잘 받았으면 무조건 서버한테 영수증(ACK) 쏴라!"
  4. 100만 대의 PC가 0.1초 만에 일제히 서버를 향해 "나 1번 패킷 잘 받았어!!" 라며 100만 개의 ACK 패킷을 융단폭격한다.
  5. 서버는 자기가 보낸 트래픽이 아니라, 오히려 전국에서 되돌아오는 영수증 폭풍(ACK Implosion)에 두드려 맞고 디도스(DDoS) 급 트래픽 부하로 그 자리에서 즉사한다. 이것이 TCP가 멀티캐스트를 절대, 네버, 꿈도 꾸지 못하는 근본적인 수학적 한계다.

2. UDP를 등에 업은 방송 서비스들 (실무 암기)

그래서 1:N 통신을 하는 서비스는 무조건 UDP 껍데기를 씌워 날아간다.

  • IPTV / 실시간 방송: 넷플릭스 같은 건 혼자 따로 보니까 TCP(유니캐스트)지만, 올레TV 같은 통신사 실시간 야구 중계는 100% UDP 멀티캐스트다. 중간에 화면이 깍두기 모양으로 깨져도 그냥 찰나의 순간 지나가 버리고 만다.
  • DHCP (IP 자동 할당): 내 폰이 "야 동네 공유기들 중에 남는 IP 있는 놈!" 하고 브로드캐스트(UDP 67/68)로 소리쳐서 받아온다.
  • RIP 라우팅 프로토콜: "동네 사람들! 내 지도 여기 있어!" 하고 30초마다 브로드캐스트나 멀티캐스트로 냅다 던지는 바보 프로토콜 역시 가벼운 UDP(520번) 껍데기를 타고 움직인다.
 ┌─────────────────────────────────────────────────────────────┐
 │                TCP(1:1) vs UDP(1:N)의 서버 부하 극단적 비교      │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [ 상황: 10GB짜리 영상을 10,000명에게 라이브 방송할 때 ]               │
 │                                                             │
 │   * TCP (유니캐스트 1:1 방식)                                  │
 │     - 1만 명과 3-way Handshake를 1만 번 맺어야 함! (메모리 파괴) │
 │     - 10GB 영상을 1만 번 복사해서 쏨. 총 전송량: 100,000 GB !!    │
 │     - 1만 명의 징징대는 재전송 요구(ACK)를 다 받아줘야 함. (서버 사망)│
 │                                                             │
 │   * UDP (멀티캐스트 1:N 방식)                                  │
 │     - Handshake 없음! 메모리 소모 0!                          │
 │     - 10GB 영상 딱 1개만 스위치 허공에 던짐. (나머진 라우터가 복사함) │
 │     - 피드백(ACK) 아예 차단! 서버는 던지고 퇴근. (서버 쾌적)        │
 │                                                             │
 │   ▶ "이 압도적인 연산량의 차이 때문에 다중 통신은 UDP의 영원한 독점이다."│
 └─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: TCP 멀티캐스트가 불가능한 이유는, 10만 명에게 무료 콘서트를 열어주고 입장객 10만 명 모두에게 **"공연 어땠는지 일일이 자필 소감문(ACK)을 써서 내 책상에 올려둬라"**고 시키는 짓이기 때문입니다. 다음 날 사장님 책상은 10만 장의 소감문 폭탄에 파묻혀 업무 마비가 옵니다.