# Unicast vs Multicast

#### 유니캐스트와 멀티캐스트의 기본 개념

유니캐스트(Unicast)는 말 그대로 1:1 통신 방식이다. 전송 주체(송신자)와 수신자가 정확히 한 쌍으로 연결되어, 특정 목적지 IP 주소 한 곳에만 데이터를 전송한다. 일반적으로 인터넷상에서 가장 많이 사용되는 통신 방식이며, TCP/UDP 프로토콜 상에서도 상대방 단일 IP와 포트를 지정해 데이터를 전송한다.

멀티캐스트(Multicast)는 1:N 통신 방식이다. 송신자는 멀티캐스트 그룹(multicast group)에 패킷을 전송하고, 해당 그룹에 가입(join)한 모든 수신자들은 이 패킷을 동시에 받아볼 수 있다. IP 레벨에서는 멀티캐스트 주소(예: 224.0.0.0\~239.255.255.255 범위)를 통해 이 그룹을 식별하고, 네트워크 장비들은 IGMP(Internet Group Management Protocol)를 통해 가입/탈퇴를 관리한다.

ROS2의 DDS(데이터 분산 서비스) 계층에서 토픽(topic) 기반 퍼블리셔/서브스크라이버 모델을 구현할 때, 멀티캐스트나 유니캐스트 방식을 선택할 수 있다. 특히 Cyclone DDS, Fast-DDS 등 구현체별로 설정에 따라 멀티캐스트를 적극 활용하기도 하며, 네트워크 토폴로지나 운영 환경에 따라 유니캐스트 방식만 허용되는 경우도 있다.

#### 데이터 전송 방식 비교

ROS2 멀티머신 환경에서 유니캐스트와 멀티캐스트를 비교할 때 주로 고려되는 항목은 다음과 같다.

**네트워크 자원 사용량**:

유니캐스트: 송신자는 수신자마다 패킷을 따로 전송해야 하므로, 수신 노드가 $N$개일 경우 총 전송량은 $N \times D$ (단, $D$는 단일 송신 패킷량)와 같이 증가한다.

$$
\text{Total\_Data}\_{\text{unicast}} = N \cdot D
$$

멀티캐스트: 송신자는 멀티캐스트 그룹으로 패킷을 한 번만 전송한다. 그러면 네트워크 장비(라우터, 스위치 등)가 필요에 따라 패킷을 복제하여 구독자에게 전달하므로, 송신자의 전송량은 $D$에 가까우며(소량의 프로토콜 오버헤드가 있음), $N$이 증가하더라도 송신자의 부담은 크게 늘지 않는다.

$$
\text{Total\_Data}\_{\text{multicast}} \approx D + \epsilon
$$

**라우팅 및 브로드캐스팅**:

유니캐스트: 특정 주소로만 전송되기 때문에 스위치와 라우터가 트래픽을 전파할 때 포트 미러링이나 브로드캐스팅을 최소화할 수 있다.

멀티캐스트: 네트워크 장비가 그룹별로 트래픽을 복제하므로, 네트워크 토폴로지가 복잡하거나 라우터 설정이 잘못되어 있다면 예상치 못한 곳으로 트래픽이 전파될 수도 있다.

**ROS2 Discovery**:

ROS2의 DDS Discovery(노드 발견) 과정에서, 멀티캐스트를 통한 브로드캐스트 성격의 통신이 활용되기도 한다. 예컨대 Fast-DDS 등 일부 구현체는 Discovery 시점에 멀티캐스트를 사용해 “이 그룹에 새 노드가 있다”고 알리거나 반응한다.

네트워크 구성 상 멀티캐스트가 막혀 있으면, Discovery 자체가 제대로 진행되지 않아 노드들이 서로를 인식하지 못하는 문제가 생길 수 있다. 이때는 유니캐스트만 사용하거나, 브로드캐스트 성격의 멀티캐스트 패킷을 허용하도록 방화벽 혹은 라우터를 설정해야 한다.

#### 네트워크 레벨 주소 구조

