最近一直在处理 https://mirrors.sjtug.sjtu.edu.cn 的一些事情，突然有了一些脑洞记录下来：
镜像站的目的主要有2个：
- 分流主源与临近的镜像源，降低带宽压力
- 加速用户的下载
同时，镜像站的资源是有限的，主要包括：
- 网络资源（从上游pull，向用户分发push）
- 硬盘资源（从上游pull时候的write，向用户分发时候的（带cache）的read）
“镜像”并不一定真的要全量下载到本地硬盘，只需要对用户透明即可。根据这个定义，反代也是一种“镜像”。
这里不考虑一致性的问题，默认看到上游任何一段连续时间的文件内容都是被允许的：很多上游源（arch）已经弃疗了，有的用两阶段同步（debian）缓解问题，只有少数（kali）之类的还在push mirroring。
同时，假设push的间隔是每天一次。
目前有三种常用的“镜像”方式：全量pull、带/不带cache的反向代理。
对以上提到的目的与资源，我们希望用定量的方式来衡量：
- 镜像前后能让主源与附近的源降低多少流量
- 用户下载的速度能提升多少
- pull的时候每次需要多少流量？push的时候每天总共需要多少流量？
- write的时候每次会写入多少？push的时候每天总共会读取多少？
我们用这几个因素来衡量一下这几种方式的好坏：
镜像前后能让主源与附近的源降低多少流量
这个问题主要取决于：
- 这个镜像能分流多少用户（流量）？
- 这些用户（流量）原来会去哪？
对于一个已经在运行的镜像站来说，1是可以通过观测得到的，2的话取决于镜像本身的性质：一部分用户会选择通过手动配置/auto ping选择自己最熟悉、最快的镜像站，也有一部分用户会选择中心源。
在假设
- 这种选择和地域无关
- 用户在同等熟悉情况下，会选择和geoloc最接近的镜像站
- 用户对镜像站的熟悉程度和这个镜像站的流量成正比 的情况下：
TODO…