阿铭Linux

nginx 作为正向代理

nginx还是蛮强大的，不仅可以作为7层的正向代理，还可以作为4层的正向代理。

参考文档  https://zhuanlan.zhihu.com/p/70522194

7层是需要加三分模块 ngx_http_proxy_connect_module，github地址：https://github.com/chobits/ngx_http_proxy_connect_module 注意，不同的Nginx版本，还需要下载不同的patch包

具体配置   参考 https://github.com/aminglinux/nginx/blob/master/proxy/z_proxy.md

配置文件

server {
     listen                         3128;


     # dns resolver used by forward proxying
     resolver                       119.29.29.29;


     # forward proxy for CONNECT request
     proxy_connect;
     proxy_connect_allow            80 443 8080;
     proxy_connect_connect_timeout  10s;
     proxy_connect_read_timeout     10s;
     proxy_connect_send_timeout     10s;


     # forward proxy for non-CONNECT request
     location / {
         proxy_pass http://$host;
         proxy_set_header Host $host;
     }
}

4层的话，需要额外增加编译参数

--with-stream  --with-stream_ssl_preread_module  --with-stream_ssl_module

配置文件

stream {
    resolver 114.114.114.114;
    server {
        listen 443;
        ssl_preread on;
        proxy_connect_timeout 5s;
        proxy_pass $ssl_preread_server_name:$server_port;
    }
}

Nginx tcp反向代理记录日志

对于Nginx访问日志，大家都很熟悉，但是对于tcp代理来说，到底能不能记录访问日志呢? 想了一下，貌似不能啊，因为毕竟访问日志里面记录的元素都是http协议的。

但是当我去搜索时，的确搜到了相关的文档，索性先试试看，测试后发现确实可以。

修改nginx配置文档/usr/local/nginx/conf/nginx.conf 设置日志格式

