标签： Ngnix

nginx、swoole高并发原理初探

leokim / / Ngnix, PHP, 技术

一、阅前热身

为了更加形象的说明同步异步、阻塞非阻塞，我们以小明去买奶茶为例。

1、同步与异步

①同步与异步的理解

同步与异步的重点在消息通知的方式上，也就是调用结果通知的方式。

  • 同步当一个同步调用发出去后，调用者要一直等待调用结果的通知后，才能进行后续的执行

  • 异步：当一个异步调用发出去后，调用者不能立即得到调用结果的返回。

异步调用，要想获得结果，一般有两种方式：
1、主动轮询异步调用的结果;
2、被调用方通过callback来通知调用方调用结果。

②：生活实例

同步买奶茶：小明点单交钱，然后等着拿奶茶；异步买奶茶：小明点单交钱，店员给小明一个小票，等小明奶茶做好了，再来取。

异步买奶茶，小明要想知道奶茶是否做好了，有两种方式：
1、小明主动去问店员，一会就去问一下：“奶茶做好了吗？”…直到奶茶做好。
2、等奶茶做好了，店员喊一声：“小明，奶茶好了！”，然后小明去取奶茶。

2、阻塞与非阻塞

①阻塞与非阻塞的理解

阻塞与非阻塞的重点在于进/线程等待消息时候的行为，也就是在等待消息的时候，当前进/线程是挂起状态，还是非挂起状态。

  • 阻塞阻塞调用在发出去后，在消息返回之前，当前进/线程会被挂起，直到有消息返回，当前进/线程才会被激活.

  • 非阻塞非阻塞调用在发出去后，不会阻塞当前进/线程，而会立即返回。

②：生活实例

阻塞买奶茶：小明点单交钱，干等着拿奶茶，什么事都不做；非阻塞买奶茶：小明点单交钱，等着拿奶茶，等的过程中，时不时刷刷微博、朋友圈…

3、总结

通过上面的分析，我们可以得知：

同步与异步，重点在于消息通知的方式;阻塞与非阻塞，重点在于等消息时候的行为。

所以，就有了下面4种组合方式

  • 同步阻塞：小明在柜台干等着拿奶茶；

  • 同步非阻塞：小明在柜台边刷微博边等着拿奶茶；

  • 异步阻塞：小明拿着小票啥都不干，一直等着店员通知他拿奶茶；

  • 异步非阻塞：小明拿着小票，刷着微博，等着店员通知他拿奶茶。

二、Nginx如何处理高并发

1、Apache面对高并发，为什么很无力？

Apache处理一个请求是同步阻塞的模式。

每到达一个请求，Apache都会去fork一个子进程去处理这个请求，直到这个请求处理完毕。

面对低并发，这种模式没什么缺点，但是，面对高并发，就是这种模式的软肋了。

  • 1个客户端占用1个进程，那么，进程数量有多少，并发处理能力就有多少，但操作系统可以创建的进程数量是有限的。

  • 多进程就会有进程间的切换问题，而进程间的切换调度势必会造成CPU的额外消耗。当进程数量达到成千上万的时候，进程间的切换就占了CPU大部分的时间片，而真正进程的执行反而占了CPU的一小部分，这就得不偿失了。

下面，举例说明这2种场景是多进程模式的软肋：

  • 及时消息通知程序比如及时聊天程序，一台服务器可能要维持数十万的连接(典型的C10K问题)，那么就要启动数十万的进程来维持。这显然不可能。

  • 调用外部Http接口时假设Apache启动100个进程来处理请求，每个请求消耗100ms，那么这100个进程能提供1000qps。

但是，在我们调用外部Http接口时，比如QQ登录、微博登录，耗时较长，假设一个请求消耗10s，也就是1个进程1s处理0.1个请求，那么100个进程只能达到10qps，这样的处理能力就未免太差了。

注：什么是C10K问题？网络服务在处理数以万计的客户端连接时，往往出现效率低下甚至完全瘫痪，这被称为C10K问题。（concurrent 10000 connection）

