用acme-tiny自动更新Let’s Encrypt HTTPS证书

Let’s Encrypt 证书不但免费,还非常简单,虽然每次只有 90 天的有效期,但可以通过脚本定期更新,配好之后一劳永逸。

ACME 全称是 Automated Certificate Management Environment,直译过来是自动化证书管理环境的意思,Let’s Encrypt 的证书签发过程使用的就是 ACME 协议。

acme-tiny是用python写的自动申请/更新Let’s Encrypt HTTPS的工具。

以下是记录Let’s Encrypt HTTPS证书申请部署的全部过程。

1.生成RSA私钥:

	    (umask 077;openssl genrsa 2048 > private.key)
	    (umask 077;openssl genrsa 4096 > private.key)

2.生成CSR请求文件:

        1).RSA 私钥(兼容性好)
	(umask 077; openssl genrsa 2048 > yoursite.key)
	(umask 077; openssl genrsa 4096 > yoursite.key)
        2).ECC 私钥(部分老旧操作系统、浏览器不支持。优点是证书体积小)
	(umask 077;openssl ecparam -genkey -name secp256r1 | openssl ec -out yoursite_ec.key)
	(umask 077;openssl ecparam -genkey -name secp384r1 | openssl ec -out yoursite_ec.key)

然后就可以生成 CSR 文件了。在 CSR 中推荐至少把域名带 www 和不带 www 的两种情况都加进去,其它子域可以根据需要添加,部分系统的openssl.cnf文件所有位置可能有所不同:

	openssl req -new -sha256 -key yoursite.key -subj "/" -reqexts SAN -config <(cat /etc/pki/tls/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:yoursite.com,DNS:www.yoursite.com")) > yoursite.csr

3.配置自动认证目录:

	mkdir -pv /your/wwwroot/challenges

然后配置一个 HTTP 服务,以 Nginx 为例:

	server {
	    server_name yoursite.com www.yoursite.com;
	    location ^~ /.well-known/acme-challenge/ {
	        alias /your/wwwroot/challenges/;
	        try_files $uri =404;
	    }
	    location / {
	        rewrite ^/(.*)$ https://yoursite.com/$1 permanent;
	    }
	}

以上配置优先查找challenges目录下的文件,如果找不到就重定向到 HTTPS 地址。这个验证服务以后更新证书还要用到,建议一直保留。

4.脚本自动获取证书:
1).脚本下载与证书获取:

		wget https://raw.githubusercontent.com/diafygi/acme-tiny/master/acme_tiny.py
		python acme_tiny.py --account-key ./private.key --csr ./yoursite.csr --acme-dir /your/wwwroot/challenges/ > ./signed.crt

2).Let’s Encrypt的”中间证书”与”网站证书”合在一起:

		wget -O - https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem > intermediate.pem
		cat signed.crt intermediate.pem > chained.pem

3).Let’s Encrypt的”根证书”和”中间证书”合在一起:

		wget -O - https://letsencrypt.org/certs/isrgrootx1.pem > root.pem
		cat intermediate.pem root.pem > full_chained.pem

5.网站nginx使用的证书

	ssl_certificate     /path/to/chained.pem;
	ssl_certificate_key /path/to/yoursite.key;

6.自动更新证书脚本
Let’s Encrypt 签发的证书只有 90 天有效期,推荐使用脚本定期更新。脚本范例如下:

cd /path/to/nginx/ssl
python acme_tiny.py --account-key ./private.key --csr ./yyfilmtechcom.csr --acme-dir /your/wwwroot/challenges/ > ./signed.crt || exit
wget -O - https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem > intermediate.pem
cat signed.crt intermediate.pem > chained.pem
wget -O - https://letsencrypt.org/certs/isrgrootx1.pem > root.pem
cat intermediate.pem root.pem > full_chained.pem
service nginx reload

把脚本放进crontab,每个月定时执行一次:

0 0 1 * * sh /path/to/renew.sh >/dev/null 2>&1

原谅地址:https://imququ.com/post/letsencrypt-certificate.html#toc-0
参考地址:https://github.com/diafygi/acme-tiny

Nginx 路由杂谈 – Rewrite 指令与重定向

在书写 nginx 路由规则的时候, 得保证规则配置的规范, 否则维护起来成本很高。 本文简要地讨论了在 rewrite 模块的基础实现的简单路由规则,并解释了常用指令的使用细节。

rewrite 与 location

首先,这是一个不完整 nginx 虚拟主机配置:

server {

    root /service/http;

    index index.php;


    rewrite ^/api/(.*)+ /index.php?app=api&amp;method=$1 break;

    rewrite ^/index.php/(.*)+ /old_api_warning.html break;


    location / {

        return 200 "index";

    }


    location = /index.php {

        return 200 "index.php";

    }

}

上面的例子中, 指定的类型可以分为两种。

  • server,root, index, location 是 ngx_http_core_module 提供的指令
  • 而 rewrite 则是 ngx_http_rewrite_module 提供的指令之一, 同类的还有常用的 if

简单地概括, nginx 的处理配置流程如下

  1. 进行 rewrite 规则匹配,根据命中规则改写 location。
  2. 如果没有被其他指令中断并退出, 则进入 location 匹配。
  3. 执行匹配成功的 location 区块中的指令。

而对于 rewrite 系列指令和 location 指令的安排, 在书写配置的时候, 应该先定义好 location , 因为 location 是和 nginx 和后端服务沟通的桥梁。 再根据 location 的需要, 使用 rewrite 将各种各样用户输入的 url 正确地映射到 对应 locaton , 由 location 中的 proxy 指令转发给后端。

比如一个常规的 php 站点,有以下类似的 location 配置。

# 静态资源

location /assets {

    root /service/http/assets/;

}

# 入口 php 脚本 位置

location /index.php {

    root /service/http/phpsrc/webroot/;

# ... 若干 fast-cgi 代理规则

}

#注意, 这份配置省略了不必要的指令,能够满足大部分的 php 应用的需要。

有时候,为了优化 url 的展示,或者兼容旧应用的 url 规则, 只是这么简单的两条 location 配置自然是不够用的。这时候我们可以通过 rewrite 规则进行弥补。

rewrite /index.html$ /app/page-default; //兼容旧 url

rewrite /app/page-(.*) /index.php?app=api&page=$1 break;

