Docker 中 NAT 和 HOST 的区别
- - snoopyxdy的博客官方说明使用Dokcer容器启动应用可以媲美直接在宿主机上启动的性能，宣称使用Docker启动应用大约可以达到原来性能的90%，如此低的性能损耗应当归功于Docker容器虚拟化的轻量级. 但是事实真的如官方所说，仅有10%的损耗吗. 我们下面将比较原生启动 redis 实例和使用Docker启动的性能对比.
Docker 中 NAT 和 HOST 的区别
标签：
docker
nat
host
| 发表时间：2015-12-10 09:37 | 作者：snoopyxdy
出处：http://snoopyxdy.blog.163.com
官方说明使用Dokcer容器启动应用可以媲美直接在宿主机上启动的性能，宣称使用Docker启动应用大约可以达到原来性能的90%，如此低的性能损耗应当归功于Docker容器虚拟化的轻量级。
但是事实真的如官方所说，仅有10%的损耗吗？我们下面将比较原生启动 redis 实例和使用Docker启动的性能对比。
测试机器：
24 CPUS，48G内存的dell 420 物理服务器
其中redis的配置文件如下：
daemonize yes
port 6379
1、宿主机直接启动redis实例：
启动命令：
redis-server /etc/redis.conf
性能测试命令：
redis-benchmark -h 127.0.0.1 -p 6379 -q -d 100
结果如下：
PING_INLINE: 70224.72 requests per second
PING_BULK: 97276.27 requests per second
SET: 99403.58 requests per second
GET: 99403.58 requests per second
INCR: 100603.62 requests per second
LPUSH: 98425.20 requests per second
LPOP: 98425.20 requests per second
SADD: 100502.52 requests per second
SPOP: 100401.61 requests per second
LPUSH (needed to benchmark LRANGE): 99700.90 requests per second
LRANGE_100 (first 100 elements): 40733.20 requests per second
LRANGE_300 (first 300 elements): 14907.57 requests per second
LRANGE_500 (first 450 elements): 5781.68 requests per second
LRANGE_600 (first 600 elements): 3832.59 requests per second
MSET (10 keys): 63816.21 requests per second
2、利用taskset绑定一个CPU，在宿主机上启动redis（这也是业界优化redis的一个偏方）：
启动命令：
taskset -c 02 redis-server /etc/redis.conf
性能测试命令：
redis-benchmark -h 127.0.0.1 -p 6379 -q -d 100
结果如下：
PING_INLINE: 73746.31 requests per second
PING_BULK: 99601.60 requests per second
SET: 99700.90 requests per second
GET: 100200.40 requests per second
INCR: 100000.00 requests per second
LPUSH: 99403.58 requests per second
LPOP: 99108.03 requests per second
SADD: 101317.12 requests per second
SPOP: 100502.52 requests per second
LPUSH (needed to benchmark LRANGE): 99304.87 requests per second
LRANGE_100 (first 100 elements): 40883.07 requests per second
LRANGE_300 (first 300 elements): 15015.02 requests per second
LRANGE_500 (first 450 elements): 5262.05 requests per second
LRANGE_600 (first 600 elements): 3892.87 requests per second
MSET (10 keys): 52938.06 requests per second
3、利用Docker的Nat网络模式启动redis（我们之前介绍的方式）：
启动命令：
docker run -v /usr/local/redis.conf:/etc/redis.conf -p 6379:6379 --name myredis -d redis:2.8.19
性能测试命令：
redis-benchmark -h 127.0.0.1 -p 6379 -q -d 100
结果如下：
PING_INLINE: 40983.61 requests per second
PING_BULK: 50276.52 requests per second
SET: 49776.01 requests per second
GET: 46533.27 requests per second
INCR: 48309.18 requests per second
LPUSH: 54406.96 requests per second
LPOP: 56369.79 requests per second
SADD: 36153.29 requests per second
SPOP: 44130.62 requests per second
LPUSH (needed to benchmark LRANGE): 49726.51 requests per second
LRANGE_100 (first 100 elements): 21459.23 requests per second
LRANGE_300 (first 300 elements): 6416.01 requests per second
LRANGE_500 (first 450 elements): 4156.97 requests per second
LRANGE_600 (first 600 elements): 3139.32 requests per second
MSET (10 keys): 50787.20 requests per second
是不是结果令大家大跌眼镜，为什么官方号称只有10%的性能损耗，而实际测试下来竟然相差了50%左右，到底哪里出了问题呢？
其实问题就出在了Docker的Nat网络模式上，如果我们换一种方式启动Docker容器，再看下测试结果，是不是能大幅提升性能呢？
4、利用Docker的Host网络模式启动redis：
启动命令：
docker run -v /usr/local/redis.conf:/etc/redis.conf --net="host" --name myredis -d redis:2.8.19
性能测试命令：
redis-benchmark -h 127.0.0.1 -p 6379 -q -d 100
结果如下：
PING_INLINE: 67613.25 requests per second
PING_BULK: 100908.17 requests per second
SET: 97751.71 requests per second
GET: 98135.42 requests per second
INCR: 101936.80 requests per second
LPUSH: 100000.00 requests per second
LPOP: 99206.34 requests per second
SADD: 100704.94 requests per second
SPOP: 100806.45 requests per second
LPUSH (needed to benchmark LRANGE): 100000.00 requests per second
LRANGE_100 (first 100 elements): 40916.53 requests per second
LRANGE_300 (first 300 elements): 15008.25 requests per second
LRANGE_500 (first 450 elements): 5552.78 requests per second
LRANGE_600 (first 600 elements): 3820.29 requests per second
MSET (10 keys): 70224.72 requests per second
最终第四个测试结果令我们满意，符合官方所说的Docker启动应用几乎没有性能损耗的说法，这点大家在使用Docker部署应用的时候一定要注意。另外值得一提的是，业界绑定CPU的偏方似乎并没有什么X用，可能在单机跑多个redis实例的情况下，有那么一点点性能提升。
最后，在使用了host模式启动Docker之后，是无法改变container监听的端口号的，我们可以通过挂载不同的配置文件来避免端口冲突的发生。
相关 [docker nat host] 推荐：
iptables NAT 学习
- - BlogJava-首页技术区为了搞清楚iptables NAT的过程，做了这个实验. 使用了1台双网卡服务器和1台单网卡服务器，2个网段. 1. 为了看到调度服务器上的数据转发过程，首先在调度服务器上分出内核的debug日志：. l 在/etc/rsyslog.conf最后增加：kern.debug /var/log/iptables.log.
nat穿透原理
- - 开源软件 - ITeye博客一直以来，说起NAT穿透，很多人都会被告知使用UDP打孔这个技术，基本上没有人会告诉你如何使用TCP协议去穿透（甚至有的人会直接告诉你TCP协议是无法实现穿透的）. 但是，众所周知的是，UDP是一个无连接的数据报协议，使用它就必须自己维护收发数据包的完整性，这常常会大大增加程序的复杂度，而且一些程序由于某些原因，必须使用TCP协议，这样就常常令一些开发TCP网络程序的人员“谈穿透色变”.
Docker & Flatpak
- - IT瘾-dev目前最流行的技术莫过于Docker，Docker和Docker衍生的东西用到了很多很酷的技术，目前deepin应用软件发布转变成flatpak，这些看似风牛马不相及的技术方案，实际都使用了一个共同的底层技术——Namespace，假如没有namespace支持，这些技术实现都将成为空中楼阁. 一句话总结，无论是Docker、sysmted-nspawn还是flatpak，都是在namespace基础上，针对不同的场景，生出的不同的解决方案.
Google Host Patch自动获取脚本
- Ken - iGFWGoogle最近发布了Google Plus，但是几乎是刚刚一发布就无法访问，同时面对着GMail，Google搜索越来越频繁的连接阻断问题，我们急需要一个方案来更方便的访问Google服务. 如果在校园网中，IPv6无疑是一个良好的解决方案，本博这篇文章给出了相关方法，在Google Code上也有一个Project专门维护Google IPv6的Host列表.
docker初体验之docker-tomcat
- - BlogJava-首页技术区docker已经是现在最热的容器技术，最近也去体验了一下，在daocloud注册了一个账号，并开始本机实战docker. daocloud免费有两个容器可用，体验送T恤，邀请送书，这里我分享一个daocloud的邀请码 https://account.daocloud.io/signup?invite_code=mxeq2jkmcur37vz6ven8，daocloud是非常棒的容器云平台，使用体验好，问题响应也及时，绑定微信还送一个额外容器.
kubernetes移除Docker？
- -两周前，Kubernetes在其最新的Changelog中宣布1.20之后将要弃用dockershime，也就说Kubernetes将不再使用Docker做为其容器运行时. 这一消息持续发酵，掀起了不小的波澜，毕竟Kubernetes+Docker的经典组合是被市场所认可的，大量企业都在使用. 看上去这个“弃用”的决定有点无厘头，那么为什么Kubernetes会做出这样的决定.
[转]iptables防火墙与NAT服务
- - 小鸥的博客iptables防火墙与NAT服务. (1)设置在不同的网络或网络安全域之间的一系列部件的组合,它能增强机构内部网络的安全性. (2)通过审查经过每一个数据包，判断它是否有相匹配的过滤规则，根据规则先后顺序一一进行比较，直到满足其中的一条规则为止，然后依据控制机制做出相应的动作，若都不能满足，则将数据包丢弃，从而保护网络安全.
Xen 虚拟机的 NAT 网络配置
- - vpsee.com我们使用 Xen 虚拟机的时候一般都是用桥接（bridging）的方式把虚拟机（domU）直接暴露在网络上，就像网络上单独的一台服务器一样，这种方式简单好用，不用在 dom0 做任何的端口转发也不用任何 iptable 规则. 不过除了 bridging 以外，Xen 还支持 routing 和 NAT 的方式配置虚拟机网络.
NAT穿透解决方案介绍
- - 编程语言 - ITeye博客Agent B看到的source address就是经过转换后的IP和Port并不知道Agent A的局域网地址；当Agent B的响应到达Agent A的NAT设备后，NAT设备查找内存中保存的和这个外网地址相对应的内网地址，如果找到后就将这个data packet转发到这个地址，这样就实现了通信.