WEBKT

Nginx Stream模块：TCP/UDP代理与负载均衡的实战精讲与配置指南

307 0 0 0

你知道吗？Nginx远不止是一个高性能的HTTP服务器或反向代理。在很多场景下，我们还会遇到需要处理非HTTP/HTTPS协议流量的需求，比如数据库连接、消息队列、自定义TCP服务等等。这时候，Nginx的Stream模块就派上大用场了。

Stream模块：Nginx的“瑞士军刀”延伸

在我看来，Stream模块是Nginx在传统HTTP处理能力之外，对底层网络协议处理能力的一次强大拓展。它允许Nginx作为通用的TCP/UDP代理服务器，这意味着你可以用它来：

  1. TCP/UDP服务代理：将客户端的TCP/UDP连接转发到后端服务器。
  2. TCP/UDP负载均衡：将TCP/UDP流量分发到多个后端服务器，实现高可用和性能扩展。
  3. 协议转换：虽然不直接进行协议内容的解析，但它能处理任何基于TCP/UDP的协议流量。

简单来说，Stream模块让Nginx不再局限于Web层，而是深入到更底层的网络传输层，为我们提供了统一的流量管理和分发能力。

如何启用Nginx Stream模块？

在使用Stream模块之前，你得确保Nginx在编译时包含了这个模块。通常情况下，如果你通过包管理器（如apt或yum）安装Nginx，它很可能已经默认编译进去了。不确定的话，可以通过nginx -V命令来检查输出中是否包含--with-stream。如果缺少，你就需要重新编译Nginx。

nginx -V
# 查找 --with-stream

Stream模块的基础配置结构

Stream模块的配置和http模块类似，它有一个独立的配置块，通常放在nginx.conf的events块之后、http块之前：

# ...其他全局配置

stream {
    # 这里是Stream模块的配置内容
    # 包含监听端口、代理规则、上游服务器组等
}

# ...http模块配置

核心功能一：TCP/UDP服务代理

最基本的用法是代理单个TCP或UDP服务。比如，你想把一个内网的MySQL数据库暴露给特定外部IP，或者只是简单地将某个端口的流量转发到另一台服务器的相同或不同端口。

场景举例：代理MySQL数据库

假设你的MySQL数据库运行在内网IP 192.168.1.100:3306，你想通过Nginx的3307端口代理它。

stream {
    server {
        listen 3307;
        proxy_pass 192.168.1.100:3306;
        # 开启proxy_protocol支持，如果后端需要获取真实客户端IP
        # proxy_protocol on;
    }
}

这里，listen 3307; 告诉Nginx在3307端口监听TCP连接（默认是TCP，如果要监听UDP，需要显式指定 listen 53 udp;）。proxy_pass 192.168.1.100:3306; 则将所有到达3307端口的连接转发到192.168.1.100的3306端口。是不是很直观？

核心功能二：TCP/UDP负载均衡

这是Stream模块的另一个强大之处。当你有多个提供相同服务的后端服务器时，你可以用Nginx将流量均衡地分发到这些服务器上。

场景举例：负载均衡Redis集群

假设你有一个Redis主从或集群，想通过Nginx进行负载均衡。

stream {
    upstream redis_backend {
        # 后端Redis服务器列表
        server 192.168.1.10:6379 weight=5;
        server 192.168.1.11:6379 weight=3;
        server 192.168.1.12:6379;
        # 这里可以配置健康检查，很重要！
        # health_check;
        # 比如：基于TCP连接的健康检查，每5秒检查一次，超时1秒，失败3次则认为宕机
        health_check interval=5s passes=1; # Nginx Plus 或 OpenResty 的 stream-healthcheck 模块支持更高级的检查
    }

    server {
        listen 63790;
        proxy_pass redis_backend;
        # 设置连接超时，防止连接长时间占用
        proxy_timeout 10s;
        # 连接建立后发送和接收的超时时间
        proxy_upload_timeout 10s;
        proxy_download_timeout 10s;
    }
}

在这个例子中：

  • upstream redis_backend 定义了一个后端服务器组，包含了三台Redis服务器。你可以为每台服务器设置weight（权重），权重越高的服务器接收到的连接越多。如果没有指定weight，默认为1。
  • server 块监听63790端口，并将所有流量转发给 redis_backend 这个上游组。
  • proxy_timeout、proxy_upload_timeout 和 proxy_download_timeout 用于控制连接超时，这在代理长连接服务时尤为重要。

负载均衡方法

upstream块支持多种负载均衡方法：

  • least_conn (最少连接数)：将请求分发给当前活跃连接数最少的服务器。对于长连接服务，这是个不错的选择。
  • hash $remote_addr (哈希)：根据客户端IP地址的哈希值来分配请求。这可以实现会话保持（session stickiness），确保来自同一客户端的请求总是转发到同一台后端服务器。但如果后端服务器宕机，哈希映射可能失效。
  • random (随机)：在组中的服务器之间随机分配请求。可以带least_time参数，优先选择响应时间最短的服务器。
  • round_robin (轮询，默认)：按顺序将请求分发给组中的每台服务器。这是默认的行为。

