软件分发加速 - 蘭陵N散記

背景

在云环境下，服务器（物理机）或虚拟机越来越多，存在同一个应用软件需要大规模地部署场景。传统的方式下是搭建一个软件仓库，由物理机或虚拟机节点直接从软件仓库下载。如果采用sftp或http协议，则只能做到从一个中心软件仓库分发软件包给其它的节点，若给上百台的节点同时分发同一软件包，则存在受带宽、负载限制等因素，导致分发的速度就会比较慢。

常用技术

组播

传统的IP通信有如下三种方式：

• 单播（Unicast）：源主机与目的主机之间点对点的通信。
• 广播（Broadcast）：源主机与同一网段中所有其它主机之间一点对多点的通信。
• 组播（Multicast）：源主机与一组目的主机之间一点对多点的通信。与广播不同的是组播组中的所有接收者都可收到同样的数据拷贝，并且只有组播组内的主机可以接收该数据，而其它主机则不能收到。

组播技术有效地解决了单点发送、多点接收的问题。所以组播非常适合运用在云环境下的软件分发场景，单点到多点的高效数据传送，能够大量节约网络带宽、降低网络负载。

一般情况下，在二层网络中，交换机会默认开启组播，但会对组播带宽进行抑制，防止网络风暴造成的影响。在实现应用中可以在交换机上设置合适的组播带宽。如果组播需要跨二层网络，需要在路由器上开启组播路由协议。

组播组内的所有主机共享同一个地址，这种地址称为组播地址。组播地址是范围在224.0.0.0~239.255.255.255之间的IP地址。此范围内的所有地址的前4个二进制为都是“1110“。组播地址也被称为D类IP地址，与其它的A类、B类和C类地址相区别。组播组是开放的，主机可以在任何时候进入或离开组。IANA(Internet Assigned Numbers Authority)组织负责分发永久组播地址。

由于组播地址是开放的，在实现组播服务，需要在上层设计加入组播的认证机制，如采用IP白名单，或在自定义上层协议，会话协商时进做登录认证。

组播是采有UDP，与单播UDP不同，前者必须考虑TTL(Time to live)值，它用IP数据包的头部的一个字节表示。TTL通过限制IP包被丢弃前通过的路由器数目，来决定IP包的生存时间。IP包每通过一个路由器，TTL就减一，当TTL变为0，这个包就被丢弃。TTL的一个作用是防止配置有误的路由器把包在路由器之间无限的来回传递，还有一个作用是限制组播的地理范围。

由于UDP不可靠，会存在丢包的情况，在设计组播服务需要考虑对传包个数与内容的校验，以及重传机制，或者在最坏的情况，采用TCP的补偿传输。通常的做法是在另开TCP连接来控制组播的传输质量，而UDP是负责数据流。

Java在1.7中，已支持MulticastSocket API。API比较低层，需要结合NIO一起使用，另外JGroup与Netty也对组播有更高层的封装。

P2P

P2P(Peer to Peer)端到端传输模型，与传统的C/S（Client-Server）模型相对应的。P2P与C/S都是单播。但C/S是集中由Server端来分发中转，所以当多个节点从Server下载软件时，对Server的流量与性能影响最大。而在P2P网络中，每个节点都是对等的。网络中的每个节点既能充当网络服务的请求者，又对其它节点的请求作出响应，提供资源和服务。

P2P组网按是否有中心索引节点来分有三种：

• 集中式P2P：存在中心服务器，保存所有节点信息与资源信息，其它节点通过它找到需要连接的节点与资源。
• 无结构化P2P：节点同时作为客户端和服务器端，无中心服务器，无中心路由器。
• 结构化P2P： 将网络中所有资源整理成一张巨大的表，表内包含资源的关键字与存入节点地址，这张表裸眼分割分别存储到网络中每个节点中。结构化组网常见有三种：