nginx(三)

最新推荐文章于 2025-03-31 09:04:26 发布

是江山er

最新推荐文章于 2025-03-31 09:04:26 发布

阅读量1.3k

点赞数

分类专栏： nginx 文章标签： nginx

本文链接：https://blog.youkuaiyun.com/jiangshannnnn/article/details/96438309

版权

nginx 专栏收录该内容

5 篇文章

订阅专栏

文章目录

证书
SSL原理
申请证书过程
配置Nginx的SSL
- Nginx配置示例（单向）
- Nginx配置双向认证
Nginx错误日志
Nginx访问日志-日志格式
Nginx优化-配置参数
Nginx优化-内核参数调整

证书

先来一个例子

A公司的小明被派到B公司办事情。B公司如何信任小明是A公司派来的呢？

普通介绍信

为了让B公司信任小明，A公司特意给小明开了一封介绍信，在信件中详细说明了小明的特征以及小明过来的目的，
并且声明这个小明确实是A公司派来的，除此之外还要有一个A公司的公章。
这样B公司前台小姐姐拿到介绍信后，通过信件内容和A公司公章就能判断出小明确实是A公司派来的员工。
 
那万一A公司公章是假的呢？毕竟公章伪造太容易了，这样岂不是会存在问题。咱们就暂且认为公章这种东西很难伪造，
否则故事无法继续喽。

引入第三方中介公司

好，回到刚才的话题。如果和B公司有业务往来的公司很多，每个公司的公章都不同，那B公司的前台小姐姐就要懂得分辨各种公章，
非常滴麻烦。所以，有某个中介公司C，发现了这个商机。C公司专门开设了一项“代理公章”的业务。
　　
于是今后，A公司的业务员去B公司，需要带2个介绍信：
介绍信1（含有C公司的公章及A公司的公章。并且特地注明：C公司信任A公司。）
介绍信2（仅含有A公司的公章，然后写上：兹有xxx先生/女士前往贵公司办理业务，请给予接洽......。）
 
这样不是增加麻烦了吗？有啥好处呢？
主要的好处在于，对于接待公司的前台，就不需要记住各个公司的公章分别是啥样子的，她只要记住中介公司C的公章即可。
当她拿到两份介绍信之后，先对介绍信1的C公章验明正身，确认无误之后，再比对“介绍信1”和“介绍信2”的两个A公章是否一致。
如果是一样的，那就可以证明“介绍信2”是可以信任的了。

SSL原理

要想弄明白SSL认证原理，首先要对CA有有所了解，它在SSL认证过程中有非常重要的作用。
说白了，CA就是一个组织，专门为网络服务器颁发证书的，国际知名的CA机构有VeriSign、Symantec，国内的有GlobalSign。
每一家CA都有自己的根证书，用来对它所签发过的服务器端证书进行验证。
 
如果服务器提供方想为自己的服务器申请证书，它就需要向CA机构提出申请。
服务器提供方向CA提供自己的身份信息，CA判明申请者的身份后，就为它分配一个公钥，
并且CA将该公钥和服务器身份绑定在一起，并为之签字，这就形成了一个服务器端证书。
 
如果一个用户想鉴别另一个证书的真伪，他就用CA的公钥对那个证书上的签字进行验证，一旦验证通过，该证书就被认为是有效的。
证书实际是由证书签证机关（CA）签发的对用户的公钥的认证。
 
证书的内容包括：电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期等等。
目前，证书的格式和验证方法普遍遵循X.509国际标准。

申请证书过程

在这里插入图片描述


首先要有一个CA根证书，然后用CA根证书来签发用户证书。
用户进行证书申请：
1. 先生成一个私钥
2. 用私钥生成证书请求(证书请求里应含有公钥信息)
3. 利用证书服务器的CA根证书来签发证书
 
这样最终拿到一个由CA根证书签发的证书，其实证书里仅有公钥，而私钥是在用户手里的。

SSL工作流程（单向）

在这里插入图片描述

1.客户端say hello 服务端
2.服务端将证书、公钥等发给客户端
3.客户端CA验证证书，成功继续、不成功弹出选择页面
4.客户端告知服务端所支持的加密算法
5.服务端选择最高级别加密算法明文通知客户端
6.客户端生成随机对称密钥key，使用服务端公钥加密发送给服务端
7.服务端使用私钥解密，获取对称密钥key
8.后续客户端与服务端使用该密钥key进行加密通信

