第9章 云计算网络与安全

对应简历：技能第12条「熟悉移动云（ECS / CLB / VPC / 云数据库 / 消息队列）与阿里云核心产品，具备 WAF、DDoS 防护、主机安全、数据库审计配置经验」+ 第16条网络部分「熟悉 TCP/IP 协议及华为 CE 系列交换机配置（VLAN 划分、网络故障诊断）」/ 项目二职责「负责云数据库、消息队列、注册中心及 WAF / DDoS 防护 / 主机安全 / 数据库审计等云服务的配置管理与业务系统发布支持」

分三块：网络基础（挂第16条）、云计算（挂第12条）、云安全（挂第12条）。VMware/KVM 虚拟化在第 8 章，本章不重复。

第一部分：网络基础（对应简历技能第16条网络部分）

9.1 OSI 七层与 TCP/IP 四层模型 【必背】

标准回答： 先说结论：OSI 是理论上的七层参考模型，工程上大家实际用的是 TCP/IP 四层模型，我平时排障就是按四层一层层收敛的。OSI 从下往上七层分别是：物理层管比特流在线缆上的传输，数据链路层把比特封装成帧、用 MAC 地址做寻址，网络层负责 IP 包的路由选路，传输层做 TCP/UDP 的端到端通信，再往上会话层、表示层、应用层分别管会话维护、加密压缩和具体应用。TCP/IP 四层是把七层做了工程化合并：网络接口层对应物理加链路层，网络层跑 IP、ICMP、ARP，传输层跑 TCP 和 UDP，应用层把 OSI 上面三层合成一层，HTTP、DNS、SSH 都在这层。这个模型对运维最大的价值是排障顺序：先看线缆网卡亮不亮，再看 IP 和路由通不通，然后测端口连不连得上，最后再看应用本身返回什么——从一层往七层逐层验证，问题一定能收敛到某一层。我在银行项目和移动云项目里定位网络问题都是这个套路，比如 kubectl 连不上 apiserver，先 ping 通不通、再 telnet 6443 端口、最后看证书和 apiserver 日志，就是四层模型的实际应用。

追问链：

• 追问1：交换机和路由器分别工作在哪一层？ → 答：交换机工作在二层，收到帧之后查 MAC 地址表决定从哪个口转发；路由器工作三层，收到包之后查路由表按目的 IP 转发。现在数据中心常用的三层交换机是带路由功能的交换机，既有二层的大容量交换能力又能做三层网关，银行项目的 CE 交换机就是这类，配了 VLANIF 接口给每个 VLAN 做网关。
• 追问2：一次 ping 通到底经历了哪些层？ → 答：ping 用的是 ICMP 协议，它工作在网络层，但整个动作是跨层的：本机应用发出 ping 命令，内核封装成 ICMP 包再套上 IP 头，然后封装成以太网帧从网卡发出去，对端收到后原路解封装再回显应答。这里有个重要的排障结论：ping 通只能验证一到三层是通的，不能证明应用正常——要验证应用得用 telnet 测端口或者 curl 看响应，这是我常踩常讲的坑。
• 追问3：ARP 协议是干什么的？ → 答：ARP 是地址解析协议，解决"已知同一网段的目标 IP，求它的 MAC 地址"的问题，靠广播请求、单播应答完成，结果缓存在本机 ARP 表里。排障时 arp -n 能看到网关的 MAC，如果 ARP 表里网关 MAC 不对或者学不到，说明二层就有问题，比如交换机端口没放行对应 VLAN，这时候连 ping 网关都不通。

9.2 三次握手与四次挥手（及原因） 【必背】

标准回答： 三次握手是 TCP 建立连接的过程。第一步客户端发一个 SYN 报文，带着随机生成的初始序列号 seq=x，表示请求建立连接；第二步服务端收到后回一个 SYN 加 ACK 的报文，自己也生成一个随机序列号 seq=y，确认号是 x+1，意思是"你的请求我收到了，我也要和你建连接"；第三步客户端再回一个 ACK，确认号是 y+1，双方连接就建立了，可以传数据了。为什么必须是三次不能是两次？核心原因是双方都要确认"自己的发送能力和接收能力都正常"：两次握手的话，服务端发了 SYN+ACK 之后无法确认客户端到底收没收到，连接状态是不完整的；另外三次握手还能防止网络里滞留的历史 SYN 报文迟到之后误建连接——旧 SYN 先到，服务端回 ACK，客户端发现不对会发 RST 拒绝，两次的话服务端就已经单方面建好连接浪费资源了。四次挥手是断开连接的过程：主动关闭方发 FIN，对端回 ACK，对端把自己剩下的数据发完之后再发 FIN，主动关闭方回最后一个 ACK，两边各自进入关闭。为什么断开要四次而建立只要三次？因为 TCP 是全双工，两个方向要分别关闭；而且被动方收到 FIN 的时候可能还有数据没发完，所以它先把 ACK 回了表示"我知道你要关了"，等数据发完再发自己的 FIN，ACK 和 FIN 拆开传，就成了四次。这套机制我在排查连接问题的时候经常用连接状态来反推，比如 ss 看到大量 SYN_SENT 说明请求发不出去，大量 ESTABLISHED 但应用无响应就要看应用层了。

追问链：

• 追问1：TIME_WAIT 是什么状态、为什么要等 2MSL？ → 答：TIME_WAIT 出现在主动关闭方，它发完最后一个 ACK 之后不直接关闭，而是等待两倍报文最大生存期（2MSL）才真正释放连接。等这两个时间的原因：一是保证最后的 ACK 如果丢了，对端还能重传 FIN 过来，本端有时间重发 ACK 完成关闭；二是让这条旧连接的所有报文在网络上自然消亡，不会串到复用相同端口的新连接里污染数据。运维场景里服务端大量 TIME_WAIT 一般是短连接高频创建导致的，比如应用没有用连接池、每个请求都新建连接，缓解办法是改长连接、用连接池。
• 追问2：大量 CLOSE_WAIT 说明什么问题？ → 答：CLOSE_WAIT 的意思是对方已经发了 FIN 过来，但本端一直没调用 close() 关闭连接。这几乎百分之百是本端应用代码的 bug——收到了关闭请求却没释放连接资源，堆积多了会耗尽文件描述符导致新连接建立不了。所以排查思路是先查应用代码，而不是怀疑网络，网络只是把对方的关闭意愿带到了，没关是应用自己的事。
• 追问3：怎么快速统计服务器上的连接状态分布？ → 答：用 ss -ant 加 awk 统计：ss -ant | awk '{print $1}' | sort | uniq -c，一眼看出 ESTABLISHED、TIME_WAIT、CLOSE_WAIT 各有多少。这个命令是我巡检和排障的常用组合，看到 CLOSE_WAIT 几百上千就知道要拉开发查代码了，看到 TIME_WAIT 爆炸就往短连接方向查。

9.3 TCP 与 UDP 的区别 【理解】

标准回答： 一句话总结：要"对"用 TCP，要"快"用 UDP。展开讲，TCP 是面向连接的协议，通信前要三次握手建立连接，传输中靠确认应答、超时重传、序列号排序保证数据可靠有序到达，数据是字节流形式，头部 20 到 60 字节，还带滑动窗口做流量控制和拥塞控制，所以 HTTP、SSH、MySQL 这些要求准确的协议都跑在 TCP 上。UDP 是无连接的，发之前不用握手，发了也不保证到、不保证顺序，数据报文有自己的边界，头部固定只有 8 字节，开销小延迟低，适合 DNS 查询、DHCP、视频流、游戏这类"丢一点没关系、快最重要"的场景。两者的联系是都在传输层、都用端口区分应用、都依赖网络层的 IP 做实际路由。我在运维里最直观的感受是排障方式不同：TCP 的服务可以用 telnet 直接探端口验证握手能不能完成，UDP 无连接就没法这样探，得用 nc -u 或者直接看应用日志。另外值得说一句的是现在 HTTP/3 和 QUIC 是在 UDP 上自己实现了类似 TCP 的可靠传输，把拥塞控制搬到应用层做优化，这个趋势我平时有跟踪，面试聊到可以作为加分的延伸。