综上，我们可以看出，Apache是同步阻塞的多进程模式，面对高并发等一些场景，是很苍白的。

2、Nginx何以问鼎高并发？

传统的服务器模型就是这样，因为其同步阻塞的多进程模型，无法面对高并发。
那么，有没有一种方式，可以让我们在一个进程处理所有的并发I/O呢？
答案是有的，这就是I/O复用技术。

①、I/O复用是神马？

最初级的I/O复用

所谓的I/O复用，就是多个I/O可以复用一个进程。

上面说的同步阻塞的多进程模型不适合处理高并发，那么，我们再来考虑非阻塞的方式。

采用非阻塞的模式，当一个连接过来时，我们不阻塞住，这样一个进程可以同时处理多个连接了。

比如一个进程接受了10000个连接，这个进程每次从头到尾的问一遍这10000个连接：“有I/O事件没？有的话就交给我处理，没有的话我一会再来问一遍。”
然后进程就一直从头到尾问这10000个连接，如果这1000个连接都没有I/O事件，就会造成CPU的空转，并且效率也很低，不好不好。

升级版的I/O复用

上面虽然实现了基础版的I/O复用，但是效率太低了。于是伟大的程序猿们日思夜想的去解决这个问题…终于！

我们能不能引入一个代理，这个代理可以同时观察许多I/O流事件呢？

当没有I/O事件的时候，这个进程处于阻塞状态；当有I/O事件的时候，这个代理就去通知进程醒来？

于是，早期的程序猿们发明了两个代理—select、poll。

select、poll代理的原理是这样的：

当连接有I/O流事件产生的时候，就会去唤醒进程去处理。

但是进程并不知道是哪个连接产生的I/O流事件，于是进程就挨个去问：“请问是你有事要处理吗？”……问了99999遍，哦，原来是第100000个进程有事要处理。那么，前面这99999次就白问了，白白浪费宝贵的CPU时间片了！痛哉，惜哉…

注:select与poll原理是一样的，只不过select只能观察1024个连接，poll可以观察无限个连接。

上面看了，select、poll因为不知道哪个连接有I/O流事件要处理，性能也挺不好的。

那么，如果发明一个代理，每次能够知道哪个连接有了I/O流事件，不就可以避免无意义的空转了吗？

于是，超级无敌、闪闪发光的epoll被伟大的程序员发明出来了。

epoll代理的原理是这样的：

当连接有I/O流事件产生的时候，epoll就会去告诉进程哪个连接有I/O流事件产生，然后进程就去处理这个进程。

如此，多高效！

②、基于epoll的Nginx

有了epoll，理论上1个进程就可以无限数量的连接，而且无需轮询，真正解决了c10k的问题。

Nginx是基于epoll的，异步非阻塞的服务器程序。自然，Nginx能够轻松处理百万级的并发连接，也就无可厚非了。

三、swoole如何处理高并发以及异步I/O的实现

1、swoole介绍

swoole是PHP的一个扩展。
简单理解：swoole=异步I/O+网络通信
PHPer可以基于swoole去实现过去PHP无法实现的功能。
具体请参考swoole官网：swoole官网

2、swoole如何处理高并发

①Reactor模型介绍

IO复用异步非阻塞程序使用经典的Reactor模型，Reactor顾名思义就是反应堆的意思，它本身不处理任何数据收发。只是可以监视一个socket(也可以是管道、eventfd、信号)句柄的事件变化。

注:什么是句柄？句柄英文为handler，可以形象的比喻为锅柄、勺柄。也就是资源的唯一标识符、资源的ID。通过这个ID可以操作资源。

Reactor只是一个事件发生器，实际对socket句柄的操作，如connect/accept、send/recv、close是在callback中完成的。

②swoole的架构

swoole采用 多线程Reactor+多进程Worker

swoole的架构图如下：

swoole的处理连接流程图如下：

当请求到达时,swoole是这样处理的：

请求到达 Main Reactor        |
        |Main Reactor根据Reactor的情况，将请求注册给对应的Reactor
