난이도: 중

해설 — 멀티캐스트·브로드캐스트: 유니캐스트 대비 트레이드오프와 게임 서버 활용

1. 유니캐스트 / 브로드캐스트 / 멀티캐스트

• 유니캐스트(unicast): 1:1 전송. 송신자는 목적지 하나의 IP를 명시하고, 네트워크는 그 하나의 호스트에게만 패킷을 전달한다. 일반적인 클라이언트-서버 통신은 전부 유니캐스트다.
• 브로드캐스트(broadcast): 1:전체(같은 서브넷 내 모든 호스트). 목적지 주소로 해당 서브넷의 브로드캐스트 주소(예: 192.168.0.255, 전역 브로드캐스트는 255.255.255.255)를 쓴다. 라우터는 기본적으로 브로드캐스트를 다른 네트워크로 전달하지 않는다(로컬 서브넷에 갇힘).
• 멀티캐스트(multicast): 1:그룹(관심 있는 호스트들만). 224.0.0.0 ~ 239.255.255.255 범위의 클래스 D 주소를 그룹 주소로 쓰고, 그 그룹에 "가입(join)"한 호스트에게만 라우터/스위치가 패킷을 전달한다. 브로드캐스트보다 세밀하게 수신자를 제어할 수 있다.

IPv6에는 브로드캐스트 개념 자체가 없고 멀티캐스트로 통합되어 있다(ff00::/8).

2. 왜 UDP 기반인가, IGMP의 역할

TCP는 1:1 연결(connection) 상태를 유지하는 프로토콜이라, "그룹"이라는 개념과 근본적으로 맞지 않는다. 하나의 송신자가 그룹 내 각 수신자와 개별 TCP 연결(핸드셰이크, 시퀀스 번호, 재전송 타이머 등)을 맺어야 한다면 이미 멀티캐스트가 아니라 유니캐스트의 반복이 되어 버린다. 반면 UDP는 비연결형이라 하나의 패킷을 그룹 주소로 "뿌리기만" 하면 되므로 멀티캐스트의 자연스러운 전송 계층이 된다. 대신 신뢰성(순서 보장, 재전송)은 애플리케이션이 직접 구현해야 한다.

**IGMP(Internet Group Management Protocol)**는 호스트가 "나는 이 멀티캐스트 그룹의 멤버가 되고 싶다"고 로컬 라우터에게 알리는 프로토콜이다. 라우터는 IGMP 메시지를 통해 각 인터페이스 너머에 특정 그룹을 구독 중인 호스트가 있는지 파악하고, 그에 따라 멀티캐스트 트래픽을 선택적으로 포워딩(또는 가지치기, pruning)한다. 즉 멀티캐스트가 "관심 있는 사람에게만" 도달하게 만드는 신호 체계다.

3. 대역폭/CPU 비교와 실무에서 안 쓰는 이유

• 유니캐스트 100회: 서버가 같은 패킷을 100번 직렬화·전송해야 한다. 서버의 업링크 대역폭을 100배 소모하고, 시스템 콜(sendto)도 100번 호출된다.
• 멀티캐스트 1회: 서버는 패킷을 한 번만 내보내면 되고, 패킷 복제는 네트워크 장비(스위치/라우터)가 트래픽 트리를 따라 수행한다. 이론적으로 서버 측 대역폭·CPU 부하가 크게 줄어든다.

하지만 실제 대규모 온라인 게임(특히 인터넷을 통한 서비스)에서 클라이언트 대상 멀티캐스트를 쓰지 않는 이유는 다음과 같다.

