月度归档：2015年12月

nginx配置limit_conn_zone来限制并发连接数以及下载带宽

配置方法如下：

1、在nginx.conf里的http{}里加上如下代码：

#ip limit
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;

复制代码

2、在需要限制并发数和下载带宽的网站配置server{}里加上如下代码：

limit_conn perip 2;
limit_conn perserver 20;
limit_rate 100k;

复制代码

补充说明下参数：

$binary_remote_addr是限制同一客户端ip地址；
$server_name是限制同一server最大并发数；
limit_conn为限制并发连接数；
limit_rate为限制下载速度；

转另一篇文章：http://hxl2009.blog.51cto.com/779549/1324473

注意：

nginx 1.1.8 之后的版本的语法改为limit_conn_zone $binary_remote_addr zone=NAME:10m;

NAME 就是 zone 的名字详情请看这里 http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html

限制连接数:

要限制连接，必须先有一个容器对连接进行计数，在http段加入如下代码：

“zone=” 给它一个名字，可以随便叫，这个名字要跟下面的 limit_conn 一致

$binary_remote_addr = 用二进制来储存客户端的地址，1m 可以储存 32000 个并发会话

… 省掉 N 字

http

{

limit_conn_zone $binary_remote_addr zone=addr:10m;

接下来需要对server不同的位置（location段）进行限速，比如限制每个IP并发连接数为1，则

server

{

listen 80;

server_name 192.168.11.128;

index index.html index.htm index.php;

limit_conn addr 1; #是限制每个IP只能发起1个连接（addr 要跟 limit_conn_zone 的变量对应）

limit_rate 100k; #限速为 100KB/秒

root html;

注意事项：

limit_rate 100k; //是对每个连接限速100k。这里是对连接限速，而不是对IP限速！如果一个IP允许两个并发连接，那么这个IP就是限速limit_rate * 2

直播及点播的视频码率,帧率和分辨率关系与区别

直播及点播视频码率,帧率和分辨率到底哪一个影响电影的清晰度

码率：影响体积，与体积成正比：码率越大，体积越大；码率越小，体积越小。

码率就是数据传输时单位时间传送的数据位数,一般我们用的单位是kbps即千位每秒。也就是取样率（并不等同与采样率，采样率的单位是Hz，表示每秒采样的次数），单位时间内取样率越大，精度就越高，处理出来的文件就越接近原始文件，但是文件体积与取样率是成正比的，所以几乎所有的编码格式重视的都是如何用最低的码率达到最少的失真，围绕这个核心衍生出来cbr（固定码率）与vbr（可变码率）， “码率”就是失真度，码率越高越清晰，反之则画面粗糙而多马赛克。

下面是通过一个wav文件的采样率来计算码率和文件大小，通过MediaInfo工具显示的文件信息如下：

概要

完整名称 :audio\wav\adele-rolling_in_the_deep.wav

文件格式 : Wave

文件大小 : 38.3 MiB

长度 : 3分 47秒

平均混合码率 : 1 411 Kbps

音频

ID : 0

文件格式 : PCM

格式设置,Endianness : Little

编码设置ID : 1

编码设置ID/提示信息 : Microsoft

长度 : 3分 47秒

码率 : 1 411.2 Kbps

声道 : 2声道

采样率 : 44.1 KHz

位深度 : 16位

大小 : 38.3 MiB (100%)

1.码率计算公式：

码率=采样率 x 位深度 x 声道

所以，上面文件的码率= 44.1Khz x 16位 x 2声道 = 1411.2 Kbps

2.文件大小 = 码率 x 时长 = 1411.2 Kbps x (3 x 60 + 47 )s = 1411.2Kbps x 227s

=38102.4 Kb

38102.4 Kb / 1024 Kb/M = 37.2M

近似等于mediainfo工具显示的文件大小38.3M。

注：此计算公式对未压缩的wav格式文件有效，不适用于mp3等被压缩的文件。

帧率：影响画面流畅度，与画面流畅度成正比：帧率越大，画面越流畅；帧率越小，画面越有跳动感。如果码率为变量，则帧率也会影响体积，帧率越高，每秒钟经过的画面越多，需要的码率也越高，体积也越大。

帧率就是在1秒钟时间里传输的图片的帧数，也可以理解为图形处理器每秒钟能够刷新几次，

分辨率：影响图像大小，与图像大小成正比：分辨率越高，图像越大；分辨率越低，图像越小。

清晰度

在码率一定的情况下，分辨率与清晰度成反比关系：分辨率越高，图像越不清晰，分辨率越低，图像越清晰。
在分辨率一定的情况下，码率与清晰度成正比关系，码率越高，图像越清晰；码率越低，图像越不清晰。

带宽、帧率

例如在ADSL线路上传输图像，上行带宽只有512Kbps，但要传输4路CIF分辨率的图像。按照常规，CIF分辨率建议码率是512Kbps，那么照此计算就只能传一路，降低码率势必会影响图像质量。那么为了确保图像质量，就必须降低帧率，这样一来，即便降低码率也不会影响图像质量，但在图像的连贯性上会有影响。

php日志错误分析:网站http返回502与504错误分析

一. 戏说
不管你是做运维还是做开发，哪怕你是游客，时不时会遇到502 Bad Gateway或504 Gateway Time-out。出现这页面，把服务重启下，再实在不行重启下服务器，问题就解决了，但是，这问题还是会困扰着你，特别是做运维的人员。夜黑风高正酣睡时，一个电话响起，让你重启服务或IISRESET，肯定是极大不爽，立马要问候他妈了。呵呵，本文总结502与504故障分析与解决方法。

二. 状态码解释
502 Bad Gateway：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
504 Gateway Time-out：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。

三. 502 Bad Gateway原因分析
将请求提交给网关如php-fpm执行，但是由于某些原因没有执行完毕导致php-fpm进程终止执行。说到此，这个问题就很明了了，与网关服务如php-fpm的配置有关了。
php-fpm.conf配置文件中有两个参数就需要你考虑到，分别是max_children和request_terminate_timeout。
max_children最大子进程数，在高并发请求下，达到php-fpm最大响应数，后续的请求就会出现502错误的。可以通过netstat命令来查看当前连接数。
request_terminate_timeout设置单个请求的超时终止时间。还应该注意到php.ini中的max_execution_time参数。当请求终止时，也会出现502错误的。
当积累了大量的php请求，你重启php-fpm释放资源，但一两分钟不到，502又再次呈现，这是什么原因导致的呢？这时还应该考虑到数据库，查看下数据库进程是否有大量的locked进程，数据库死锁导致超时，前端终止了继续请求，但是SQL语句还在等待释放锁，这时就要重启数据库服务了或kill掉死锁SQL进程了。
对于长时间的请求可以考虑使用异步方式，可以参阅《关于PHP实现异步操作的研究》。

四. 504 Gateway Time-out原因分析
504错误一般是与nginx.conf 配置有关了。主要与以下几个参数有关：fastcgi_connect_timeout、fastcgi_send_timeout、 fastcgi_read_timeout、fastcgi_buffer_size、fastcgi_buffers、 fastcgi_busy_buffers_size、fastcgi_temp_file_write_size、 fastcgi_intercept_errors。特别是前三个超时时间。如果fastcgi缓冲区太小会导致fastcgi进程被挂起从而演变为 504错误。

五. 小结
总而言之，502错误主要从四个方向入手：
1. max_children
2. request_terminate_timeout、max_execution_time
3. 数据库
4. 网关服务是否启动如php-fpm

504错误主要查看nginx.conf关于网关如fastcgi的配置

php日志分析:解决NGINX+PHP-FPM failed to ptrace(PEEKDATA) Input/output error出错问题

今天查看php的错误日志（error_log = /usr/local/php/var/log/php-fpm.log ）和慢日志（slowlog = /usr/local/php/var/log/php-fpm.log.slow ） , 发现错误日志里很多 “ ERROR: failed to ptrace(PEEKDATA) pid 4276: Input/output error (5) ”这样的错误，想找出出现这错误的原因于是从网上搜了如下的文章。他说是他的网站经常出现 ”bad gateway“ 错误才去查日志发现有这个错误。我现在还不知道我的日志里出现这样的错误是不是我的页面也出现 ”bad gateway“ 的错误。带查证ing。

查了好几个资料都说是 php开启了慢日志引起的为了让系统不出现异常决定吧慢日志注释掉。

request_slowlog_timeout = 30
slowlog = /usr/local/php/var/log/php-fpm.log.slow

资料一：

网站总是出现bad gateway 提示，时有，时无，查看了一下error_log日志，居然出现一堆错误，如下

[29-Mar-2014 22:40:10] ERROR: failed to ptrace(PEEKDATA) pid 4276: Input/output error (5)
[29-Mar-2014 22:53:54] ERROR: failed to ptrace(PEEKDATA) pid 4319: Input/output error (5)
[29-Mar-2014 22:56:30] ERROR: failed to ptrace(PEEKDATA) pid 4342: Input/output error (5)
[29-Mar-2014 22:56:34] ERROR: failed to ptrace(PEEKDATA) pid 4321: Input/output error (5)
[29-Mar-2014 22:56:40] ERROR: failed to ptrace(PEEKDATA) pid 4314: Input/output error (5)

网上也找了很多方法，很多人说是 rlimit_files 打开文件数的问题，但是觉得不太靠谱，最后找到鬼佬的话，看上去还有几分道理。

http://serverfault.com/questions/406532/i-o-error-with-php5-fpm-ptracepeekdata-failed

It appears you have request_slowlog_timeout enabled. This normally takes any request longer than N seconds, logs that it was taking a long time, then logs a stack trace of the script so you can see what it was doing that was taking so long.

In your case, the stack trace (to determine what the script is doing) is failing. If you’re running out of processes, it is because either:

After php-fpm stops the process to trace it, the process fails to resume because of the error tracing it
The process is resuming but continues to run forever.
My first guess would be to disable request_slowlog_timeout. Since it’s not working right, it may be doing more harm than good. If this doesn’t fix the issue of running out of processes, then set the php.ini max_execution_time to something that will kill the script for sure.

看样子是因为我打开了slowlog 然后，再设置了 request_slowlog_timeout 这个参数，，所以后php 没有执行完就出错了。。

上面解决的办法是：

禁用 php-fpm.conf 里的 request_slowlog_timeout 和 slowlog ，然后，修改 php.ini 里的max_execution_time 参数

资料二：

最近服务器频繁出现502（nginx+php+php-fpm的架构），调试过程中在php-fpm的日志中发现了大量的：

[02-Aug-2014 08:55:24] ERROR: failed to ptrace(PEEKDATA) pid 4046: Input/output error (5)
[02-Aug-2014 08:55:24] NOTICE: finished trace of 4046
[02-Aug-2014 08:55:24] NOTICE: child 4047 stopped for tracing
[02-Aug-2014 08:55:24] NOTICE: about to trace 4047
[02-Aug-2014 08:55:24] ERROR: failed to ptrace(PEEKDATA) pid 4047: Input/output error (5)
[02-Aug-2014 08:55:24] NOTICE: finished trace of 4047
[02-Aug-2014 08:55:24] NOTICE: child 4054 stopped for tracing
[02-Aug-2014 08:55:24] NOTICE: about to trace 4054
[02-Aug-2014 08:55:24] ERROR: failed to ptrace(PEEKDATA) pid 4054: Input/output error (5)
[02-Aug-2014 08:55:24] NOTICE: finished trace of 4054
[02-Aug-2014 08:55:24] NOTICE: child 4076 stopped for tracing
[02-Aug-2014 08:55:24] NOTICE: about to trace 4076

经对比最近两次系统调优所使用的配置文件发现，是因为php-fpm的配置引起：

#request_slowlog_timeout = 5s
#slowlog = /usr/local/php/var/log/php-fpm.log.slow

解决办法是注释掉上面的配置即可。/etc/init.d/php-fpm restart生效

scons-2.4.1 和jsoncpp 库配置

由于需要将项目能够在某平台上跑起来，所以需要对服务器进行重新编译，将boost库版本降下来，比较悲催。

平台是CentOS release 6.5 (Final)

首先是编译jsoncpp，步骤如下：

1. 下载scons-2.4.1.tar.gz，解压得到scons-2.4.1 下载入口：http://sourceforge.net/projects/scons/files/scons/2.4.1/

2. 进目录去，执行python setup.py install

3. 下载jsoncpp-src-0.5.0.tar.gz，解压得到jsoncpp-src-0.5.0 下载入口：http://sourceforge.net/projects/jsoncpp/?source=typ_redirect

4. 进目录去，执行：scons platform=linux-gcc，可能结果报错：No module named SCons.Script

5. 修改scons命令：vim /usr/local/bin/scons，在187行：import SCons.Script前面添加一行：sys.path.append(“/usr/local/lib64/scons-2.2.0”)

我的系统是64位的，如果你的是32位的，那么可能是：sys.path.append(“/usr/local/lib/scons-2.2.0”)，自己去/user/local/lib和lib64目录下看看就行了

6. 保存修改后，重新执行：scons platform=linux-gcc，O了

7.当然你可以把库直接放到/usr/lib.

cp jsoncpp-src-0.5.0/libs/linux-gcc-4.4.7/libjson_linux-gcc-4.4.7_libmt.* /usr/lib/

Nginx + FastCgi + Spawn-fcgi + c 的架构搭建

Php写的很有段时间了，最近看公司一些关键的后端CGI都是用C写的，以lighthttp 最为server 。忽然也有种学习用C写CGI的想法。虽然php结合php-fpm的fastcgi模式也有不错的性能，反正多学一种东西又有和不可以呢？何况，某些情况下C的性能还是php无法比拟的。

先有必要有这样第一个认识：ngxin作为一个webserver，本身并不包含CGI的解释器，需要通过一个中间件【例如php-fpm】来运行CGI。他们之间的模式大致是：

      nginx   <–   socket –>   php-fpm——–>php

那么nginx既然要运行c写的CGI那么也应该有类似php-fpm的东西。baidu, google了下，发现有一个spawn-fcgi的东西。原本是lighttp 内的fastcgi进程管理器。于是又搜索了下，折腾了一个下午，终于抛出了经典的hello world !!!   。下面是具体步骤：

大致分为5步：

1、安装Spawn-fcgi    【启动cgi的时候需要】

wget http://www.lighttpd.net/download/lighttpd-1.4.19.tar.gz tar zxvf lighttpd-1.4.19.tar.gz cd lighttpd-1.4.19 ./configure make

复制编译好的spawn-fcgi到 nginx目录，很主要！！！！

cp ./src/spawn-fcgi /usr/local/nginx/sbin/

2、安装fastcgi库:: 【提供编写cgi时的类库】

wget http://www.fastcgi.com/dist/fcgi.tar.gz tar zxvf fcgi.tar.gz cd fcgi ./configure make make install

fcgio.cpp:50: error: ‘EOF’ was not declared in this scope解决办法PS：

我想这个fcgi开发一点也不活跃，而gcc的最新版本不断出来，很有可能是由于这方面引的原因，我又调整了一下关键字

gcc compile fcgi，(之前都是没有方向的搜索)。终于在第一条结果中找到原因了：http://bugs.gentoo.org/256654

解决办法：

在/include/fcgio.h文件中加上 #include <cstdio>，然后再编译安装就通过了。

3、测试代码::


	#include <fcgi_stdio.h>
int main( int argc, char *argv[] )
{
  while( FCGI_Accept() >= 0 )
  {
      FCGI_printf( "Status: 200 OK\r\n" );
      FCGI_printf( "Content-Type: text/html\r\n\r\n" );
      FCGI_printf( "Hello world in C\n" );
  }
  return 0;
}

编译：：

g++ -o test.cgi test.cpp -L /usr/local/lib/ -lfcgi

4、启动Spawn-fcgi::

spawn-fcgi -a 127.0.0.1 -p 7000 -u www -f /data/cgi-bin/test.cgi

如果报： error while loading shared libraries: libfcgi.so.0: cannot open shared object file: No such file or directory

请执行如下命令：为了这个错误，折腾了很长时间哦！

cp /usr/local/lib/libfcgi.so.0 /usr/lib

5、配置nginx.conf


	  location ~ \.cgi$
  {
        fastcgi_pass  127.0.0.1:7000;
        fastcgi_index index.cgi;
        fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
        include fastcgi_params;
    }

重启nginx

/etc/init.d/nginx reload

ssh服务监听多个端口

修改sshd的配置文件

默认位置：/etc/ssh/sshd_config

注释掉 Port 这行

然后添加 ListenAddress 行

e.g： ListenAddress 10.243.140.211:22

ListenAddress 10.243.140.211:22

ListenAddress 0.0.0.0:36000

这样ssh就监听了两个端口， port 22监听在10.243.140.211上， port 36000监听在本机所有IP0.0.0.0上

然后重启sshd服务生效，命令 /etc/int.d/sshd restart

重启后注意iptables同样要开放端口，如果是云服务要同时主要云服务提供的防火墙是否放开访问。

114DNS、Dnspod DNS、阿里DNS、百度DNS、360DNS、Google DNS公共DNS评测体验报告

114DNS、腾讯dnspod DNS、阿里DNS、百度DNS、360DNS、Google DNS公共DNS评测体验报告从ping及dig返回时间对比测试，国内DNS普遍很快，而阿里DNS最快，次之腾讯dnspod DNS，然后114DNS，百度及360DNS中规中矩，而Google DNS还是很慢，我们还是拥抱国产DNS吧，推荐腾讯DNSPOD DNS 119.29.29.29 阿里DNS 223.6.6.6、223.5.5.5

[root@localhost ~]# ping 114.114.114.114 -c 4;ping 119.29.29.29 -c 4;ping 223.6.6.6 -c 4;ping 180.76.76.76 -c 4;ping 101.226.4.6 -c 4;ping 8.8.8.8 -c 4

PING 114.114.114.114 (114.114.114.114) 56(84) bytes of data.
64 bytes from 114.114.114.114: icmp_seq=1 ttl=77 time=24.9 ms
64 bytes from 114.114.114.114: icmp_seq=2 ttl=95 time=26.5 ms
64 bytes from 114.114.114.114: icmp_seq=3 ttl=65 time=26.0 ms
64 bytes from 114.114.114.114: icmp_seq=4 ttl=76 time=26.4 ms

— 114.114.114.114 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3031ms
rtt min/avg/max/mdev = 24.919/25.990/26.536/0.671 ms
PING 119.29.29.29 (119.29.29.29) 56(84) bytes of data.
64 bytes from 119.29.29.29: icmp_seq=1 ttl=53 time=10.2 ms
64 bytes from 119.29.29.29: icmp_seq=2 ttl=53 time=15.3 ms
64 bytes from 119.29.29.29: icmp_seq=3 ttl=53 time=10.0 ms
64 bytes from 119.29.29.29: icmp_seq=4 ttl=53 time=9.68 ms

— 119.29.29.29 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3014ms
rtt min/avg/max/mdev = 9.684/11.345/15.391/2.345 ms
PING 223.6.6.6 (223.6.6.6) 56(84) bytes of data.
64 bytes from 223.6.6.6: icmp_seq=1 ttl=53 time=7.56 ms
64 bytes from 223.6.6.6: icmp_seq=2 ttl=53 time=8.45 ms
64 bytes from 223.6.6.6: icmp_seq=3 ttl=53 time=7.08 ms
64 bytes from 223.6.6.6: icmp_seq=4 ttl=53 time=6.69 ms

— 223.6.6.6 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3011ms
rtt min/avg/max/mdev = 6.698/7.450/8.453/0.661 ms
PING 180.76.76.76 (180.76.76.76) 56(84) bytes of data.
64 bytes from 180.76.76.76: icmp_seq=1 ttl=54 time=36.7 ms
64 bytes from 180.76.76.76: icmp_seq=2 ttl=54 time=37.3 ms
64 bytes from 180.76.76.76: icmp_seq=3 ttl=54 time=36.5 ms
64 bytes from 180.76.76.76: icmp_seq=4 ttl=54 time=36.1 ms

— 180.76.76.76 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3041ms
rtt min/avg/max/mdev = 36.136/36.675/37.327/0.432 ms
PING 101.226.4.6 (101.226.4.6) 56(84) bytes of data.
64 bytes from 101.226.4.6: icmp_seq=1 ttl=55 time=30.5 ms
64 bytes from 101.226.4.6: icmp_seq=2 ttl=55 time=30.7 ms
64 bytes from 101.226.4.6: icmp_seq=3 ttl=55 time=28.4 ms
64 bytes from 101.226.4.6: icmp_seq=4 ttl=55 time=30.6 ms

— 101.226.4.6 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3035ms
rtt min/avg/max/mdev = 28.478/30.091/30.722/0.934 ms
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=2 ttl=45 time=39.6 ms

— 8.8.8.8 ping statistics —
4 packets transmitted, 1 received, 75% packet loss, time 4000ms
rtt min/avg/max/mdev = 39.617/39.617/39.617/0.000 ms
[root@localhost ~]# traceroute -n 114.114.114.114;traceroute -n 119.29.29.29;traceroute -n 223.6.6.6;traceroute -n 180.76.76.76;traceroute -n 101.226.4.6;traceroute -n 8.8.8.8
traceroute to 114.114.114.114 (114.114.114.114), 30 hops max, 60 byte packets
1 192.168.1.100 0.470 ms 0.670 ms 0.886 ms
2 100.64.0.1 6.717 ms 6.723 ms 10.996 ms
3 183.56.68.41 6.734 ms 6.794 ms 6.844 ms
4 183.56.64.161 7.278 ms 7.200 ms 7.313 ms
5 183.56.65.38 10.736 ms 10.794 ms 10.733 ms
6 202.97.64.77 33.088 ms 32.746 ms 32.487 ms
7 218.2.134.2 32.125 ms 26.167 ms 26.070 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
traceroute to 119.29.29.29 (119.29.29.29), 30 hops max, 60 byte packets
1 192.168.1.100 0.448 ms 0.654 ms 0.871 ms
2 100.64.0.1 131.462 ms 131.469 ms 131.562 ms
3 183.56.68.97 6.767 ms 6.779 ms 6.778 ms
4 183.56.64.113 6.848 ms 6.902 ms 6.999 ms
5 183.56.65.14 10.389 ms 10.449 ms 10.617 ms
6 61.140.0.37 10.306 ms 10.130 ms 11.986 ms
7 61.140.1.10 16.669 ms 10.706 ms 10.718 ms
8 183.61.145.194 9.224 ms 10.416 ms 10.001 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
traceroute to 223.6.6.6 (223.6.6.6), 30 hops max, 60 byte packets
1 192.168.1.100 0.462 ms 0.669 ms 0.890 ms
2 14.127.64.1 13.381 ms 13.834 ms 14.015 ms
3 113.106.43.229 7.094 ms 7.107 ms 7.198 ms
4 119.136.12.158 7.109 ms 7.232 ms 7.284 ms
5 183.56.66.2 10.394 ms 183.56.65.62 13.996 ms 183.56.65.74 8.326 ms
6 119.147.221.10 7.730 ms 119.147.223.106 9.083 ms 119.147.221.130 11.309 ms
7 119.147.220.238 12.315 ms 7.492 ms 7.509 ms
8 * * 14.215.137.50 9.989 ms
9 * 42.120.242.234 10.362 ms 10.063 ms
10 42.120.242.214 14.005 ms * 14.055 ms
11 42.120.253.10 6.657 ms * 42.120.253.2 8.375 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
traceroute to 180.76.76.76 (180.76.76.76), 30 hops max, 60 byte packets
1 192.168.1.100 0.378 ms 0.581 ms 0.797 ms
2 14.127.64.1 7.265 ms 7.344 ms 7.409 ms
3 113.106.43.229 7.197 ms 7.313 ms 7.432 ms
4 59.40.49.110 7.507 ms 7.563 ms 7.590 ms
5 * * *
6 202.97.65.101 42.138 ms 42.004 ms *
7 * * *
8 220.181.17.118 38.775 ms * 39.623 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
traceroute to 101.226.4.6 (101.226.4.6), 30 hops max, 60 byte packets
1 192.168.1.100 0.495 ms 0.723 ms 0.882 ms
2 100.64.0.1 6.797 ms 6.844 ms 6.984 ms
3 183.56.68.41 6.885 ms 7.006 ms 7.060 ms
4 183.56.64.153 7.126 ms 7.187 ms 7.235 ms
5 183.56.65.2 11.666 ms 11.620 ms 11.698 ms
6 61.152.86.209 34.800 ms 38.168 ms 34.288 ms
7 * * *
8 124.74.233.134 31.913 ms 31.789 ms 33.247 ms
9 101.226.0.30 34.916 ms 33.804 ms 33.766 ms
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.1.100 0.433 ms 0.649 ms 0.859 ms
2 14.127.64.1 6.670 ms 6.890 ms 8.232 ms
3 113.106.43.233 6.648 ms 8.238 ms 8.758 ms
4 119.136.12.142 7.658 ms 8.177 ms 8.247 ms
5 183.56.65.62 14.300 ms 183.56.65.54 10.677 ms 183.56.65.62 14.295 ms
6 202.97.35.210 15.390 ms 15.077 ms 15.025 ms
7 202.97.60.70 11.663 ms 202.97.91.178 10.466 ms 202.97.60.70 10.198 ms
8 202.97.61.22 11.875 ms 14.665 ms 14.108 ms
9 202.97.62.214 11.413 ms 11.453 ms 12.505 ms
10 209.85.241.58 15.582 ms 13.576 ms 209.85.241.56 23.106 ms
11 216.239.40.13 11.598 ms 216.239.40.11 13.685 ms 12.834 ms
12 209.85.253.89 38.926 ms 38.903 ms 37.668 ms
13 64.233.175.205 44.340 ms 209.85.250.103 39.732 ms 39.431 ms
14 * * *
15 8.8.8.8 40.948 ms 41.787 ms 41.446 ms

腾讯DNSPod公共DNS 119.29.29.29 体验报告

上周看到DNSPod官网正式推出了公共DNS服务，并且号称是国内第一家支持ECS协议的公共DNS，于是抓紧时间体验了下。(其实很久之前就听闻DNSPod有搞公共DNS的动作，不知道为什么一直没有正式对外推广，后来看了服务介绍，个人猜测可能就是为了等Google的ECS协议才拖到现在发布吧。)Anyway，随着代表腾讯的DNSPod加入，现在BAT三家的公共DNS服务算是全部集齐!

DNSPod的公共DNS服务(又称“Public DNS+”)IP是119.29.29.29，和他家之前推出的移动解析“D+”是一样的，目测后端应该是同一套架构。(再吐个槽，怎么现在都喜欢在名字后面搞个+号呢?DNSPod之前出了httpdns叫D+，现在搞公共DNS，又叫Public DNS+，是为了响应“互联网+”号召么?)

言归正传!我特意找了国内外几家知名的公共DNS对比测试，它们是：

114dns： 114.114.114.114

阿里： 223.5.5.5.5

百度： 180.76.76.76

360： 101.226.4.6

Google： 8.8.8.8

从宣传资料来看，各家卖点都差不多，基本都是快速、准确、稳定、无劫持等等。下面就以这些方面做考量，用实际数据说话吧。

1、快速

关于DNS的持续测试工具，我简单选用ping测试。通过测试ping来测试延时，也可以反映DNS的解析延时。

1-1 从全国各地的3大运营商进行ping测试，测试结果如下：

如上图，可以清晰地看到Google的公共DNS平均时延极高，达到了174.495ms。果然从大陆访问Google远在台湾的服务器，速度还是太慢了!

1-2 以下是去掉Google后，国内几家公共DNS的延时表现：

DNSPod的公共DNS延时最低，为35ms;其次是百度的38.503ms和114的40.195ms;阿里的公共DNS延时最高，达到了41.246ms，仍需努力呀!

【结论】在国内，本土4家公共DNS的速度远远快于国外的Google。其中DNSPod最快，但与国内其他公共DNS差距不算大。至于360，连Anycast都没有，直接懒测out!

2、准确

如果运营商没有各种劫持和NAT的话，毫无疑问运营商的递归DNS应该是最准确的，但事实往往事与愿违，也是因为这样，我们不得不使用公共DNS，因此公共DNS的准确度，是重要的考虑因素。

理论来讲，如果公共DNS能支持Google的ECS协议，直接把用户的IP信息透传到授权DNS，授权DNS根据用户的IP而不是递归的IP来进行智能解析，这样就可以保证解析的准确度了。但是据了解，目前除了国外的Google和Open DNS支持ECS以外，国内之前的公共DNS都没有支持，DNSPod算是第一家。

个人认为主要原因应该是支持ECS的技术难度太高：需要每个域名、每个线路、每个IP段单独缓存，缓存量实在是太大了，而如果不缓存速度又太慢。技术投入大，而实际收益不高，应该是国内其他公共DNS对ECS望而却步的原因。

2.1 各家公共DNS对ECS协议的支持情况：

经过实际测试发现，DNSPod的公共DNS确实如它宣传的一致，是支持了ECS的!并且支持程度和Google一样，在接入端和后端都支持ECS。这确实是个惊喜!以后终于可以用着国内的公共DNS，享受快速解析的同时也不牺牲解析准确度了。

另外，国内其他4家中，只有阿里的公共DNS在接入端是支持ECS。但说实话，单单在接入端支持ECS对用户解析准确度的提升并没有实质性的帮助，还是和使用用户实际IP一样依赖后端递归DNS的分布情况，只是可以方便用户对解析准确度进行测试而已。所以像Open DNS的接入端都没有支持ECS，只是后端支持。

又有问题来了，当用户解析域名的授权DNS不支持ECS时，只有公共DNS支持ECS也没用啊。这时候怎么办呢?那就只有靠公共DNS的后端节点部署情况来提升解析准确度了。

在更多省份的运营商部署更多的递归DNS节点，就可以根据用户DNS请求中的IP分配到对应的节点去。当某个省份运营商没有递归DNS节点时，只能将请求分配到邻近省份同运营商的递归节点上，解析准确度会受到一定影响。简单来讲，就是“节点越多，解析越准确!”。

从各家公共DNS的官网上看了下后端递归DNS节点的部署情况，发现DNSPod的节点部署竟然也是最多的!

2.1 各家公共DNS节点情况：

如上，在国内几家公共DNS中，DNSPod的公共DNS无论是总结点数还是国外节点数，都比其他家高得多。(百度的节点数没公布，不知道有多少个。Google没有国内节点，测试了下国内用户的DNS查询请求，是路由到了台湾的解析服务器。)

【结论】DNSPod的公共DNS在接入端和后端都支持ECS协议，准确度等同Google，速度又比Google快。另外DNSPod密集的节点部署，进一步保证了解析准确度，Public DNS+确实值得推荐!为良心产品点赞!

3、稳定

因为无法知道各家公共DNS的具体架构，所以我用dig测试和ping测试丢包率来看下各家公共DNS服务的稳定性(未测试360)。

dig测试来看，BAT和114都部署了多个国内接入节点，且每个接入节点都是多台服务器组成的集群，都用同一个IP使用BGP Anycast接入，不管是单服务器故障还是单节点故障，都可以快速切换，稳定性上应该是都有保障的。Google的话，因为国内没有服务器且经常受到防护墙的干扰，稳定性欠佳。

3-1 ping测试的丢包率，各家公共DNS结果如下：

从ping测试的丢包率来看，国内各家公共DNS丢包率都差不多，DNSPod、阿里、114的丢包率都在1%左右，百度丢包略高为2.286%。

Google的结果就惨多了，半夜之后好点在30%左右，白天和上半夜在70%左右，整体丢包率为50%左右，纵是真爱也真心不敢推荐使用。

【结论】 DNSPod、阿里、114和百度4家的公共DNS服务，在稳定性没有看出明显差别，大家都可以放心使用。

4、无劫持

所有公共DNS都宣称自己无劫持，这个功能不太好测试，但是实际使用中确实没发现明显的恶意劫持，就算都过关吧。

以上就是我对市场上几家主流公共DNS服务进行的实际体验报告。最终发现新出的“Public DNS+”(腾讯DNSPod的公共DNS)确实不错，无论速度、准确度、稳定性都可圈可点，与其他家相比都不逊色甚至略强。感兴趣的不妨把DNS改为119.29.29.29试试吧。

腾讯DNSPod推出新Open DNS服务，公共DNS是119.29.29.29

9月7日消息，近日，腾讯旗下DNSPod正式推出了类似google open dns服务，公共域名解析服务Public DNS+，使用同一个服务IP 119.29.29.29，号称安全零劫持。

DNS劫持是一种通过改变指定域名在运营商侧DNS配置的正确解析指向，将该域名的解析结果重定向到劫持IP的劫持行为。DNS劫持类型可大致分为运营商缓存，广告，恶意劫持等类别。

DNSPod推出的Public DNS+服务号称有安全零劫持、准确不丢包、快速无等待、稳定多容灾的优势。

DNSPod建立于2006年3月份，是中国第一大DNS解析服务提供商、第一大域名托管商，2011年8月8日被腾讯收购，收购完成后，DNSPod保持独立运营。

国内外几家知名的公共DNS:

114dns： 114.114.114.114

阿里： 223.5.5.5.5

百度： 180.76.76.76

360： 101.226.4.6

Google： 8.8.8.8

我们就测试一下这些dns dig的速度如何：

360DNS 101.226.4.6 dig测试
# dig @101.226.4.6 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @101.226.4.6 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23722
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 331 IN CNAME v.tc.qq.com.
v.tc.qq.com. 3165 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 60 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 161 IN A 119.147.253.22
p21.tcdn.qq.com. 161 IN A 119.147.33.32
p21.tcdn.qq.com. 161 IN A 119.147.253.21
p21.tcdn.qq.com. 161 IN A 119.147.33.28
p21.tcdn.qq.com. 161 IN A 119.147.253.20
p21.tcdn.qq.com. 161 IN A 113.107.238.22
p21.tcdn.qq.com. 161 IN A 119.147.33.29
p21.tcdn.qq.com. 161 IN A 119.147.33.31
p21.tcdn.qq.com. 161 IN A 119.147.33.30
p21.tcdn.qq.com. 161 IN A 59.57.18.147
;; Query time: 31 msec
;; SERVER: 101.226.4.6#53(101.226.4.6)
;; WHEN: Wed Dec 2 11:50:05 2015
;; MSG SIZE rcvd: 244

百度DNSdig测试180.76.76.76
# dig @180.76.76.76 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @180.76.76.76 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54787
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 488 IN CNAME v.tc.qq.com.
v.tc.qq.com. 856 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 315 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 319 IN A 119.147.33.30
p21.tcdn.qq.com. 319 IN A 119.147.253.21
p21.tcdn.qq.com. 319 IN A 119.147.33.29
p21.tcdn.qq.com. 319 IN A 119.147.33.28
p21.tcdn.qq.com. 319 IN A 119.147.33.31
p21.tcdn.qq.com. 319 IN A 119.147.253.22
p21.tcdn.qq.com. 319 IN A 59.57.18.147
p21.tcdn.qq.com. 319 IN A 119.147.253.20
p21.tcdn.qq.com. 319 IN A 113.107.238.22
p21.tcdn.qq.com. 319 IN A 119.147.33.32
;; Query time: 38 msec
;; SERVER: 180.76.76.76#53(180.76.76.76)
;; WHEN: Wed Dec 2 11:49:34 2015
;; MSG SIZE rcvd: 244

阿里Open DNS公共DNSdig测试： 223.5.5.5.5
# dig @223.6.6.6 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @223.6.6.6 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55386
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 235 IN CNAME v.tc.qq.com.
v.tc.qq.com. 235 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 235 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 235 IN A 119.147.253.20
p21.tcdn.qq.com. 235 IN A 113.107.238.22
p21.tcdn.qq.com. 235 IN A 119.147.33.30
p21.tcdn.qq.com. 235 IN A 59.57.18.147
p21.tcdn.qq.com. 235 IN A 119.147.33.32
p21.tcdn.qq.com. 235 IN A 119.147.33.28
p21.tcdn.qq.com. 235 IN A 119.147.33.29
p21.tcdn.qq.com. 235 IN A 119.147.253.22
p21.tcdn.qq.com. 235 IN A 119.147.253.21
p21.tcdn.qq.com. 235 IN A 119.147.33.31
;; Query time: 5 msec
;; SERVER: 223.6.6.6#53(223.6.6.6)
;; WHEN: Wed Dec 2 11:48:56 2015
;; MSG SIZE rcvd: 244

腾讯Dnspod openDNS 公共DNS dig测试 119.29.29.29
# dig @119.29.29.29 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @119.29.29.29 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63125
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 169 IN CNAME v.tc.qq.com.
v.tc.qq.com. 3169 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 169 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 169 IN A 119.147.33.32
p21.tcdn.qq.com. 169 IN A 119.147.253.21
p21.tcdn.qq.com. 169 IN A 113.107.238.22
p21.tcdn.qq.com. 169 IN A 119.147.33.30
p21.tcdn.qq.com. 169 IN A 119.147.33.29
p21.tcdn.qq.com. 169 IN A 59.57.18.147
p21.tcdn.qq.com. 169 IN A 119.147.33.31
p21.tcdn.qq.com. 169 IN A 119.147.33.28
p21.tcdn.qq.com. 169 IN A 119.147.253.20
p21.tcdn.qq.com. 169 IN A 119.147.253.22
;; Query time: 12 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Wed Dec 2 11:47:43 2015
;; MSG SIZE rcvd: 244

114dns公共DNS dig测试： 114.114.114.114
# dig @114.114.114.114 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @114.114.114.114 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35456
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 172 IN CNAME v.tc.qq.com.
v.tc.qq.com. 2611 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 539 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 262 IN A 113.107.238.22
p21.tcdn.qq.com. 262 IN A 119.147.33.30
p21.tcdn.qq.com. 262 IN A 119.147.33.29
p21.tcdn.qq.com. 262 IN A 119.147.33.31
p21.tcdn.qq.com. 262 IN A 119.147.33.32
p21.tcdn.qq.com. 262 IN A 119.147.253.20
p21.tcdn.qq.com. 262 IN A 119.147.33.28
p21.tcdn.qq.com. 262 IN A 119.147.253.22
p21.tcdn.qq.com. 262 IN A 119.147.253.21
p21.tcdn.qq.com. 262 IN A 59.57.18.147
;; Query time: 27 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Wed Dec 2 11:48:44 2015
;; MSG SIZE rcvd: 244

【DNS服务器IP地址-域名注册查询-CDN加速技术】

DNS服务器IP地址,域名注册,CDN加速技术,linux,web服务器,SRE,微服务,DevOps,运维

月度归档：2015年12月

nginx配置limit_conn_zone来限制并发连接数以及下载带宽

直播及点播的视频码率,帧率和分辨率关系与区别

php日志错误分析:网站http返回502与504错误分析

php日志分析:解决NGINX+PHP-FPM failed to ptrace(PEEKDATA) Input/output error出错问题

scons-2.4.1 和jsoncpp 库配置

Nginx + FastCgi + Spawn-fcgi + c 的架构搭建

ssh服务监听多个端口

114DNS、Dnspod DNS、阿里DNS、百度DNS、360DNS、Google DNS公共DNS评测体验报告

腾讯DNSPod公共DNS 119.29.29.29 体验报告

腾讯DNSPod推出新Open DNS服务，公共DNS是119.29.29.29