SSL工作流程（双向）

单向认证，仅仅是客户端需要检验服务端证书是否是正确的，而服务端不会检验客户端证书是否是正确的。双向认证，指客户端验证服务器端证书，而服务器也需要通过CA的公钥证书来验证客户端证书。

双向验证的过程：

1.客户端say hello 服务端
2.服务端将证书、公钥等发给客户端
3.客户端CA验证证书，成功继续、不成功弹出选择页面
4.客户端将自己的证书和公钥发送给服务端
5.服务端验证客户端证书，如不通过直接断开连接
6.客户端告知服务端所支持的加密算法
7.服务端选择最高级别加密算法使用客户端公钥加密后发送给客户端
8.客户端收到后使用私钥解密并生成随机对称密钥key，使用服务端公钥加密发送给服务端
9.服务端使用私钥解密，获取对称密钥key
10.后续客户端与服务端使用该密钥key进行加密通信

自制CA证书

生成CA根证书
# mkdir /etc/pki/ca_test //创建CA更证书的目录

# cd /etc/pki/ca_test

# mkdir root server client newcerts  //创建几个相关的目录

# echo 01 > serial   //定义序列号为01

# echo 01 > crlnumber  //定义crl号为01

# touch index.txt  //创建index.txt

# cd ..

# vi tls/openssl.cnf  //改配置文件
default_ca     = CA_default 改为 default_ca     = CA_test
[ CA_default ] 改为 [ CA_test ]
dir             = /etc/pki/CA  改为  dir             = /etc/pki/ca_test
certificate	= $dir/cacert.pem  改为 certificate	= $dir/root/ca.crt
private_key	= $dir/private/cakey.pe 改为  private_key	= $dir/root/ca.key

# openssl genrsa -out /etc/pki/ca_test/root/ca.key  //生成私钥

# openssl req -new -key /etc/pki/ca_test/root/ca.key -out /etc/pki/ca_test/root/ca.csr   
//生成请求文件，会让我们填写一些指标,这里要注意：如果在这一步填写了相应的指标，
比如Country Name、State or Province Name、hostname。

# openssl x509 -req -days 3650 -in /etc/pki/ca_test/root/ca.csr -signkey /etc/pki/ca_test/root/ca.key -out /etc/pki/ca_test/root/ca.crt 
//生成crt文件

生成server端证书

# cd /etc/pki/ca_test/server

# openssl genrsa -out server.key   //生成私钥文件

# openssl req -new -key server.key -out server.csr//生成证书请求文件，填写信息需要和ca.csr中的Organization Name保持一致

# openssl ca -in server.csr -cert /etc/pki/ca_test/root/ca.crt -keyfile /etc/pki/ca_test/root/ca.key -out server.crt -days 3650  
//用根证书签名server.csr，最后生成公钥文件server.crt，此步骤会有两个地方需要输入y
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

生成客户端证书

如果做ssl的双向认证，还需要给客户端生成一个证书，步骤和上面的基本一致
# cd /etc/pki/ca_test/client

# openssl genrsa -out  client.key  //生成私钥文件

# openssl req -new  -key client.key -out client.csr  //生成请求文件，填写信息需要和ca.csr中的Organization Name保持一致

# openssl ca -in client.csr -cert /etc/pki/ca_test/root/ca.crt -keyfile /etc/pki/ca_test/root/ca.key -out client.crt -days 3650 
//签名client.csr, 生成client.crt，此步如果出现
failed to update database
TXT_DB error number 2

需执行：
# sed -i 's/unique_subject = yes/unique_subject = no/' /etc/pki/ca_test/index.txt.attr

执行完，再次重复执行签名client.csr那个操作

配置Nginx的SSL

Nginx配置示例（单向）

cp /etc/pki/ca_test/server/server.* /usr/local/nginx/conf/
{
    listen 443 ssl;
    server_name www.testlinux.com;
    index index.html index.php;
    root /data/wwwroot/testlinux.com;
    ssl on;
    ssl_certificate server.crt;
    ssl_certificate_key server.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ALL:!DH:!EXPORT:!RC4:+HIGH:+MEDIUM:!eNULL;
    ssl_prefer_server_ciphers on;
    ...
}

配置说明

