mirrorhub的性能问题与之后的计划

➜  /tmp time ./run-mirrors.sh # curl -L mirrors.moe/archlinux十次
./run-mirrors.sh  0.16s user 0.03s system 1% cpu 15.436 total
➜  /tmp time ./run-ustc.sh   # curl -L mirrors.ustc.edu.cn/archlinux十次
./run-ustc.sh  0.10s user 0.01s system 4% cpu 2.285 total

302重定向存在一些问题：

每个文件访问带来两次请求: T_MirrorHub + T_ActualMirror
静态路由非常不便，作用范围小

这边的想法是，把CDN放到DNS去做，利用DNS的智能解析功能来选择最快的ip。

目前我们尝试配置了archlinux.mirrors-cn.com，会根据地理位置解析到Tuna、USTC和SJTUG的不同ip上去。

之后，对于每一个镜像，都能够通过${mirror}.mirrors-cn.com/${mirror}来访问。

但是，目前还使用不了的原因有：

有的服务器没有Listen archlinux.mirrors-cn.com
有的服务器配置了http重定向https，但把archlinux.mirrors-cn.com重定向到https://archlinux.mirrors-cn.com
https://archlinux.mirrors-cn.com ，解析到的服务器没有证书，会报证书错误
（可能会有的）镜像名不一致，有的地方是imageA.mirrors-cn.com/imageA，有的地方是imageA.mirrors-cn.com/imagea

因此，如果需要利用DNS智能解析，就要保证所有解析到的ip都要能被相同方式访问。这里的相同方式包括：

所有加入解析列表的镜像都要能通过http://{imageName}.mirrors-cn.com/{imageName}，与https://...（在0次或多次重定向后）被访问
同一个镜像有共同的imageName

如果希望加入mirrors-cn.com这个计划，我们草拟了一份协议以规范加入mirrors-cn镜像源的表现：https://github.com/sjtug/mirrors-cn-protocol/ 。如果有意见欢迎提出。

tuna / mirrorhub

mirrorhub的性能问题与之后的计划 #2