**유니캐스트 주소(Unicast Address)**: 일반적인 IPv4 주소(예: 192.168.0.10)나 IPv6 주소(예: fe80::1234:abcd) 같은 호스트 단위 식별자를 사용한다.

**멀티캐스트 주소(Multicast Address)**: IPv4의 경우 224.0.0.0 \~ 239.255.255.255, IPv6의 경우 ff00::/8 범위가 멀티캐스트로 예약되어 있다. ROS2 DDS에서 내부적으로 멀티캐스트 주소를 활용해 특정 그룹에 노드를 묶고, 해당 토픽을 퍼블리시하면 그룹 가입자들이 패킷을 전달받는다.

#### 네트워크 토폴로지 예시

아래는 단순화된 멀티캐스트 네트워크 토폴로지를 표현한 예시이다:

{% @mermaid/diagram content="flowchart LR
A(ROS2 Publisher<br/>Multicast IP: 224.x.x.x) --> R1(Router)
R1 --> S1(ROS2 Subscriber 1)
R1 --> S2(ROS2 Subscriber 2)
R1 --> S3(ROS2 Subscriber 3)" %}

* Publisher는 멀티캐스트 IP로 패킷을 전송.
* 라우터(R1)는 IGMP를 기반으로 가입된 노드(S1, S2, S3)에게만 패킷을 복제/전달.
* 수신자(Subscriber)들은 멀티캐스트 그룹에 가입(join) 요청을 해야 패킷을 받을 수 있다.

#### 멀티캐스트 관련 네트워크 설정 이슈

ROS2 멀티머신 환경에서 멀티캐스트가 원활히 동작하기 위해서는 운영 체제와 네트워크 장비(스위치, 라우터) 모두에서 몇 가지 설정이 필요하다. 대표적으로 다음과 같은 이슈가 존재한다.

1. **IGMP(Internet Group Management Protocol) 설정**
   * 대부분의 L3 스위치나 라우터는 IGMP 스누핑(IGMP Snooping) 기능을 통해, 특정 멀티캐스트 그룹에 가입한 노드만 트래픽을 받아볼 수 있게 한다. 이를 통해 불필요한 포트로 멀티캐스트 트래픽이 흘러 들어가는 것을 최소화한다.
   * 관리자가 IGMP 스누핑을 꺼 놓았거나, 라우터에서 IGMP 설정이 제대로 되어 있지 않다면, 멀티캐스트 트래픽이 차단되거나 반대로 브로드캐스팅 형태로 모든 포트에 흘러들어갈 수 있다.
2. **TTL(Time To Live) 및 멀티캐스트 전송 범위**
   * 멀티캐스트 트래픽은 IP 헤더의 TTL 값에 따라 전달 범위가 달라진다.
   * 일반적으로 로컬 네트워크에서만 멀티캐스트를 사용한다면 TTL을 1로 설정하기도 하며, 여러 라우터를 거쳐 다른 서브넷(subnet)까지 도달하게 하려면 TTL 값을 더 높게 조정해야 한다.
3. **방화벽(Firewall) 규칙**
   * 서버나 데스크톱 운영체제에서 방화벽이 활성화되어 있는 경우, 멀티캐스트 트래픽(UDP 7400, 7410 등 DDS 기본 포트)을 허용해야 Discovery가 정상 작동한다.
   * iptables, ufw 등 Linux 계열 방화벽이나 Windows 방화벽에서 멀티캐스트 트래픽을 제한하거나 차단하고 있을 수 있다.
4. **라우터 멀티캐스트 라우팅 설정**
   * 기업 네트워크나 여러 서브넷을 갖는 복잡한 네트워크에서, 멀티캐스트를 서브넷 간에 전달하려면 PIM(Protocol Independent Multicast) 설정을 통해 라우팅 프로토콜을 활성화해야 한다.
   * 단일 서브넷에서만 운용한다면 PIM 설정까지는 필요 없을 수 있지만, IGMP 설정이 제대로 되어 있는지 확인이 필요하다.

#### 운영체제별 멀티캐스트 확인

ROS2 노드가 정상적으로 멀티캐스트를 송수신하는지 확인하기 위해서는 OS 차원에서 멀티캐스트 사용 여부를 테스트할 수 있어야 한다. 간단한 방법으로는 `ping` 대신 `mcast` 도구를 사용하는 방법, 혹은 `avahi-browse` 등을 통해 멀티캐스트 패킷이 전달되는지 확인한다.

예시:

```bash
# 시스템에 mcast 설치가 되어 있다고 가정
$ mcast send 224.0.0.1 5000 "Hello Multicast"
```

다른 터미널이나 노드에서 멀티캐스트를 수신할 수 있는지 테스트한다:

```bash
$ mcast recv 224.0.0.1 5000
```

만약 여기서 수신이 안 된다면, IGMP 스누핑 여부나 방화벽 설정을 재점검해야 한다.

#### ROS2 DDS 설정과 유니캐스트, 멀티캐스트

1. **Discovery 시나리오**
   * 기본적으로 ROS2는 DDS Discovery 과정에서 멀티캐스트를 적극 활용한다.
   * 멀티캐스트가 차단된 환경에서는 유니캐스트 페어링(peer) 설정이 필요할 수 있다. 즉, 노드 IP를 직접 지정해서 서로를 인식시키는 방식을 써야 한다.
2. **QoS 옵션**
   * 멀티캐스트를 통한 Reliable QoS(예: 신뢰성 있는 전송) 시, 네트워크 장비가 제대로 패킷 손실을 방지하고 재전송이 이뤄질 수 있도록 구성되어야 한다.
   * 높은 주파수(High Frequency) 데이터 전송 시, 유니캐스트로 전송할 경우 송신부하가 커질 수 있음을 고려한다.
3. **초기 설정 변경**
   * Cyclone DDS 예: `CYCLONEDDS_URI` 혹은 `cyclonedds.xml` 파일에서 `<Discovery>`, `<Multicast>` 항목을 통해 멀티캐스트 사용 여부를 지정할 수 있다.
   * Fast-DDS 예: `fastdds.xml`의 `<transport_descriptors>` 항목에 멀티캐스트를 사용하도록 설정하거나, 유니캐스트만 허용하도록 조정할 수 있다.

#### 멀티서브넷 환경에서의 고려 사항

ROS2 멀티머신 시스템이 단일 서브넷(Subnet)을 넘어 여러 서브넷에 걸쳐 구성되는 경우, 멀티캐스트 트래픽이 서브넷 간을 왕래하기 위해서는 네트워크 라우터/스위치에서 특정 멀티캐스트 라우팅 프로토콜(PIM 등)이 동작해야 한다. 다음과 같은 사항을 고려해야 한다.

1. **서브넷 간 멀티캐스트 지원 여부**
   * 멀티캐스트 라우팅이 설정되지 않은 라우터를 통해서는, 서브넷을 넘어가는 멀티캐스트 패킷이 차단될 수 있다.
   * 기업 내부망이나 공공기관망 등 보안이 까다로운 환경에서는 멀티캐스트가 원천 차단되어 있을 가능성이 높다.
2. **IGMP 버전 호환성**
   * IGMP에는 버전 1, 2, 3 등이 있으며, 라우터가 IGMPv2만 지원하지만 호스트나 DDS 구현체에서 IGMPv3를 사용하려고 하면 문제가 생길 수 있다.
   * 일반적으로 네트워크 장비가 IGMPv2 이상을 지원하므로 큰 문제는 없지만, 특정 고전 장비나 IoT 환경에서는 제약이 있을 수 있다.
3. **유니캐스트 대체 방안**
   * 만약 서브넷 간 멀티캐스트가 불가능한 환경이라면, ROS2 DDS의 Static Discovery, InitialPeersList, 혹은 unicast metatraffic 설정 등을 통해 수동으로 노드 정보를 공유해야 한다.
   * 멀티캐스트 대신 브로드캐스트를 사용하는 것은 많은 보안 및 성능 문제를 일으킬 수 있으므로 권장되지 않는다(대다수 라우터가 브로드캐스트를 서브넷 간에 전달하지도 않음).

#### 성능 모니터링과 디버깅

유니캐스트와 멀티캐스트 중 어느 방식을 선택하든, 실제 네트워크 성능을 확인하고 문제를 디버깅하는 절차가 중요하다. 다음과 같은 툴과 방법을 고려할 수 있다.

1. **rtpsdump, wireshark 등 패킷 캡처**
   * ROS2 DDS는 RTPS(Real-Time Publish Subscribe) 프로토콜 위에서 동작한다. `rtpsdump`와 같은 도구 또는 `wireshark`를 활용해 실제 RTPS 패킷 흐름을 분석할 수 있다.
   * 멀티캐스트 주소로 패킷이 잘 흘러가는지, IGMP Report/Query가 제대로 전송되는지 확인 가능하다.
2. **ddstopic와 명령줄 툴**
   * ROS2 CLI(명령줄 인터페이스)에서 `ros2 topic echo`, `ros2 topic list` 등 명령어로 토픽이 실제로 송수신되는지 확인할 수 있다.
   * DDS 구현체마다 자체 디버깅 툴을 제공하기도 하므로, Cyclone DDS, Fast-DDS 등에 맞춰 활용할 수 있다.
3. **시스템 리소스 모니터링**
   * 멀티캐스트일 때 송신 측 CPU 사용률이 확실히 줄어들 수 있지만, 수신 측에서 패킷을 복제하거나 필터링하는 과정에서 부하가 걸릴 수 있다.
   * 유니캐스트일 때는 송신 측 부하가 수신 노드 수에 따라 커질 수 있으므로, CPU나 네트워크 대역폭 사용량을 모니터링하는 것이 중요하다.
   * Linux 기반 시스템에서는 `nload`, `iftop`, `netstat -s` 같은 툴로 네트워크 사용량을 간단히 파악 가능하다.

#### 대규모 트래픽 시뮬레이션

멀티머신 ROS2 환경에서 대용량 트래픽(예: 카메라 영상 스트리밍, LiDAR 데이터 등)을 발생시키는 상황을 시뮬레이션해 보면, 유니캐스트와 멀티캐스트 사이에 큰 성능 차이가 날 수 있다.

1. **성능 지표**
   * 지연시간(Latency), 처리량(Throughput), 패킷 손실률(Packet Loss)이 대표적인 지표다.
   * 대규모 퍼블리셔 수, 서브스크라이버 수, 메시지 전송 주기(Hz), 메시지 크기 등의 변수에 따라 지표가 달라진다.
2. **부하 테스트**
   * ROS2에서는 `$ros2 topic pub` 명령어로 특정 토픽에 빠른 속도로 데이터를 퍼블리시하고, 여러 노드에서 `$ ros2 topic echo`로 수신 상태를 모니터링할 수 있다.
   * 좀 더 체계적인 부하 테스트 도구로는 Apex.AI에서 제공하는 apex\_performance\_test를 사용할 수도 있다.
3. **네트워크 시뮬레이터**
   * 실제 물리 네트워크 환경을 구축하기 전에, NS-3, Mininet 등 시뮬레이터를 통해 멀티캐스트 라우팅, IGMP 스누핑 등을 미리 검증해 볼 수 있다.
   * 이는 대규모 노드가 동시에 구독·발행할 때 발생하는 트래픽 패턴을 가상화된 환경에서 확인할 수 있다는 이점이 있다.

#### NAT 및 VPN 환경에서의 고려 사항

유니캐스트와 멀티캐스트는 로컬 네트워크(LAN) 내에서는 비교적 단순하게 구성 가능하지만, NAT(Network Address Translation)가 적용된 환경이나 VPN(Virtual Private Network)을 통해 원격지와 연결되는 환경에서는 추가적인 고려가 필요하다.

1. **NAT Traversal 문제**
   * NAT를 거쳐야 하는 경우, 멀티캐스트는 보통 제대로 전달되지 않는다. NAT 라우터는 일반적으로 멀티캐스트 주소에 대한 매핑(Translation)을 수행하지 않기 때문이다.
   * 일부 고급 NAT 장비나 VPN 솔루션에서는 멀티캐스트 패킷을 터널링(tunneling)하여 전달할 수 있지만, 일반적인 NAT 환경에서는 유니캐스트만 실질적으로 통신이 가능하다.
2. **VPN 멀티캐스트 지원**
   * OpenVPN이나 IPSec 기반 VPN 환경에서 멀티캐스트를 지원하려면, 브리지(bridge) 모드 또는 멀티캐스트를 터널링하는 설정이 필요하다.
   * 만약 VPN이 유니캐스트 터널만 지원한다면, 멀티캐스트를 쓰지 못하고 유니캐스트 통신으로 대체해야 한다.
   * 기업용 VPN 솔루션 중에 멀티캐스트를 정책적으로 막아 두는 경우도 있으므로, 관리자와 협의가 필요하다.
3. **멀티캐스트를 대체하기 위한 DDS 브리지**
   * ROS2 DDS 구현체 중에는, 두 네트워크를 연결해주는 ‘브리지(bridge) 노드’를 따로 두어 다른 서브넷 간, 또는 NAT 뒤의 네트워크 간 통신을 유니캐스트로 중계할 수 있게 하는 기능이 제공되기도 한다.
   * 이 경우 내부망에서는 멀티캐스트를 활용하고, 외부와 연결되는 구간에서는 유니캐스트로 변환하여 전달함으로써, NAT 문제를 우회한다.

#### IPv6 환경에서 유니캐스트와 멀티캐스트

IPv6에서도 유니캐스트와 멀티캐스트가 존재하고, 멀티캐스트를 더욱 광범위하게 사용하도록 설계되었다. 다만 ROS2 DDS를 IPv6-only 환경에서 운용할 때는 다음 사항을 주의한다.

1. **링크 로컬(Link-Local) 주소**
   * IPv6 주소에는 fe80::/10 범위로 된 링크 로컬 주소가 있으며, 멀티캐스트 통신도 이 범위 내에서 이루어진다.
   * 동일 링크(서브넷) 내 멀티캐스트 통신은 IPv6에서 별도의 설정 없이도 상대적으로 쉽지만, 라우팅 영역을 넘어가려면 라우터가 MLD(Multicast Listener Discovery)를 지원해야 한다.
2. **DDS 구현체의 IPv6 지원 범위**
   * Cyclone DDS, Fast-DDS 등 대부분의 ROS2 DDS 구현체는 IPv6를 지원하지만, 일부 예전 버전에서는 IPv6 지원이 미흡하거나 Discovery가 불안정할 수 있다.
   * IPv6-only 모드(IPv4가 전혀 없는 환경)로 설정할 때는, DDS 설정 파일에서 명시적으로 IPv6를 활성화해야 할 수 있다.
3. **IPv6 멀티캐스트 주소 범위**
   * IPv6에서 멀티캐스트 주소는 ff00::/8 범위로 할당된다.
   * 예: ff02::1: All Nodes on Link, ff02::2: All Routers on Link.
   * ROS2 DDS는 일반적으로 ff02, ff05 등의 스코프(scope) 주소를 이용해 로컬, 사이트 범위에서 멀티캐스트를 실시할 수 있다.

#### 보안(Security) 관점에서의 유니캐스트 vs 멀티캐스트

1. **포트 스캐닝(Port Scanning) 및 공격 표면(Attack Surface)**
   * 유니캐스트는 주로 특정 IP/포트를 대상으로 통신하기 때문에 방화벽 정책 설정이 비교적 명확하다.
   * 멀티캐스트는 여러 수신자에게 동시에 전달되고, 네트워크 장비(라우터, 스위치)가 패킷을 복제하므로, 방화벽이나 IPS(침입 방지 시스템) 설정이 좀 더 복잡해질 수 있다.
2. **DDS 보안 확장(Security Plugins)**
   * ROS2 DDS에는 보안 확장(DDS Security)을 통해 RTPS 레벨 암호화, 인증(Authentication), 접근 제어(Access Control)를 적용할 수 있다.
   * 멀티캐스트를 쓴다고 해도, DDS 보안 확장을 통해 패킷이 암호화되어 있으면 중간에서 패킷을 탈취해도 내용이 유출되지 않는다.
   * 다만 멀티캐스트 트래픽이 차단되지 않도록, 방화벽에서 UDP 포트(예: 7400\~7500 등 DDS 기본 포트) 및 멀티캐스트 주소 범위를 허용해야 한다.

#### 실시간(Real-Time) 요구사항

실시간 시스템에서 ROS2를 사용한다면, 유니캐스트와 멀티캐스트를 선택할 때 다음 측면을 유의해야 한다.

1. **지연시간(Latency) 변동 폭**
   * 멀티캐스트는 네트워크 장비가 패킷 복제와 그룹 관리에 관여하기 때문에, 특정 라우팅 시점에서 지연이 발생할 수 있다.
   * 유니캐스트는 경로가 확실히 정해져 있지만, 수신 노드가 많아질수록 송신자 측 부하가 커져서 지연이 늘어날 위험이 있다.
2. **RTOS(Real-Time Operating System)와 DDS**
   * 일부 RTOS나 임베디드 리눅스 시스템에서는 네트워크 스택을 간소화했을 수 있으며, 멀티캐스트를 제한적으로만 지원하기도 한다.
   * 실시간 커널 설정(RT 커널) 하에서 멀티캐스트 IGMP 처리가 우선순위가 낮게 설정되어 있으면, Discovery나 토픽 전달이 지연될 가능성이 있다.
3. **QoS(Profile) 튜닝**
   * Reliable vs. Best-effort, Deadline, Liveliness 등 QoS 정책을 통해 메시지 전달 보장 수준과 실시간성을 트레이드오프해야 한다.
   * 유니캐스트-멀티캐스트 선택과 별개로, QoS 설정이 부적절하면 원하는 실시간 성능이 나오지 않을 수 있다.

#### DDS RMW 구현체별 멀티캐스트/유니캐스트 설정 예시

ROS2의 다양한 RMW(Remote Method Wire) 구현체—예: CycloneDDS, Fast-DDS(rmw\_fastrtps), RTI Connext DDS 등—마다 멀티캐스트 설정 방식이 조금씩 다르다. 일반적으로 XML 설정 파일 혹은 환경변수를 통해 다음과 같은 항목을 수정한다.

**Cyclone DDS**:

* 기본 설정 파일명은 `cyclonedds.xml`이며, ROS2에서는 환경변수 `CYCLONEDDS_URI` 혹은 `CYCLONEDDS_FILE`를 통해 설정 파일 경로를 지정 가능하다.
* 멀티캐스트 제어 예시:

```xml
<CycloneDDS>
  <Domain id="any">
    <Discovery>
      <!-- 멀티캐스트 사용 여부 -->
      <AllowMulticast>true</AllowMulticast>
      <!-- 멀티캐스트 TTL 값 설정 -->
      <MulticastTTL>1</MulticastTTL>
    </Discovery>
  </Domain>
</CycloneDDS>
```

* `<AllowMulticast>false</AllowMulticast>`로 설정하면 유니캐스트 Discovery만 시도하므로, 같은 서브넷이라도 멀티캐스트 패킷이 사용되지 않는다.

**Fast-DDS (rmw\_fastrtps)**:

* 기본 설정 파일은 `fastdds.xml` 혹은 `DEFAULT_FASTRTPS_PROFILES.xml` 등을 활용한다.
* 멀티캐스트 설정 예시(Transport Descriptors):

  ```xml
  <transport_descriptors>
    <transport_descriptor>
      <prefix>udp</prefix>
      <sendBufferSize>65536</sendBufferSize>
      <receiveBufferSize>65536</receiveBufferSize>
      <!-- 멀티캐스트 사용 허용 -->
      <interfaceWhiteList>
        <address>192.168.0.10</address> <!-- 특정 NIC에 대해서만 멀티캐스트 허용 -->
      </interfaceWhiteList>
    </transport_descriptor>
  </transport_descriptors>
  ```
* Discovery 관련 옵션에서 `MetatrafficMulticastLocatorList`와 `MetatrafficUnicastLocatorList`를 조정해, 멀티캐스트/유니캐스트를 병행하거나 특정 방식만 사용하게 설정 가능하다.

**RTI Connext DDS (rmw\_connextdds)**:

* 일반적으로 ROS2 무료 버전에서는 RTI Connext의 제한된 라이선스 버전을 사용한다.
* `USER_QOS_PROFILES.xml` 파일에서 `DiscoveryQosPolicy`나 `TransportMulticastMapping` 등을 통해 멀티캐스트 설정을 제어한다:

  ```xml
  <participant_qos>
    <discovery>
      <multicast_enabled>true</multicast_enabled>
    </discovery>
  </participant_qos>
  ```
* RTI Connext의 경우, “멀티캐스트 Transport” 설정과 “Built-in Discovery”용 멀티캐스트 설정을 구분해 세밀하게 조정할 수 있다.

#### 특정 상황별 베스트 프랙티스

1. **단일 서브넷, 다수 노드**
   * 멀티캐스트를 활용해 Discovery 및 토픽 전송을 구성하면 송신부하가 줄어든다.
   * 단, 네트워크 스위치에서 IGMP 스누핑이 제대로 설정되어 있어야 불필요한 브로드캐스트가 발생하지 않는다.
2. **서브넷 간 통신 or NAT 뒤 환경**
   * 대체로 유니캐스트 기반으로 설정하거나, VPN에서 멀티캐스트 터널링 지원이 되는지 확인한다.
   * DDS 브리지나 Static Peers 설정을 통해 노드 주소를 직접 지정하는 방법이 효과적이다.
3. **보안이 중요한 기업망**
   * 방화벽에서 멀티캐스트를 허용해야 Discovery가 정상 작동한다.
   * DDS 보안(암호화/인증)을 적용해도, 멀티캐스트 패킷 자체가 차단되는 것은 막을 수 없으므로 네트워크 정책 조정이 우선이다.
4. **고주파수(High-Frequency) 데이터 전송**
   * 카메라, LiDAR 등 대용량 스트리밍이 필요한 경우 멀티캐스트로 퍼블리싱하면 송신자 부담이 줄어 성능 이점이 크다.
   * 하지만 중간 라우터나 스위치가 멀티캐스트 트래픽을 충분히 처리할 수 있는지(멤버십 관리, 트래픽 복제 성능 등) 사전에 점검해야 한다.

#### 장단점 종합

| 분류            | 유니캐스트                       | 멀티캐스트                                     |
| ------------- | --------------------------- | ----------------------------------------- |
| **송신 부하**     | 수신자가 많을수록 송신량 증가            | 한 번 전송으로 여러 수신자에게 전송 가능                   |
| **네트워크 구성**   | 라우터/스위치 설정이 단순함             | IGMP/PIM 설정 등 추가 설정 필요                    |
| **NAT/VPN**   | 대부분 NAT를 통과 가능              | NAT 뒤에서는 일반적으로 불가능, VPN 특수 설정 필요          |
| **Discovery** | 브로드캐스트 없이 각 노드 주소를 수동 설정 가능 | 기본적으로 ROS2에서 선호(자동 노드 발견), 단 막혀 있으면 설정 필요 |
| **보안/방화벽**    | 특정 IP/포트만 열면 되므로 관리 용이      | 멀티캐스트 주소 범위, IGMP 트래픽 등에 대한 별도 허용 필요      |
| **실시간성**      | 노드 수 증가 시 송신자 지연 증가 가능      | 라우터의 멀티캐스트 관리에 따라 지연 편차 발생 가능             |