1. 443端口为ssl监听端口。
2. ssl on表示打开ssl支持。
3. ssl_certificate指定crt文件所在路径，如果写相对路径，必须把该文件和nginx.conf文件放到一个目录下。
4. ssl_certificate_key指定key文件所在路径。
5. ssl_protocols指定SSL协议。
6. ssl_ciphers配置ssl加密算法，多个算法用:分隔，ALL表示全部算法，!表示不启用该算法，+表示将该算法排到最后面去。
7. ssl_prefer_server_ciphers 如果不指定默认为off，当为on时，在使用SSLv3和TLS协议时，服务器加密算法将优于客户端加密算法。

Nginx配置双向认证

配置示例：

{
    listen 443 ssl;
    server_name www.testlinux.com;
    index index.html index.php;
    root /data/wwwroot/testlinux.com;
    ssl on;
    ssl_certificate server.crt;
    ssl_certificate_key server.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ALL:!DH:!EXPORT:!RC4:+HIGH:+MEDIUM:!eNULL;
    ssl_prefer_server_ciphers on;
    ssl_client_certificate ca.crt; //这里的ca.crt是根证书公钥文件
    ssl_verify_client on;
    ...
}

Nginx错误日志

ginx错误日志平时不用太关注，但是一旦出了问题，就需要借助错误日志来判断问题所在。

配置参数格式：error_log /path/to/log level;

Nginx错误日志级别

常见的错误日志级别有debug | info | notice | warn | error | crit | alert | emerg
级别越高记录的信息越少，如果不定义，默认级别为error.

它可以配置在main、http、server、location段里。

如果在配置文件中定义了两个error_log，在同一个配置段里的话会产生冲突，所以同一个段里只允许配置一个error_log。
但是，在不同的配置段中出现是没问题的。

Nginx错误日志示例

error_log  /var/log/nginx/error.log crit;

如果要想彻底关闭error_log，需要这样配置

error_log /dev/null;

Nginx访问日志-日志格式

Nginx访问日志格式
Nginx访问日志可以设置自定义的格式，来满足特定的需求。
访问日志格式示例
示例1

    log_format combined_realip '$remote_addr $http_x_forwarded_for [$time_local]'
    '$host "$request_uri" $status'
    '"$http_referer" "$http_user_agent"';

示例2

    log_format main '$remote_addr [$time_local] '
    '$host "$request_uri" $status "$request"'
    '"$http_referer" "$http_user_agent" "$request_time"';

若不配置log_format或者不在access_log配置中指定log_format，则默认格式为：
    '$remote_addr - $remote_user [$time_local] "$request" '
    '$status $body_bytes_sent "$http_referer" '
    '"$http_user_agent";

常见变量

变量	说明
$time_local	通用日志格式下的本地时间；（服务器时间）
$remote_addr	客户端（用户）IP地址
$status	请求状态码，如200，404，301，302等
$body_bytes_sent	发送给客户端的字节数，不包括响应头的大小
$bytes_sent	发送给客户端的总字节数
$request_length	请求的长度（包括请求行，请求头和请求正文）
$request_time	请求处理时间，单位为秒，小数的形式
$upstream_addr	集群轮询地址
$upstream_response_time	指从Nginx向后端（php-cgi)建立连接开始到接受完数据然后关闭连接为止的时间
$remote_user	用来记录客户端用户名称
$request	请求方式（GET或者POST等）+URL（包含 $request_method,$ host,$request_uri）
$http_user_agent	用户浏览器标识
$http_host	请求的url地址（目标url地址）的host
$host	等同于$http_host
$http_referer	来源页面，即从哪个页面转到本页，如果直接在浏览器输入网址来访问，则referer为空
$uri	请求中的当前URI(不带请求参数，参数位于 $a r g s) ，不同于浏览器传递的$ request_uri的值，它可以通过内部重定向，或者使用index指令进行修改。
$document_uri	等同于$uri
$request_uri	比 $u r i 多了参数，即$ uri+$args
$http_x_forwarded_for	如果使用了代理，这个参数会记录代理服务器的ip和客户端的ip

Nginx优化-配置参数

