考虑到我手上的服务器逐渐的增多，有时候需要大规模的部署同一个文件，例如因为方便使用systemtap这个工具定位问题，需要把手上几百台服务器同时安装kernel-debuginfo这个包，原有的方式采用一个源服务器，采用rsync或者scp之类的文件传输方式只能做到一个点往下分发这个文件，这个时候下发的速度就会比较的慢，基于以上原因，我写了一个基于bt协议传输文件的小工具，实际测试，传输到10个机房，70多台机器传输一个240M的这个内核文件，到所有的机器，源采用限速2m/s的上传速度，测试的结果大概只要140s，就可以全部传输完毕，这个效率是非常之高，如果不限速的情况下速度会更快，下面把这个程序开源出来。

    NAT是在传输层及以上做的，传输层最主要的2个协议是TCP和UDP。对于TCP和UDP而言，每个包都有很基本的4个要素：src ip、src port、dst ip、dst port。 根据在做NAT的时候是否保留src ip和src port，可以把NAT分为这么三种： Cone: 将src ip映射到一个固定的IP，并且将src port映射到一个固定的Port，无论dst ip和dst port是什么。 Single IP address, symmetric：将src ip映射到一个固定的IP，将src port映射到一个随机的port，但是保证对于相同的(dst ip,dst port), src port始终相同。（否则双方没法通话啊，回来的包回给哪个端口呢？） Multiple IP address, symmetric:与上面类似，但是src ip可能会有多个。

    从09年第一次阅读Dynamo论文，到最近阅读Amazon S3的一篇专利，一路过来对论文的理解可以简单归结为两个字

    分享下2年前做过的一个传输项目，比较粗糙，当年的相关文档找不全了:( 背景：运维中经常遇到这类传输需求，A生成数据，然后将数据分发到下游B1,B2,B3….Bn。传统的做法有如下几种： A生成数据文件后，顺带生成flag（标记文件）。下游机器配置定时任务，定期探测A机器的数据是否生成，当生成后通过wget下载 A生成数据文件后，直接通过scp将数据推送到下游机器。 上述方式一般都采用系统命令和SSH信任关系，对系统依赖较强...