🔗 Feature: Multicast ICP cluster
- 目标: 通过多播优化集群流量，从而减少带宽和延迟。
- 状态：已完成。
- 版本: 2.x
🔗 详细信息
多播本质上是将一个 IP 数据包发送给多个接收者的能力。多播常用于音频和视频会议系统。
🔗 我如何知道我的网络是否支持多播？
一种方法是询问管理您网络的人。如果您的网络管理员不知道，或者看起来很奇怪，那么您可能不支持。
另一种方法是使用 mtrace 程序，该程序可以在 Xerox PARC FTP 站点 上找到。Mtrace 类似于 traceroute。它会告诉您您与另一个站点之间的多播路径。例如
> mtrace mbone.ucar.edu
mtrace: WARNING: no multicast group specified, so no statistics printed
Mtrace from 128.117.64.29 to 192.172.226.25 via group 224.2.0.1
Querying full reverse path... * switching to hop-by-hop:
0 oceana-ether.nlanr.net (192.172.226.25)
-1 avidya-ether.nlanr.net (192.172.226.57) DVMRP thresh^ 1
-2 mbone.sdsc.edu (198.17.46.39) DVMRP thresh^ 1
-3 * nccosc-mbone.dren.net (138.18.5.224) DVMRP thresh^ 48
-4 * * FIXW-MBONE.NSN.NASA.GOV (192.203.230.243) PIM/Special thresh^ 64
-5 dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61) DVMRP thresh^ 64
-6 dec3800-2-fddi-0.Denver.mci.net (204.70.152.61) DVMRP thresh^ 1
-7 mbone.ucar.edu (192.52.106.7) DVMRP thresh^ 64
-8 mbone.ucar.edu (128.117.64.29)
Round trip time 196 ms; total ttl of 68 required.
🔗 我应该使用多播 ICP 吗？
简而言之：不，可能不应该。
您应该使用多播的原因
- 它减少了 Squid 调用 sendto() 将 UDP 数据包放入网络的次数。
- 使用多播很时尚，很酷。
您不应该使用多播的原因
- 多播隧道/配置/基础设施通常不稳定。您可能会丢失多播连接，但仍然拥有单播连接。
- 多播不会简化您的 Squid 配置文件。每个受信任的邻居缓存仍然必须指定。
- 多播不会减少发送的 ICP 回复数量。它确实减少了发送的 ICP 查询数量，但并未减少回复的数量。
- 多播会暴露您的缓存的一些隐私问题。加入多播组不需要任何特殊的权限。任何人都可以加入您的群组并窃听 ICP 查询消息。但是，您的多播流量的范围可以得到控制，使其不会超出某些边界。
我们只建议在您有密切控制权的网络基础设施上使用多播 ICP。换句话说，仅在您的本地区域网络上使用多播，或者如果您是 ISP，则可能在您的广域网上使用。我们认为在拥塞的链路或商品骨干网上使用多播 ICP 可能是一个坏主意。
🔗 配置 - 发送
要配置 Squid 将 ICP 查询发送到多播地址，您需要创建另一个指定为 multicast 的邻居缓存条目。例如
cache_peer 224.9.9.9 multicast 0 3130 ttl=64
- 224.9.9.9 是一个示例多播组地址。
- multicast 表明这是一种特殊类型的邻居。
- HTTP 端口参数对于多播对等方将被忽略，但 ICP 端口 (3130) 非常重要。
- 最后一个参数 ttl=64 指定发送到此地址的查询的多播 TTL 值。
- 最好将最小 TTL 增加几倍，以提供一定的误差余量和应对变化。
您还必须指定哪些邻居将响应您的多播查询，因为隐式信任来自未知地址的任何 ICP 回复都是不明智的。
请注意，ICP 回复会发送回 单播 地址；它们不是多播，所以 Squid 无法判断回复是来自常规查询还是多播查询。
查询。
要配置您的多播组邻居，请使用 cache_peer 指令和 multicast-responder 选项。
cache_peer cache1 sibling 3128 3130 multicast-responder
cache_peer cache2 sibling 3128 3130 multicast-responder
这里的字段都是相关的。
ICP 端口号 (3130) 必须与上面定义多播对等方的 cache_peer 行中的端口号相同。
第三个字段必须是 parent 或 sibling，以指示 Squid 应如何处理回复。
当为对等方设置了 multicast-responder 标志时，Squid 将不会直接 (即单播) 向其发送 ICP 查询，而是发送到特殊的 multicast 组 cache_peer。
🔗 我如何知道要使用哪个多播 TTL？
多播 TTL（在您的多播组的 cache_peer 行中指定）决定了您的 ICP 查询将“走多远”。在 Mbone 中，每个网络接口或隧道都有一个特定的 TTL 阈值。多播数据包的 TTL 必须大于该数据包的定义 TTL 才能跨越该链路转发。
例如，mrouted 手册页建议
32 for links that separate sites within an organization.
64 for links that separate communities or organizations, and are attached to the Internet MBONE.
128 for links that separate continents on the MBONE.
确定所需 TTL 的一个好方法是运行 mtrace，如上所示，并查看最后一行。它将显示到达另一台主机所需的最小 TTL。
如果您的 TTL 设置得太高，您的 ICP 消息可能会“走得太远”并被其他人窃听。如果您只在 LAN 上使用多播，正如我们建议的那样，那么您的 TTL 将会很小，例如 ttl=4。
🔗 配置 - 接收和响应
您必须使用 mcast_groups 指令告诉 Squid 加入多播组地址。
例如
mcast_groups 224.9.9.9
当然，您的多播 ICP 组的所有成员都需要使用完全相同的多播组地址。
碰巧选择了相同的多播地址，那么他们可能会发现他们的群组在某个点“重叠”。如果其中一个查询缓存使用较大的 TTL 值，这一点尤其明显。有两种方法可以减少群组重叠的风险：
- 使用唯一的群组地址
- 使用 TTL 或管理范围限制多播消息的范围。
使用唯一的地址是一个好主意，但并非没有潜在问题。如果您随机选择地址，您怎么知道其他人不会也随机选择相同的地址？NLANR 已被 IANA 分配了一块多播地址，用于这种情况。如果您想获得其中一个地址，请 写信给我们。但是，请注意，NLANR 或 IANA 无权阻止任何人使用分配给您的地址。
限制多播消息的范围可能是更好的解决方案。它们可以通过上面讨论的 TTL 值或一些称为管理范围地址的新技术来限制。在这里，您可以为特定地址的流量配置明确定义的边界。RFC 2365 (Administratively Scoped IP Multicast) 描述了这一点。
类别：功能
导航：站点搜索，站点页面，类别，🔼 向上