搞不懂，我的手机没有公网IP，服务器响应报文如何被路由到手机？

五阳
3,730 阅读12分钟

6年前，在我刚毕业的时候，我困惑于一个问题：“我的手机和个人电脑等设备只有内网IP，而没有公网IP的情况下，公网服务器的响应IP报文如何被路由到我的内网设备呢？“

我知道：任何联网的设备都可以主动连接公网IP的服务器，因为公网IP是全球唯一分配的，IP层报文经过路由器的层层路由可以到达公网服务器。然而我实在想不通：公网服务器的响应报文该如何回来？

这个问题让我感到很困扰，我上学时学的计算机网络知识已经还给老师了，我尝试询问周围的同事，可惜没有人能给出一个可靠的答案。直到我了解到NAT（网络地址转换）技术，才最终解答了我的疑问。

NAT，即网络地址转换，是一种用于解决IP地址短缺问题的技术。它通过在内部网络和公共网络之间建立一个转换表，将多个内部私有IP地址映射为一个公共IP地址，实现多个设备共享一个公网IP地址的功能。

在科普 NAT 之前，有必要说明一下 内网IP。

0. 内网 IP 不能随意分配！

内网IP的分配是有规范的，不可以随意分配。如果内网IP和公网IP冲突，网络报文无法被路由器正确地路由。因为路由器不知道这个IP报文应该被路由到内网设备，还是路由到上一层网关（直至公网IP）。

为了避免冲突，IP协议中事先规定了三个网段作为内网IP的范围，分别是

  1. A类地址的 10.0.0.0 至 10.255.255.255
  2. B类地址的 172.16.0.0 至 172.31.255.255，
  3. C类地址的 192.168.0.0 至 192.168.255.255。

因此在一个局域网内，以上三个网段的设备都是内网设备，除此外基本（排除 127.0.0.1 等）都是公网设备。这样所有的IP地址都不会冲突！

在家用局域网中，通常使用的是 192.168.xxx.xxx 的格式；而在公司的机房中，由于设备数量庞大，一般会选择以 10.xxx.xxx.xxx 开头的网段。这是因为 192 开头的C类地址能够满足家用局域网设备数量的需求，而 10.xxx.xxx.xxx 网段可以适应大规模的公司机房环境，其中可能存在数以百万计的物理服务器，和数以千万计的虚拟机或者Docker实例。

1. 公网流量如何路由到内网设备

设想一下，内网IP为 192.168.100.100 的用户设备，请求到公网服务器。如果公网服务器收到的IP报文中，显示来源是 192.168.100.100。因为 192 开头的 IP 是内网地址，所以服务器响应用户请求时，就会错误地把请求路由到内网，无法正确路由到用户设备上！

所以…… 正确的显示来源是什么呢？

内网设备想要 “连通” 公网服务器，是需要路由器等网络设备层层转发的，正如下图而言，内网设备需要有公网IP的网络出口才能连通 到另一个公网设备。

image.png 因此，刚才问题答案是，内网IP报文到达公网机器时，来源应该被设置为 相应的 运营商公网出口IP。即公网出口网络设备要把IP来源改为自己。这样公网服务器收到请求报文后，对应的响应IP报文也会回复到用户端的公网出口IP。

看下图，用户端的IP报文到达运营商网络出口时，IP来源被替换为 运营商公网出口IP。下图中网络来源为 192 开头的内网Ip 地址，被替换为公网出口 IP（100.100.100.100）。像这种偷偷更换来源 IP 和目标 IP 的行为在 NAT 技术上很常见，后面会经常看到！

image.png

2. 公网机器发送响应报文时

当公网服务器响应时，IP 目标地址 是运营商公网出口而非用户的内网地址！然后运营商服务器会再次转发，转发前，运营商机器需要知道该转发给谁，转发给哪个用户设备。

如下图所示，用户端（192.168.100.100） 访问 公网地址（200.200.200.200）的IP 来源和目标被替换的过程。

image.png 首先公网机器响应给 运营商公网出口时。

第一步：来源 IP 是（200.200.200.200），目标IP 是（100.100.100.100）。