(每个Reactor都有epoll。用来监听客户端的变化)        |
        |客户端有变化时，交给worker来处理        |
        |worker处理完毕，通过进程间通信(比如管道、共享内存、消息队列)发给对应的reactor。        |
        |reactor将响应结果发给相应的连接        |
        |
    请求处理完成

因为reactor基于epoll，所以每个reactor可以处理无数个连接请求。 如此，swoole就轻松的处理了高并发。

3、swoole如何实现异步I/O

基于上面的Swoole结构图，我们看到swoole的worker进程有2种类型：
一种是 普通的worker进程，一种是 task worker进程。

worker进程是用来处理普通的耗时不是太长的请求；task worker进程用来处理耗时较长的请求，比如数据库的I/O操作。

我们以异步Mysql举例：

耗时较长的Mysql查询进入worker            |
            |worker通过管道将这个请求交给taskworker来处理            |
            |worker再去处理其他请求            |
            |task worker处理完毕后，处理结果通过管道返回给worker            |
            |worker 将结果返回给reactor            |
            |reactor将结果返回给请求方

如此，通过worker、task worker结合的方式，我们就实现了异步I/O。

四、参考文章

Nginx 多进程模型是如何实现高并发的？
PHP并发IO编程之路
epoll 或者 kqueue 的原理是什么？
IO 多路复用是什么意思？

NGINX＋fastcgi(cgi)运作原理

leokim / / Ngnix

１．NGINX服务器原理
nginx在启动后，会有一个master进程和多个worker进程。master进程主要用来管理worker进程。
master主要做以下几件事：

(1).接收来自外界的信号
(2).向各worker进程发送信号
(3).监控worker进程的运行状态，当worker进程退出后(异常情况下)，
会自动重新启动新的worker进程。
而基本的网络事件，则是放在worker进程中来处理了。多个worker进程之间是对等,他们同等竞争来自客户端的请求，各进程互相之间是独立 的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。worker进程的个数是可以设置的，一般我们会 设置与机器cpu核数一致，这里面的原因与nginx的进程模型以及事件处理模型是分不开的。nginx的进程模型，可以由下图来表示： 

chapter-2-1.png

因为master来管理worker进程，所以我们要操作nginx只需要与master进程通信就行了。master进程会接收来自外界发来的信号，再根据信号做不同的事情。所以我们要控制nginx，只需要通过kill向master进程发送信号就行了。
worker进程又是如何处理请求的呢？我们前面有提到，worker进程之间是平等的，每个进程，处理请求的机会也是一样的。当我们提供80端口的 http服务时，一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？首先，每个worker进程都是从master进程fork过来，在 master进程里面，先建立好需要listen的socket（listenfd）之后，然后再fork出多worker进程。所有worker进程 的listenfd会在新连接到来时变得可读，为保证只有一个进程处理该连接，所有worker进程在注listenfd读事件前抢 accept_mutex，抢到互斥锁的那个进程注册listenfd读事件，在读事件里调用accept接受该连接。当一个worker进程在 accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可 以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。

2.FAST_CGI模型
FAST_CGI实在CGI上改进而来的，在说FAST_CGI之前必须先说说CGI。CGI叫是公共网关接口，它实际上是一段程序。是外部应用程序与Web服务器之间的接口标准，是在CGI程序和Web服务器之间传递信息的规程。上面讲到的nginx程序是不能直接调用外部程序的，要调用外部程序必须使用cig接口。nginx调用CGI的过程是这样的：

    1.浏览器通过ＨＴＭＬ表单或超链接请求指向一个CGI应用程序的URL。

    2.nginx服务器收到请求后，nginx服务器的worker进程需要执行执行指定的CGI应用程序（此时CGI初始化，启动CGI应用程序。）

    3.CGI应用程序执行所需要的操作（通常是基于浏览者输入的内容）。

    4.CGI应用程序把结果格式化为nginx或浏览器能够理解的文档（通常是HTML网页）,然后终止此CGI应用程序。

    5.nginx把结果返回到浏览器中。