请注意这两条 rewrite 规则区别的在最后一个 flag 参数 break,可用的 flag 参数还有 `permanent`, `redirect`, `last` 等, 后面分析它们之间的差别。

多出来的 break 参数作用会使得 rewirte 指令的跳转方式发生变化:

  • 没有 flag 的 rewrite 指令完成 location 改写之后,继续往下寻找其他 rewrite 规则,看看有没有符合要求的。如果没有,那么进入 location 匹配。
  • 带 break,跳过其他所有 rewrite 规则,进入 location 匹配

这里简单总结一下:

  • 如果某一条 rewrite 规则命中直接转发给后端应用,那么应该加上一个 break 标记。
  • 如果 rewrite 规则起补充作用,还需要其他规则配合完成,那么不带第三个的 flag 参数。

以上说的 rewrite 规则属于 nginx 的内部重定向规则, 也就是说, 用户外部看到的 url 依然是他输入的 url , 而转给后端应用的 $uri , 则已经是 nginx 改写之后的结果。

如果需要进行显式地外部重定向, 需要借助 redirect , permanent 这两个 flag 进行 302 和 301 重定向. 它的行为和 break 类似, 区别在于 nginx 会中断流程, 通过 http 请求告诉用户端进行重定向, 也就是这次请求不需要进过后端服务, 由 nginx 全职负责。

rewrite /error.html$ /error2.html redirect;

break 和 last 区别

这两个 flag 都会中断当前 rewrite 流程, 不再继续匹配后续的 rewrite 指令。

wiki 上是这么写的

stops processing the current set of ngx_http_rewrite_module directives and starts a search for a new location matching the changed URI

如果是在 server 的顶级部分, 那么它们的作用是相同, 跳过剩下的 rewrite 指定, 进入 location 匹配。 如果 rewrite 是在 server 区块顶级 if 内部, 和直接放在 server 下级的 rewrite 行为是一致的。

server {

    rewrite /error1.html /error.html break;

    rewrite /error2.html /error.html last;

&nbsp;

    if ( $arg_version = "1.1" ) {

        rewrite /error3.html /error.html break;

    }

&nbsp;

    location = error.html {

    }

}

以上的 rewrite 的跳转行为是相同的, 进入 location 匹配流程。

而两者的区别, 在于当 rewrite 指令存在于 location 区块中时, 见例子

location = index.php {

    if ( $arg_q  = "" ) {

      rewrite /index.php /error.html last;

    }

}
location = error.html {

    if ( $arg_test ~= "" ) {

        rewrite /error.html /error-test.html break;

    }

}

第一个 location , 如果 q 参数为空, 那么将展示错误页面。

第二个 location , 如果 test 参数不为空, 通过 rewrite 规则,使用另外一个 error-test.html, 但 location 不变

注意, 这里并没有一个 `location = error2.html` 的匹配规则

从这个 case 的结果, 可以明显得区分两个指令之间的细微差别

  • last 跳出 location 块,重新进行 location 匹配
  • break 跳过 location 下的后续 rewrite 规则,执行其他指令。

所以 last 的特殊在于重新进行 location 匹配, 这也就是为什么会从”locaton = index.php”转向”locaton = error.html”

所以一般情况下, 使用 break 指令会相对安全, 不会造成循环重定向。

比如:

location = error.html {

    rewrite /error.html /error.html  break;

&nbsp;

    if ($arg_q = "") {

      return 404 "not q";

    }

&nbsp;

    fastcgi_pass 127.0.0.1:9000;

    #其他 fastcgi 配置

}

 

location = error.html {

    rewrite /error.html /error.html last;

    fastcgi_pass 127.0.0.1:9000;

}

第一个例子,完成了 rewrite 指令之后,break 指令使得后续的其他 rewrite 规则失效, 接着进行 proxy. 第二个例子会导致不断地进行 location 匹配, 最终导致 nginx 返回 500.

返回结果是这样的:

HTTP/1.1 500 Internal Server Error

Server: nginx/1.6.3

Date: Sat, 18 Apr 2015 12:10:49 GMT

Content-Type: text/html

Content-Length: 192

Connection: close

注:nginx 会记录同一条 rewrite 规则的执行次数,如果超过10次,将自动触发 500 进行自我保护。

小结

这里构造了两组例子用来说明 last 和 break 两个 flag 参数行为上的不一致。 并不是说 rewrite 规则在 server 和 location 上下文中的行为不一致, 而是他们的行为特征很容易造成误解。

两者的本质区别在于是否重新进行 location 匹配,所以当在 location 上下文 进行 last rewrite时。 对于不熟悉 rewrite 指定的其他人容易造成误解。

所以还是前文所提到的观点, 尽可能地将 rewrite 和 location 离开来。 在 location 中进行 rewrite, 容易造成重定向问题。

由于 rewrite 模块的 `rewrite` 和 `if` 指令会使得 nginx

的路由规则出现较多的逻辑和分支跳转, 在维护性上是比较糟糕的,

并不推荐过多地进行使用, 本文只是从行为和特性上分析了这些指令,

并不代表支持过度使用 rewrite 指令。

return 指令的应用

在 rewrite 模块中, 有一条非常有用的指令 return, 用于直接返回客户端指定的状态码。 甚至支持指定文本内容和url, 相比起使用 rewrite 指令302进行曲线救国,要简便地多。

location = /index.php {

    if ( $arg_q = "" ) {

        return 302 /page_not_found.html;

    }

&nbsp;

    if ( $arg_id = "" ) {

        return 404 "page not found";

    }

    return 200 "hello";

}

对于常规的基于 url 提供服务的应用, 基础的 rewrite 指令配合已经足够完成大部分任务。

 

 

Nginx 关于 location 的匹配规则详解

有些童鞋的误区

1 location 的匹配顺序是“先匹配正则,再匹配普通”。

矫正: location 的匹配顺序其实是“先匹配普通,再匹配正则”。我这么说,大家一定会反驳我,因为按“先匹配普通,再匹配正则”解释不了大家平时习惯的按“先匹配正则,再匹配普通”的实践经验。这里我只能暂时解释下,造成这种误解的原因是:正则匹配会覆盖普通匹配(实际的规则,比这复杂,后面会详细解释)。

2 location 的执行逻辑跟 location 的编辑顺序无关。