追问链：

• 追问1：UDP 想要可靠怎么办？ → 答：传输层本身不管，要在应用层自己补——参照 TCP 的思路做确认应答、超时重传、序列号排序和拥塞控制，典型例子就是 QUIC 协议，它在 UDP 之上实现了接近 TCP 的可靠性，同时避免了 TCP 三次握手的延迟和队头阻塞问题。所以说可靠不可靠最终是工程取舍，不是绝对的能力边界。
• 追问2：TCP 粘包了解吗？ → 答：知道原因。TCP 是字节流协议，不保留报文边界，发送方多次 write 的数据可能被合并成一个段发出去，接收方一次 read 可能拿到两条"消息"粘在一起，这就是俗称的粘包。它不是 TCP 的 bug，是字节流的特性。解决办法在应用层定边界：固定长度、用分隔符，或者消息头里带长度字段。排查业务"消息错乱"的问题时要想到这一层。

9.4 常见端口 【必背】

标准回答： 端口这块我按"天天见的"和"项目里特别记住的"两层背。天天见的：22 是 SSH，80 是 HTTP，443 是 HTTPS，53 是 DNS，3306 是 MySQL，6379 是 Redis，5432 是 PostgreSQL，1433 是 SQLServer，1521 是 Oracle，3389 是 Windows 远程桌面，8080 是常见的 HTTP 备用端口。监控和容器体系的：9100 是 node_exporter，9090 是 Prometheus，3000 是 Grafana，10050 和 10051 是 Zabbix 的 Agent 和 Server 端口。Kubernetes 体系的：6443 是 apiserver，2379 和 2380 是 etcd 的客户端和服务端通信端口，10250 是 kubelet，30000 到 32767 是 NodePort 默认范围。还有一个我特别记住的 16443——银行项目里负载均衡和其中一台 master 复用一台机器，6443 已经被 apiserver 占了，所以前置的 Nginx 监听 16443 做 apiserver 的代理端口。记端口不只是背数字，真正的价值是排障时形成条件反射：看到连不上先想这个端口该由谁监听、防火墙放没放行；做规划时想端口冲突，比如监控节点上 Prometheus 9090 和业务端口会不会撞。

追问链：

• 追问1：怎么查本机哪个端口被谁占用？ → 答：ss -lntp | grep :端口 一步拿到监听地址、进程名和 PID，比 netstat 快；如果是容器环境还要注意端口可能是被 docker-proxy 或者 kube-proxy 占的，宿主机 ss 看到的进程是代理而不是业务本身，这个区别在排障时容易误判。
• 追问2：一个端口被占用了，杀进程就能解决吗？ → 答：分情况。如果是残留的旧进程占着，确认没有业务流量后按"先 kill -15 优雅停、等几秒不行再 kill -9"处理；如果是有业务在跑的端口被规划给了新服务，那要做的是改新服务的端口规划而不是硬杀旧服务。生产上动端口前先确认归属，这是变更纪律。

实操模板（端口速查清单）：

21 FTP（20 数据）   22 SSH          23 Telnet       25 SMTP
53 DNS             67/68 DHCP      69 TFTP         80 HTTP
110 POP3           143 IMAP        443 HTTPS       445 SMB
1433 SQLServer     1521 Oracle     3306 MySQL      3389 RDP
5432 PostgreSQL    6379 Redis      8080 HTTP 备用  9100 node_exporter
9090 Prometheus    3000 Grafana    6443 K8s apiserver  2379 etcd
10050/10051 Zabbix Agent/Server  16443 银行项目 apiserver LB 端口

9.5 DNS 解析流程 【理解】

标准回答： DNS 解析我按一次完整的域名访问讲。用户在浏览器输入域名后，系统先查本地缓存——浏览器自己的缓存、操作系统的缓存、还有 hosts 文件，任何一层命中就直接用。都没命中，就去问配置的本地 DNS 服务器，一般是运营商的或者公司内网的，公共的像 223.5.5.5、114.114.114.114。本地 DNS 如果有缓存直接返回；没有的话，它就代替用户开始迭代查询：先问根域名服务器，根说"这是 .com 的，你去问顶级域服务器"；再问 .com 顶级域服务器，它说"这个域名的权威 DNS 在哪你去问它"；最后问权威 DNS 服务器，拿到最终的 IP 地址。整个结果按 TTL 的值在各级缓存起来，下次就不用再问一遍了。这里有个概念区分经常被考：客户端到本地 DNS 之间是递归查询——客户端只发一次，剩下的全由本地 DNS 负责问到底；本地 DNS 到根、顶级域、权威之间是迭代查询——每次得到一个"下一跳"的地址自己再接着问。运维排障的时候，DNS 问题的典型特征是"ping IP 通、ping 域名不通"，用 nslookup 或者 dig 验证，对比指定不同的 DNS 服务器还能判断是不是本地 DNS 有污染或者故障，应急手段是改 hosts 或者换公共 DNS。

追问链：

• 追问1：怎么判断一个"访问不了"是 DNS 的问题？ → 答：分两步验证：第一步 dig 或者 nslookup 这个域名，看能不能解析出 IP；第二步直接 ping 解析出来的或者已知的 IP。如果 dig 失败但 ping IP 通，问题就在解析环节；如果 dig 成功但 ping IP 不通，问题在链路或者对端。经典案例就是"QQ 能登、网页打不开"——QQ 走 IP 直连不依赖域名解析，网页必须先过 DNS，所以这个现象基本锁定 DNS 故障。
• 追问2：递归查询和迭代查询的区别再说一遍？ → 答：递归是"你帮我问到底"——客户端把问题交给本地 DNS，它必须返回最终答案，中间过程客户端不参与；迭代是"我告诉你去问谁"——本地 DNS 问根服务器，根不替它查而是指路给顶级域，本地 DNS 自己一步步问过去。客户端对本地 DNS 是递归，本地 DNS 对上游是迭代，这两个关系放在一起说最清楚。

实操模板（DNS 排查命令组）：

nslookup www.example.com          # 基本解析（是否返回、返回什么）
dig www.example.com +short        # 精简结果
dig @223.5.5.5 www.example.com    # 指定 DNS 服务器对比（判断本地 DNS 污染/故障）
cat /etc/resolv.conf              # 本机 DNS 配置
ping <解析出的IP>                  # 验证三层通（区分"解析问题"还是"链路问题"）

9.6 DHCP 与私有地址 【了解】

标准回答： DHCP 是自动分配 IP 地址的协议，交互四步：客户端上来先广播一个 DHCPDISCOVER 发现消息，网络里的 DHCP 服务器都收得到；服务器回一个 DHCPOFFER 广播，提供一个候选 IP；客户端从中选一个，发 DHCPREQUEST 请求确认；服务器最后回 DHCPACK 确认，里面带上分配的 IP 和租约期限，默认 8 天，到期要续租。这个流程记四句话：发现、提供、选择、确认。私有地址是 RFC1918 规定的三段内网地址：10.0.0.0/8、172.16.0.0/12（也就是 172.16 到 172.31 这一段）、192.168.0.0/16，它们不能直接在公网路由，出公网必须经过 NAT 地址转换。我们日常所有的公司内网、家庭网络用的都是这三段里的地址。云上的场景要说明一下：ECS 的内网 IP 是在 VPC 里静态规划分配的，比如项目二我是按节点角色规划固定 IP 的，不走 DHCP；DHCP 的四步交互主要出现在办公网和虚拟化业务网这种终端自动获取地址的场景，原理要会讲，但云上运维用得少，这个边界我说清楚反而显得实在。

追问链：