FAST_CGI的过程和CGI差不多，不同在于FAST_CGI在服务器启动时载入FAST_CGI管理程序，这个管理程序自身初始化并启动多个子程序（这些子程序都是CGI程序），然后等待连接到来，当请求到达服务器时，FAST_CGI进程管理器选择并连接到一个CGI进程，同时服务器将CGI环境变量和标准输入发送到CGI程序，此时CGI程序就开始处理请求。处理完成后关闭此请求的连接（CGI程序不关闭继续运行），然后等待下次的请求连接。

nginx指令中的优化（配置文件）

leokim / / Ngnix

nginx指令中的优化（配置文件）

worker_processes 8;

nginx进程数，建议按照cpu数目来指定，一般为它的倍数。

worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

为每个进程分配cpu，上例中将8个进程分配到8个cpu，当然可以写多个，或者将一个进程分配到多个cpu。

worker_rlimit_nofile 102400;

这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit -n的值保持一致。

use epoll;

使用epoll的I/O模型，这个不用说了吧。

worker_connections 102400;

每个进程允许的最多连接数，理论上每台nginx服务器的最大连接数为worker_processes*worker_connections。

keepalive_timeout 60;

keepalive超时时间。

client_header_buffer_size 4k;

客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求的头部大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得。

open_file_cache max=102400 inactive=20s;

这个将为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开文件数一致，inactive是指经过多长时间文件没被请求后删除缓存。

open_file_cache_valid 30s;

这个是指多长时间检查一次缓存的有效信息。

open_file_cache_min_uses 1;

open_file_cache指令中的inactive参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive时间内一次没被使用，它将被移除。

内核参数的优化

net.ipv4.tcp_max_tw_buckets = 6000

timewait的数量，默认是180000。

net.ipv4.ip_local_port_range = 1024    65000

允许系统打开的端口范围。

net.ipv4.tcp_tw_recycle = 1

启用timewait快速回收。

net.ipv4.tcp_tw_reuse = 1

开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接。

net.ipv4.tcp_syncookies = 1

开启SYN Cookies，当出现SYN等待队列溢出时，启用cookies来处理。

net.core.somaxconn = 262144

web应用中listen函数的backlog默认会给我们内核参数的net.core.somaxconn限制到128，而nginx定义的NGX_LISTEN_BACKLOG默认为511，所以有必要调整这个值。

net.core.netdev_max_backlog = 262144

每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。

net.ipv4.tcp_max_orphans = 262144

系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，孤儿连接将即刻被复位并打印出警告信息。这个限制仅仅是为了防止简单的DoS攻击，不能过分依靠它或者人为地减小这个值，更应该增加这个值(如果增加了内存之后)。

net.ipv4.tcp_max_syn_backlog = 262144

记录的那些尚未收到客户端确认信息的连接请求的最大值。对于有128M内存的系统而言，缺省值是1024，小内存的系统则是128。

net.ipv4.tcp_timestamps = 0

时间戳可以避免序列号的卷绕。一个1Gbps的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种“异常”的数据包。这里需要将其关掉。

net.ipv4.tcp_synack_retries = 1

为了打开对端的连接，内核需要发送一个SYN并附带一个回应前面一个SYN的ACK。也就是所谓三次握手中的第二次握手。这个设置决定了内核放弃连接之前发送SYN+ACK包的数量。

net.ipv4.tcp_syn_retries = 1

在内核放弃建立连接之前发送SYN包的数量。

net.ipv4.tcp_fin_timeout = 1

如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。对端可以出错并永远不关闭连接，甚至意外当机。缺省值是60秒。2.2 内核的通常值是180秒，你可以按这个设置，但要记住的是，即使你的机器是一个轻载的WEB服务器，也有因为大量的死套接字而内存溢出的风险，FIN- WAIT-2的危险性比FIN-WAIT-1要小，因为它最多只能吃掉1.5K内存，但是它们的生存期长些。