矫正:这句话不全对,“普通 location ”的匹配规则是“最大前缀”,因此“普通 location ”的确与 location 编辑顺序无关;但是“正则 location ”的匹配规则是“顺序匹配,且只要匹配到第一个就停止后面的匹配”;“普通 location ”与“正则 location ”之间的匹配顺序是?先匹配普通 location ,再“考虑”匹配正则 location 。注意这里的“考虑”是“可能”的意思,也就是说匹配完“普通 location ”后,有的时候需要继续匹配“正则 location ”,有的时候则不需要继续匹配“正则 location ”。两种情况下,不需要继续匹配正则 location :( 1 )当普通 location 前面指定了“ ^~ ”,特别告诉 Nginx 本条普通 location 一旦匹配上,则不需要继续正则匹配;( 2 )当普通 location 恰好严格匹配上,不是最大前缀匹配,则不再继续匹配正则。

总结一句话:“正则 location 匹配让步普通 location 的严格精确匹配结果;但覆盖普通 location 的最大前缀匹配结果”

官方文档解释

REFER:  http://wiki.nginx.org/NginxHttpCoreModule#location

location

syntax: location [=|~|~*|^~|@] /uri/ { … }

default: no

context: server

This directive allows different configurations depending on the URI.

(译者注:1 、different configurations depending on the URI 说的就是语法格式:location [=|~|~*|^~|@] /uri/ { … } ,依据不同的前缀“= ”,“^~ ”,“~ ”,“~* ”和不带任何前缀的(因为[A] 表示可选,可以不要的),表达不同的含义, 简单的说尽管location 的/uri/ 配置一样,但前缀不一样,表达的是不同的指令含义。2 、查询字符串不在URI 范围内。例如:/films.htm?fid=123 的URI 是/films.htm 。)

It can be configured using both literal strings and regular expressions. To use regular expressions, you must use a prefix:

1.”~” for case sensitive matching

2.”~*” for case insensitive matching

译文:上文讲到location /uri/ 可通过使用不同的前缀,表达不同的含义。对这些不同前缀,分下类,就2 大类:正则location ,英文说法是location using regular expressions 和普通location ,英文说法是location using literal strings 。那么其中“~ ”和“~* ”前缀表示正则location ,“~ ”区分大小写,“~* ”不区分大小写;其他前缀(包括:“= ”,“^~ ”和“@ ”)和无任何前缀的都属于普通location 。

To determine which location directive matches a particular query, the literal strings are checked first.

译文:对于一个特定的 HTTP 请求( a particular query ), nginx 应该匹配哪个 location 块的指令呢(注意:我们在 nginx.conf 配置文件里面一般会定义多个 location 的)?匹配 规则是:先匹配普通location (再匹配正则表达式)。注意:官方文档这句话就明确说了,先普通location ,而不是有些同学的误区“先匹配正则location ”。

Literal strings match the beginning portion of the query – the most specific match will be used.

前面说了“普通location ”与“正则location ”之间的匹配规则是:先匹配普通location ,再匹配正则location 。那么,“普通location ”内部(普通location 与普通location )是如何匹配的呢?简单的说:最大前缀匹配。原文:1 、match the beginning portion of the query (说的是匹配URI 的前缀部分beginning portion ); 2 、the most specific match will be used (因为location 不是“严格匹配”,而是“前缀匹配”,就会产生一个HTTP 请求,可以“前缀匹配”到多个普通location ,例如:location /prefix/mid/ {} 和location /prefix/ {} ,对于HTTP 请求 /prefix/mid/t.html ,前缀匹配的话两个location 都满足,选哪个?原则是:the most specific match ,于是选的是location /prefix/mid/ {} )。

Afterwards, regular expressions are checked in the order defined in the configuration file. The first regular expression to match the query will stop the search.

这段话说了两层意思,第一层是:“Afterwards, regular expressions are checked ”, 意思是普通location 先匹配,而且选择了最大前缀匹配后,不能就停止后面的匹配,最大前缀匹配只是一个临时的结果,nginx 还需要继续检查正则location (但至于最终才能普通location 的最大前缀匹配,还是正则location 的匹配,截止当前的内容还没讲,但后面会讲)。第二层是“regular expressions are checked in the order defined in the configuration file. The first regular expression to match the query will stop the search. ”,意思是说“正则location ”与“正则location ”内部的匹配规则是:按照正则location 在配置文件中的物理顺序(编辑顺序)匹配的(这句话就说明location 并不是一定跟顺序无关,只是普通location 与顺序无关,正则location 还是与顺序有关的),并且只要匹配到一条正则location ,就不再考虑后面的(这与“普通location ”与“正则location ”之间的规则不一样,“普通location ”与“正则location ”之间的规则是:选择出“普通location ”的最大前缀匹配结果后,还需要继续搜索正则location )。

If no regular expression matches are found, the result from the literal string search is used.

这句话回答了“普通location ”的最大前缀匹配结果与继续搜索的“正则location ”匹配结果的决策关系。如果继续搜索的“正则location ”也有匹配上的,那么“正则location ”覆盖 “普通location ”的最大前缀匹配(因为有这个覆盖关系,所以造成有些同学以为正则location 先于普通location 执行的错误理解);但是如果“正则location ”没有能匹配上,那么就用“普通location ”的最大前缀匹配结果。

For case insensitive operating systems, like Mac OS X or Windows with Cygwin, literal string matching is done in a case insensitive way (0.7.7). However, comparison is limited to single-byte locale’s only.

Regular expression may contain captures (0.7.40), which can then be used in other directives.

It is possible to disable regular expression checks after literal string matching by using “^~” prefix. If the most specific match literal location has this prefix: regular expressions aren’t checked.

通常的规则是,匹配完了“普通location ”指令,还需要继续匹配“正则location ”,但是你也可以告诉Nginx :匹配到了“普通location ”后,不再需要继续匹配“正则location ”了,要做到这一点只要在“普通location ”前面加上“^~ ”符号(^ 表示“非”,~ 表示“正则”,字符意思是:不要继续匹配正则)。

By using the “=” prefix we define the exact match between request URI and location. When matched search stops immediately. E.g., if the request “/” occurs frequently, using “location = /” will speed up processing of this request a bit as search will stop after first comparison.

