FPs

Articles with the nginx tag

Ngxfmt

接手一坨缩进、格式乱七八糟的Nginx 配置,简直要命。想起golang 有一个gofmt,动手做一个简单的ngxfmt。

Continue ->

ip.fangpeishi.com

server {
    listen 80;
    server_name ip.fangpeishi.com;
    location / {
        default_type text/plain;
        return 200 "$remote_addr\n";
    }
}

获取外网IP,给自己在某些脚本里面用,没有查询地址、运营商的需求。


高流量負載下Nginx 調優

  • 原文地址: Martin Fjordvald
  • 已獲得原文作者翻譯許可,本文遵循原文許可協議
  • 原文發表時間:April 27,2011

我曾經討論過一些Nginx 最常見的問題,毫無疑問,其中一個問題就是關於如何優化nginx 獲得高性能。不必驚訝,因爲大多數nginx 新用戶都是從Apache 遷移過來,所以他們習慣於調整配置和使用巫術來盡可能讓服務器達到最佳性能。

恩,我得告訴你一些壞消息,你並不能真的顯著優化nginx。沒有什麼配置能讓你的負載降低一半,或讓PHP 運行速度快2 倍。謝天謝地,好消息是nginx 不需要任何調優,因爲直接使用它時就已經被優化過了。最大的優化發生在當你決定運行通過ape-get install ,yum install 或 make install 安裝的nginx。(請注意這些倉庫內容常常過期。Wiki 的安裝頁面上通常有最新的倉庫。)

也就是說,有很多選項會影響nginx 的行爲,但是這些選項的默認值並不全都爲高流量的情況優化過。另外我們也需要考慮nginx 運行的平臺,優化我們的操作系統,因爲它們某些地方也會有瓶頸。

總之,我們沒法優化單個連接的加載時間,但是可以確保nginx 處理高流量的情況時有優化過的理想的環境。當然,我所說的高流量是指每秒幾百個請求,絕大多數人不需要爲這種情況費心思,不過如果你有興趣或者準備處理這種情況,請繼續往下讀吧。

Continue ->

Nginx 加載配置的順序分析

問題背景

在部署HTTPS 的時候,2台Nginx 下都部署了多個域名的證書,即NginxA 部署了證書a.com 和b.com 的證書,NginxB 也部署了證書a.com 和b.com ,域名a.com 指向NginxA,域名b.com 指向NginxB。
在用SSL LABS 檢測的時候,發現b.com 會出現“This site works only in browsers with SNI support.”,而a.com 不會。
SNI

SNI 介紹

關於SNI 的簡單介紹:

在 Nginx 中可以通过指定不同的 server_name 来配置多个站点。HTTP/1.1 协议请求头中的 Host 字段可以标识出当前请求属于哪个站点。但是对于 HTTPS 网站来说,要想发送 HTTP 数据,必须等待 SSL 握手完成,而在握手阶段服务端就必须提供网站证书。对于在同一个 IP 部署不同 HTTPS 站点,并且还使用了不同证书的情况下,服务端怎么知道该发送哪个证书?
Server Name Indication,简称为 SNI,是 TLS 的一个扩展,为解决这个问题应运而生。有了 SNI,服务端可以通过 Client Hello 中的 SNI 扩展拿到用户要访问网站的 Server Name,进而发送与之匹配的证书,顺利完成 SSL 握手。

引用來源:关于启用 HTTPS 的一些经验分享(二)

使用OpenSSL 測試NginxA,NginxB,不指定Host 頭,NginxA 返回的是a.com 的證書,NginxB 返回的也是a.com 的證書。

openssl s_client -connect nginx_ip:443 -showcerts < /dev/null 

Nginx 源碼分析

基本確定是配置加載的順序問題。在NginxA 和NginxB 中先加載的都是a.com。 在nginx.conf 中,我用 include 指令 引入了 某目錄下的所有conf 結尾的配置:

include /home/xxxxx/*.conf;

懷疑Nginx include 是按照字典順序,即a-z 的順序。看下源代碼,參考的Nginx 代碼版本是1.11.0。
先找到include 指定相關的函數:
Continue ->