AWS NLB处理gRPC流式连接的底层机制及连接超时疑问

核心逻辑：NLB的TCP连接超时机制 #

NLB是四层（TCP/UDP）负载均衡，它的连接管理完全基于TCP会话。默认情况下，NLB会为每条TCP连接设置350秒的超时窗口（可通过AWS控制台或CLI调整至最大4000秒）——如果连接在这段时间内没有任何数据包传输，NLB会主动终止连接并清理自身的连接跟踪记录。

gRPC流式连接的适配矛盾 #

gRPC流式连接依赖长期存活的TCP连接来持续传输数据，但如果流式传输出现空闲间隙（比如业务上暂时没有数据发送），就会触发NLB的超时逻辑。这里需要注意：gRPC基于HTTP/2协议，HTTP/2本身支持PING帧保活，但需要客户端或服务端主动配置发送PING，才能让NLB检测到连接活性，重置超时倒计时。

NLB处理超时连接的底层流程 #

• NLB会维护一张连接跟踪表，记录每条TCP连接的源/目标IP端口、超时倒计时等关键信息。
• 只要连接上有数据包传输（包括gRPC的流式数据、HTTP/2的控制帧如PING），NLB就会立即重置该连接的超时倒计时。
• 当倒计时归零时，NLB会先向客户端和后端服务器发送TCP FIN包，尝试优雅终止连接；如果FIN包未得到响应，后续会发送RST包强制断开。
• 连接终止后，NLB会删除对应连接跟踪表条目，释放占用的资源。

适配gRPC长连接的可行方案 #

• 配置gRPC客户端/服务端的HTTP/2保活：定期发送PING帧（比如每300秒一次），确保在NLB超时窗口内有数据包流转，避免超时触发。
• 调整NLB的TCP超时时间：根据业务需求将超时值调至合理范围（最大4000秒），但需注意过长的超时会增加NLB的连接跟踪资源消耗，需权衡资源成本。

内容的提问来源于stack exchange，提问作者Ronaldo Lanhellas