10-四层/七层代理实战适配安卓工控设备长连接、心跳上报场景一、四层代理 vs 七层代理OSI模型视角网络分层这块七层模型OSI大家应该都背过物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。Nginx 代理主要涉及第四层传输层和第七层应用层。四层代理L4工作在传输层只看 TCP/UDP 端口和IP地址不关心应用层协议内容。Nginx 中由stream模块实现。七层代理L7工作在应用层能解析 HTTP/HTTPS/WebSocket 等协议头可以根据 URL、Header、Cookie 做路由决策。Nginx 中由http模块实现。用一个通俗的比喻来区分四层代理 快递分拣中心只看包裹上的地址标签IP端口不拆包裹七层代理 海关检查要把包裹打开看里面的东西HTTP请求头、URL再决定怎么处理对比项四层代理stream七层代理http工作层级传输层TCP/UDP应用层HTTP/HTTPS性能更高不解析协议内容稍低需要解析HTTP头路由能力仅IP端口URL/Header/Cookie维度适用协议任意TCP/UDP协议HTTP/HTTPS/WebSocket典型场景数据库代理、MQTT、自定义TCP协议Web服务、API网关、静态资源二、安卓工控设备的长连接需求我们的无人售货柜使用瑞芯微RK3568主板跑的是定制版安卓系统。每台售货柜需要和后端保持长连接用于心跳上报设备每30秒上报一次状态温度、库存、门禁状态实时指令下发后台远程开门、补货指令、价格变更交易数据同步用户开门取货后的结算数据上传通信协议有三种选择MQTT物联网标准协议轻量级适合低带宽场景WebSocket基于HTTP升级适合Web端实时通信自定义TCP协议性能最高但需要自己处理粘包/拆包售货柜场景用的是 MQTT 自定义TCP协议混合方案MQTT 做心跳和指令推送自定义TCP协议做大文件传输固件升级包。三、stream 模块四层代理配置实战首先确认 Nginx 编译时包含了 stream 模块nginx-V21|grepstream如果没有需要在编译时加上--with-stream参数。MQTT 负载均衡配置# nginx.conf 主配置文件 # stream 模块必须写在 http 块外面和 http 平级 stream { # MQTT 后端服务器集群 upstream mqtt_backend { server 192.168.1.201:1883 max_fails3 fail_timeout30s; server 192.168.1.202:1883 max_fails3 fail_timeout30s; server 192.168.1.203:1883 max_fails3 fail_timeout30s; # least_conn; # MQTT长连接适合用最少连接策略 } # MQTT TCP 代理 server { listen 1883; proxy_pass mqtt_backend; proxy_connect_timeout 5s; proxy_timeout 300s; # MQTT长连接保活超时5分钟无数据断开 } # MQTT over TLS加密通道 server { listen 8883 ssl; ssl_certificate /etc/nginx/ssl/mqtt.pem; ssl_certificate_key /etc/nginx/ssl/mqtt.key; proxy_pass mqtt_backend; proxy_connect_timeout 5s; proxy_timeout 300s; } }关键参数说明proxy_timeout 300s这个参数很重要。MQTT 是长连接设备连上后要一直保持如果超时设置太短设备会被频繁断开重连浪费资源。设成5分钟配合 MQTT 自身的 KeepAlive 心跳机制足够保持连接稳定。least_connMQTT 长连接场景下轮询策略会导致连接数不均匀——先启动的节点连的设备多后启动的节点连的少。用least_conn确保连接数均衡分配。自定义TCP协议代理固件升级用的自定义TCP协议传输大文件需要更大的超时时间stream { upstream firmware_upload_backend { server 192.168.1.201:9000; server 192.168.1.202:9000; } server { listen 9000; proxy_pass firmware_upload_backend; proxy_connect_timeout 10s; proxy_timeout 3600s; # 固件包可能几百MB给1小时超时 # 代理缓冲区调大提升传输性能 proxy_buffer_size 64k; } }四、七层 WebSocket 代理配置WebSocket 虽然是基于HTTP升级的但在 Nginx 的http模块中配置。后台管理系统的实时大屏需要 WebSocket 推送设备状态配置如下http { upstream websocket_backend { server 192.168.1.201:8082; server 192.168.1.202:8082; ip_hash; # WebSocket长连接用ip_hash保持会话 } server { listen 443 ssl; server_name ws.vending.com; ssl_certificate /etc/nginx/ssl/vending.pem; ssl_certificate_key /etc/nginx/ssl/vending.key; location /ws/device-status { proxy_pass http://websocket_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # WebSocket长连接超时配置 proxy_read_timeout 3600s; proxy_send_timeout 3600s; } } }WebSocket 代理的三个关键配置proxy_http_version 1.1WebSocket 协议要求 HTTP/1.1默认 Nginx 用 HTTP/1.0 代理后端必须手动切换。UpgradeConnection头这是 HTTP 协议升级到 WebSocket 的握手关键告诉后端我要把连接升级成 WebSocket。proxy_read_timeout 3600sWebSocket 连接建立后如果没有数据传输Nginx 默认60秒就断开。后台大屏可能几分钟才有一次数据更新必须加大超时。五、设备心跳上报完整转发方案整理一下售货柜设备从上线到心跳的完整链路售货柜设备(安卓工控机) │ ├── MQTT:1883 ──────────► Nginx(stream四层代理) ──► EMQX集群 │ 心跳上报 指令下发 │ ├── TCP:9000 ──────────► Nginx(stream四层代理) ──► 固件升级服务 │ 大文件传输 │ └── HTTPS:443 /ws/ ────► Nginx(http七层代理) ──► WebSocket服务 后台实时大屏对应的 Nginx 完整配置结构# /etc/nginx/nginx.conf # 四层代理设备端通信 stream { include /etc/nginx/stream.d/*.conf; } # 七层代理Web端API WebSocket http { include /etc/nginx/conf.d/*.conf; }stream.d/mqtt.confupstream mqtt_cluster { least_conn; server 192.168.1.201:1883 max_fails3 fail_timeout30s; server 192.168.1.202:1883 max_fails3 fail_timeout30s; server 192.168.1.203:1883 max_fails3 fail_timeout30s; } server { listen 1883; proxy_pass mqtt_cluster; proxy_connect_timeout 5s; proxy_timeout 300s; }六、四层健康检查stream 模块的健康检查和 http 模块类似但有个额外的问题四层代理不解析协议内容只能做TCP连接层面的探测。upstream mqtt_cluster { server 192.168.1.201:1883 max_fails3 fail_timeout30s; server 192.168.1.202:1883 max_fails3 fail_timeout30s; server 192.168.1.203:1883 max_fails3 fail_timeout30s; }被动健康检查的逻辑Nginx 尝试建立 TCP 连接如果连接失败就算一次fail3次失败后标记节点为不可用30秒后重试。但这有个缺陷——TCP端口能连上不代表 MQTT 服务正常可能 EMQX 进程假死但端口还在监听。如果需要主动健康检查需要编译安装nginx_upstream_check_moduleupstream mqtt_cluster { server 192.168.1.201:1883; server 192.168.1.202:1883; check interval3000 rise2 fall3 timeout2000 typetcp; }interval3000每3秒检查一次rise2连续成功2次才标记为健康fall3连续失败3次才标记为故障typetcp检查类型TCP连接级别七、四层还是七层选择指南最后给个决策参考MQTT、自定义TCP协议→ 四层代理stream七层根本解析不了WebSocket→ 七层代理http需要处理HTTP升级握手普通HTTP API→ 七层代理需要URL路由能力追求极致性能的HTTP→ 可以用四层代理但会丧失所有七层功能售货柜项目里设备端走四层MQTT/TCP管理端走七层HTTP/WebSocket各取所长。