• 追问1：网络里有人私接了路由器当 DHCP 服务器，终端拿到错误网关，怎么防？ → 答：在交换机上配 DHCP Snooping 功能，把接终端的端口设为非信任口、只把上联 DHCP 服务器的口设为信任口，这样非信任口发来的 OFFER 报文直接丢弃，私接的 DHCP 服务器就分不出地址了。这是二层安全的一个经典配置。
• 追问2：DHCP 租约到期前会发生什么？ → 答：客户端会在租约的一半时间点尝试向原服务器续租，直接发 REQUEST 就行不用再走广播；如果服务器没响应，到租约 87.5% 的时候会广播 REQUEST 向任意服务器续租；全都没人理，租约到期客户端必须释放地址重新走四步申请。理解这个机制就能解释"电脑换网段之后一段时间不上网"之类的现象。

9.7 VLAN 划分与 Trunk 【必背】

标准回答： VLAN 是在交换机上把一个物理局域网逻辑地划分成多个广播域的技术。为什么需要它：第一，隔离广播风暴，没有 VLAN 的话一个二层网络里所有设备共享一个广播域，设备一多广播流量互相干扰；第二，安全隔离，不同部门的流量二层就隔开；第三，灵活，按业务分组改 VLAN 配置就行，不用重新布线。关键技术点是：不同 VLAN 之间二层是不通的，要互通必须经过三层设备——三层交换机的 VLANIF 接口做各 VLAN 的网关，或者路由器做单臂路由。端口类型有两种必须分清：Access 口接终端设备，只属于一个 VLAN，收发都不打标签；Trunk 口用在交换机之间或者接服务器，一条链路上承载多个 VLAN 的流量，靠 802.1Q 在帧上打 4 字节标签区分，native VLAN 例外不打。服务器虚拟化场景就是这两者的组合：物理交换机口起 trunk 放行多个 VLAN，虚拟化平台这边分布式交换机的端口组绑定 VLAN ID，虚拟机挂到哪个端口组就在哪个 VLAN——银行项目里我在 FC 上配端口组就是这个模型，和网络团队的交换机 trunk 配置是一张规划表对出来的，双方按表施工、按表验收。

追问链：

• 追问1：银行项目的管理面和业务面是怎么隔离的？ → 答：每台服务器都是双平面：管理 IP 和业务 IP 分开，分别接到不同的交换机或者不同的 VLAN，管理流量和业务流量物理或逻辑隔离；在这个基础上还有第三张网——BMC 带外管理网，接的 iBMC 管理口。三张网互不抢带宽，业务网再怎么打满，管理操作和带外救机器都不受影响。这是我做过最扎实的一次平面隔离实践，后来移动云上的安全组分层设计也是同一个隔离思想。
• 追问2：两台交换机级联的口怎么配？ → 答：两端都配成 trunk，并且放行所需要的 VLAN 列表，两边要一致。如果一端配了 trunk 另一端是 access，流量标签对不上，轻则不通，重则不同 VLAN 的流量串到一起造成安全问题。所以交换机配置变更有互检环节，改完用 display vlan 和 display port vlan 核对两端的放行列表。
• 追问3：怎么定位环路和广播风暴？ → 答：先看现象：所有端口流量同时异常打满、CPU 升高、ping 出现大面积超时和抖动。用 display interface brief 看哪个口流量异常、有没有大量广播包和 CRC 错包，再检查是不是有口被误接成了环路。防的办法是交换机上配 STP 生成树协议，通过阻塞冗余路径自动破环，故障时再自动切换。银行组网里管理和业务双平面分开、各自独立组网，天然减少了环路面。

9.8 路由基础、默认网关与子网划分 【理解】

标准回答： 路由的本质是路由器查路由表按最长前缀匹配决定下一跳。路由的来源有三类：直连路由，接口配了 IP 自动生成；静态路由，管理员手工写死，简单可控但不自适应，网络一变就得手工改；动态路由，OSPF 这类链路状态协议在路由器之间自动同步拓扑变化，BGP 用在自治域之间。还有一个特殊的默认路由 0.0.0.0/0，掩码最短所以优先级最低，专门兜底匹配所有未知目的地——服务器和出口设备上必配，不然访问任何没明细路由的地址都直接丢包。三层交换机做网关的场景，每个 VLAN 建一个 VLANIF 三层接口配上网段的网关地址，该网段所有主机的默认网关指向它。子网划分我拿一道必背题讲：把 192.168.0.0/24 划成每个子网至少容纳 50 台主机。计算过程：50 台需要主机位至少 6 位，2 的 6 次方减 2 等于 62，够；从主机位借 2 位做子网位，掩码变成 /26 即 255.255.255.192；得到 4 个子网：192.168.0.0/26 可用地址 .1 到 .62、.64/26 是 .65 到 .126、.128/26 是 .129 到 .190、.192/26 是 .193 到 .254，每个子网 62 个可用地址。注意每个子网头尾两个地址不能用：网络号是主机位全 0，广播地址是主机位全 1，比如第一个子网的广播是 .63。

追问链：

• 追问1：/26 子网的广播地址怎么快速算？ → 答：记住块大小：/26 的块是 64，子网网络号加上块大小减 1 就是广播地址，比如 192.168.0.0/26 的广播就是 0 加 64 减 1 等于 .63；可用范围就是网络号加 1 到广播地址减 1。这套"块大小"口诀对 /25（128）、/27（32）、/28（16）都通用，现场算网段很快。
• 追问2：服务器上怎么查和临时加路由？ → 答：ip r 或者 route -n 看路由表，ping 网关 验证默认路由通不通；临时加一条路由用 ip route add 目标网段 via 网关，永久生效要写网卡配置文件或者 NetworkManager。排障时"同网段通、跨网段不通"第一个就看默认网关和路由表。

9.9 网络排查命令链（ping/telnet/traceroute/ss） 【必背】

标准回答： 网络排查我有一套固定的五层命令链，从本机往数据方向逐层推进。第一层看本机：ip a 确认地址配了没、网卡 up 没 up，ip r 看路由和默认网关，ss -antup 看监听端口和连接状态，然后 ping 网关 验证本机到网关这段通不通——网关都不通基本是本机配置或者二层的问题。第二层测链路：ping 对端IP 通不通，不通的话 traceroute 对端IP 看路径断在哪一跳，是出网关就断还是中间某一跳断。第三层测端口：telnet IP 端口 或者 nc -zv IP 端口，验证四层能不能连上，ping 通 telnet 不通就查对端服务监听、防火墙和安全组。第四层测服务：curl -v 带详细输出访问，看七层返回的状态码、证书和响应内容。第五层抓包：tcpdump -i eth0 host 对端 and port 端口，看两个机器之间到底有没有报文交互、交互到哪一步卡住了，比如 TCP 握手只发不回、还是回了 RST。辅助的还有 arp -n 看 ARP 学习、ss -ant | awk '{print $1}' | sort | uniq -c 统计连接状态分布。这套链条的价值是把模糊的"网络不通"变成精确的"断在第几层"，我在银行现场和云上排障都是这么走的，只是云上把"物理链路"换成"安全组"作为第一嫌疑人。

追问链：

• 追问1：ping 通但 telnet 端口不通，怎么继续查？ → 答：这说明三层通、四层不通，问题收敛在端口层面。按三个方向查：第一，对端服务到底起没起、有没有监听这个端口，登对端 ss -lntp 看；第二，监听地址是不是 0.0.0.0——很多服务默认只听 127.0.0.1，本机自测没问题、外面就连不上，这是超高频坑；第三，路径上的防火墙或者云上安全组有没有放行这个端口。三步查完基本必有答案。
• 追问2：tcpdump 抓包你实际用来解决过什么问题？ → 答：典型场景是验证两台机器之间有没有真实的数据交互。比如怀疑证书协商失败，抓包能看到 TCP 三次握手完成、客户端发 ClientHello 之后对端直接回 RST 或者没有响应，一下就能区分"网络断"还是"服务拒"。命令形如 tcpdump -vvv -nnn -i eth0 host A and port 6443，加 -nnn 是不做域名和端口反解，输出干净。抓包是网络排障的终点站，前面命令都定位不了就上它。