然后，运营商将 IP 报文转发给用户设备时，来源 IP 还是公网机器的 IP（200.200.200.200）不变化。然而目标 IP 修改为用户设备的 IP（192.168.xx.xx）。

对于用户设备而言，发送请求时目标IP 是公网机器，收到响应时来源 IP 还是公网机器。用户设备丝毫没有感觉到，在中间被路由转发的过程，目标和来源 IP 频繁被路由设备修改！

在这个环节，有一个关键问题：运营商收到公网机器的响应时，它怎么知道该路由给哪个用户设备！

3. NAT 如何进行地址映射

最简单的映射方式是：每一个内网 IP 都映射到一个运营商的公网IP。即内网 Ip 和运营商公网 IP 一对一映射！

这种方式很少见，用户设备和内网设备非常多，这样非常耗费公网IP，一般不会采用。

TCP 和 UDP 协议除基于 IP 地址外，还有端口，如果引入端口参与映射，则大大提高运营商公网 IP 的利用度！

一个 TCP 报文 包括如下参数：

  1. 用户 IP + 用户端口
  2. 公网 IP + 公网端口

这四个参数非常关键，相当于是 TCP 连接的唯一主键。当运营商收到公网机器的响应报文时，它可以拿到四个参数分别为：

运营商公网 IP + 端口 、目标机器公网 IP + 端口。其中关键的参数有三位：运营商公网端口，目标机器公网 IP 和端口。

为什么运营商公网 IP 不关键呢？因为根据 IP 路由协议，响应报文已经被路由到该机器，每一个运营商公网出口都会维护一套单独的 映射表 ，所以自己的 IP 地址不关键。

当前的难点是：如何根据 运营商公网端口，目标机器公网 IP 和 端口 三个参数，映射到 用户 IP 和端口的问题。

用户请求时，会建立映射表。当收到用户请求时，运营商服务器的 NAT 模块会分配一个端口供本次请求使用，建立一个映射项：运营商机器端口 + 目标公网 IP + 目标公网端口 这三个参数映射到 用户 IP 和用户端口

例如下表

NAT 映射表运营商机器端口目标公网 IP目标公网端口用户 IP用户端口
1300200.200.200.20080192.168.22.226000
2
3

在运营商机器转发IP报文时，除替换IP外，也会替换端口。相比NAT 一比一映射IP地址，增加端口映射，可以大大提高运营商公网 IP 的利用度。接下来有个问题？

每个机器的端口最大数为 65535，说明每个运营商机器最多 同时支持转发 65535 个请求?

这个推论不成立。

从上面的映射表可以看到，运营商机器收到响应报文时，会根据 三个关键参数 进行映射，而非只根据 自身端口映射。以上面 NAT 映射表的第一条记录为例，运营商机器的 300 端口，并非仅仅服务于 200.200.200.200 这次请求。300 端口还可以同时服务 250.250.250.250 + 80 端口，以及其他连接！

由于映射的参数有三个，而不仅仅是运营商端口一项，因此并发程度非常高。

理论的最大并发度应该是 65535 * （公网 IP 数）* 65535，这个并发度非常高。 一个运营商机器似乎支持海量的NAT连接，实际上，并非海量。

因为常用的 Http 协议端口是 80，目标公网机器的端口数常用的基本是 80 端口。

其次用户常用的软件非常集中，例如微信、抖音、稀土掘金等，访问的公网 IP 也集中于这些公司的 IP 地址。

所以基于此，最高并发度变为：65535 * 常用的公网 IP数 * 有限的端口数（80、443）。

这个并发度并非海量，但是基本上足够使用了，一个小区或办公区的网络设备数量不会过于庞大。65535 * 有限的公网 IP数 * 有限的端口数，这样的并发度足够支持一般场景使用。

除非出现极端的情况！ 即一个小区的大量用户集中访问于一个公网 IP 的 80 端口，这样网络流量一定会发生拥塞！在某些用户流量集中的区域，可以安排更多的 NAT 设备，提供更多的公网 IP。

一个小区一个公网 IP 吗？

根据 chatgpt 的回答，通常情况下，一个小区只有一个公网 IP。 image.png