stream {
 log_format proxy '$remote_addr [$time_local] '
 '$protocol $status $bytes_sent $bytes_received '
 '$session_time "$upstream_addr" '
 '"$upstream_bytes_sent" "$upstream_bytes_received" "$upstream_connect_time"';
 include ./conf.d/*.tcpstream;
}

修改具体的tcp配置文档

server{
 error_log /opt/log/device5001_error.log;
 access_log /opt/log/device5001_access.log proxy;
 listen 5001;
 proxy_pass device5001;
}

日志如下：

但是，需要提醒你的是：

nginx会等待session结束才会记录到日志文件；
session日志只是tcp层面的记录，包括session时间，发送接收字节数等等；
session内部发送日志(比如一个socket连接建立起来以后，多次发送心跳数据）需要在应用层面才能记录；

centos使用yum update升级到指定小版本

参考： https://www.cnblogs.com/configure/p/10918189.html

提供一个搜狐镜像的7.6的yum源：

[C7.6.1810-base]
name=CentOS-7.6.1810 - Base
baseurl=http://mirrors.sohu.com/centos/7.6.1810/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
enabled=1

[C7.6.1810-updates]
name=CentOS-7.6.1810 - Updates
baseurl=http://mirrors.sohu.com/centos/7.6.1810/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
enabled=1

[C7.6.1810-extras]
name=CentOS-7.6.1810 - Extras
baseurl=http://mirrors.sohu.com/centos/7.6.1810/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
enabled=1

[C7.6.1810-centosplus]
name=CentOS-7.6.1810 - CentOSPlus
baseurl=http://mirrors.sohu.com/centos/7.6.1810/centosplus/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
enabled=1

[C7.6.1810-fasttrack]
name=CentOS-7.6.1810 - Fasttrack
baseurl=http://mirrors.sohu.com/centos/7.6.1810/fasttrack/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
enabled=1

nginx反向代理时保持长连接

【场景描述】

HTTP1.1之后，HTTP协议支持持久连接，也就是长连接，优点在于在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

如果我们使用了nginx去作为反向代理或者负载均衡，从客户端过来的长连接请求就会被转换成短连接发送给服务器端。

为了支持长连接，我们需要在nginx服务器上做一些配置。

·【要求】

使用nginx时，想要做到长连接，我们必须做到以下两点：

1. 从client到nginx是长连接
2. 从nginx到server是长连接

对于客户端而言，nginx其实扮演着server的角色，反之，之于server，nginx就是一个client。

·【保持和 Client 的长连接】

我们要想做到Client与Nginx之间保持长连接，需要：

1. Client发送过来的请求携带“keep-alive”header。
2. Nginx设置支持keep-alive

【HTTP配置】

默认情况下，nginx已经开启了对client连接的 keepalive 支持。对于特殊场景，可以调整相关参数。

大多数情况下，keepalive_requests = 100也够用，但是对于 QPS 较高的场景，非常有必要加大这个参数，以避免出现大量连接被生成再抛弃的情况，减少TIME_WAIT。
QPS=10000 时，客户端每秒发送 10000 个请求 (通常建立有多个长连接)，每个连接只能最多跑 100 次请求，意味着平均每秒钟就会有 100 个长连接因此被 nginx 关闭。

同样意味着为了保持 QPS，客户端不得不每秒中重新新建 100 个连接。

因此，如果用netstat命令看客户端机器，就会发现有大量的TIME_WAIT的socket连接 (即使此时keep alive已经在 Client 和 NGINX 之间生效)。

·【保持和Server的长连接】

想让Nginx和Server之间维持长连接，最朴素的设置如下：

【upstream配置】

upstream中，有一个参数特别的重要，就是keepalive。

这个参数和之前http里面的 keepalive_timeout 不一样。

这个参数的含义是，连接池里面最大的空闲连接数量。

不理解？没关系，我们来举个例子：

场景：

有一个HTTP服务，作为upstream服务器接收请求，响应时间为100毫秒。

要求性能达到10000 QPS，我们需要在nginx与upstream服务器之间建立大概1000条HTTP请求。（1000/0.1s=10000）

最优情况：

假设请求非常的均匀平稳，每一个请求都是100ms，请求结束会被马上放入连接池并置为idle（空闲）状态。

我们以0.1s为单位：

1. 我们现在keepalive的值设置为10，每0.1s钟有1000个连接

2. 第0.1s的时候，我们一共有1000个请求收到并释放

3. 第0.2s的时候，我们又来了1000个请求，在0.2s结束的时候释放

请求和应答都比较均匀，0.1s释放的连接正好够用，不需要建立新连接，且连接池中没有idle状态的连接。

第一种情况：

应答非常平稳，但是请求不平稳的时候

4. 第0.3s的时候，我们只有500个请求收到，有500个请求因为网络延迟等原因没有进来

这个时候，Nginx检测到连接池中有500个idle状态的连接，就直接关闭了（500-10）个连接

5. 第0.4s的时候，我们收到了1500个请求，但是现在池里面只有（500+10）个连接，所以Nginx不得不重新建立了（1500-510）个连接。

如果在第4步的时候，没有关闭那490个连接的话，只需要重新建立500个连接。

第二种情况：

请求非常平稳，但是应答不平稳的时候

4. 第0.3s的时候，我们一共有1500个请求收到

但是池里面只有1000个连接，这个时候，Nginx又创建了500个连接，一共1500个连接

5. 第0.3s的时候，第0.3s的连接全部被释放，我们收到了500个请求

Nginx检测到池里面有1000个idle状态的连接，所以不得不释放了（1000-10）个连接

造成连接数量反复震荡的一个推手，就是这个keepalive 这个最大空闲连接数。

上面的两种情况说的都是 keepalive 设置的不合理导致Nginx有多次释放与创建连接的过程，造成资源浪费。

keepalive 这个参数设置一定要小心，尤其是对于 QPS 要求比较高或者网络环境不稳定的场景，一般根据 QPS 值和 平均响应时间能大致推算出需要的长连接数量。

然后将keepalive设置为长连接数量的10%到30%。

【location配置】

HTTP 协议中对长连接的支持是从 1.1 版本之后才有的，因此最好通过 proxy_http_version 指令设置为 1.1。

HTTP1.0不支持keepalive特性，当没有使用HTTP1.1的时候，后端服务会返回101错误，然后断开连接。

而 “Connection” header 可以选择被清理，这样即便是 Client 和 Nginx 之间是短连接，Nginx 和 upstream 之间也是可以开启长连接的。

【另外一种高级方式】

http里面的map的作用是：

让转发到代理服务器的 “Connection” 头字段的值，取决于客户端请求头的 “Upgrade” 字段值。

如果 $http_upgrade没有匹配，那 “Connection” 头字段的值会是upgrade。

如果 $http_upgrade为空字符串的话，那 “Connection” 头字段的值会是 close。

【补充】

NGINX支持WebSocket。

对于NGINX将升级请求从客户端发送到后台服务器，必须明确设置Upgrade和Connection标题。

这也算是上面情况所非常常用的场景。

HTTP的Upgrade协议头机制用于将连接从HTTP连接升级到WebSocket连接，Upgrade机制使用了Upgrade协议头和Connection协议头。

为了让Nginx可以将来自客户端的Upgrade请求发送到后端服务器，Upgrade和Connection的头信息必须被显式的设置。

【注意】

在nginx的配置文件中，如果当前模块中没有proxy_set_header的设置，则会从上级别继承配置。

继承顺序为：http, server, location。

如果在下一层使用proxy_set_header修改了header的值，则所有的header值都可能会发生变化，之前继承的所有配置将会被丢弃。

所以，尽量在同一个地方进行proxy_set_header，否则可能会有别的问题。

·【参考】

Nginx中文官方文档： http://www.nginx.cn/doc/

测试参考文档： https://www.lijiaocn.com/问题/2019/05/08/nginx-ingress-keep-alive-not-work.html

keep-alive参考文档： https://wglee.org/2018/12/02/nginx-keepalive/

mysql命令行不再提醒警告

在Linux命令行里输入mysql 用户密码就会提示：

Warning: Using a password on the command line interface can be insecure.

即使我们用2>想给它重定向也无济于事。

有一个方法可以隐藏掉这个警告。

 mysql_config_editor set --user=root --socket=/tmp/mysql.sock --password

输入密码即可，这样就可以把密码保存到一个配置文件里 ~/.mylogin.cnf, 这个文件不能直接cat查看

以后再次使用mysql时，直接敲mysql命令即可完成登录。

搭建一个局域网http的yum源

mkdir /data/yumdata

mount /dev/cdrom /mnt/
cp /mnt/Packages/*rpm /data/yumdata

createrepo /data/yumdata/

createrepo --update /data/yumdata/

yum install epel-release
yum install nginx

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        root         /data/yumdata;
        autoindex on;

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

systemctl start nginx

cd /etc/yum.repos.d
mkdir bak
mv *.repo  bak/  //把系统自带的repo挪走
vim my.repo //内容如下

[aming]
name=myserver
baseurl=http://192.168.133.140
gpgcheck=0
enabled=1

rsync -av rsync://mirrors.ustc.edu.cn/centos/7/os/x86_64/Packages/  /data/yumdata/

yum  clean all   //删除缓存

Nginx代理tomcat https跳转到http

问题

网站采用了 Nginx 反向代理 Tomcat 的方式来负载均衡。

Nginx使用https，默认端口443。Tomcat使用http，端口8080

结果今天后台操作停留时间过长session超时后，跳转到登录页面时出现无法访问错误。如图：

分析

可以看到，出错的原因应该是跳转的时候加上了web默认80端口，而https默认的端口并不是80，所以导致无法访问。

后台无session时跳转代码：

1. requestURL = HttpUtils.encodeUrl(requestURL);
2. String path = request.getContextPath();
3. String basePath = request.getScheme() + "://" + request.getServerName() + ":" + request.getServerPort() + path
4. + "/";
5. return basePath + "user/login?goUrl=" + requestURL;

代码跳转的是绝对路径，包括schema和port，问题应该就在这里。

经过调试发现获取到的request.getScheme()总是http而非实际的https,相应的request.getServerPort()也就成了80。

端口是80而非Tomcat本身的8080说明获取到的确实是nginx转发过来的请求，那schema为什么得不到呢？

解决

通过查找资料，发现nginx请求转发时必须设置proxy_set_header才能让被代理的tomcat获取到正确的客户端ip等信息。

但是之前已经设置过nginx的proxy_set_header，而获取ip等也毫无问题：

1. proxy_set_header X-Real-IP $remote_addr;
2. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
3. proxy_set_header Host $http_host;
4. proxy_set_header X-Forwarded-Proto $scheme;
5. proxy_redirect http:// $scheme://;
6. proxy_pass http://localhost:8080;#转向tomcat处理

上面有一行设置了proxy_redirect，所以浏览器地址栏的schema仍然是https.

接着查找资料，发现要传递schema，在Tomcat端也需要相应配置。

1. <Engine>
2. <Valve className="org.apache.catalina.valves.RemoteIpValve"
3. remoteIpHeader="X-Forwarded-For"
4. protocolHeader="X-Forwarded-Proto"
5. protocolHeaderHttpsValue="https"/>
6. </Engine >

加上后，重启Tomcat，一切正常了！

这个命令你看得懂么

直接上命令

history 1 | { read x cmd; echo “$cmd”; }

对于read命令的了解，仅限于在shell脚本中使用read -p，对于这种用法从来没用过，更不知道它的含义。

今天抽空琢磨了一下，终于搞明白了来龙去脉。先来写几个命令吧：

# read a b c

1 2 3

# echo $a

1

# echo $b

2

# echo $c

3

# read x y

1 2 3

# echo $x

1

# echo $y

2 3

到这，也许你似乎看出一些门道了。read命令，后面跟的是变量名，可以是1个，也可以是多个，用空格分隔。回车后，输入的字符就是在给这些变量赋值，输入的字符串也需要用空格分隔，如果和上面的变量名一个一个地对应，那么这样就一个一个地赋值了。

如果没有对应呢？通过上面的命令也可以发现，如果值比变量多，它只对应前面的。例如，变量只有x和y，而值是1 2 3，则它把x赋值1，后面的2 3一股脑赋值给最后面的变量y。

再来一个例子吧。

# echo 1 2 3 4 5|read a b c

# echo $a

1

# echo $b

2

# echo $c

3 4 5

再回头看这条命令：

history 1 | { read x cmd; echo “$cmd”; }

管道前面，history 1表示取最后一条命令。管道后面'{ }’内是一整体，相当于一个函数，函数里面可以有多条命令，用分号分割，而且最后一条命令也必须加分号。第一条命令和'{‘之间必须要有空格。