除了上文的“^~ ”可以阻止继续搜索正则location 外,你还可以加“= ”。那么如果“^~ ”和“= ”都能阻止继续搜索正则location 的话,那它们之间有什么区别呢?区别很简单,共同点是它们都能阻止继续搜索正则location ,不同点是“^~ ”依然遵守“最大前缀”匹配规则,然而“= ”不是“最大前缀”,而是必须是严格匹配(exact match )。

这里顺便讲下“location / {} ”和“location = / {} ”的区别,“location / {} ”遵守普通location 的最大前缀匹配,由于任何 URI 都必然以“/ ”根开头,所以对于一个URI ,如果有更specific 的匹配,那自然是选这个更specific 的,如果没有,“/ ”一定能为这个URI 垫背(至少能匹配到“/ ”),也就是说“location / {} ”有点默认配置的味道,其他更specific 的配置能覆盖overwrite 这个默认配置(这也是为什么我们总能看到location / {} 这个配置的一个很重要的原因)。而“location = / {} ”遵守的是“严格精确匹配exact match ”,也就是只能匹配 http://host:port/ 请求,同时会禁止继续搜索正则location 。因此如果我们只想对“GET / ”请求配置作用指令,那么我们可以选“location = / {} ”这样能减少正则location 的搜索,因此效率比“location / {}” 高(注:前提是我们的目的仅仅只想对“GET / ”起作用)。

On exact match with literal location without “=” or “^~” prefixes search is also immediately terminated.

前面我们说了,普通location 匹配完后,还会继续匹配正则location ;但是nginx 允许你阻止这种行为,方法很简单,只需要在普通location 前加“^~ ”或“= ”。但其实还有一种“隐含”的方式来阻止正则location 的搜索,这种隐含的方式就是:当“最大前缀”匹配恰好就是一个“严格精确(exact match )”匹配,照样会停止后面的搜索。原文字面意思是:只要遇到“精确匹配exact match ”,即使普通location 没有带“= ”或“^~ ”前缀,也一样会终止后面的匹配。

先举例解释下,后面例题会用实践告诉大家。假设当前配置是:location /exact/match/test.html { 配置指令块1} ,location /prefix/ { 配置指令块2} 和 location ~ \.html$ { 配置指令块3} ,如果我们请求 GET /prefix/index.html ,则会被匹配到指令块3 ,因为普通location /prefix/ 依据最大匹配原则能匹配当前请求,但是会被后面的正则location 覆盖;当请求GET /exact/match/test.html ,会匹配到指令块1 ,因为这个是普通location 的exact match ,会禁止继续搜索正则location 。

To summarize, the order in which directives are checked is as follows:

1.Directives with the “=” prefix that match the query exactly. If found, searching stops.

2.All remaining directives with conventional strings. If this match used the “^~” prefix, searching stops.

3.Regular expressions, in the order they are defined in the configuration file.

4.If #3 yielded a match, that result is used. Otherwise, the match from #2 is used.

这个顺序没必要再过多解释了。但我想用自己的话概括下上面的意思“正则 location 匹配让步普通 location 的严格精确匹配结果;但覆盖普通 location 的最大前缀匹配结果”。

It is important to know that nginx does the comparison against decoded URIs. For example, if you wish to match “/images/%20/test”, then you must use “/images/ /test” to determine the location.

在浏览器上显示的URL 一般都会进行URLEncode ,例如“空格”会被编码为%20 ,但是Nginx 的URL 的匹配都是针对URLDecode 之后的。也就是说,如果你要匹配“/images/%20/test ”,你写location 的时候匹配目标应该是:“/images/ /test ”。

Example:

location   = / {

# matches the query / only.

[ configuration A ]

}

location   / {

# matches any query, since all queries begin with /, but regular

# expressions and any longer conventional blocks will be

# matched first.

[ configuration B ]

}

location ^~ /images/ {

# matches any query beginning with /images/ and halts searching,

# so regular expressions will not be checked.

[ configuration C ]

}

location ~* \.(gif|jpg|jpeg)$ {

# matches any request ending in gif, jpg, or jpeg. However, all

# requests to the /images/ directory will be handled by

# Configuration C.

[ configuration D ]

}

上述这4 个location 的配置,没什么好解释的,唯一需要说明的是location / {[configuration B]} ,原文的注释严格来说是错误的,但我相信原文作者是了解规则的,只是文字描述上简化了下,但这个简化容易给读者造成“误解:先检查正则location ,再检查普通location ”。原文:“matches any query, since all queries begin with /, but regular expressions and any longer conventional blocks will be matched first. ”大意是说:“location / {} 能够匹配所有HTTP 请求,因为任何HTTP 请求都必然是以‘/ ’开始的(这半句没有错误)。但是,正则location 和其他任何比‘/ ’更长的普通location (location / {} 是普通location 里面最短的,因此其他任何普通location 都会比它更长,当然location = / {} 和 location ^~ / {} 是一样长的)会优先匹配(matched first )。” 原文作者说“ but regular expressions will be matched first. ”应该只是想说正则 location 会覆盖这里的 location / {} ,但依然是普通 location / {} 先于正则 location 匹配,接着再正则 location 匹配;但其他更长的普通 location ( any longer conventional blocks )的确会先于 location / {} 匹配。

Example requests:

/ -> configuration A

/documents/document.html -> configuration B

/images/1.gif -> configuration C

/documents/1.jpg -> configuration D

Note that you could define these 4 configurations in any order and the results would remain the same.

需要提醒下:这里说“in any order ”和“… remain the same ”是因为上面只有一个正则location 。文章前面已经说了正则location 的匹配是跟编辑顺序有关系的。

While nested locations are allowed by the configuration file parser, their use is discouraged and may produce unexpected results.

实际上 nginx 的配置文件解析程序是允许 location 嵌套定义的( location / { location /uri/ {} } )。但是我们平时却很少看见这样的配置,那是因为 nginx 官方并不建议大家这么做,因为这样会导致很多意想不到的后果。

The prefix “@” specifies a named location. Such locations are not used during normal processing of requests, they are intended only to process internally redirected requests (see error_page , try_files ).

文章开始说了location 的语法中,可以有“= ”,“^~ ”,“~ ”和“~* ”前缀,或者干脆没有任何前缀,还有“@ ”前缀,但是后面的分析我们始终没有谈到“@ ”前缀。文章最后点内容,介绍了“@”的用途:“@ ”是用来定义“Named Location ”的(你可以理解为独立于“普通location (location using literal strings )”和“正则location (location using regular expressions )”之外的第三种类型),这种“Named Location ”不是用来处理普通的HTTP 请求的,它是专门用来处理“内部重定向(internally redirected )”请求的。注意:这里说的“内部重定向(internally redirected )”或许说成“forward ”会好点,以为内internally redirected 是不需要跟浏览器交互的,纯粹是服务端的一个转发行为。

