什么是 Nginx

Nginx 是俄罗斯人编写的非常轻量级的 HTTP 服务器,Nginx,它的发音为“engine X”,是一个高性能的HTTP和反向代理服务器,同时也是一个 IMAP/POP3/SMTP 代理服务器。Nginx 是由俄罗斯人 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的,它曾经在该站点运行超过两年半了。Igor Sysoev 在建设的我的项目时,应用基于 BSD 许可。

Nginx 特点

Nginx 做为 HTTP 服务器,有以下几项根本个性:

  • 解决动态文件,索引文件以及主动索引;关上文件描述符缓冲.
  • 无缓存的反向代理减速,简略的负载平衡和容错.
  • FastCGI,简略的负载平衡和容错.
  • 模块化的构造。包含 gzipping, byte ranges, chunked responses,以及 SSI-filter 等 filter。如果由 FastCGI 或其它代理服务器解决单页中存在的多个 SSI,则这项解决能够并行运行,而不须要互相期待。
  • 反对 SSL 和 TLSSNI.

Nginx 专为性能优化而开发,性能是其最重要的考量,实现上十分重视效率 。它反对内核 Poll 模型,能禁受高负载的考验,有报告表明能反对高达 50,000 个并发连接数。
Nginx 具备很高的稳定性。
Nginx 反对热部署。
Nginx 代码品质十分高,代码很标准,手法成熟,模块扩大也很容易。

Nginx概述

HTTP根底性能:

  • 解决动态文件,索引文件以及主动索引;
  • 反向代理减速(无缓存),简略的负载平衡和容错;
  • FastCGI,简略的负载平衡和容错;
  • 模块化的构造。过滤器包含gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI过滤器中,到同一个 proxy 或者 FastCGI 的多个子申请并发解决;
  • SSL 和 TLS SNI 反对;

IMAP/POP3 代理服务性能:

  • 应用内部 HTTP 认证服务器重定向用户到 IMAP/POP3 后端;
  • 应用内部 HTTP 认证服务器认证用户后连贯重定向到外部的 SMTP 后端;
  • 认证办法:
  • POP3: POP3 USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5;
  • IMAP: IMAP LOGIN;
  • SMTP: AUTH LOGIN PLAIN CRAM-MD5;
  • SSL 反对;
  • 在 IMAP 和 POP3 模式下的 STARTTLS 和 STLS 反对;

反对的操作系统:

  • FreeBSD 3.x, 4.x, 5.x, 6.x i386; FreeBSD 5.x, 6.x amd64;
  • Linux 2.2, 2.4, 2.6 i386; Linux 2.6 amd64;
  • Solaris 8 i386; Solaris 9 i386 and sun4u; Solaris 10 i386;
  • MacOS X (10.4) PPC;
  • windows 编译版本反对 windows 系列操作系统;

构造与扩大:

  • 一个主过程和多个工作过程,工作过程运行于非特权用户;
  • kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select, 以及 poll 反对;
  • kqueue反对的不同性能包含 EV_CLEAR, EV_DISABLE (长期禁止事件), NOTE_LOWAT, EV_EOF, 无效数据的数目,错误代码;
  • sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+), 和 sendfilev (Solaris 8 7/01+) 反对;
  • 输出过滤 (FreeBSD 4.1+) 以及 TCP_DEFER_ACCEPT (Linux 2.4+) 反对;
  • 10,000 非流动的 HTTP keep-alive 连贯仅须要 2.5M 内存。
  • 最小化的数据拷贝操作;

其余HTTP性能:

  • 基于IP 和名称的虚拟主机服务;
  • Memcached 的 GET 接口;
  • 反对 keep-alive 和管道连贯;
  • 灵便简略的配置;
  • 重新配置和在线降级而无须中断客户的工作过程;
  • 可定制的拜访日志,日志写入缓存,以及快捷的日志回卷;
  • 4xx-5xx 错误代码重定向;
  • 基于 PCRE 的 rewrite 重写模块;
  • 基于客户端 IP 地址和 HTTP 根本认证的访问控制;
  • PUT, DELETE, 和 MKCOL 办法;
  • 反对 FLV (Flash 视频);
  • 带宽限度;

试验个性:

  • 内嵌的 perl
  • 通过 aio_read()/aio_write() 的套接字工作的试验模块,仅在 FreeBSD 下。
  • 对线程的试验化反对,FreeBSD 4.x 的实现基于 rfork()

