MikeWang000000
求教tcp判断NAT类型的理论依据是什么？
关于 UDP，RFC3489 中有配有流程图： https://www.rfc-editor.org/rfc/rfc3489#page-22
RFC 中确实没有对 TCP 进行分类，并且在 RFC5389 中废弃了原定的 UDP 分类。
Furthermore, classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.
所以 Natter 的 TCP NAT 分类，是根据原先 RFC3489 中对 UDP 的 NAT 分类，类推而来的。 TCP 可以和 UDP 一样按 “包” 分析。将 TCP 的每个 “包” 的行为与 RFC 上的情况对应即可。
关于 UDP，RFC3489 中有配有流程图： https://www.rfc-editor.org/rfc/rfc3489#page-22
RFC 中确实没有对 TCP 进行分类，并且在 RFC5389 中废弃了原定的 UDP 分类。
Furthermore, classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.
所以 Natter 的 TCP NAT 分类，是根据原先 RFC3489 中对 UDP 的 NAT 分类，类推而来的。 TCP 可以和 UDP 一样按 “包” 分析。将 TCP 的每个 “包” 的行为与 RFC 上的情况对应即可。
理论上TCP的NAT分类和UDP的NAT分类应该保持一致，但是一些场景下出现不一致的情况。比如TCP_NAT结果是NAT3 (port_restricted)而UDP_NAT结果是NAT4(symmtric)。是不是表明无法直接通过类推UDP的方式来进行TCP检测？
理论上TCP的NAT分类和UDP的NAT分类应该保持一致，但是一些场景下出现不一致的情况。
理论上 TCP 和 UDP 的 NAT 情况会出现不一致。例如 OpenWRT 中常用的一个内核模块 Chion82/netfilter-full-cone-nat ，这个模块只实现了 UDP 的 Fullcone NAT，那么检测 TCP 结果就是 NAT 3，UDP 为 NAT 1。
同样的，ISP 处的 CGNAT 也会有类似情形。如果怀疑检测结果不准，可以用 stunclient 等工具手动测试。