关于开源软件镜像联盟（技术篇）

请先阅读：关于开源软件镜像联盟（非技术篇），谢谢

一、DNS or 301?

Update: 之前我对DNS的CNAME理解错误，现在更正。参考文献：https://tools.ietf.org/html/rfc3568

DNS方案（如果说得不对欢迎拍砖）：

1. 每个镜像分配一个二级域名，以便分别调度；NS记录设置为主站

2. 用户从运营商DNS查询IP

3. 主站根据来源IP（运营商DNS的IP）返回一个或多个镜像节点的IP地址

4. 运营商DNS把这个IP返回给用户，同时缓存一定期限

5. 用户与镜像节点建立连接，进行下载
   301方案：

6. 域名A记录解析到主站

7. 用户与主站建立连接，发起HTTP请求

8. 主站根据用户来源IP返回HTTP 301状态，跳转到一个镜像节点

9. 用户与这个镜像节点建立连接，进行下载

**比较**	**DNS**	**301**
调度精确性	只能获知运营商DNS的IP，按区域匹配	可以获知用户IP，根据用户IP精确匹配
调度策略修改	需要等到DNS缓存超时才能生效	随时修改，立即生效
镜像节点目录结构	必须相同	不必相同
用户需要访问校外	不需要	需要(*)
访问延迟	几乎不增加延迟	需要先与主站建立连接，增加一次TCP握手的延迟
主站压力	运营商DNS有缓存，压力低	每个访问都要去主站，而且HTTP请求解析成本比DNS高，故压力高
主站稳定性要求	高	较高
多主站负载均衡	可以实现	可以实现

(*) 即使校内有镜像节点，用户也必须开通校外访问权限（限制IPv6的学校多吗？如果大部分学校的IPv6没有访问限制则忽略此条）

二、镜像间通信

主节点要实时监控各镜像节点的状态，例如用Ganglia/Nagios；发现故障时，一方面要调整调度策略，让新请求不再走这个镜像；另一方面要通过邮件发出报警。

一个镜像的大陆主节点定期从上游源同步。同步完成后通知其他节点来自己这里同步（这个API还要讨论）；如果同步失败，也要通知其他节点自己去上游源同步。

镜像的访问日志有分析价值，是调度策略调整的重要依据，因此要有一种机制，每天各节点把Web访问日志汇总到主站，主站再按照镜像进行分类。

各镜像站尽量协商使用同一种Linux发行版，方便编写“维护工具链”。

三、主站Web界面要提供的信息

• 公开的镜像列表，显示每个镜像的大小、每日更新量统计、已经有哪些镜像节点，以及每个节点维护着哪些镜像，以便新加入的镜像站量力而行，把有限的资源用到最需要的镜像上。
• 各镜像节点的状态监控
• 用户使用每个镜像的帮助信息
  本文参考：http://blog.ustc.edu.cn/pipermail/ustc_lug/2013-March/009974.html