net.ipv4.tcp_keepalive_time = 30

当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时。

一个完整的内核优化配置

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096        87380   4194304
net.ipv4.tcp_wmem = 4096        16384   4194304
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 262144
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 30
net.ipv4.ip_local_port_range = 1024    65000

一个简单的nginx优化配置文件

user  www www;
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000;
error_log  /www/log/nginx_error.log  crit;
pid        /usr/local/nginx/nginx.pid;
worker_rlimit_nofile 204800;

events
{
  use epoll;
  worker_connections 204800;
}

http
{
  include       mime.types;
  default_type  application/octet-stream;

  charset  utf-8;

  server_names_hash_bucket_size 128;
  client_header_buffer_size 2k;
  large_client_header_buffers 4 4k;
  client_max_body_size 8m;

  sendfile on;
  tcp_nopush     on;

  keepalive_timeout 60;

  fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2
                keys_zone=TEST:10m
                inactive=5m;
  fastcgi_connect_timeout 300;
  fastcgi_send_timeout 300;
  fastcgi_read_timeout 300;
  fastcgi_buffer_size 16k;
  fastcgi_buffers 16 16k;
  fastcgi_busy_buffers_size 16k;
  fastcgi_temp_file_write_size 16k;
  fastcgi_cache TEST;
  fastcgi_cache_valid 200 302 1h;
  fastcgi_cache_valid 301 1d;
  fastcgi_cache_valid any 1m;
  fastcgi_cache_min_uses 1;
  fastcgi_cache_use_stale error timeout invalid_header http_500;
  
  open_file_cache max=204800 inactive=20s;
  open_file_cache_min_uses 1;
  open_file_cache_valid 30s;
  


  tcp_nodelay on;
  
  gzip on;
  gzip_min_length  1k;
  gzip_buffers     4 16k;
  gzip_http_version 1.0;
  gzip_comp_level 2;
  gzip_types       text/plain application/x-javascript text/css application/xml;
  gzip_vary on;


  server
  {
    listen       8080;
    server_name  ad.test.com;
    index index.php index.htm;
    root  /www/html/;

    location /status
    {
        stub_status on;
    }

    location ~ .*\.(php|php5)?$
    {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include fcgi.conf;
    }

    location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|css)$
    {
      expires      30d;
    }

    log_format  access  '$remote_addr - $remote_user [$time_local] "$request" '
              '$status $body_bytes_sent "$http_referer" '
              '"$http_user_agent" $http_x_forwarded_for';
    access_log  /www/log/access.log  access;
      }
}

关于FastCGI的几个指令

fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10m inactive=5m;

这个指令为FastCGI缓存指定一个路径，目录结构等级，关键字区域存储时间和非活动删除时间。

fastcgi_connect_timeout 300;

指定连接到后端FastCGI的超时时间。

fastcgi_send_timeout 300;

向FastCGI传送请求的超时时间，这个值是指已经完成两次握手后向FastCGI传送请求的超时时间。

fastcgi_read_timeout 300;

接收FastCGI应答的超时时间，这个值是指已经完成两次握手后接收FastCGI应答的超时时间。

fastcgi_buffer_size 16k;

指定读取FastCGI应答第一部分需要用多大的缓冲区，这里可以设置为fastcgi_buffers指令指定的缓冲区大小，上面的指令指定它将使用1个16k的缓冲区去读取应答的第一部分，即应答头，其实这个应答头一般情况下都很小（不会超过1k），但是你如果在fastcgi_buffers指令中指定了缓冲区的大小，那么它也会分配一个fastcgi_buffers指定的缓冲区大小去缓存。

fastcgi_buffers 16 16k;