实操模板（网络排查命令树）：

1 本机:  ip a | ip r | ss -antup | ping <网关>
2 链路:  ping <对端IP> → traceroute <对端IP>（看断在哪跳）
3 端口:  telnet <IP> <端口> 或 nc -zv <IP> <端口>
4 服务:  curl -v http(s)://<域名或IP>:<端口>/路径   # 看状态码
5 抓包:  tcpdump -vvv -nnn -i eth0 host <对端IP> and port <端口>
6 组合:  ss -ant | awk '{print $1}' | sort | uniq -c   # 连接状态统计

9.10 华为 CE 系列交换机基础配置 【必背】

标准回答： 华为 CE 系列是数据中心级交换机，银行项目里我真实配置过：管理和 BMC 网用的是 CE6856HI，业务网用的是 CE6863。基础配置我讲五件套的操作流：先用 console 或者带外登进设备，system-view 从用户视图进系统视图才能改配置；sysname SW-MGMT-01 给交换机改名，规范命名方便辨识；vlan batch 10 20 批量创建 VLAN；然后进端口划 VLAN——接终端的口配 access 模式，port link-type access 加 port default vlan 10；交换机之间的级联口配 trunk，port link-type trunk 加 port trunk allow-pass vlan 10 20 放行需要的 VLAN 列表；最后给交换机自己配管理地址，interface Vlanif 10 里 ip address x.x.x.x 掩码，配完之后就可以通过这个地址 SSH 远程管理了。所有配置做完必须 save 保存——华为设备不保存重启全丢，这是我每次配置完必做的动作，也是巡检时要检查的项。日常诊断命令：display interface brief 看所有端口的状态和收发流量，display vlan 看 VLAN 划分，display mac-address 看 MAC 地址学习情况，display lldp neighbor brief 看下联和上联的都是什么设备，定位物理连接特别有用。我的定位是讲操作和诊断不讲深层理论，堆叠 CSS 这些我们现场没做，被问到就按"文档层理解 + 会后补"的口径答。

追问链：

• 追问1：为什么强调必须 save？有没有真实教训？ → 答：华为设备配置默认只在内存里运行，不 save 的话断电或重启后配置全部回退到上次保存点，轻则管理地址丢了要爬Console，重则 trunk 放行列表没了业务中断。我养成的习惯是每完成一段配置立即 save，并且把"save 状态检查"写进巡检清单，防止同事改了配置没保存留下隐患。
• 追问2（兜底话术示范）：被问堆叠/CSS、跨设备链路聚合细节 → 答："我们银行现场是管理、业务双平面独立组网，没有做堆叠，所以堆叠的配置细节我没有实操过。原理层面我理解堆叠是把两台交换机虚拟化成一台逻辑设备，统一管理、链路可以做跨设备聚合来提升可靠性和带宽。配置级的细节可以会后补。"这样答既守住了诚实边界，又展示了原理理解。

实操模板（CE 基础配置，可背）：

system-view
sysname SW-MGMT-01
vlan batch 10 20                     # 批量建 VLAN
interface 10GE1/0/1
 port link-type access
 port default vlan 10                # 接终端/管理口
interface 10GE1/0/24
 port link-type trunk
 port trunk allow-pass vlan 10 20    # 级联上联口
interface Vlanif 10
 ip address <管理IP> <掩码>           # 交换机管理地址
quit
save                                 # 必须保存！
# 诊断：display interface brief / display vlan / display mac-address / display lldp neighbor brief

第二部分：云计算（对应简历技能第12条）

9.11 VPC、子网、安全组 【必背】

标准回答： 这三个是云上网络的骨架，我按从大到小说。VPC 虚拟私有云是云上逻辑隔离的私有网络空间，每个 VPC 之间天然二层隔离，里面的网段自己定义——项目二我用一个 C 类网段跨三个可用区部署了整个集群。子网是 VPC 内部按可用区再切分的网段，云资源都创建在某个子网里，跨可用区部署本质就是把资源分布到不同可用区的子网。安全组是实例级的有状态虚拟防火墙，挂在 ECS 的网卡上，默认拒绝一切入站流量，要访问必须显式加规则。它"有状态"的意思是：入方向规则放行的连接，它的响应出站流量自动允许，不用写回程规则——这和传统无状态 ACL 的区别是必考点，网络 ACL 作用在子网级、无状态，进出方向要各写各的。一句话区分三者职责：VPC 和子网管"网络怎么组"，安全组管"谁能访问我"。项目二的安全组我是按角色分组的：管控面只放行跳板机网段访问 6443 和 22，业务面按"入口到应用到数据库"的链路式放行，默认全部拒绝，任何变更走申请审批。这套最小权限的规划方法比记住某个控制台按钮重要得多，换哪家云都适用。

追问链：

• 追问1：安全组"有状态"具体帮运维省了什么事？ → 答：省掉回程规则。举个例子，我放行了入方向的 SSH 22 端口，那这台机器主动回给客户端的响应包自动就允许出站了，不需要再写一条"出方向放行 22"。如果是无状态的方案比如网络 ACL，就得进出两边都配，规则数量翻倍还容易漏。理解这个机制，排查"为什么我的规则不生效"时就不会去乱加出站规则。
• 追问2：云上 K8s 集群的节点间安全组怎么配？ → 答：节点互通要放行集群的关键端口：6443 是 apiserver，2379 和 2380 是 etcd，10250 是 kubelet，还有 NodePort 的 30000 到 32767 段，另外 Flannel 的 VXLAN 用到 8472 的 UDP。配错安全组是云上 K8s 节点 NotReady 的常见根因之一——节点注册不上、健康检查过不去，我排查 NotReady 的固定动作里就有"核对安全组放行列表"这一步。
• 追问3：安全组规则变更怎么管理才不出事故？ → 答：三个纪律：变更必须走申请审批、有工单记录；改动前先把原规则导出备份；一次只改最小范围并验证后再收尾。安全组配错的影响是即时的、全局的，比如误放行 0.0.0.0/0 到数据库端口就是把库暴露公网。所以我把安全组当成高危变更管理，绝不随手点。

实操模板（安全组规划示例表）：

安全组          方向  协议  端口         授权对象             用途
sg-master       入    TCP   6443         跳板机网段/CLB       apiserver
sg-master       入    TCP   22           跳板机网段           SSH 运维
sg-node-all     入    TCP   10250        master 网段          kubelet
sg-node-all     入    TCP   30000-32767  业务入口网段         NodePort
sg-db(内网ACL)  入    TCP   3306         应用子网             云数据库
默认策略        入    ALL   ALL          拒绝                 最小权限

9.12 ECS、CLB、NAT 网关、EIP 【必背】

标准回答： 这四个是我项目二的云资源主力，逐个说。ECS 弹性云服务器就是云上的虚拟机，项目二开了 7 台：3 台 master、3 台 worker 加 1 台独立监控节点，跨三个可用区部署做机房级故障隔离。CLB 负载均衡是流量入口，分四层和七层两种：四层工作在传输层，直接转发 TCP/UDP 报文，性能好、延迟低、透传源 IP，适合数据库和 TCP 类服务——我们把 apiserver 的统一入口就做成 CLB 四层监听 6443，配上对三个 master 的健康检查，某个 master 故障时 CLB 自动把它摘除，kubectl 的流量无感切到健康的 master；七层工作在应用层，能按域名和 URL 路由、终止 TLS、改写 HTTP 头，适合 Web 业务入口。一句话记：四层管"转发"，七层管"内容"。NAT 网关解决的是"VPC 里没有公网 IP 的资源怎么出公网"，核心机制是 SNAT 源地址转换——内网主机主动发起的出站流量，把源地址转换成 NAT 网关绑定的 EIP 出去，回来自动转回来。项目二全集群的节点都是纯内网机器，统一通过 NAT 网关加 EIP 的组合出公网拉镜像、下软件包。EIP 是独立的弹性公网 IP 资源，可以绑定解绑，NAT 网关上绑的就是它。这套组合的设计思想是出入口收敛：出方向统一走 NAT 网关，入方向统一走 CLB，管理入口统一走跳板机，所有流量都有明确的道，审计和排障都简单。