Nginx配置参数优化
Nginx作为高性能web服务器，即使不特意调整配置参数也可以处理大量的并发请求。
以下的配置参数是借鉴网上的一些调优参数，仅作为参考，不见得适于你的线上业务。
worker进程
worker_processes
该参数表示启动几个工作进程，建议和本机CPU核数保持一致，每一核CPU处理一个进程。
worker_rlimit_nofile
它表示Nginx最大可用的文件描述符个数，需要配合系统的最大描述符，建议设置为102400。
还需要在系统里执行ulimit -n 102400才可以。
也可以直接修改配置文件/etc/security/limits.conf修改
增加：
#* soft nofile 655350 (去掉前面的#)
#* hard nofile 655350 (去掉前面的#)
worker_connections
该参数用来配置每个Nginx worker进程最大处理的连接数，这个参数也决定了该Nginx服务器最多能处理多少客户端请求
（worker_processes * worker_connections)，建议把该参数设置为10240，不建议太大。
http和tcp连接
use epoll
使用epoll模式的事件驱动模型，该模型为Linux系统下最优方式。
multi_accept on
使每个worker进程可以同时处理多个客户端请求。
sendfile on
使用内核的FD文件传输功能，可以减少user mode和kernel mode的切换，从而提升服务器性能。
tcp_nopush on
当tcp_nopush设置为on时，会调用tcp_cork方法进行数据传输。
使用该方法会产生这样的效果：当应用程序产生数据时，内核不会立马封装包，而是当数据量积累到一定量时才会封装，然后传输。
tcp_nodelay on
不缓存data-sends（关闭 Nagle 算法），这个能够提高高频发送小数据报文的实时性。
(关于Nagle算法)
【假如需要频繁的发送一些小包数据，比如说1个字节，以IPv4为例的话，则每个包都要附带40字节的头，
也就是说，总计41个字节的数据里，其中只有1个字节是我们需要的数据。
为了解决这个问题，出现了Nagle算法。
它规定：如果包的大小满足MSS，那么可以立即发送，否则数据会被放到缓冲区，等到已经发送的包被确认了之后才能继续发送。
通过这样的规定，可以降低网络里小包的数量，从而提升网络性能。】
keepalive_timeout
定义长连接的超时时间，建议30s，太短或者太长都不一定合适，当然，最好是根据业务自身的情况来动态地调整该参数。
keepalive_requests
定义当客户端和服务端处于长连接的情况下，每个客户端最多可以请求多少次，可以设置很大，比如50000.
reset_timeout_connection on
设置为on的话，当客户端不再向服务端发送请求时，允许服务端关闭该连接。
client_body_timeout
客户端如果在该指定时间内没有加载完body数据，则断开连接，单位是秒，默认60，可以设置为10。
send_timeout
这个超时时间是发送响应的超时时间，即Nginx服务器向客户端发送了数据包，但客户端一直没有去接收这个数据包。
如果某个连接超过send_timeout定义的超时时间，那么Nginx将会关闭这个连接。单位是秒，可以设置为3。
buffer和cache(以下配置都是针对单个请求)
client_body_buffer_size
当客户端以POST方法提交一些数据到服务端时，会先写入到client_body_buffer中，如果buffer写满会写到临时文件里，建议调整为128k。
client_max_body_size
浏览器在发送含有较大HTTP body的请求时，其头部会有一个Content-Length字段，client_max_body_size是用来限制Content-Length所示值的大小的。
这个限制body的配置不用等Nginx接收完所有的HTTP包体，就可以告诉用户请求过大不被接受。会返回413状态码。
例如，用户试图上传一个1GB的文件，Nginx在收完包头后，发现Content-Length超过client_max_body_size定义的值，
就直接发送413(Request Entity Too Large)响应给客户端。
将该数值设置为0，则禁用限制，建议设置为10m。
client_header_buffer_size
设置客户端header的buffer大小，建议4k。
large_client_header_buffers
对于比较大的header（超过client_header_buffer_size）将会使用该部分buffer，两个数值，第一个是个数，第二个是每个buffer的大小。
建议设置为4 8k
open_file_cache
该参数会对以下信息进行缓存：
打开文件描述符的文件大小和修改时间信息;
存在的目录信息;
搜索文件的错误信息（文件不存在无权限读取等信息）。
格式：open_file_cache max=size inactive=time;
max设定缓存文件的数量，inactive设定经过多长时间文件没被请求后删除缓存。
建议设置 open_file_cache max=102400 inactive=20s;
open_file_cache_valid
指多长时间检查一次缓存的有效信息。建议设置为30s。
open_file_cache_min_uses
open_file_cache指令中的inactive参数时间内文件的最少使用次数，
如,将该参数设置为1，则表示，如果文件在inactive时间内一次都没被使用，它将被移除。
建议设置为2。
压缩
对于纯文本的内容，Nginx是可以使用gzip压缩的。使用压缩技术可以减少对带宽的消耗。
由ngx_http_gzip_module模块支持