location 实例练习

Nginx 的语法形式是: location [=|~|~*|^~|@] /uri/ { … } ,意思是可以以“ = ”或“ ~* ”或“ ~ ”或“ ^~ ”或“ @ ”符号为前缀,当然也可以没有前缀(因为 [A] 是表示可选的 A ; A|B 表示 A 和 B 选一个),紧接着是 /uri/ ,再接着是 {…} 指令块,整个意思是对于满足这样条件的 /uri/ 适用指令块 {…} 的指令。

上述各种 location 可分两大类,分别是:“普通 location ”,官方英文说法是 location using   literal strings 和“正则 location ”,英文说法是 location using regular expressions 。其中“普通 location ”是以“ = ”或“ ^~ ”为前缀或者没有任何前缀的 /uri/ ;“正则 location ”是以“ ~ ”或“ ~* ”为前缀的 /uri/ 。

那么,当我们在一个 server 上下文编写了多个 location 的时候, Nginx 对于一个 HTTP 请求,是如何匹配到一个 location 做处理呢?用一句话简单概括 Nginx 的 location 匹配规则是:“正则 location ”让步 “普通 location ”的严格精确匹配结果;但覆盖 “普通 location ”的最大前缀匹配结果。理解这句话,我想通过下面的实例来说明。

#1 先普通 location ,再正则 location

周边不少童鞋告诉我, nginx 是“先匹配正则 location 再匹配普通 location ”,其实这是一个误区, nginx 其实是“先匹配普通 location ,再匹配正则 location ”,但是普通 location 的匹配结果又分两种:一种是“严格精确匹配”,官方英文说法是“ exact match ”;另一种是“最大前缀匹配”,官方英文说法是“ Literal strings match the beginning portion of the query – the most specific match will be used. ”。我们做个实验:

 

例题 1 :假设 nginx 的配置如下

server {

listen       9090;

server_name  localhost;

location / {

root   html;

index  index.html index.htm;

deny all;

}

location ~ \.html$ {

allow all;

}

}

附录 nginx 的目录结构是: nginx->html->index.html

上述配置的意思是: location / {… deny all;} 普通 location 以“ / ”开始的 URI 请求(注意任何 HTTP 请求都必然以“ / ”开始,所以“ / ”的意思是所有的请求都能被匹配上),都拒绝访问; location ~\.html$ {allow all;} 正则 location 以 .html 结尾的 URI 请求,都允许访问。

测试结果:

[root@web108 ~]# curl http://localhost:9090/

<html>

<head><title>403 Forbidden</title></head>

<body bgcolor=”white”>

<center><h1>403 Forbidden</h1></center>

<hr><center>nginx/1.1.0</center>

</body>

</html>

[root@web108 ~]# curl http://localhost:9090/index.html

<html>

<head>

<title>Welcome to nginx!</title>

</head>

<body bgcolor=”white” text=”black”>

<center><h1>Welcome to nginx!</h1></center>

</body>

</html>

[root@web108 ~]# curl http://localhost:9090/index_notfound.html

<html>

<head><title>404 Not Found</title></head>

<body bgcolor=”white”>

<center><h1>404 Not Found</h1></center>

<hr><center>nginx/1.1.0</center>

</body>

</html>

[root@web108 ~]#

测试结果如下:

URI 请求 HTTP 响应
curl http://localhost:9090/ 403 Forbidden
curl http://localhost:9090/index.html Welcome to nginx!
curl http://localhost:9090/index_notfound.html 404 Not Found

curl http://localhost:9090/ 的结果是“ 403 Forbidden ”,说明被匹配到“ location / {..deny all;} ”了,原因很简单 HTTP 请求 GET / 被“严格精确”匹配到了普通 location / {} ,则会停止搜索正则 location ;

curl http://localhost:9090/index.html 结果是“ Welcome to nginx! ”,说明没有被“ location / {…deny all;} ”匹配,否则会 403 Forbidden ,但 /index.html 的确也是以“ / ”开头的,只不过此时的普通 location / 的匹配结果是“最大前缀”匹配,所以 Nginx 会继续搜索正则 location , location ~ \.html$ 表达了以 .html 结尾的都 allow all; 于是接着就访问到了实际存在的 index.html 页面。

curl http://localhost:9090/index_notfound.html   同样的道理先匹配 location / {} ,但属于“普通 location 的最大前缀匹配”,于是后面被“正则 location ” location ~ \.html$ {} 覆盖了,最终 allow all ; 但的确目录下不存在 index_notfound.html 页面,于是 404 Not Found 。

如果此时我们访问 http://localhost:9090/index.txt 会是什么结果呢?显然是 deny all ;因为先匹配上了 location / {..deny all;} 尽管属于“普通 location ”的最大前缀匹配结果,继续搜索正则 location ,但是 /index.txt 不是以 .html 结尾的,正则 location 失败,最终采纳普通 location 的最大前缀匹配结果,于是 deny all 了。

[root@web108 ~]# curl http://localhost:9090/index.txt

<html>

<head><title>403 Forbidden</title></head>

<body bgcolor=”white”>

<center><h1>403 Forbidden</h1></center>

<hr><center>nginx/1.1.0</center>

</body>

</html>

[root@web108 ~]#

#2 普通 location 的“隐式”严格匹配

例题 2 :我们在例题 1 的基础上增加精确配置

server {

listen       9090;

server_name  localhost;

location /exact/match.html {

allow all;

}

location / {

root   html;

index  index.html index.htm;

deny all;

}

location ~ \.html$ {

allow all;

}

}

测试请求:

[root@web108 ~]# curl http://localhost:9090/exact/match.html

<html>

<head><title>404 Not Found</title></head>

<body bgcolor=”white”>

<center><h1>404 Not Found</h1></center>

<hr><center>nginx/1.1.0</center>

</body>

</html>

[root@web108 ~]#