追问链：

• 追问1：apiserver 入口为什么用四层 CLB 而不是七层？ → 答：因为 kubectl 和集群组件连 apiserver 走的是 TCP 上的 TLS 长连接，不需要七层的域名路由、改写头这些能力；四层转发性能更好、延迟更低，健康检查直接配 TCP 探测 6443 端口就行，探测逻辑简单可靠。只有需要按 HTTP 路径分流、或者要在负载均衡上卸载证书的 Web 流量才值得上七层。
• 追问2：云上为什么用 CLB，不自建 Nginx + Keepalived？ → 答：我两种都真实做过，对比很有说服力。银行内网环境没有云负载均衡可用，所以我自建了 Nginx 加 Keepalived 的 VIP 漂移方案，要自己维护健康检查脚本、处理脑裂、管理 VIP；云上有托管 CLB，它本身就是多可用区高可用架构、没有单点，健康检查和自动摘除都是平台能力，不用自己维护。所以结论是云上首选托管服务，把精力留给业务；自建方案的能力我在内网环境已经验证过，两边原理是通的。
• 追问3：SNAT 和 DNAT 的区别？ → 答：SNAT 改的是源地址，场景是内网主动出公网，出去的包源 IP 从内网地址变成公网 EIP；DNAT 改的是目标地址，场景是公网主动进来，比如把 EIP 的某个端口映射到内网某台服务器的端口，外部访问 EIP:port 实际打到内网机器上。一句话：SNAT 管出去，DNAT 管进来。

9.13 云数据库 RDS、对象存储、快照与备份 【理解】

标准回答： 云数据库 RDS 是托管数据库服务，自带主备高可用、自动备份、监控告警这些能力。它和自建的核心取舍我用项目二的真实决策讲：当时业务上线时间紧，我们选了云数据库 MySQL 主备版，规格 8 核 16G 加 300G SSD，另外配了 Redis 双机热备。选托管的理由是同城热备自动切换、备份点可恢复、补丁和版本由云方维护，我们小团队不用自己兜底数据库的高可用和备份；代价是成本比自建高、有一定厂商锁定。另外有个架构决策常被问：数据库为什么不进 K8s 集群？我的答案是数据库是有状态重负载，它的滚动更新、数据一致性要求和容器"随发随销"的模型不匹配，伸缩粒度也对不上，生产上数据库放云托管服务、应用进集群，这个分层是稳妥的做法。对象存储是存海量非结构化数据的，按桶组织、HTTP API 访问、按量计费、容量近乎无限，适合图片、备份文件、日志归档，它和块存储（云硬盘）、文件存储（NAS）是云上三种存储形态，按数据的访问方式选型。快照是云盘或者实例某一时刻的只读副本，我的运维纪律是高风险变更前先打快照，比如节点系统大升级前，出问题可以整盘回滚；备份策略则是周期性的自动备份加保留天数，重要数据还要考虑异地容灾。另外 etcd 这类核心组件我们有独立的 snapshot save 备份规范，和云盘快照是两套互补的机制。

追问链：

• 追问1：快照和镜像有什么区别？ → 答：快照是磁盘数据在某一时刻的副本，用途是回滚恢复，可以恢复到原盘也可以基于它新建盘；镜像是"可启动的模板"，包含启动所需的完整定义，用来批量开新实例。两者有衔接关系：自定义镜像经常是从一个打好补丁调好配置的云盘快照制作出来的，项目二节点标准化初始化的复用就可以走"配置一台、做镜像、批量开节点"的路子。
• 追问2：RDS 的主备切换怎么验证过？ → 答：云控制台提供主备切换或者故障模拟的功能，切换过程有秒级到分钟的连接闪断，应用侧要靠连接池的自动重连机制扛过去。我们验收的时候验证了两件事：一是执行主备切换，确认角色互换、新的主库继续可写；二是确认应用的连接串指向的是带自动切换能力的域名或者地址而不是写死主库 IP，这样切换对应用才是透明的。

9.14 移动云与阿里云产品对照（双云经验） 【理解】

标准回答： 我的双云经验一句话概括：概念同构、命名不同、习惯可迁移。对照着说：云服务器两家都叫 ECS；负载均衡移动云叫 CLB，阿里云叫 SLB 或者新的 ALB；私有网络都叫 VPC；云数据库移动云叫云数据库 MySQL/Redis，阿里云叫 RDS 和云数据库 Redis 版；对象存储移动云是 EOS，阿里云是 OSS；镜像仓库移动云是私有镜像仓库，阿里云是 ACR 容器镜像服务。因为阿里云是国内云计算的事实标准，各家云的概念模型基本都是照着这套来的，所以迁移成本主要不在概念而在三件事：控制台操作习惯要重新熟悉、API 和 SDK 命名有差异、软件源和镜像源地址要换。我日常就是两朵云同时操作的：生产集群跑在移动云上，AI 工具链和部分公共资源用阿里云，切换没有障碍。面试时被问到"来了我们用的 XX 云怎么办"，我的回答是：一两天就能上手操作层面，我更看重带过去的是方法论——云资源规划表怎么做、安全组矩阵怎么设计、出入口怎么收敛，这套东西和厂商无关。注意口径：提到仓库域名和账号一律说"内网私有仓库"，不报真实域名。

追问链：

• 追问1：两朵云有没有遇到行为不一致的地方？ → 答：有，最典型的是镜像拉取和配套服务细节。不同云的公共镜像源地址不同、可用的服务目录不同，比如某些中间件托管服务一家有另一家没有，这时候要么换对应产品要么自己部署。我的处理办法是建设方案里把"依赖的云服务清单"列出来，换云时逐项对照，缺的自己补——这也是我把项目二方案沉淀成文档的价值之一。
• 追问2：选云的时候怎么评估？ → 答：三个维度：一看客户和合规要求，比如有的客户指定要国企背景的云；二看区域和网络质量，业务用户在哪、节点就选哪，跨区域访问延迟摆在那；三看成本，同样规格的计费方式、流量费、有没有优惠框架都影响总账。项目二选移动云苏州节点就是综合了客户要求和地域因素定的。

第三部分：云安全（对应简历技能第12条）

9.15 等保与 WAF 【必背】

标准回答： 等保是网络安全等级保护制度的简称，它是国家信息安全的基本制度，核心是按系统的重要程度定级——一到五级，级别越高要求越严，三级以上系统要求每年做测评。落地是技术加管理两面：技术面包括安全组最小权限、日志审计留存、入侵防范、备份恢复、通信加密这些控制项；管理面包括制度、人员、应急预案。金融和政务客户基本是硬性合规要求，我们项目二配套的一整套安全服务——WAF、DDoS 防护、主机安全、数据库审计——就是按等保要求和客户合规要求采购配置的，这回答了"你们为什么要买这些安全产品"这个问题。WAF 是 Web 应用防火墙，部署在 HTTP 流量入口，防护的是应用层攻击，具体就是 OWASP Top 10 那一类：SQL 注入、XSS 跨站脚本、WebShell 上传、命令注入、扫描器探测，外加 CC 攻击防护——CC 是高频的恶意请求，靠限速和人机识别来防，它和 DDoS 打带宽是两码事。WAF 的识别机制以规则和语义引擎为主，在七层看请求内容里的恶意特征。我的角色口径要说准：我负责这些安全服务的开通配置、策略调优和业务发布放行，不是安全攻防专家，这个边界诚实讲反而稳。