配置如下：
gzip on; //开启gzip功能
gzip_min_length 1024; //设置请求资源超过该数值才进行压缩，单位字节
gzip_buffers 16 8k; //设置压缩使用的buffer大小，第一个数字为数量，第二个为每个buffer的大小
gzip_comp_level 6; //设置压缩级别，范围1-9,9压缩级别最高，也最耗费CPU资源
gzip_types text/plain application/x-javascript text/css application/xml image/jpeg image/gif image/png; //指定哪些类型的文件需要压缩
gzip_disable "MSIE 6\."; //IE6浏览器不启用压缩

测试：
curl -I -H "Accept-Encoding: gzip, deflate" http://www.testlinux.com/1.css
日志
错误日志级别调高，比如crit级别，尽量少记录无关紧要的日志。
对于访问日志，如果不要求记录日志，可以关闭，
静态资源的访问日志关闭
静态文件过期
对于静态文件，需要设置一个过期时间，这样可以让这些资源缓存到客户端浏览器，
在缓存未失效前，客户端不再向服务期请求相同的资源，从而节省带宽和资源消耗。

配置示例如下：
location ~* ^.+\.(gif|jpg|png|css|js)$                                      
{
    expires 1d; //1d表示1天，也可以用24h表示一天。
}
作为代理服务器
Nginx绝大多数情况下都是作为代理或者负载均衡的角色。
因为前面章节已经介绍过以下参数的含义，在这里只提供对应的配置参数：
http
{
    proxy_cache_path /data/nginx_cache/ levels=1:2 keys_zone=my_zone:10m inactive=300s max_size=5g;
    ...;
    server
    {
	proxy_buffering on;
	proxy_buffer_size 4k;
	proxy_buffers 2 4k;
	proxy_busy_buffers_size 4k;
	proxy_temp_path /tmp/nginx_proxy_tmp 1 2;
	proxy_max_temp_file_size 20M;
	proxy_temp_file_write_size 8k;
	
	location /
	{
	    proxy_cache my_zone;
	    ...;
	}
    }
}
SSL优化
适当减少worker_processes数量，因为ssl功能需要使用CPU的计算。
使用长连接，因为每次建立ssl会话，都会耗费一定的资源（加密、解密）
开启ssl缓存，简化服务端和客户端的“握手”过程。
ssl_session_cache   shared:SSL:10m; //缓存为10M
ssl_session_timeout 10m; //会话超时时间为10分钟

Nginx优化-内核参数调整

调整Linux内核参数

作为高性能WEB服务器，只调整Nginx本身的参数是不行的，因为Nginx服务依赖于高性能的操作系统。
以下为常见的几个Linux内核参数优化方法。

1 net.ipv4.tcp_max_tw_buckets

对于tcp连接，服务端和客户端通信完后状态变为timewait，假如某台服务器非常忙，连接数特别多的话，那么这个timewait数量就会越来越大。
毕竟它也是会占用一定的资源，所以应该有一个最大值，当超过这个值，系统就会删除最早的连接，这样始终保持在一个数量级。
这个数值就是由net.ipv4.tcp_max_tw_buckets这个参数来决定的。
CentOS7系统，你可以使用sysctl -a |grep tw_buckets来查看它的值，默认为32768，
你可以适当把它调低，比如调整到8000，毕竟这个状态的连接太多也是会消耗资源的。
但你不要把它调到几十、几百这样，因为这种状态的tcp连接也是有用的，
如果同样的客户端再次和服务端通信，就不用再次建立新的连接了，用这个旧的通道，省时省力。

2 net.ipv4.tcp_tw_recycle = 1

该参数的作用是快速回收timewait状态的连接。上面虽然提到系统会自动删除掉timewait状态的连接，但如果把这样的连接重新利用起来岂不是更好。
所以该参数设置为1就可以让timewait状态的连接快速回收，它需要和下面的参数配合一起使用。

3 net.ipv4.tcp_tw_reuse = 1

该参数设置为1，将timewait状态的连接重新用于新的TCP连接，要结合上面的参数一起使用。

