nginx使用长连接代理grpc流量

nginx使用长连接代理grpc流量

Nginx在1.13.10版本支持了对grpc流量的反向代理，恰好业务有需求，要在sidecar容器中代理grpc流量。因此参考 指引文档进行了配置。但是并未如预期般顺利运行，按照示例配置后，nginx与后端的grpc服务并非长连接，导致了一系列问题，在此做个记录，也给有需要的读者做一个参考，对具体过程不感兴趣的可直接跳到最后查看完整配置。

踩坑过程

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent"';
    server {
        listen 80 http2;
 
        access_log logs/access.log main;
 
        location / {
            grpc_pass grpc://localhost:8500;
        }
    }
}

如上为官方实例中的转发配置，配置并重启nginx后，简单调用时没有遇到问题。但是在后续的压测环境中发现会出现偶发的Stream removed错误（如下图所示）。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tdl1OL1S-1665312857898)(https://raw.githubusercontent.com/enjoyliu/pic/main/202210091746665.png)]

分析HTTP2协议得知Stream即http2的一个请求，多个stream复用会同一个TCP连接，由此猜测应该是在压测的过程中，TCP连接发生了中断，因此进入nginx容器内部查看通过netstat查看连接情况，果然发现出现了大量的TIME_WAIT连接（如下图所示）。关于TIME_WAIT的含义，可参考https://draveness.me/whys-the-design-tcp-time-wait/

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ek1iZbzX-1665312857900)(https://raw.githubusercontent.com/enjoyliu/pic/main/202210091746387.png)]

查询资料后发现发现在nginx的默认配置下，grpc与后端并不会使用连接复用，查阅相关资料后发现是没有配置keepalive相关参数导致的，keepalive用于配置与后端和客户端的连接保持，参数的具体含义参照官方说明或下文的配置注释。

http {
  	# 与客户端的连接配置
    keepalive 2000;  # 允许的空闲连接数
    keepalive_timeout 75s; # 超时时间，超时后连接关闭
    keepalive_requests 4294967295; # 单连接处理最大请求次数，超过后连接关闭
  	
   # 与后端服务的连接配置
    upstream grpc_server {
        server localhost:8500 max_fails=2 ; # placeholder
        keepalive 2000;  # 允许的空闲连接数
        keepalive_timeout 75s; # 超时时间，超时后连接关闭
        keepalive_requests 4294967295; # 单连接处理最大请求次数，超过后连接关闭
    }
    server {
          listen 80 http2;

          access_log logs/access.log main;

          location / {
              grpc_pass grpc://grpc_server;
          }
     }
}

按照上述配置配置对应的keepalive参数后，可以看到TCP连接数大大下降，同时TIME_WAIT也大量减少，但是在压测过程中中，发现 Stream removed错误出现的概率有明显下降但仍然存在，同时注意到请求错误出现的时间与出现TIME_WAIT连接的时间高度同步，怀疑还是连接保持相关的问题。

搜索相关资料无果后，想到网关侧的nginx-ingress-gateway并未出现类似问题，于是查看了nginx-ingress中的nginx默认配置 ，在对比连接保持相关的参数后，注意到了 reset_timedout_connection，默认是关闭状态，开启后会跳过TCP的TIME_WAIT的状态，直接释放连接相关资源。结合之前注意到的请求失败的时间与TIME_WAIT出现的尝试加上该配置后，再次压测服务，最终没有再出现类似问题。

问题最终得到了解决，笔者认为这里大致是因为在TIME_WAIT状态下，客户端仍然会有请求发送到nginx，但nginx不会再转发到后端，导致了该问题，如果有对nginx更为熟悉的读者，也希望可以在此解惑。

最终配置

问题得到解决后，可以通过长连接稳定代理grpc流量的nginx配置如下（略去了很多非连接相关配置），供大家参考：

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent"';
 		# 与客户端的连接配置
    keepalive 2000;  # 允许的空闲连接数
    keepalive_timeout 75s; # 超时时间，超时后连接关闭
    keepalive_requests 4294967295; # 单连接处理最大请求次数，超过后连接关闭
    reset_timedout_connection on;  # 重置超时连接、跳过time_wait
  
    upstream grpc_server {
        server localhost:8500 max_fails=2 ; # placeholder
        keepalive 2000;  # 允许的空闲连接数
        keepalive_timeout 75s; # 超时时间，超时后连接关闭
        keepalive_requests 4294967295; # 单连接处理最大请求次数，超过后连接关闭
    }
  
    server {
        listen 80 http2;
 
        access_log logs/access.log main;
 
        location / {
            grpc_pass grpc://grpc_server;
        }
    }
}

参考资料

1. https://www.nginx.com/blog/nginx-1-13-10-grpc/
2. http://nginx.org/en/docs/http/ngx_http_upstream_module.html
3. http://nginx.org/en/docs/http/ngx_http_core_module.html
4. https://draveness.me/whys-the-design-tcp-time-wait/
5. https://web.dev/performance-http2/#streams,-messages,-and-frames