追问链：

• 追问1：WAF、传统防火墙、DDoS 防护三者怎么区分？ → 答：看它们工作的层次。传统防火墙在三四层，管的是 IP 和端口的通不通，是网络访问控制；WAF 在七层，管的是请求内容恶不恶意，看得到 SQL 注入的 payload；DDoS 防护管的是流量规模，防的是带宽和连接被冲垮。三者层次不同、互补关系，一个典型的对外业务三者都要有：防火墙做访问控制，DDoS 防护保带宽，WAF 保应用。
• 追问2：WAF 误杀了正常请求怎么处理？ → 答：处理顺序是：先看 WAF 的拦截日志，定位这次请求命中了哪条规则、哪个参数；然后加白名单，注意白名单要精确到具体的 URL、参数或者规则 ID，不能一刀切把整类规则关掉，那样等于开天窗；放行之后做业务验证确认功能恢复。还有一个前置实践：WAF 上线建议先开观察模式也就是只告警不拦截，跑一段时间把误报摸清、白名单配好，再切到拦截模式，这个顺序能避免上线即故障。
• 追问3：CC 攻击和 DDoS 的区别再讲清楚一点？ → 答：CC 攻击在应用层，攻击者发的每个请求看起来都是"合法"的 HTTP 请求，但通过高频请求把服务器的 CPU、数据库连接这些资源耗尽，特征是带宽不高但服务变慢挂掉，难防在于请求本身合规；DDoS 是流量型攻击，直接用海量的包把带宽、连接表打满，特征是流量曲线瞬间飙升，靠云端的流量清洗中心来抗。一个耗应用资源、一个耗网络资源，防护手段也完全不同。

9.16 DDoS 防护、主机安全与数据库审计 【理解】

标准回答： 这三个是项目二安全配套的主力，逐个说。DDoS 基础防护是云厂商默认提供的流量清洗能力， SYN Flood、UDP Flood 这类流量攻击会被云侧牵引到清洗中心，把恶意流量洗掉再把干净流量回源，项目二配套的 DDoS 原生防护是 5G 的基础带宽，如果面对更大规模的攻击就要买高防 IP 这类付费方案。主机安全是企业版的 HIDS 类产品，装个 Agent 就接入，干两件事：一是安全基线核查，检查弱口令、高危端口、配置合规这些项，对照 CIS 和等保基线给出评分和整改建议；二是入侵检测，异常登录、后门和 WebShell 文件、恶意进程、挖矿行为这些都会告警。数据库审计解决的是"数据库被谁动过"的问题，它记录谁、什么时间、从哪个地址、执行了什么 SQL、访问了哪些表，全量留痕，用于事后追责和满足等保的审计要求。我的真实职责是这些服务的配置管理者：做规划选型建议、配置策略——基线检查项开哪些、告警级别怎么定、审计规则覆盖哪些库——以及业务发布时的放行配合，比如 WAF 白名单和安全组变更，另外制定了账号权限最小化的规范。这套讲清楚"我管什么、管到什么深度"，比把自己包装成安全专家可信得多。

追问链：

• 追问1：数据库审计和数据库自己的日志有什么本质区别？ → 答：三个区别：第一，审计设备是独立部署的，以旁路镜像或者代理方式采集全量 SQL 访问行为，和数据库本身分离，数据库管理员删不掉；第二，它做了防篡改设计，日志完整性有保障，取证的可信度高；第三，它自带合规报表，直接对应等保的审计条款输出报告。数据库本地日志则可能被高权限账号删除或者关闭，出事后取证的可信度不够，这就是等保场景一定要独立审计的原因。
• 追问2：主机安全告警某台机器疑似挖矿，你的处置流程？ → 答：五步：第一步先隔离止损，用安全组把这台机器的出入流量收紧或者直接断网，防止它继续消耗资源并且横向扩散；第二步处置本体，kill 掉恶意进程，清理它落地的持久化项——计划任务、自启服务、可疑的公钥；第三步排查入侵入口，最常见的弱口令、未授权访问的 Redis、有漏洞的 Web 应用逐个对；第四步补丁加固后恢复业务；第五步回溯排查它有没有在内网横向移动、别的机器有没有被同样手法打进来的痕迹，最后把事件写进故障手册。

9.17 HTTPS 与证书基础 【必背】

标准回答： HTTPS 就是 HTTP 跑在 TLS 之上，它解决明文传输被窃听篡改的问题。机制上分两段：握手阶段用非对称加密——RSA 或者 ECDHE 这类算法——完成两件事，一是验证服务端身份（检查证书是不是可信 CA 签发的、域名对不对），二是协商出一个这次会话用的对称密钥；握手完成后的通信用对称加密算法比如 AES 加解密。为什么这么分工？因为非对称加密慢好几个数量级，只适合用来交换密钥和做签名，真正大量数据传输靠快的对称加密——一句话"非对称解决密钥交换和身份认证，对称解决传输性能"。证书体系是 CA 信任链：证书由 CA 逐级签发，证书里绑定着域名或者 IP 的身份，浏览器或者客户端验证整条链才信任。运维视角我记四件事：第一，TLS 终止点通常在 Nginx 或者负载均衡上，项目一就是 Nginx 的 443 挂证书、80 端口 301 跳转到 443；第二，SAN 字段决定这张证书对哪些域名和 IP 有效，这是我在银行项目真实踩过坑的地方；第三，有效期管理，证书过期是经典生产事故，要有到期告警和续期规范；第四，自签证书要把 CA 链分发到信任端，否则客户端报不信任。

追问链：

• 追问1：证书 SAN 踩过什么坑？详细讲讲。 → 答：真实案例：银行项目把单 master 升级成三 master 之后，用 VIP 去连 apiserver 报 x509 证书错误。排查用 openssl x509 -in apiserver.crt -text -noout 查看证书详情，发现 SAN 字段里只有原来的地址，没有新加的 VIP 和 master 主机名，apiserver 的证书校验不过。解法是改 kubeadm 的配置文件，在 certSANs 里补上新的 VIP 和主机名，把 /etc/kubernetes/pki 下的旧证书移走，用 kubeadm init phase certs apiserver 重新签发 apiserver 证书，然后重启 apiserver 生效。这个案例给我的教训一句话：改集群入口地址必须先想证书。这题讲出来非常加分，因为是自己踩的坑、有完整闭环。
• 追问2：怎么查证书有效期？你们的证书管理规范是什么？ → 答：查有效期用 openssl x509 -in 证书.crt -noout -dates，看 SAN 列表用 -text 参数。规范是到期前 30 天处理续期，K8s 集群证书用 kubeadm certs renew all 或者按组件单独续，续完重启对应组件；同时监控里配了证书剩余天数的告警，把"人记得"变成"系统提醒"，这也是我在运维规范里定的条目之一。
• 追问3：为什么非对称加密不直接用来加密数据？ → 答：性能差几个数量级。RSA 这类算法的加解密速度比 AES 慢成百上千倍，拿它加密一个网页的传输流是不现实的。所以工程上的设计就是让两者各干擅长的事：非对称在握手阶段建立信任和交换密钥，之后全用对称密钥跑流量，安全性和性能都兼顾了。

9.18 最小权限原则 【了解】

标准回答： 最小权限原则是说任何主体——不管是一个人、一个账号、一个服务还是 K8s 里的一个 Pod——只授予它完成任务所必需的最小权限，多一点都不给。这个原则的价值在于压缩攻击面和失误面：权限越小，账号泄露或者误操作造成的伤害就越小，出了事也好追责。我的项目里这条原则贯穿始终：K8s 里 kube-state-metrics 只绑 view 只读角色，Kuboard 按命名空间做多级权限隔离；云上安全组默认拒绝、按角色开放最小端口范围；数据库账号按应用分库授权，不用 root 账号跑业务；AI 平台的 API 密钥统一管理、定期轮换，谁用谁申请。被问"怎么落地"时我的答案是三句话：默认拒绝、按角色申请、定期审计回收——先从制度上保证没有"裸奔"的权限，再靠周期性的审计把沉淀下来的多余权限清出去。