4 net.ipv4.tcp_syncookies = 1

tcp三次握手中，客户端向服务端发起syn请求，服务端收到后，也会向客户端发起syn请求同时连带ack确认，
假如客户端发送请求后直接断开和服务端的连接，不接收服务端发起的这个请求，服务端会重试多次，
这个重试的过程会持续一段时间（通常高于30s），当这种状态的连接数量非常大时，服务器会消耗很大的资源，从而造成瘫痪，
正常的连接进不来，这种恶意的半连接行为其实叫做syn flood攻击。
设置为1，是开启SYN Cookies，开启后可以避免发生上述的syn flood攻击。
开启该参数后，服务端接收客户端的ack后，再向客户端发送ack+syn之前会要求client在短时间内回应一个序号，
如果客户端不能提供序号或者提供的序号不对则认为该客户端不合法，于是不会发ack+syn给客户端，更涉及不到重试。

5 net.ipv4.tcp_max_syn_backlog

该参数定义系统能接受的最大半连接状态的tcp连接数。客户端向服务端发送了syn包，服务端收到后，会记录一下，
该参数决定最多能记录几个这样的连接。在CentOS7，默认是256，当有syn flood攻击时，这个数值太小则很容易导致服务器瘫痪，
实际上此时服务器并没有消耗太多资源（cpu、内存等），所以可以适当调大它，比如调整到30000。

6 net.ipv4.tcp_syn_retries

该参数适用于客户端，它定义发起syn的最大重试次数，默认为6，建议改为2。

7 net.ipv4.tcp_synack_retries

该参数适用于服务端，它定义发起syn+ack的最大重试次数，默认为5，建议改为2，可以适当预防syn flood攻击。

8 net.ipv4.ip_local_port_range

该参数定义端口范围，系统默认保留端口为1024及以下，以上部分为自定义端口。这个参数适用于客户端，
当客户端和服务端建立连接时，比如说访问服务端的80端口，客户端随机开启了一个端口和服务端发起连接，
这个参数定义随机端口的范围。默认为32768    61000，建议调整为1025 61000。

9 net.ipv4.tcp_fin_timeout

tcp连接的状态中，客户端上有一个是FIN-WAIT-2状态，它是状态变迁为timewait前一个状态。
该参数定义不属于任何进程的该连接状态的超时时间，默认值为60，建议调整为6。

10 net.ipv4.tcp_keepalive_time

tcp连接状态里，有一个是established状态，只有在这个状态下，客户端和服务端才能通信。正常情况下，当通信完毕，
客户端或服务端会告诉对方要关闭连接，此时状态就会变为timewait，如果客户端没有告诉服务端，
并且服务端也没有告诉客户端关闭的话（例如，客户端那边断网了），此时需要该参数来判定。
比如客户端已经断网了，但服务端上本次连接的状态依然是established，服务端为了确认客户端是否断网，
就需要每隔一段时间去发一个探测包去确认一下看看对方是否在线。这个时间就由该参数决定。它的默认值为7200秒，建议设置为30秒。

11 net.ipv4.tcp_keepalive_intvl

该参数和上面的参数是一起的，服务端在规定时间内发起了探测，查看客户端是否在线，如果客户端并没有确认，
此时服务端还不能认定为对方不在线，而是要尝试多次。该参数定义重新发送探测的时间，即第一次发现对方有问题后，过多久再次发起探测。
默认值为75秒，可以改为3秒。

12 net.ipv4.tcp_keepalive_probes

第10和第11个参数规定了何时发起探测和探测失败后再过多久再发起探测，但并没有定义一共探测几次才算结束。
该参数定义发起探测的包的数量。默认为9，建议设置2。
设置和范例

在Linux下调整内核参数，可以直接编辑配置文件/etc/sysctl.conf，然后执行sysctl -p命令生效
 
结合以上分析的各内核参数，范例如下
net.ipv4.tcp_fin_timeout = 6
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_max_tw_buckets = 8000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 30000
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 2
net.ipv4.ip_local_port_range = 1025 61000
net.ipv4.tcp_keepalive_intvl = 3
net.ipv4.tcp_keepalive_probes = 2

[root@centos-03 vhost]# sysctl -a |grep tw_buckets
net.ipv4.tcp_max_tw_buckets = 4096

1.查看time-wait数量

ss -an