上大学时，偶然了解到 SQL注入，我感觉很新奇。后来对一个兼职网站进行 SQL 注入的尝试。经过几次尝试后，我发现无法再访问这个网站。宿舍和其他几个宿舍的同学也无法访问此网站。我不禁得意洋洋，难道是因为我的攻击导致了这个网站的崩溃？

后来我找到其他大学的高中同学，让他们访问这个网站，他们访问是没问题的。那时我明白了，这个网站只是封掉了我们学校的公网 IP，或者是这栋男生宿舍楼的公网 IP ，它并没有崩溃！

个人经验来看，一个小区或者办公楼会根据实际的需要安排一定数量的公网 IP，一般情况下共用一个公网 IP。

总结

当 公网 IP 不够用时，可通过 NAT 协议实现多个用户设备共享同一个公网 IP，提高 公网IP 地址的利用度。Ipv4 的地址数量有限，在 2011 年已经被分配完，未来如果全面实现了 ipv6 协议，我们手机等终端设备也可能会有一个公网 IP。

但是公网 Ip 全球都可以访问，与此对应的网络安全问题不可忽视。NAT 技术则可以有效保护用户设备，让用户安全上网，这也是它附带的好处。

如果看完有所收获，感谢点赞支持！

我的开源项目

最后夹带一点私货，五阳最近花了3个月的时间完成一个开源项目。

开源3周以来，已有近 230 多个关注和Fork

Gitee：gitee.com/juejinwuyan…

GitHub github.com/juejin-wuya…

开源平台上有很多在线商城系统，功能很全，很完善，关注者众多，然而实际业务场景非常复杂和多样化，开源的在线商城系统很难完全匹配实际业务，广泛的痛点是

  • 功能堆砌，大部分功能用不上，需要大量裁剪；
  • 逻辑差异点较多，需要大量修改；
  • 功能之间耦合，难以独立替换某个功能。

由于技术中间件功能诉求较为一致，使用者无需过多定制化，技术中间件开源项目以上的痛点不明显，然而电商交易等业务系统虽然通用性较多，但各行业各产品的业务差异化极大，所以导致以上痛点比较明显

所以我在思考，有没有一个开源系统，能提供电商交易的基础能力，能让开发者搭积木的方式，快速搭建一个完全契合自己业务的新系统呢？

  • 他们可以通过编排和配置选择自己需要的功能，而无需在一个现成的开源系统上进行裁剪
  • 他们可以轻松的新增扩展业务的差异化逻辑，不需要阅读然后修改原有的系统代码！
  • 他们可以轻松的替换掉他们认为垃圾的、多余的系统组件，而不需要考虑其他功能是否会收到影响

开发者们，可以择需选择需要的能力组件，组件中差异化的部分有插件扩展点能轻松扩展。或者能支持开发者快速的重新写一个完全适合自己的新组件然后编排注册到系统中？

memberclub 就是基于这样的想法而设计的。 它的定位是电商类交易系统工具箱， 以SDK方式对外提供通用的交易能力，能让开发者像搭积木方式，从0到1，快速构建一个新的电商交易系统！

image.png

具体介绍可参见

Gitee开源地址：gitee.com/juejinwuyan…

GitHub开源地址 : github.com/juejin-wuya…

在这个项目中你可以学习到 SpringBoot 集成 以下框架或组件。

  1. Mybatis、Mybatis-plus 集成多数据源
  2. Sharding-jdbc 多数据源分库分表
  3. redis/redisson 缓存
  4. Apollo 分布式配置中心
  5. Spring Cloud 微服务全家桶
  6. RabbitMq 消息队列
  7. H2 内存数据库
  8. Swagger + Lombok + MapStruct

同时你也可以学习到以下组件的实现原理

  1. 流程引擎的实现原理
  2. 扩展点引擎实现原理
  3. 分布式重试组件实现原理
  4. 通用日志组件实现原理 参考：juejin.cn/post/740727…
  5. 商品库存实现原理： 参考：juejin.cn/post/731377…
  6. 分布式锁组件： 参考：
  7. Redis Lua的使用
  8. Spring 上下文工具类 参考： juejin.cn/post/746927…
avatar
文章
阅读
粉丝