追问链：

• 追问1：给你一个新环境，权限体系从哪开始治理？ → 答：先做盘点：把所有账号、密钥、权限对象列出来，对照"谁在用、用来干什么"打标签。第二步收紧：没有归属的账号停用、权限明显超出需要的降级、默认全开的改成默认拒绝。第三步建流程：新权限走申请审批、变更留记录、每季度复审。这套动作我在 AI 平台 API 密钥管理和云账号治理上都实际执行过。

9.19 云网络三个高频场景速答（面试常考）

• 场景一：云上服务突然访问不了，怎么排查？ → 答：云上排障和机房排障的顺序不一样，第一嫌疑人是配置而不是线缆。我的三步：第一步查安全组和网络 ACL 有没有最近变更——云上大量的"突然不通"都是变更引起的，先看变更记录；第二步查实例和监听，登机器 ss -lntp 看服务在不在、监听地址是不是 0.0.0.0 而不是只听 127.0.0.1；第三步查负载均衡的健康检查状态，后端被摘除了流量自然就断了。传统网络层的 ping、traceroute 放最后，因为云上的"逻辑网络配置"远比"物理链路"容易出问题。
• 场景二：跨可用区部署为什么值得做？ → 答：为了机房级故障隔离。可用区是同一地域内电力和网络相互独立的机房，一个可用区整体断电断网，另一个可用区里的节点继续服务，业务最多抖动不中断。项目二的 3 个 master 就跨了 3 个可用区，配合 CLB 的健康检查自动摘除，任何一个机房出问题，控制平面的访问入口都无感切换——这就是我们敢把控制平面可用性设计目标定到 99.99% 的底气。
• 场景三：VPC 里的机器怎么出公网？ → 答：三条路按场景选：给单台机器绑 EIP，它就有了独立公网 IP，出入都方便，但每台都绑既贵又暴露面大；NAT 网关做 SNAT，整个子网的内网机器共用一个出口主动出公网，不对外暴露任何入口，适合集群节点拉镜像下软件包这种纯出站需求；CLB 转发是入方向的，只对外提供服务不解决出站。项目二的设计是全集群统一走 NAT 网关加 EIP 出口、业务入口走 CLB、管理入口走跳板机——出入口收敛之后，审计流量、排查问题都清晰。

9.20 用 tcpdump 看懂一次完整的 TCP 连接 【理解】

标准回答： 如果面试官问"你说熟 TCP，抓包给我讲讲一次连接长什么样"，我按 tcpdump 的真实输出讲。命令是 tcpdump -i eth0 -nnn host 对端IP and port 8080——-i 指定网卡，-nnn 表示不做域名和端口反解析，输出干净。一次正常连接的输出序列：先是三次握手的三行，第一行客户端发出 Flags [S]（SYN），seq 是随机初始序列号；第二行服务端回 [S.]（SYN+ACK，点号表示 ACK 位），ack 等于第一行的 seq 加一；第三行客户端回 [.]（纯 ACK），握手完成。中间是数据传输，会看到 Flags [P.]（PSH，携带数据推送）和对应的 ACK，还可以从 seq 和 length 看出每次发了多少字节。断开时看四次挥手：主动方发 [F.]（FIN），对端 ACK，对端再发自己的 FIN，主动方回最后的 ACK；主动方这边随后进入 TIME_WAIT。异常形态我认三种：只看到 SYN 没有回包——对端没收到或拒绝，配合防火墙/安全组排查；回的是 [R]（RST）——连接被强制重置，通常是端口没监听或被防护设备切断；大量重传（同样的 seq 反复出现）——链路质量差或对端处理不过来。这套"从 Flags 讲故事"的能力，是 TCP 知识从背诵变成实感的分水岭，我在排查 apiserver 连接问题时就是这么用的。

追问链：

• 追问1：抓包怎么过滤只看某个端口的流量？ → 答：用 BPF 过滤表达式，tcpdump -i eth0 tcp port 6443 -nnn 只看这个端口的 TCP 包，再加 host 参数限定对端 IP 进一步缩小范围；想存下来离线分析就加 -w file.pcap，用 Wireshark 打开看图形化时序。过滤的原则是先窄后宽——先精确过滤定位问题，什么都没抓到再放宽条件，一上来全量抓包自己把自己淹死。
• 追问2：抓包看到 RST 一般是什么原因？ → 答：三种常见来源：一是目标端口没有进程监听，内核直接回 RST 拒绝；二是安全设备或者防火墙主动切断连接；三是应用异常退出时内核替它发 RST。区分方法：RST 出现在握手阶段多半是端口没人听或者被拦，出现在 established 之后多半是防护设备干预或进程崩溃——结合 ss 看监听状态就能定位。

9.21 网络质量与带宽测试：mtr 与 iperf3 【了解】

标准回答： 这两个小工具是网络问题定位的补刀神器。mtr 是 traceroute 的增强版，它结合了 ping 和路由追踪：mtr -n 目标IP 跑起来会持续发包，实时显示每一跳的丢包率和延迟——它比 traceroute 强在能看出"丢包丢在哪一跳、延迟在哪一跳跳起来"，而且能区分"中间路由不响应 ICMP 但转发正常"（那一跳显示丢包但后续跳正常，是假丢包）和"真丢包"（从某一跳开始后续全部丢）。排查跨网段访问慢，mtr 一跑基本能锁定是链路问题还是端点问题。iperf3 是带宽测试工具：服务端 iperf3 -s 起监听，客户端 iperf3 -c 服务端IP -t 10 打十秒流，直接给出吞吐量；加 -R 反向测、-u 测 UDP——用途是验证两台机器之间的实际带宽是否达标，比如怀疑云主机之间带宽被限制、或者内网互联的实际吞吐，iperf3 给出硬数据。这两个工具解决的是"延迟/丢包/带宽"三类网络质量问题的量化——口说网络不好没有说服力，mtr 和 iperf3 的输出才是证据。我在内网环境验证跨网段服务访问质量时用过这套组合。

追问链：

• 追问1：mtr 里某一跳显示 100% 丢包但后面几跳正常，说明什么？ → 答：说明那一跳的路由器只是不响应 ICMP 探测（限速或策略），但它转发数据是正常的——这是"假丢包"，不能看到丢包就断定那一跳有问题。判断真丢包的标准是：从某一跳开始，它和它后面的所有跳都丢包，那才是那一跳或其之后的链路真有问题。这个细节能讲出来，说明真用过 mtr 而不是背的名词。

9.22 等保 2.0 三级技术要求速览（运维相关部分） 【了解】

标准回答： 等保 2.0 我从运维落地视角讲和岗位最相关的五个控制点。安全通信网络：通信传输加密——生产系统上 HTTPS、数据库和中间件内网传输按需加密，这就是我们 Nginx 挂证书 443 的合规背景之一。安全区域边界：边界防护和访问控制——安全组最小权限、网络分区分域，我们的 VPC 子网划分和分层安全组矩阵就是这一条的落地。安全计算环境：身份鉴别（口令复杂度、登录失败处理、双因素按需）、访问控制（账号权限最小化）、安全审计（日志留存——等保要求日志留存不少于六个月，这一点直接影响我们的日志归档策略）、入侵防范（主机安全 Agent）、数据备份恢复（备份策略加异地）。安全管理中心：集中管控——集中监控、集中审计，这也是我们配 DME 集中监控和数据库审计的合规依据。我的口径是"配置管理者"：这些控制点里安全组、证书、备份、日志、主机安全这几块的配置实施我都真实做过，测评机构来现场时配合提供证据材料我也有经验；但等保定级备案的流程细节（比如几级去哪备案）属于安全合规岗的专业范围，我理解到"知道自己的系统为什么必须配这些"这一层。