结果进一步验证了“普通 location ”的“严格精确”匹配会终止对正则 location 的搜索。这里我们小结下“普通 location ”与“正则 location ”的匹配规则:先匹配普通 location ,再匹配正则 location ,但是如果普通 location 的匹配结果恰好是“严格精确( exact match )”的,则 nginx 不再尝试后面的正则 location ;如果普通 location 的匹配结果是“最大前缀”,则正则 location 的匹配覆盖普通 location 的匹配。也就是前面说的“正则 location 让步普通 location 的严格精确匹配结果,但覆盖普通 location 的最大前缀匹配结果”。

#3 普通 location 的“显式”严格匹配和“ ^~ 前缀

上面我们演示的普通 location 都是不加任何前缀的,其实普通 location 也可以加前缀:“ ^~ ”和“ = ”。其中“ ^~ ”的意思是“非正则,不需要继续正则匹配”,也就是通常我们的普通 location ,还会继续搜索正则 location (恰好严格精确匹配除外),但是 nginx 很人性化允许配置人员告诉 nginx 某条普通 location ,无论最大前缀匹配,还是严格精确匹配都终止继续搜索正则 location ;而“ = ”则表达的是普通 location 不允许“最大前缀”匹配结果,必须严格等于,严格精确匹配。

例题 3 :“ ^~ ”前缀的使用

server {

listen       9090;

server_name  localhost;

location /exact/match.html {

allow all;

}

location ^~ / {

root   html;

index  index.html index.htm;

deny all;

}

location ~ \.html$ {

allow all;

}

}

把例题 2 中的 location / {} 修改成 location ^~ / {} ,再看看测试结果:

URI 请求 修改前 修改后
curl http://localhost:9090/ 403 Forbidden 403 Forbidden
curl http://localhost:9090/index.html Welcome to nginx! 403 Forbidden
curl http://localhost:9090/index_notfound.html 404 Not Found 403 Forbidden
curl http://localhost:9090/exact/match.html 404 Not Found 404 Not Found

除了 GET /exact/match.html 是 404 Not Found ,其余都是 403 Forbidden ,原因很简单所有请求都是以“ / ”开头,所以所有请求都能匹配上“ / ”普通 location ,但普通 location 的匹配原则是“最大前缀”,所以只有 /exact/match.html 匹配到 location /exact/match.html {allow all;} ,其余都 location ^~ / {deny all;} 并终止正则搜索。

例题 4 :“ = ”前缀的使用

server {

listen       9090;

server_name  localhost;

location /exact/match.html {

allow all;

}

location = / {

root   html;

index  index.html index.htm;

deny all;

}

location ~ \.html$ {

allow all;

}

}

例题 4 相对例题 2 把 location / {} 修改成了 location = / {} ,再次测试结果:

URI 请求 修改前 修改后
curl http://localhost:9090/ 403 Forbidden 403 Forbidden
curl http://localhost:9090/index.html Welcome to nginx! Welcome to nginx!
curl http://localhost:9090/index_notfound.html 404 Not Found 404 Not Found
curl http://localhost:9090/exact/match.html 404 Not Found 404 Not Found
curl http://localhost:9090/test.jsp 403 Forbidden 404 Not Found

最能说明问题的测试是 GET /test.jsp ,实际上 /test.jsp 没有匹配正则 location ( location ~\.html$ ),也没有匹配 location = / {} ,如果按照 location / {} 的话,会“最大前缀”匹配到普通 location / {} ,结果是 deny all 。

#4 正则 location 与编辑顺序

location 的指令与编辑顺序无关,这句话不全对。对于普通 location 指令,匹配规则是:最大前缀匹配(与顺序无关),如果恰好是严格精确匹配结果或者加有前缀“ ^~ ”或“ = ”(符号“ = ”只能严格匹配,不能前缀匹配),则停止搜索正则 location ;但对于正则 location 的匹配规则是:按编辑顺序逐个匹配(与顺序有关),只要匹配上,就立即停止后面的搜索。

配置 3.1

server {

listen       9090;

server_name  localhost;

location ~ \.html$ {

allow all;

}

location ~ ^/prefix/.*\.html$ {

deny all;

}

}

配置 3.2

server {

listen       9090;

server_name  localhost;

location ~ ^/prefix/.*\.html$ {

deny all;

}

location ~ \.html$ {

allow all;

}

}

测试结果:

URI 请求 配置 3.1 配置 3.2
curl http://localhost:9090/regextest.html 404 Not Found 404 Not Found
curl http://localhost:9090/prefix/regextest.html 404 Not Found 403 Forbidden

解释:

Location ~ ^/prefix/.*\.html$ {deny all;} 表示正则 location 对于以 /prefix/ 开头, .html 结尾的所有 URI 请求,都拒绝访问;   location ~\.html${allow all;} 表示正则 location 对于以 .html 结尾的 URI 请求,都允许访问。 实际上, prefix 的是 ~\.html$ 的子集。

在“配置 3.1 ”下,两个请求都匹配上 location ~\.html$ {allow all;} ,并且停止后面的搜索,于是都允许访问, 404 Not Found ;在“配置 3.2 ”下, /regextest.html 无法匹配 prefix ,于是继续搜索 ~\.html$ ,允许访问,于是 404 Not Found ;然而 /prefix/regextest.html 匹配到 prefix ,于是 deny all , 403 Forbidden 。

配置 3.3

server {

listen       9090;

server_name  localhost;

location  /prefix/ {

deny all;

}

location  /prefix/mid/ {

allow all;

}

}

配置 3.4

server {

listen       9090;

server_name  localhost;

location  /prefix/mid/ {

allow all;

}

location  /prefix/ {

deny all;

}

}

测试结果:

URI 请求 配置 3.1 配置 3.2
curl http://localhost:9090/prefix/t.html 403 Forbidden 403 Forbidden
curl http://localhost:9090/prefix/mid/t.html 404 Not Found 404 Not Found

测试结果表明:普通 location 的匹配规则是“最大前缀”匹配,而且与编辑顺序无关。

#5 “@ 前缀 Named Location 使用

REFER:  http://wiki.nginx.org/HttpCoreModule#error_page

假设配置如下:

server {

listen       9090;

server_name  localhost;

location  / {

root   html;

index  index.html index.htm;

allow all;

}

#error_page 404 http://www.baidu.com # 直接这样是不允许的

error_page 404 = @fallback;

location @fallback {

proxy_pass http://www.baidu.com;

}

}

