浏览 3.1k
测试方法:
在两台机器上启动iperf,并通过NGINX转发请求。
A机器:以客户端模式启动Iperf。客户端以TCP方式连接至本机的NGINX,NGINX将该连接转换为TLS方式,并填入SNI字段,之后转发至NGINX配置中指定的地址;
B机器:以服务端模式启动Iperf。NGINX接收到来自A机器的请求后,根据请求中的SNI字段和配置文件中的转发关系,将流量转发至对应的Iperf服务端。
NGINX配置
1.Iperf客户端一侧NGINX配置如下:
worker_processes 8;
pid /home/test-machine/.local/nginx.pid;
events {
worker_connections 1024;
}
stream {
# For task 1:
server {
listen 1313 reuseport;
ssl_protocols TLSv1.3 TLSv1.2 TLSv1.1;
proxy_pass 192.168.23.169:8185;
proxy_ssl on;
proxy_ssl_server_name on;
proxy_ssl_name task_1_server_0;
ssl_certificate /home/test-machine/nginx-cfg/cert/server1.crt;
ssl_certificate_key /home/test-machine/nginx-cfg/cert/server1.key;
}
server {
listen 1314 reuseport;
ssl_protocols TLSv1.3 TLSv1.2 TLSv1.1;
proxy_pass 192.168.23.169:8185;
proxy_ssl on;
proxy_ssl_server_name on;
proxy_ssl_name task_1_server_1;
ssl_certificate /home/test-machine/nginx-cfg/cert/server1.crt;
ssl_certificate_key /home/test-machine/nginx-cfg/cert/server1.key;
}
# End.
# For task 2:
server {
listen 2313 reuseport;
ssl_protocols TLSv1.3 TLSv1.2 TLSv1.1;
proxy_pass 192.168.23.169:8185;
proxy_ssl on;
proxy_ssl_server_name on;
proxy_ssl_name task_2_server_0;
ssl_certificate /home/test-machine/nginx-cfg/cert/server1.crt;
ssl_certificate_key /home/test-machine/nginx-cfg/cert/server1.key;
}
server {
listen 2314 reuseport;
ssl_protocols TLSv1.3 TLSv1.2 TLSv1.1;
proxy_pass 192.168.23.169:8185;
proxy_ssl on;
proxy_ssl_server_name on;
proxy_ssl_name task_2_server_1;
ssl_certificate /home/test-machine/nginx-cfg/cert/server1.crt;
ssl_certificate_key /home/test-machine/nginx-cfg/cert/server1.key;
}
# End.
error_log /home/test-machine/.local/logs/error.log error;
}
2.Iperf服务端一侧NGINX配置如下:
worker_processes 8;
pid /home/test-machine/.local/nginx.pid;
events {
worker_connections 1024;
multi_accept on;
}
stream {
# For task 1:
upstream tcp_task_1_server_0 {
server 127.0.0.1:1313;
}
upstream tcp_task_1_server_1 {
server 127.0.0.1:1314;
}
# End.
# For task 2:
upstream tcp_task_2_server_0 {
server 127.0.0.1:2313;
}
upstream tcp_task_2_server_1 {
server 127.0.0.1:2314;
}
# End.
server {
listen 8185 ssl;
ssl_protocols TLSv1.3 TLSv1.2 TLSv1.1;
ssl_certificate /home/test-machine/nginx-cfg/cert/server1.crt;
ssl_certificate_key /home/test-machine/nginx-cfg/cert/server1.key;
proxy_pass $stream_map;
ssl_session_cache shared:SSL:10m;
#ssl_preread on;
}
map $ssl_server_name $stream_map {
# For task 1:
task_1_server_0 127.0.0.1:1313;
task_1_server_1 127.0.0.1:1314;
# End.
# For task 2:
task_2_server_0 127.0.0.1:2313;
task_2_server_1 127.0.0.1:2314;
# End.
}
error_log /home/test-machine/.local/logs/error.log debug;
}
Iperf执行命令
1.Iperf客户端一侧执行命令如下:
iperf3 -c 127.0.0.1 -p 1313
iperf3 -c 127.0.0.1 -p 1314
iperf3 -c 127.0.0.1 -p 2313
iperf3 -c 127.0.0.1 -p 2314
2.Iperf服务端一侧执行命令如下:
iperf3 -s -p 1313
iperf3 -s -p 1314
iperf3 -s -p 2313
iperf3 -s -p 2314
问题描述:
当以上多组任务同时进行时,NGINX会出现转发错误的情况,如:当服务端的NGINX接收到SNI值为task_2_server_0的流量时,该请求应该被NGINX转发至127.0.0.1:2313,但是实际情况是该请求在某些时候会被NGINX错误地转发至127.0.0.1:1313,并且该错误只有在NGINX转发某一客户端启动后的第一次通信时才会出现。请问该问题是因为什么?

按点赞数排序
按时间排序
sticky模块只能在linux下吧,win下没有。tomcat好像有个session复制吧,或者可以用共享session。
没办法完全不受影响的,因为mirror是子请求,当子请求未结束时,主请求消耗的内存至少是无法释放的。你可以尝试在/mirror里,把超时时间大幅度调低,包括connect/read/send,再压下看看。
微信公众号
加入微信群