Nginx命令

工作目录阐明:要求在Nginx.exe目录下执行
1.启动命令
start nginx
Linux下命令: ./nginx
2.重起命令
nginx -s reload
Linux下命令: ./nginx -s reload
3.敞开命令
nginx -s stop
Linux下命令: ./nginx -s stop

Nginx反向代理的原理

反向代理:用户拜访服务器,服务器晓得客户信息,客户不晓得服务器信息
正向代理:用户拜访服务器,服务器不晓得客户信息,客户晓得服务器信息
默认拜访门路:localhost:80
在conf目录下nginx.conf
只有一个http协定

 #gzip  on;#一个服务器,一个server    server {#端口个别不改        listen       80;#监听域名  服务名称不能反复        server_name  localhost;        #charset koi8-r;        #access_log  logs/host.access.log  main;#开启反向代理   代表全副申请        location / {#root关键字  代理的是一个目录            root   html;#index关键字   代表默认页面            index  index.html index.htm;        }

例如:

1.配置图片代理

    server {          listen       80;          server_name   image.jt.com;#域名          location / {              root D:/JT-SOFT/images;#本地磁盘地位              }         }   #必须在协定之内实现

HOSTS文件

作用:实现本地域名与ip地址的映射
默认门路:C:\Windows\System32\drivers\etc\hosts

实现域名代理

#实现默认80跳转8091通过image.jt.com间接拜访 server {          listen       80;          server_name   image.jt.com;            location / {#发动url申请地址            proxy_pass http://localhost:8091;          }       }

Nginx实现集群搭建

动静获取端口号

@RestControllerpublic class PortController {    @Value("${server.port}")    private int port;    @RequestMapping("/getport")    public String getport(){        return "端口号"+port;    }

我的项目打包

 server{         listen 80;         server_name   manage.jt.com;        location /{            #proxy_pass http://localhost:8091;            proxy_pass http://jtwindows;}}      #配置tomacat服务器集群      upstream jtwindows{                   server  127.0.0.1:8081;                   server  127.0.0.1:8082;                   server  127.0.0.1:8083;}

打包我的项目三次 端口别离是8081,8082,8083
别离都运行到程序上通过域名/getport测试端口是否能实现轮训
默认是轮训策略
权重策论:weight数值越高拜访越频繁数值越低根本不会被拜访:

 #配置tomacat服务器集群      upstream jtwindows{                   server  127.0.0.1:8081 weight=50;                   server  127.0.0.1:8082 weight=1;                   server  127.0.0.1:8083 weight=2;}

iphash策论

upstream jtwindows{                   ip_hash;                   server  127.0.0.1:8081 weight=50;                   server  127.0.0.1:8082 weight=1;                   server  127.0.0.1:8083 weight=2;}

毛病:1.容易造成负载不均

  2.如果Ip地址与用户绑定在一起,如果tomcat服务器宕机,则间接影响用户  IPhash实用场景:个别进行压力测试时应用      
事件模型

Nginx反对如下解决连贯的办法(I/O复用办法),这些办法能够通过use指令指定。

  • select - 规范办法。 如果以后平台没有更无效的办法,它是编译时默认的办法。你能够应用配置参数 --with-select_module 和 --without-select_module 来启用或禁用这个模块。
  • poll - 规范办法。 如果以后平台没有更无效的办法,它是编译时默认的办法。你能够应用配置参数 --with-poll_module 和 --without-poll_module 来启用或禁用这个模块。
  • kqueue - 高效的办法,应用于 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 应用双处理器的MacOS X零碎应用kqueue可能会造成内核解体。
  • epoll - 高效的办法,应用于Linux内核2.6版本及当前的零碎。在某些发行版本中,如SuSE 8.2, 有让2.4版本的内核反对epoll的补丁。
  • rtsig - 可执行的实时信号,应用于Linux内核版本2.2.19当前的零碎。默认状况下整个零碎中不能呈现大于1024个POSIX实时(排队)信号。这种状况对于高负载的服务器来说是低效的;所以有必要通过调节内核参数 /proc/sys/kernel/rtsig-max 来减少队列的大小。可是从Linux内核版本2.6.6-mm2开始, 这个参数就不再应用了,并且对于每个过程有一个独立的信号队列,这个队列的大小能够用 RLIMIT_SIGPENDING 参数调节。当这个队列过于拥塞,nginx就放弃它并且开始应用 poll 办法来解决连贯直到恢复正常。
  • /dev/poll - 高效的办法,应用于 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+.
  • eventport - 高效的办法,应用于 Solaris 10. 为了防止出现内核解体的问题, 有必要装置 这个 安全补丁。
Nginx高级属性

1.down属性
阐明:如果服务器宕机,则能够通过down属性把服务器宕掉

upstream jtwindows{                   #ip_hash;                   server  127.0.0.1:8081 weight=50 down;                   server  127.0.0.1:8082 weight=1;                   server  127.0.0.1:8083 weight=2;}

2.backup属性
备用机的设定,个别条件下备用机是不干活的,然而当主时机忙时,或者宕机是才会启用备用机
8081宕机了(down)启用备用机

upstream jtwindows{                   #ip_hash;                   server  127.0.0.1:8081 weight=50 down;                   server  127.0.0.1:8082 weight=1;                   server  127.0.0.1:8083 weight=2 backup;}

3.tomcat服务器高可用
阐明:如果人为增加down属性,效率不高,自动检测服务器是否宕机,如果宕机主动标识为down
max_fails=1设置最大的失败次数,如果超过最大次数则标识为down
fail_timeout=60s 生效的超时工夫(60s)

upstream jtwindows {        #ip_hash;        server localhost:8081 max_fails=1 fail_timeout=60s;        server localhost:8082 max_fails=1 fail_timeout=60s;        server localhost:8083 max_fails=1 fail_timeout=60s;    }

Nginx常见问题

  • [#notwork 某些东东不工作 (URL重写, 代理, 门路, ...)]
  • [#other 有没有其它相似的Web服务器]
  • [#chroot 对于chroot的反对是否在打算之中?]
  • [#usecase 在什么状况下应用Nginx比应用squid要好?]
  • [#imapexample 有没有人能给出一个残缺的.conf配置文件来具体的解读一下怎么配置和测试 IMAP 模块, 而不只是对于 IMAP 的只言片语啊?]
  • [#smtpexample 怎么让Nginx成为以postfix做为后端的SMTP代理?]
  • [#loadbalancing Nginx应用什么算法来实现负载平衡? 它能实现基于连接数的负载平衡吗?]
  • [#proxy_buffering 我能敞开从代理服务器到后端服务器的缓存吗或者应用上传进度个性?]

某些东东不工作 (URL重写, 代理, 门路, ...)

例如: 如URL重写(rewrite)不工作了或者是unix的门路(/$PATH)的问题云云...

请仔细阅读 [NginxDebugging] 并且 逐行 查看谬误日志。
如果你没找到谬误 打起精神 试着到IRC或邮件列表里阐明一下你碰到的问题。

有没有其它相似的Web服务器

  • Cherokee
  • Lighttpd (Lighty)
  • thttpd

对于各自的优缺点请应用本人喜爱的搜寻引挚查找  ;-)

对于chroot的反对是否在打算之中?

有人晓得吗?

在什么状况下应用Nginx比应用squid要好? 反之亦然。

大体上来说nginx次要用于反向减速代理而不是像squid那样做为惯例代理服务器。Nginx的最大劣势在于高负载状况下内存和CPU的低消耗。 我不认为squid能给你带来比nginx更好的性能。

有没有人能给出一个残缺的.conf配置文件来具体的解读一下怎么配置和测试 IMAP 模块, 而不只是对于 IMAP 的只言片语啊?

按照 [NginxImapProxyExample] 开始你的配置. 对于不同配置参数的具体信息, 请查看 [NginxMailCoreModule] 页。

示例1: 用运行于apache上的php脚本做后端验证

示例2: 应用运行于同一个服务器的 nginx-embedded-perl 模块作为 imap/pop代理和认证后端

怎么让Nginx成为以postfix做为后端的SMTP代理?

有人晓得不?

Nginx应用什么算法来实现负载平衡? 它能实现基于连接数的负载平衡吗?

目前Nginx应用简略的轮巡算法,所以无奈做根本链接计数的负载平衡。 这个可能会在未来的版本中有所扭转。

我能敞开从代理服务器到后端服务器的缓存吗或者应用上传进度个性?

基于 太多人询问上面的问题:

  • 我能为了失去上传进度而敞开代理的缓存吗
  • 应用nginx我怎么能力给用户显示上传进度
  • ...

到目前为止 (2007-Apr-26) 还没有方法敞开到后端服务器的缓存.