上述配置文件的意思是:如果请求的 URI 存在,则本 nginx 返回对应的页面;如果不存在,则把请求代理到 baidu.com 上去做个弥补(注: nginx 当发现 URI 对应的页面不存在, HTTP_StatusCode 会是 404 ,此时 error_page 404 指令能捕获它)。

测试一:

[root@web108 ~]# curl http://localhost:9090/nofound.html -i

HTTP/1.1 302 Found

Server: nginx/1.1.0

Date: Sat, 06 Aug 2011 08:17:21 GMT

Content-Type: text/html; charset=iso-8859-1

Location: http://localhost:9090/search/error.html

Connection: keep-alive

Cache-Control: max-age=86400

Expires: Sun, 07 Aug 2011 08:17:21 GMT

Content-Length: 222

 

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>

<html><head>

<title>302 Found</title>

</head><body>

<h1>Found</h1>

<p>The document has moved <a href=”http://www.baidu.com/search/error.html“>here</a>.</p>

</body></html>

[root@web108 ~]#

当我们 GET /nofound.html 发送给本 nginx , nginx 找不到对应的页面,于是 error_page 404 = @fallback ,请求被代理到 http://www.baidu.com ,于是 nginx 给 http://www.baidu.com 发送了 GET /nofound.html ,但 /nofound.html 页面在百度也不存在,百度 302 跳转到错误页。

直接访问 http://www.baidu.com/nofound.html 结果:

[root@web108 ~]# curl http://www.baidu.com/nofound.html -i

HTTP/1.1 302 Found

Date: Sat, 06 Aug 2011 08:20:05 GMT

Server: Apache

Location: http://www.baidu.com/search/error.html

Cache-Control: max-age=86400

Expires: Sun, 07 Aug 2011 08:20:05 GMT

Content-Length: 222

Connection: Keep-Alive

Content-Type: text/html; charset=iso-8859-1

 

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>

<html><head>

<title>302 Found</title>

</head><body>

<h1>Found</h1>

<p>The document has moved <a href=”http://www.baidu.com/search/error.html“>here</a>.</p>

</body></html>

[root@web108 ~]#

 

测试二:访问一个 nginx 不存在,但 baidu 存在的页面

[root@web108 ~]# curl http://www.baidu.com/duty/ -i

HTTP/1.1 200 OK

Date: Sat, 06 Aug 2011 08:21:56 GMT

Server: Apache

P3P: CP=” OTI DSP COR IVA OUR IND COM ”

P3P: CP=” OTI DSP COR IVA OUR IND COM ”

Set-Cookie: BAIDUID=5C5D2B2FD083737A0C88CA7075A6601A:FG=1; expires=Sun, 05-Aug-12 08:21:56 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

Set-Cookie: BAIDUID=5C5D2B2FD083737A2337F78F909CCB90:FG=1; expires=Sun, 05-Aug-12 08:21:56 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

Last-Modified: Wed, 05 Jan 2011 06:44:53 GMT

ETag: “d66-49913b8efe340”

Accept-Ranges: bytes

Content-Length: 3430

Cache-Control: max-age=86400

Expires: Sun, 07 Aug 2011 08:21:56 GMT

Vary: Accept-Encoding,User-Agent

Connection: Keep-Alive

Content-Type: text/html

 

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”

http://www.w3.org/TR/html4/loose.dtd“>

。。。。

</body>

</html>

显示,的确百度这个页面是存在的。

[root@web108 ~]# curl http://localhost:9090/duty/ -i

HTTP/1.1 200 OK

Server: nginx/1.1.0

Date: Sat, 06 Aug 2011 08:23:23 GMT

Content-Type: text/html

Connection: keep-alive

P3P: CP=” OTI DSP COR IVA OUR IND COM ”

P3P: CP=” OTI DSP COR IVA OUR IND COM ”

Set-Cookie: BAIDUID=8FEF0A3A2C31D277DCB4CC5F80B7F457:FG=1; expires=Sun, 05-Aug-12 08:23:23 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

Set-Cookie: BAIDUID=8FEF0A3A2C31D277B1F87691AFFD7440:FG=1; expires=Sun, 05-Aug-12 08:23:23 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

Last-Modified: Wed, 05 Jan 2011 06:44:53 GMT

ETag: “d66-49913b8efe340”

Accept-Ranges: bytes

Content-Length: 3430

Cache-Control: max-age=86400

Expires: Sun, 07 Aug 2011 08:23:23 GMT

Vary: Accept-Encoding,User-Agent

 

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”

http://www.w3.org/TR/html4/loose.dtd“>

<html>

。。。

</body>

</html>

当 curl http://localhost:9090/duty/ -i 时, nginx 没找到对应的页面,于是 error_page = @fallback ,把请求代理到 baidu.com 。注意这里的 error_page = @fallback 不是靠重定向实现的,而是所说的“ internally redirected ( forward )”。

Nginx 禁止IP访问

需求:
在Nginx上设置禁止通过IP访问服务器,只能通过域名访问。

注意:默认情况下,nginx中的虚拟主机是允许用户通过IP访问,或者通过未设置的域名访问的。

关键一点是在server的设置里添加一行:

listen 80 default_server;

后面的default_server参数表示这个是默认虚拟主机。此设置很有用。
假如有人通过ip或者未知域名访问你的网站的时候,你希望禁止显示任何有效内容,可以给他返回500。
目前国内很多机房都要求网站主关闭空主机头,防止未备案的域名指向过来造成麻烦,则可以这样设置:

 
server {
listen 80 default_server;
return 500;
}

也可以把这些流量收集起来,导入到自己的网站,只要做以下跳转设置就可以:

server {
listen 80 default_server;
rewrite ^(.*) http://www.mywebsite.com permanent;
}

按照如上设置后,确实不能通过IP访问服务器了,但是在应该用中出现当server_name后跟多个域名时,其中一个域名怎么都无法访问。设置如下:

 
server
{
listen 80;
server_name www.mywebsite.com mywebsite.com;
}

没更改之前,通过server_name中的www.mywebsite.com mywebsite.com均可访问服务器,加入禁止IP访问的设置后,通过mywebsite.com无法访问服务器了,www.mywebsite.com mywebsite.com可以访问

用 nginx -t 检测配置文件会提示warning:
[warn]: conflicting server name “mywebsite.com” on 0.0.0.0:80, ignored
the configuration file /usr/local/webserver/nginx/conf/nginx.conf syntax is ok
configuration file /usr/local/webserver/nginx/conf/nginx.conf test is successful

