我想要从位于家用路由器后面的家用计算机 (192.168.0.2) 连接到 google.com（ping 返回 216.58.204.78）。192.168.0.2 打开本地 TCP 端口（例如 60000），然后通过我的路由器 NAT 向 216.58.204.78:80 发送一条消息，该端口被转换为 :60010。我知道对 192.168.0.2:60000 的回复实际上将发送到 :60010，我的路由器将使用 NAT 表将回复转发到 192.168.0.2。
我的问题是当该消息到达 Google 端时会发生什么。Google 路由器是否只使用端口 80 将消息发送到 Google 服务器，如果是，Google 服务器回复时会发生什么？服务器是否在其他端口上回复，然后在发送过程中进行转换，因此我的机器的进一步回复不再是端口 80，而是“面向公众”的端口？我有点不明白 Google 端在 NATing 方面发生了什么。
这种类型的 NAT 通常是有状态的，并跟踪连接或“流”。第一个数据包会导致转换状态被记住（例如，这样路由器就会知道要将回复发送到哪个内部地址），并且两个方向的所有后续数据包都会重新使用相同的映射，只要它们是同一流的一部分。
例如，在客户端，如果路由器已决定将源从 转换为
internal:60000，external:61000它将在整个连接期间始终如一地执行此操作，当然将使用相同的映射将传入的回复转发回 internal:60000。如果服务器位于 NAT 之后，情况也是如此：第一个入站数据包建立状态（在这种情况下根据静态“端口转发”规则），并且所有出站回复自动遵循相同的反向映射。
因此，如果第一个入站数据包是到
external:80并被转换为internal:8989，则来自internal:8989（到同一客户端地址：端口）的所有出站回复都将被 NAT 以显示为来自external:80- 源端口不会改变，因为映射已经建立。（话虽如此：不要假设服务器根本就位于 NAT 后面！在 Google 的规模下，它们很可能确实位于 NAT 后面，但是 Web 服务器拥有自己的公共 IP 地址而没有任何 NAT 也是很常见的。）
不。只有一种协议可以做到这一点 - TFTP - 而我见过的所有其他协议都将从与原始端口相同的端口进行回复。（这实际上意味着 NAT 必须专门识别 TFTP，有时 TFTP 无法通过 NAT 工作。）
（此外，您描述的方法显然是 TCP/IP 发明之前 ARPANET ICP 的工作方式，但实际上这不再重要了……）