• 인터넷 멀티캐스트 라우팅 미보급: 대부분의 ISP/백본 라우터가 멀티캐스트 라우팅(PIM 등)을 활성화하지 않는다. 실질적으로 인터넷 전역에서 멀티캐스트는 거의 라우팅되지 않는다고 봐야 한다. 즉 회사 밖 일반 사용자에게는 애초에 도달하지 않는다.
• NAT/방화벽과의 상성 문제: 가정용 공유기, 기업 방화벽 대부분이 멀티캐스트 트래픽을 차단하거나 다루지 못한다.
• 개인화된 데이터 요구: MMORPG의 대부분의 패킷은 "모두에게 동일한 내용"이 아니라 플레이어별 시야(interest management), 권한, 개인화된 상태 차이를 반영해야 하므로 애초에 그룹 브로드캐스트로 보낼 수 있는 데이터가 제한적이다.
• 신뢰성/순서 제어의 어려움: 그룹 전체에 대해 재전송·순서 보장을 구현하는 복잡도가 유니캐스트 대비 훨씬 크다(누가 못 받았는지 개별 추적 필요).
• 서버 측 최적화로 충분히 대체 가능: 관심 영역(AoI, Area of Interest) 기반으로 유니캐스트 전송 대상을 좁히고, 서버 내부적으로 패킷 버퍼를 한 번만 직렬화해 여러 소켓에 sendto만 반복하는 방식으로도 CPU 비용을 상당히 줄일 수 있다.

응용 시나리오 풀이

LAN 파티 서버 디스커버리 설계

같은 서브넷 안에서는 브로드캐스트/멀티캐스트가 잘 동작하므로 로컬 디스커버리에 적합하다.

• 소켓 설정: UDP 소켓을 열고 SO_BROADCAST 옵션을 활성화(브로드캐스트 방식일 경우 송신 측에 필요)하거나, 멀티캐스트 방식이면 IP_ADD_MEMBERSHIP(또는 setsockopt로 멀티캐스트 그룹 join)을 사용한다. 수신 측은 잘 알려진 포트(예: UDP 45678)로 바인드하고, 여러 프로세스가 같은 포트를 재사용할 수 있도록 SO_REUSEADDR/SO_REUSEPORT를 설정한다.
• 흐름: 방을 찾는 클라이언트가 "PING/DISCOVER" 패킷을 서브넷 브로드캐스트 주소(또는 지정된 멀티캐스트 그룹)로 전송한다. 방을 호스팅 중인 각 PC는 이 요청을 받으면 자신의 방 정보(방 이름, 인원, IP:포트)를 담아 요청자에게 유니캐스트로 응답한다. 이후 실제 게임 트래픽(입력, 상태 동기화)은 발견된 IP로 유니캐스트/P2P 연결을 맺어 진행한다. 즉 "찾기"만 브로드캐스트, "게임 플레이"는 유니캐스트로 분리하는 것이 일반적 패턴이다.

인터넷 매치메이킹 서버로 확장되지 않는 이유

브로드캐스트는 애초에 서브넷을 벗어나지 못하도록 라우터가 차단하고, 멀티캐스트는 앞서 설명했듯 대부분의 인터넷 백본/ISP가 라우팅을 지원하지 않는다. 클라우드 데이터센터의 실제 매치메이킹 서버는 전 세계에 흩어진 클라이언트를 상대해야 하는데, 이들 사이에는 신뢰할 수 있는 멀티캐스트 경로가 존재하지 않는다. 따라서 인터넷 규모에서는 결국 각 클라이언트와 개별 유니캐스트(TCP/HTTP 또는 UDP) 연결을 맺을 수밖에 없다.

분산 게임 서버 간 이벤트 전파 대안

여러 물리 서버에 걸친 존(zone) 서버들에게 이벤트를 전파할 때는 네트워크 계층의 IP 멀티캐스트 대신, 애플리케이션/미들웨어 계층의 pub/sub 메시지 브로커(Redis Pub/Sub, Kafka, NATS, RabbitMQ 등)를 사용하는 것이 실무 표준이다. 이유는 다음과 같다.

• 데이터센터 내부망이라도 라우터/스위치의 멀티캐스트 설정에 의존하지 않고 TCP 기반으로 안정적으로 동작한다.
• 메시지 브로커는 재전송, 순서 보장, 컨슈머 그룹, 장애 복구(재접속 시 유실분 재수신) 등을 이미 구현해 제공한다.
• 구독(subscribe) 토픽 단위로 라우팅을 세밀하게 제어할 수 있어(예: zone.3.events), 특정 존 서버들만 정확히 타겟팅하기 쉽다.
• 수평 확장이 용이하고, 운영/모니터링 도구(지연, 처리량, 백프레셔 확인)가 잘 갖춰져 있다.

즉 "네트워크 수준의 멀티캐스트"는 인프라 제약 때문에 인터넷 서비스에는 거의 쓰이지 않고, 그 역할은 애플리케이션 계층의 메시지 브로커가 대신한다.