最后,通过在listen 80 default;后再加server_name _;进行解决,形式如下:

 
server
{
listen 80 default_server;
server_name _;
return 500;
}

或者
server {
listen 80 dufault_server;
server_name _;
rewrite ^(.*) http://www.mywebsite.com permanent;
}

这样,通过mywebsite.com就能访问服务器了,问题解决了,但具体原因还是不清楚。

Events模块

events模块中包含nginx中所有处理连接的设置。

events { 
worker_connections 2048; 
multi_accept on; 
use epoll; 
} 
Syntax:	worker_connections number;
Default:	
worker_connections 512;
Context:	events

Sets the maximum number of simultaneous connections that can be opened by a worker process.
It should be kept in mind that this number includes all connections (e.g. connections with proxied servers, among others), not only connections with clients. Another consideration is that the actual number of simultaneous connections cannot exceed the current limit on the maximum number of open files, which can be changed by worker_rlimit_nofile.

设置可由一个worker进程同时打开的最大连接数。如果设置了上面提到的worker_rlimit_nofile,我们可以将这个值设得很高。
理论上,每台nginx服务器的最大连接数为worker_processes * worker_connections。
记住,最大客户数也由系统的可用socket连接数限制(~ 64K),所以设置不切实际的高没什么好处。

Syntax:	multi_accept on | off;
Default:	
multi_accept off;
Context:	events

If multi_accept is disabled, a worker process will accept one new connection at a time. Otherwise, a worker process will accept all new connections at a time.

The directive is ignored if kqueue connection processing method is used, because it reports the number of new connections waiting to be accepted.

告诉nginx收到一个新连接通知后接受尽可能多的连接。

Syntax:	use method;
Default:	—
Context:	events

Specifies the connection processing method to use. There is normally no need to specify it explicitly, because nginx will by default use the most efficient method.

设置用于复用客户端线程的轮询方法。如果你使用Linux 2.6+,你应该使用epoll。如果你使用*BSD,你应该使用kqueue。
(值得注意的是如果你不知道Nginx该使用哪种轮询方法的话,它会选择一个最适合你操作系统的)

worker_processes

worker_processes
定义了nginx对外提供web服务时的worker进程数。最优值取决于许多因素,包括(但不限于)CPU核的数量、存储数据的硬盘数量及负载模式。

不能确定的时候,将其设置为可用的CPU内核数将是一个好的开始(设置为“auto”将尝试自动检测它)。亦可设置为其2倍,以优化性能。

查看CPU内核数:

cat /proc/cpuinfo | grep processor

worker_rlimit_nofile

  1. worker_rlimit_nofile

更改worker进程的最大打开文件数限制。如果没设置的话,这个值为操作系统的限制。设置后你的操作系统和Nginx可以处理比“ulimit -a”更多的文件,所以把这个值设高,这样nginx就不会有“too many open files”问题了。

查看系统的最大文件数:

ulimit -a
ulimit -n

更改系统最大文件数设置:

ulimit -v unlimited
cat &gt;&gt;/etc/security/limits.conf&lt;&lt;eof
* soft nproc 65535
* hard nproc 65535
* soft nofile 65535
* hard nofile 65535
eof

Nginx的accept_mutex配置

Syntax: accept_mutex on | off;
Default:
accept_mutex on;
Context: events

Syntax: accept_mutex_delay time;
Default:
accept_mutex_delay 500ms;
Context: events

Nginx的accept_mutex配置

通常多数人不会注意Nginx的accept_mutex配置,不过实际上它对系统的吞吐量有一定的影响,今天生物钟紊乱睡不着觉,索性闲扯一下Nginx的accept_mutex配置。

让我们看看accept_mutex的意义:当一个新连接到达时,如果激活了accept_mutex,那么多个Worker将以串行方式来处理,其中有一个Worker会被唤醒,其他的Worker继续保持休眠状态;如果没有激活accept_mutex,那么所有的Worker都会被唤醒,不过只有一个Worker能获取新连接,其它的Worker会重新进入休眠状态,这就是「惊群问题」。

Nginx缺省激活了accept_mutex,也就是说不会有惊群问题,但真的有那么严重么?实际上Nginx作者Igor Sysoev曾经给过相关的解释:

OS may wake all processes waiting on accept() and select(), this is called thundering herd problem. This is a problem if you have a lot of workers as in Apache (hundreds and more), but this insensible if you have just several workers as nginx usually has. Therefore turning accept_mutex off is as scheduling incoming connection by OS via select/kqueue/epoll/etc (but not accept()).

简单点说:Apache动辄就会启动成百上千的进程,如果发生惊群问题的话,影响相对较大;但是对Nginx而言,一般来说,worker_processes会设置成CPU个数,所以最多也就几十个,即便发生惊群问题的话,影响相对也较小。

另:高版本的Linux中,accept不存在惊群问题,不过epoll_wait等操作还有。

假设你养了一百只小鸡,现在你有一粒粮食,那么有两种喂食方法:

  • 你把这粒粮食直接扔到小鸡中间,一百只小鸡一起上来抢,最终只有一只小鸡能得手,其它九十九只小鸡只能铩羽而归。这就相当于关闭了accept_mutex。
  • 你主动抓一只小鸡过来,把这粒粮食塞到它嘴里,其它九十九只小鸡对此浑然不知,该睡觉睡觉。这就相当于激活了accept_mutex。可以看到此场景下,激活accept_mutex相对更好一些,让我们修改一下问题的场景,我不再只有一粒粮食,而是一盆粮食,怎么办?

此时如果仍然采用主动抓小鸡过来塞粮食的做法就太低效了,一盆粮食不知何年何月才能喂完,大家可以设想一下几十只小鸡排队等着喂食时那种翘首以盼的情景。此时更好的方法是把这盆粮食直接撒到小鸡中间,让它们自己去抢,虽然这可能会造成一定程度的混乱,但是整体的效率无疑大大增强了。

Nginx缺省激活了accept_mutex,是一种保守的选择。如果关闭了它,可能会引起一定程度的惊群问题,表现为上下文切换增多(sar -w)或者负载上升,但是如果你的网站访问量比较大,为了系统的吞吐量,我还是建议大家关闭它。

来源:http://huoding.com/2013/08/24/281