在NAT中，UDP会话有两种不同的超时。
在大多数NAT配置中，UDP timeout设置为30 seconds。然而，UDP stream timeout被设置为180 seconds。我知道配置可能会被网络管理员更改。但是，UDP会话由一对源端点和目标端点标识。 NAT应该将连接分类为流。
我的问题是NAT如何以及何时将连接分类为流而不是什么时候？虽然看起来一对连续的双向send()和receive()将UDP连接分类为流，但我没有找到有证据的证据。
此外，我认为不同的NAT策略适用于不同的算法。但是有没有RFC或任何已发表的论文记录这些算法？
在下面的link流中定义为在两个方向上进行通信的会话。但是需要多少发送和接收？这在不同的NAT中有所不同吗？
在此上下文中，“流”表示连接跟踪机制已在“两个方向”看到数据包，因此默认超时更长。如果只看到一个方向，则应用“其他”超时。
通常，当LAN客户端将UDP数据报发送到WAN时，NAT将UDP流（也称为端口状态）与用于将数据报发送到WAN的端口相关联。当NAT在特定端口上从WAN接收UDP数据报时，它会查看是否存在与该端口关联的UDP流，如果是，则将数据报转发给关联LAN客户端。否则数据报将被删除。
当两个不同的LAN客户端想要通过WAN相互发送UDP数据报时，通常的做法是遍历他们的NAT是UDP hole punching：两个客户端开始从/向同一端口发送数据报，以便他们的NAT关联UDP流和开始转发数据报。