追问链：

• 追问1：日志留存六个月这条怎么落地的？ → 答：分两类落地：系统和应用日志通过 logrotate 加归档脚本，按日期压缩存到备份存储，保留策略设置大于六个月再滚动清理；关键审计类日志（数据库审计、操作审计）在审计平台里配置保留周期。难点是磁盘容量——六个月的日志量不小，所以归档要走压缩加异机存储，而不是堆在本地。这条我按规范执行过，属于"知道为什么、做过怎么配"的层次。

9.23 本章案例

• 【真实项目】项目二云网络与安全配套（STAR，完整版约 250 字）：背景是外包业务系统要上线，客户和等保合规要求网络安全体系必须同步到位。任务是我负责移动云上整个网络规划与安全配套的落地。行动分四块：网络层规划一个 VPC 跨三个可用区，子网按角色划分，7 台 ECS 固定 IP 分配；入口层配置 CLB 四层监听 6443 挂接三个 master，配置 TCP 健康检查和自动摘除，业务入口按需开放；出口层建设 NAT 网关加 EIP 的统一出公网通道，集群拉镜像、节点更新全走这里；安全层按角色设计安全组矩阵——管控面只放跳板机网段的 6443 和 22、节点组放行 10250 和 NodePort 段、数据库只收应用子网流量——并配套配置 WAF、DDoS 原生防护、主机安全和数据库审计的策略，业务发布时逐项做放行验证。结果是业务系统一次性通过安全检查合规上线，账号密钥统一纳管，这套安全组矩阵和配置基线沉淀成了方案文档。
• 【真实项目】银行内网双平面组网（STAR）：背景是银行生产环境对管理流量与业务流量隔离有明确要求。任务是我配合网络规划完成三张网的实施。行动：每台服务器规划管理 IP 加业务 IP 双平面，分别接 CE6856HI 管理/BMC 交换机与 CE6863 业务交换机，iBMC 口单独接 BMC 管理网，交换机上按规划表做 VLAN 划分和 trunk 放行，FC 的端口组与交换机配置一一对应。结果是管理、业务、带外三张网完全隔离——业务网流量再大不影响管理操作，业务故障时带外通道随时能救机器，这套"平面隔离"的实践是我网络理解最扎实的一块。
• 【课程项目】网络基础实验（口径：课程实验 + 真实配置结合）：课程里做了 VLAN 与 Trunk 划分、子网划分计算、DHCP 四步交互、ping/telnet/traceroute 全链路排查的成套实验；这些基础操作和银行现场 CE 交换机的真实配置经验互相印证，面试时按"课程实验打底、银行现场实操"的口径讲。
• 【经典故障】网页打不开排查（课程八股案例，完整版约 200 字）：背景是用户反馈网页打不开但 QQ 能登录。排查按"网络连接 → DNS → 代理 → 服务器"四层收敛：先 ping 网关和公网 IP 确认链路通；链路通而域名不通就锁定 DNS——nslookup 查解析失败，换 223.5.5.5、114.114.114.114 公共 DNS 对比，能解析就是本地 DNS 故障或者缓存污染，清缓存、改 DNS 后恢复；再顺手确认浏览器代理设置有没有被改；最后如果 DNS 正常还打不开，curl 看服务器响应定位服务端。结果是用更换 DNS 解决。这个案例的价值是展示分层排查思路，和云上"ping → 安全组 → 服务监听 → 日志"的顺序完全同构，面试里我常拿它把传统网络和云网络的能力串起来讲。

9.24 章末自测清单

1. TCP/IP 四层是哪四层？ → 网络接口、网络、传输、应用。
2. 三次握手为什么不能两次？ → 双方都要确认收发能力正常，且防历史 SYN 建错连接。
3. 四次挥手为什么四次？ → 全双工两个方向分别关，被动方 ACK 与 FIN 中间可能还有数据要发。
4. TIME_WAIT 在哪端、等多久？ → 主动关闭方，2MSL。
5. ping 通 telnet 不通查什么？ → 服务监听（ss -lntp）、防火墙/安全组、监听地址是否 0.0.0.0。
6. Access 和 Trunk 口区别？ → Access 属单 VLAN 不打标签接终端；Trunk 承载多 VLAN 带 802.1Q 标签接级联。
7. 默认路由是什么？ → 0.0.0.0/0 兜底路由，匹配所有未知目的地。
8. 192.168.0.0/24 按 50 主机划分子网？ → 借 2 位，/26 掩码，4 个子网各 62 可用地址。
9. 安全组是什么？ → 实例级有状态虚拟防火墙，默认拒绝入站，只写入方向规则。
10. CLB 四层和七层区别？ → 四层 TCP/UDP 转发快（apiserver 用它）；七层 HTTP 按内容路由、终止 TLS（Web 入口）。
11. SNAT 是什么场景？ → NAT 网关里内网无公网资源统一出公网的源地址转换。
12. RDS 主备比自建强在哪？ → 自动切换、自动备份、托管补丁监控；代价是成本。
13. 移动云 CLB 对应阿里云什么？ → SLB；其余 ECS/VPC/EOS↔OSS 概念同构。
14. 等保是什么？ → 网络安全等级保护制度，金融/政务按级别强制测评，技术+管理双落地。
15. WAF 防什么、CC 和 DDoS 区别？ → 防 OWASP Top10 应用攻击与 CC；CC 应用层耗资源，DDoS 流量型打带宽。
16. HTTPS 握手加密怎么分工？ → 非对称协商密钥+验证证书，对称加密传输数据。
17. 查证书 SAN 和有效期命令？ → openssl x509 -in crt -text / -noout -dates。
18. 主机安全两大能力？ → 安全基线核查 + 入侵检测（异常登录/WebShell/恶意进程）。
19. 云上服务不可访问第一嫌疑人？ → 安全组/ACL 变更，其次监听状态与 CLB 健康检查。
20. 数据库审计比数据库本地日志强在哪？ → 独立旁路采集、防篡改、合规报表，满足等保可追溯。
21. 出公网的三条路？ → 绑 EIP、NAT 网关 SNAT、CLB 转发；集群统一 NAT 出口便于审计。
22. tcpdump 里 [S]/[S.]/[F.]/[R] 各代表什么？ → SYN 请求 / SYN+ACK 应答 / FIN 关闭 / RST 强制重置。
23. mtr 假丢包怎么判断？ → 某跳丢包但后续跳正常=路由不响应 ICMP 的假丢包；某跳起后续全丢=真丢包。
24. 等保日志留存要求？ → 不少于六个月，logrotate 归档加异机存储落地。
25. iperf3 用来干什么？ → 两点间带宽压测，给出实际吞吐的硬数据（-s 服务端 / -c 客户端）。

9.25 本章口径红线（面试前再读一遍）

1. 角色口径：网络是"配置过真实设备 + 排障经验丰富"，CE 交换机按操作与诊断讲，不深入堆叠、BGP 等没做过的领域，被问到用兜底话术。
2. 云安全角色：我是"配置管理者与合规落地者"——规划选型建议、策略配置、发布放行、账号权限规范，不冒充安全攻防专家。
3. 脱敏：VPC 网段、EIP、仓库域名、账号一律不报具体值，说"某内网网段""内网私有仓库"。
4. 数字口径：7 台 ECS、3 可用区、CLB 四层 6443、DDoS 原生防护 5G、RDS 8C16G/300G、证书到期前 30 天续期——这些数字有据可查，大胆讲。
5. 课程级内容（DHCP 细节、子网计算之外的 TCP 深机制）按"课程实验 + 理解"口径，超纲追问用兜底话术。
6. 双云经验讲同构和迁移方法论，不贬低任何厂商；阿里云侧重讲 AI 工具链使用，移动云讲生产集群，分工清晰。