在upstream块内部，通过一行指令就能指定负载均衡方法，例如：

upstream my_service {
    least_conn;
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

健康检查（Health Check）

对于负载均衡来说，健康检查是不可或缺的。如果后端服务器宕机了，Nginx能自动将其从可用服务器列表中移除，避免将流量转发到不可用的服务器。

Nginx开源版对Stream模块的健康检查支持相对基础，主要通过proxy_connect_timeout来判断连接是否成功。如果你需要更高级的健康检查功能（例如HTTP GET请求、自定义脚本检查等），通常需要依赖Nginx Plus或OpenResty的stream-lua-nginx-module结合lua-resty-healthcheck等第三方模块来实现。

Nginx开源版的简单健康检查实践：

虽然Nginx开源版的stream模块没有像http模块那样自带丰富的健康检查指令（如health_check），但我们可以通过合理配置proxy_connect_timeout和后端服务器的max_fails、fail_timeout参数来间接实现连接级别的“健康检查”：

stream {
    upstream my_app {
        server 192.168.1.1:8080 max_fails=3 fail_timeout=30s;
        server 192.168.1.2:8080 max_fails=3 fail_timeout=30s;
    }

    server {
        listen 8000;
        proxy_pass my_app;
        # 连接后端服务器的超时时间
        proxy_connect_timeout 1s; # 如果1秒内无法建立连接，则认为失败
    }
}
  • max_fails=3: 在fail_timeout时间内，如果与后端服务器的连接尝试失败3次，则认为该服务器宕机。
  • fail_timeout=30s: 如果服务器被标记为宕机，30秒后Nginx会尝试重新连接它，以检查是否恢复。

高级配置项与注意事项

  • proxy_buffer: 缓冲来自客户端或后端的数据。对于高并发或大流量的场景，合理配置缓冲区大小能提高性能。proxy_buffer_size 和 proxy_buffers 决定了每个连接的缓冲区大小和数量。
  • proxy_timeout: 设置与后端服务器之间连接的超时时间，包括建立连接、发送数据、接收数据等阶段的超时。务必根据实际服务特性调整，避免客户端长时间等待或资源耗尽。
  • proxy_protocol: 这是一个非常实用的功能，当你使用Nginx作为透明代理或在负载均衡器之后需要获取客户端真实IP时非常有用。它允许Nginx向后端服务器发送一个包含客户端IP和端口信息的PROXY协议头。后端服务器（如HAProxy、Redis、MySQL等）需要支持并解析这个协议头。
    stream {
    server {
        listen 8888;
        proxy_pass 192.168.1.100:8000;
        proxy_protocol on; # 启用PROXY协议
    }
}
    后端服务器收到连接后，需要配置解析PROXY协议，例如HAProxy、Redis（通过proxy-protocol-enabled yes）或PostgreSQL。
  • proxy_bind: 允许Nginx绑定到特定的源IP地址或网卡接口与后端服务器建立连接。这在多网卡或需要特定路由规则的场景下很有用。
  • 日志记录: Stream模块也有自己的日志格式和访问日志配置，通过access_log和error_log指令可以方便地进行调试和监控。

我的经验与建议

我在实际工作中，Nginx Stream模块最常用的地方是代理一些内网服务，比如数据库、Kube-API Server、或者自定义的微服务网关。它特别擅长处理那些“不讲HTTP规矩”的纯TCP/UDP应用。

一个我经常遇到的坑是超时配置。如果proxy_timeout或proxy_connect_timeout设置得太短，当后端服务处理时间稍长时，连接就会被Nginx无情地掐断，导致客户端报错。反之，设置得太长又可能导致资源耗尽，拖垮Nginx自身。所以，一定要根据后端服务的SLA（服务等级协议）和预期响应时间来仔细调整。

另一个是健康检查。Nginx开源版的Stream模块自带的健康检查功能确实比较简陋，生产环境中如果你对后端服务的可用性要求极高，并且后端服务无法通过简单的TCP连接建立来判断健康状态（比如需要特定的应用层握手），我强烈建议考虑Nginx Plus或OpenResty生态中的高级健康检查模块。这些工具能提供更精细的、应用层面的健康检测，从而更准确地判断后端服务是否真正可用。

总而言之，Nginx的Stream模块是一个非常实用的工具，它扩展了Nginx的能力边界，让Nginx不仅是Web流量的调度者，也能成为底层TCP/UDP流量的强大管理者。掌握它，你的网络架构将更加灵活和健壮！

码农老王 NginxStream模块TCP/UDP代理

评论点评