1 云平台内核：网络要理解什么
订单 API 已经部署成功，实例也显示健康，但顾客偶尔在付款后等不到结果。应用日志只留下超时，数据库却可能已经写入订单。此时，“网络不通”只是现象：请求可能尚未进入实例，也可能到达实例后，响应在返回途中消失。云网络内核这一课要建立的能力，是把这些可能性放回真实路径，知道应向哪个位置索取证据。
这里的“内核”指支撑云网络行为的底层机制，不意味着所有工作都由操作系统内核执行。虚拟交换、隧道、状态跟踪、转发规则和硬件卸载可以共同参与。入门阶段先抓住数据包经过的边界、边界保存的状态，以及边界允许通过的大小和速率。至于具体平台把规则放在什么模块、如何编译转发表，留到后续深入学习。
以部署在私有子网的订单 API 为例：公网用户先访问入口负载均衡，入口将请求转给服务实例，实例再连接数据库。实例还要访问公网支付接口，这通常经过出口网关。用户身份令牌由应用或入口验证，实例访问数据库凭据由身份系统管理；这些身份关系不会替代网络可达性，网络可达也不代表调用已经得到授权。
控制面负责接收“创建子网、绑定安全组、配置路由”等意图，并把它们变成转发设备使用的规则。数据面处理实际到来的包。控制台显示配置成功，只能说明某个管理步骤完成，不能单独证明所有转发节点已经应用新规则。因此排查时既要保留配置版本，也要检查实际流量经过的节点和时间。
可以把每次调用拆成几类问题：目的地址如何找到，租户如何隔离，策略是否允许，包是否能装进下一段链路，途中是否有足够状态和处理能力，以及响应是否能回来。后面的 Underlay、Overlay、NAT、MTU 和连接跟踪分别回答其中部分问题。它们组合起来，才形成应用看到的网络服务。
图中的每个边界都值得留下观测点。应用记录请求标识、耗时和结果；平台记录连接、流量、丢弃原因和网关状态。请求标识通常不会直接出现在网络层流记录中，需要借助时间、源地址、目的地址、端口和协议关联。经过 NAT 后地址发生变化，还要补上转换关系，才能把应用故障与底层事件连接起来。
2 Underlay、Overlay 与网关
Underlay 是承载网络流量的底层网络，可以包含宿主机的物理网卡、交换机和路由设备。它需要保证宿主机之间可以通信。Overlay 是建立在这张网络上的逻辑网络，用于表达租户的地址空间、隔离关系和转发规则。同样是 10.0.1.8，可能分别属于不同租户；仅靠这个地址，底层网络无法判断它属于谁。
常见做法是封装：将租户原来的包作为内层，再加上外层地址和隧道标识。外层回答“送到哪台承载设备”，隧道标识帮助接收端识别逻辑网络，内层保留应用所理解的源地址和目的地址。VXLAN 是常见封装方式，但这一课不要求记住报文字段。关键在于，底层看到的地址和实例看到的地址可能不同。
假设订单 API 实例位于宿主机 A，数据库实例位于宿主机 B。源端先依据虚拟网络规则判断目标位置，再封装并交给底层网络。目的端收到外层包后解封装，将内层包交给正确的虚拟接口。实际平台也可能采用不需要这类隧道的路由方案；应根据平台说明识别路径，不能把封装当成所有云网络的固定实现。
网关负责连接不同的网络范围，例如不同子网、私有网络与公网。它可能执行路由、策略检查或地址转换，但“网关”并不自动意味着同时执行全部功能。公网入口负载均衡、私网路由出口和 NAT 网关也不必是同个组件。画路径时应写明每个节点承担的功能，否则遇到问题容易向错误的设备查询日志。
租户能够配置的路由表通常表达逻辑下一跳，不一定展示底层经过的交换机。实例内运行 traceroute，也可能因为隧道隐藏、设备不回应或策略限制，看不到完整路径。看不到中间跳不等于中间没有网络，看见某跳不回应也不能直接证明它丢弃业务流量。应结合端到端结果和平台侧证据判断。
封装还引入额外字节和处理工作。内层包原本能通过实例接口，加上外层头后，却可能超过底层链路允许的大小。这是本课案例的起点。理解双层视角还有另个好处：抓包时知道自己正在看租户地址还是宿主机地址，避免拿内层目的地址去解释外层路由，也避免把底层连通误当成租户策略正确。
3 限速、连接跟踪与 NAT
网络资源并非只有“通”和“不通”。平台可能按实例、虚拟接口、租户或网关限制带宽，也可能限制每秒包数、每秒新建连接数或并发连接数。这些指标约束不同资源：大文件更容易消耗带宽，大量小包可能先碰到包处理上限，频繁建立短连接则可能先耗尽连接创建能力。只盯着 Mbps，可能完全看不到瓶颈。
限速常用令牌桶作入门解释：令牌以固定速率补充，桶容量允许短时突发。发送数据需要消耗令牌，令牌不足时，系统可能排队、延迟或丢弃，具体取决于实现。桶的突发容量不能变成长期免费带宽。对订单 API 而言，营销活动开始时的瞬时请求可能尚未拉高分钟平均带宽，却已经造成排队和尾延迟。
连接跟踪通常称为 conntrack。它保存某条流的状态，使设备能够识别后续包与返回包的关系。常见流标识包含源地址、目的地址、源端口、目的端口和协议，也称五元组；在多租户环境还需要网络范围等上下文。这里的“连接”是设备维护的流状态，UDP 虽然没有 TCP 握手，也可能占用带有超时的跟踪条目。
有状态策略可以允许已经获准建立的流量返回，而不必让用户为每个临时端口编写返回规则。代价是设备需要保存、查找和回收状态。应用关闭连接，并不保证各个中间设备立即释放条目；设备可能继续等待报文或超时。如果观察到活跃业务连接已经下降、状态表占用仍然很高，应先了解条目生命周期。
NAT 会修改包的地址，有时也修改端口。订单实例访问支付接口时，源 NAT 可以将私网源地址转换成出口公网地址，并记录映射，使响应能够回到原实例。目标 NAT 则修改目的地址，常见于某些入口转发场景。转换并不加密数据，也不替代授权规则；它解决的是地址表达和回程映射问题。
NAT 映射与连接跟踪经常配合，但不能把所有状态都视为同张表。平台可能为连接数、端口分配和转换映射分别设限。多个实例共享公网出口时，即使实例各自很空闲，也可能在出口聚合后遇到端口或连接容量限制。端口容量还受目标分布、地址数量和复用方式影响，不能简单按固定端口数量推断所有平台容量。
连接复用能减少握手、新建流和状态周转压力，却会让单条连接承载更多请求。应同时考虑连接池大小、空闲回收、服务端超时和故障后的重建节奏。连接池越大不一定越好：大量空闲连接仍可能占用状态。重试也会改变网络负载，超时后立即并发重试，可能把原本短暂的拥塞扩大成连接风暴。
4 动手：追踪一次租户丢包点
这次练习假设你能查看测试实例和平台提供的网络观测信息。目标是判断订单实例访问支付测试端点时，故障发生在哪段边界。不要先修改生产路由、关闭策略或清空状态表。先固定测试对象、时间窗口、请求大小和频率，保留故障发生前的配置，才能让不同位置的证据具备可比性。
先写出预期路径：订单进程、实例接口、宿主机虚拟网络、出口网关、外部测试端点，以及响应的返回路径。标明源和目的五元组；经过 NAT 的位置另记转换后地址。若入口代理会重新建立连接，代理前后是不同的流，不能拿客户端连接的端口直接寻找代理到后端的报文。
在获准的测试环境，可以用以下命令获取实例侧的基础信息。地址为文档示例，应替换为实际测试目标。ping 失败只说明该探测没有成功，业务可能使用不同协议，目标也可能不回应 ICMP。curl 成功则只能证明当次请求与当时路径成功，不能证明整个观察窗口完全无丢包。
ip -s link show dev eth0
ip route get 203.0.113.20
curl --connect-timeout 3 --max-time 10 https://pay-test.example/health接口统计应至少记录测试前后 2 个时间点，用增量观察错误和丢弃，避免把历史累计值当成当前故障。路由查询帮助确认本机选择的出口，但不会证明后续网关状态正常。应用探测还应记录连接建立耗时、首字节耗时和总耗时，以区分尚未建连、等待服务处理以及传输过程停滞。
如果权限允许，在实例侧进行短时、定向抓包；平台侧则查询对应虚拟接口、策略、网关的流日志和丢弃计数。抓包范围应限定目标与端口，并按数据管理要求保护采集结果。租户通常无权进入宿主机，因此交给平台团队的材料应包含时间窗口、租户网络标识、五元组和复现步骤，而不是要求对方“查整个网络”。
判断遵循边界比较：源端看见发出，不代表网关已经收到；网关看见转换后的发出，不代表外部端点已经收到。若目的端记录已收到请求，还要继续追踪响应。某处没有日志，也可能是日志未启用、采样遗漏或查询字段错误。只有确认观测覆盖范围后，“没有记录”才能成为缩小范围的依据。
最后把结果写成可检验的陈述，例如“测试窗口内，实例发出 20 次连接尝试，出口出现新连接分配失败增量，外部端点未见对应连接”。这支持继续调查出口容量，但还不能断言业务代码毫无问题。保留假设、证据和未覆盖区间，比单独写“疑似网络问题”更方便协作，也便于修复后使用相同条件验证。
5 功能丰富与性能取舍
云网络提供租户隔离、有状态策略、地址转换、负载均衡和流量观测，使应用不必自己实现所有边界能力。但包经过更多处理环节，可能增加查表、状态访问、排队和日志成本。性能取舍应从业务需要出发：订单支付关注超时和结果一致性，批量导出关注持续吞吐，不能用单个峰值速率评价两者。
比较方案时，要先固定测试条件。小包和大包对系统施加的压力不同，长连接与短连接的建立开销不同，单流与多流也可能使用不同资源。记录包长、并发连接、新建连接速率、是否经过 NAT，以及策略和观测功能是否启用。脱离这些条件的“支持多少吞吐”，不足以推算自己的服务容量。
平均延迟之外，还要观察 p95、p99 等分位值。p99 表示观察样本中约 99% 的延迟不超过该值，并不承诺未来请求必然满足。短时突发可能只影响少量请求，却让付款确认超出超时预算。测试应覆盖业务高峰和突发持续时间，避免只在低负载下验证连通，再把结果外推到大促场景。
硬件卸载和快速转发路径可以降低部分处理开销，但也可能改变计数器的位置、抓包可见范围和可用功能。入门阶段只需记住：观测工具所见可能只是实际路径的部分。启用加速前后都应确认策略语义和监控方式，不能因为某个软件接口计数下降，就推断真实流量也随之减少。
合理取舍通常是保留必要隔离与访问边界，再通过连接复用、容量分配和观测范围优化成本。采样日志能减少开销，却可能漏掉低频故障；完整记录更有利于追踪，但需要处理存储量与敏感信息。方案应说明平时如何观测、事件期间如何提高精度，以及提高精度后的资源预算。
交互中的状态占用计算只是帮助理解趋势：连接创建越快、状态保留越久，所需条目通常越多。真实系统还会受流量类型、关闭行为、超时分类和容量分区影响。使用估算选择压测范围，再用平台指标验证，比把教学模型当成采购规格可靠。也不要通过关闭有状态防护来证明性能提升后，就直接把它视为可上线方案。
6 常见坑：conntrack 表打满
连接跟踪表容量有限。条目接近上限时，新流可能无法创建状态，旧流却仍可继续通信。于是会出现很有迷惑性的现象：已有数据库连接正常，新实例启动后连接失败；某些顾客刷新后偶尔成功，另些请求持续超时。网络没有整体断开，问题集中在状态创建，因此只用已有长连接做健康检查可能漏报。
可以用“平均新建流速率 × 平均状态停留时间”粗略估算稳态占用。假设每秒新建 200 条流，平均停留 120 秒，粗略需要 24000 个条目。这个关系适用于相对稳定的观察范围，不能描述所有突发，也不能把应用请求数直接当成新流数；使用连接复用时，很多请求可以共享同条连接。
首先核对条目使用量、容量上限、创建失败和丢弃增量，并按协议、来源和状态分布查看主要贡献者。若使用率不高，也要确认指标覆盖的是否为发生故障的节点或容量分区。汇总平均值可能掩盖某台宿主机或某个网关已经达到上限；租户接口正常也不能排除共享出口的状态资源不足。
常见诱因包括连接池失效、客户端频繁重建连接、异常重试、扫描流量以及大量等待超时回收的条目。需要把发布事件、请求速率和新建连接速率放在相同时间轴上。例如发布后业务请求量没变，新建连接却增长数倍，更应检查连接复用和超时设置，而不是立即判断外部攻击。
直接扩大表可能缓解容量压力，但需要更多内存和处理资源，也无法修复无限重试。直接缩短超时则可能提前删除仍有价值的状态，导致空闲长连接恢复发送时失败。更稳妥的顺序是抑制异常来源、修复连接管理，再按资源预算调整容量与超时，并验证正常业务的最长空闲间隔。
清空状态表会破坏现有连接，不能作为日常诊断动作。恢复措施应有影响范围、操作窗口和回退条件。修复后同时观察新连接成功率、旧连接稳定性、状态占用和应用错误率；仅仅看到表使用量下降，不代表顾客的付款确认已经恢复。若重试仍未受控，容量可能很快再次耗尽。
7 案例：隧道外层 MTU 导致黑洞
订单 API 跨宿主机迁移后，健康检查始终正常，小订单也能提交，但包含较长商品清单的请求偶尔卡住。应用团队怀疑数据库变慢，数据库却没有收到对应查询。抓包显示 TCP 握手完成，后续较大的报文反复重传。这里的线索是“大小相关”：同个目的地和端口，小流量成功，较大传输停滞。
MTU 是接口或路径允许承载的最大网络层包大小。假设某段底层链路 MTU 为 1500 字节，隧道新增开销为 50 字节，那么该段留给内层 IP 包的空间只有 1450 字节。这是便于理解的示例；实际开销会随外层地址族、封装和附加标签变化，需要依据真实路径计算，不能把 1450 当成通用配置。
源实例若仍按 1500 字节发送内层包，封装后会达到 1550 字节，超过示例链路的限制。后续行为取决于协议、标志和实现，可能分片，也可能丢弃并发出差错通知。路径 MTU 发现依靠相关通知帮助发送端调整大小；IPv4 常涉及需要分片的通知，IPv6 使用 Packet Too Big 通知，路由器不会替 IPv6 包执行分片。
如果通知被过滤或无法送回发送端，发送端可能继续重传相同大小的包，形成“黑洞”：连接看似已建立，数据却无法推进。重传还会拉长请求耗时。TLS 握手或响应中也可能出现较大的报文，所以不能把症状限定为“请求体超过某个字数”，应用字节数与线上分段方式并不是简单对应关系。
排查时，在相同源、目的和路径条件下比较不同大小的探测与实际业务传输，检查接口 MTU、隧道开销和相关差错通知。Linux 上的 tracepath 可以提供路径 MTU 线索；某些受管网络不回应探测，因此结果仍需与平台证据交叉确认。只在实例里降低 MTU 后测试成功，支持大小相关假设，却还需要找到配置不一致的真实边界。
修复通常要让租户接口 MTU、封装设计和底层承载能力保持一致，并确保必要的路径差错通知可达。某些边界可以调整 TCP MSS，帮助限制 TCP 数据段大小，但它不能自动解决 UDP 或所有非 TCP 流量的问题。验证应覆盖跨宿主机、跨子网和公网出口等实际路径，并同时观察较大请求和较大响应。
8 把云网络内核写进方案
方案首先要画清应用依赖：用户到入口、入口到订单 API、API 到数据库、API 到支付端点，分别使用什么地址范围、协议和端口。将逻辑路径与实现边界关联，说明哪里进行策略检查、哪里转换地址、哪里可能封装。若某段实现由平台托管，明确需要平台提供的能力和证据，避免把不可见细节写成已验证事实。
容量部分应区分带宽、包速率、并发连接、新建连接速率和 NAT 资源。业务侧给出高峰请求、连接复用比例及重试行为，平台侧据此估算状态规模，再通过测试修正。为突发保留余量时，应说明基于什么活动规模和持续时间，而不只是写“预留充足资源”。同时确认容量限制作用于实例、节点还是共享出口。
可靠性部分要包含返回路径。入口多副本不代表出口没有共享故障点，跨可用区部署也不保证所有出口状态同步。应确认故障切换时公网源地址是否变化、现有连接能否保留，以及支付端点是否有源地址白名单。对不能保留的连接，由应用使用受控重试和订单幂等机制处理，避免网络恢复后产生重复业务操作。
观测部分要把指标变成行动条件：新建连接失败增长时查看状态资源，大小相关停滞时检查 MTU 与差错通知，只有某条路径异常时比较策略和路由。告警阈值应结合基线、容量上限和业务超时预算制定。指标名称相似不代表定义相同，方案中要记录统计范围、采样间隔和负责团队。
验收应覆盖部署后的真实路径，而不仅是控制台配置。分别测试正常请求、连接突发、大包传输与故障恢复，保存配置版本和结果。如果平台不能提供宿主机级证据，应提前约定支持请求所需字段与响应方式。这样，当顾客看到超时时，团队能从已知边界开始定位，不必临时补画网络拓扑。
9 从云平台内核：网络走向安全架构（C58）
网络隔离为安全架构提供边界，但边界必须有明确含义。Overlay 能帮助区分租户网络，并不等于载荷已加密；NAT 隐藏了部分地址表达，并不证明请求可信；有状态规则允许返回流量，也不判断订单操作是否符合业务权限。安全设计需要把网络路径与身份、授权和数据保护组合起来。
以订单 API 为例，入口只接受必要服务端口，实例仅能访问所需数据库和支付端点，数据库身份凭据由专门机制管理。即使源地址来自允许的子网，应用仍需检查调用身份和操作权限。反过来，即使身份令牌有效，网络策略仍可限制不需要的横向访问，缩小配置错误或凭据泄漏后的影响范围。
本课的观测方法也能支持安全调查：保存转换关系和时间范围，可以帮助解释某个公网连接来自哪个工作负载。但流日志通常只能说明通信元数据，无法单独证明应用执行了什么动作。应关联身份审计、应用事件和网络证据，并限制这些记录的访问与保留范围，因为观测数据本身也可能包含敏感信息。
进入 C58 前，应能回答 3 个问题：订单请求经过哪些信任边界，边界依据什么信息作决定，决定失败或设备失效后会留下什么证据。网络路径让这些问题有了具体位置。接下来的安全架构将继续讨论如何让身份、权限与防护措施在这些位置形成完整设计，并用可验证的控制降低风险。
放进方案里
订单服务部署于私有子网，公网请求经入口负载均衡到达 API，数据库仅接受服务所需的访问，API 通过受管出口连接支付端点。网络图同时标注租户地址、网关边界、NAT 位置和返回方向。平台负责底层承载、封装与转发能力，应用团队负责连接池、超时、重试和订单幂等；双方共同维护路径与故障证据。
容量规划分别记录高峰带宽、包速率、并发连接和新建连接速率，并确认各项限制的作用范围。根据连接创建速率和状态停留时间估算连接跟踪需求，以实际压测修正，给出突发持续时间和余量依据。共享出口还需确认地址转换容量，验证其他工作负载增长时是否会影响订单服务。
接口 MTU 按实际封装开销与承载路径设置，确保必要的路径差错通知可达。验收覆盖跨宿主机通信、较大请求与响应、公网出口和故障切换。出口切换若导致现有连接中断，应用通过有上限的退避重试恢复，并以业务幂等标识避免重复下单；支付端点的源地址限制也纳入切换测试。
监控同时采集连接建立失败、丢弃增量、状态表占用、网关容量及应用延迟分位值。故障记录包含时间窗口、网络范围、转换前后五元组、配置版本和测试条件。日志缺失时先确认采样与覆盖范围。出现状态压力时先抑制异常连接来源，再评估扩容；禁止将清空状态作为常规排查步骤。
上线评审以真实路径的验收结果为依据，写明平台不可见部分的支持接口、责任人和回退条件。涉及策略、超时、MTU 或出口变更时，重新验证相关路径及业务结果，把可达性、容量与恢复行为作为可持续维护的交付内容。
10 小结：下一步安全架构（C58）
理解云网络，需要同时看见租户逻辑路径与底层承载路径。封装改变包大小，网关改变路径或地址，连接跟踪保存状态，限速与容量约束决定高峰时的表现。排查从明确时间、流和边界开始，再比较各处证据。
可以自测：为什么旧连接正常时新连接仍可能失败？为什么健康检查通过而较大传输停滞？为什么 NAT 不能代替授权？能用状态容量、MTU 与安全边界解释这些现象，就具备进入 C58 安全架构的基础。