指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答，如上所示，如果一个PHP脚本所产生的页面大小为256k，则会为其分配16个16k的缓冲区来缓存，如果大于256k，增大于256k的部分会缓存到fastcgi_temp指定的路径中，当然这对服务器负载来说是不明智的方案，因为内存中处理数据速度要快于硬盘，通常这个值的设置应该选择一个你的站点中的php脚本所产生的页面大小的中间值，比如你的站点大部分脚本所产生的页面大小为256k就可以把这个值设置为16 16k，或者4 64k 或者64 4k，但很显然，后两种并不是好的设置方法，因为如果产生的页面只有32k，如果用4 64k它会分配1个64k的缓冲区去缓存，而如果使用64 4k它会分配8个4k的缓冲区去缓存，而如果使用16 16k则它会分配2个16k去缓存页面，这样看起来似乎更加合理。

fastcgi_busy_buffers_size 32k;

这个指令我也不知道是做什么用，只知道默认值是fastcgi_buffers的两倍。

fastcgi_temp_file_write_size 32k;

在写入fastcgi_temp_path时将用多大的数据块，默认值是fastcgi_buffers的两倍。

fastcgi_cache TEST

开启FastCGI缓存并且为其制定一个名称。个人感觉开启缓存非常有用，可以有效降低CPU负载，并且防止502错误。但是这个缓存会引起很多问题，因为它缓存的是动态页面。具体使用还需根据自己的需求。

fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;

为指定的应答代码指定缓存时间，如上例中将200，302应答缓存一小时，301应答缓存1天，其他为1分钟。

fastcgi_cache_min_uses 1;

缓存在fastcgi_cache_path指令inactive参数值时间内的最少使用次数，如上例，如果在5分钟内某文件1次也没有被使用，那么这个文件将被移除。

fastcgi_cache_use_stale error timeout invalid_header http_500;

不知道这个参数的作用，猜想应该是让nginx知道哪些类型的缓存是没用的。 以上为nginx中FastCGI相关参数，另外，FastCGI自身也有一些配置需要进行优化，如果你使用php-fpm来管理FastCGI，可以修改配置文件中的以下值：

<value name="max_children">60</value>

同时处理的并发请求数，即它将开启最多60个子线程来处理并发连接。

<value name="rlimit_files">102400</value>

最多打开文件数。

<value name="max_requests">204800</value>

每个进程在重置之前能够执行的最多请求数。

centos7 nginx安装

leokim / / Ngnix

安装nginx必备软件

yum install -y gcc
yum install -y gcc-c++
yum install -y pcre pcre-devel
yum install -y zlib zlib-devel
yum install -y openssl openssl-devel

修改/etc/sysctl.conf

fs.file-max = 999999 //表示一个进程最多可以打开的文件句柄数
net.ipv4.tcp_tw_reuse = 1 //这个参数设置为1，表示允许将TIME-WAIT状态的socket重新用于新的TCP连接。
net.ipv4.tcp_keepalive_time = 600 //监控对方连接是否正常的心跳发送间隔时间，默认2小时，设置小更快清理无效连接。
net.ipv4.tcp_fin_timeout = 30 //当tcp处于FIN_WAIT_2状态时，socket保持的最长时间
net.ipv4.ip_local_port_range = 1024 61000
net.ipv4.tcp_rmem = 4096 32768 262142
net.ipv4.tcp_wmem = 4096 32768 262142
net.core.netdev_max_backlog = 8096
net.core.rmem_default = 262142
net.core.wmem_default = 262142
net.core.rmem_max = 2097152
net.core.wmem_max = 2097152
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 1024

修改默认运行端口

修改 nginx.conf 文件实现。在 Linux 上该文件的路径为 /usr/local/nginx/conf/nginx.conf，Windows 下 安装目录\conf\nginx.conf。

server {
	listen       81;
	server_name  localhost;
	
	location / {
		root   html;
		index  index.html index.htm;
	}
	……
}

对iptable进行修改

vi /etc/sysconfig/iptables #编辑防火墙配置文件

-A INPUT -m state --state NEW -m tcp -p tcp --dport 81 -j ACCEPT

systemctl restart iptables.service #最后重启防火墙使配置生效
systemctl enable iptables.service #设置防火墙开机启动

启动ngnix

/usr/local/nginx/sbin/ngnix

成功！

blob.png