3. 网络基础与安全组配置：TCP/IP协议栈、DNS解析原理、HTTP/HTTPS协议、云上VPC与安全组规则实战
网络是云上运维的命脉。你想想看，应用跑得再快，网络不通，一切都是白搭。我见过太多新手，一上来就折腾代码，结果连个安全组规则都没配对，排查了一整天。这一章，咱们就把网络基础和安全组配置彻底捋清楚。
3.1 TCP/IP协议栈：数据包在云上的旅行
TCP/IP协议栈，说白了就是数据包从你的应用出发，到对端服务器，再回来的完整路径。它分四层，每一层都有自己的职责。
| 层级 | 核心协议 | 职责 | 我常关注的坑 |
|---|---|---|---|
| 应用层 | HTTP, DNS, SSH | 定义数据格式和交互逻辑 | 协议版本、超时时间 |
| 传输层 | TCP, UDP | 端到端可靠传输或快速传输 | 端口号、连接状态、重传率 |
| 网络层 | IP, ICMP | 寻址和路由选择 | IP冲突、路由表、TTL |
| 网络接口层 | 以太网, ARP | 物理介质上的帧传输 | MAC地址、MTU大小 |
我记得有一次线上故障，应用响应极慢。查了半天，发现是MTU设置过大，导致IP分片严重。嗯，从那以后，我排查网络性能问题，第一件事就是看MTU和TCP重传率。
核心要点：TCP的三次握手和四次挥手，是排查连接问题的基本功。你可以用 tcpdump 或 ss -tpan 观察连接状态。如果大量 TIME_WAIT 或 CLOSE_WAIT，说明应用层没处理好连接复用或关闭。
3.2 DNS解析原理：域名背后的寻址之旅
DNS解析，就是把域名翻译成IP地址的过程。这个过程看似简单，但坑特别多。我建议你把它拆成几个关键步骤来理解。
- 本地缓存查询：浏览器或操作系统先查自己的DNS缓存。如果命中，直接返回。
- 递归查询：本地DNS服务器（通常是云服务商提供的）向根域名服务器发起查询。
- 迭代查询：根服务器返回顶级域（如 .com）的地址，本地DNS再去问顶级域服务器。
- 权威解析：顶级域服务器返回权威域名服务器的地址，最终拿到目标IP。
避坑指南：我曾经遇到一个诡异的问题，应用偶尔连不上数据库。排查发现，是DNS缓存了旧的IP地址。数据库迁移后，TTL没设短，导致部分请求路由到了旧IP。从那以后，我坚持把关键服务的DNS TTL设为60秒，并且用 nslookup 或 dig 定期验证解析结果。
为什么会这样？因为DNS解析是分层缓存的。你改了DNS记录，全球生效需要时间。这个时间取决于TTL值。所以，做DNS变更前，先把TTL调低，等变更生效后再调回去。
3.3 HTTP/HTTPS协议：应用层的通信语言
HTTP协议，是咱们和云上服务打交道最频繁的协议。HTTPS就是在HTTP外面套了一层TLS加密。我个人习惯，在生产环境中，强制使用HTTPS，除非是内部监控或调试接口。
HTTP的核心是请求-响应模型。一个典型的请求包含：方法（GET/POST）、路径、头部（Headers）、主体（Body）。响应包含：状态码、头部、主体。
状态码速查表：
- 2xx：成功。200 OK，201 Created。
- 3xx：重定向。301永久，302临时，304未修改（缓存）。
- 4xx：客户端错误。400 Bad Request，401未授权，403禁止，404未找到，429限流。
- 5xx：服务端错误。500内部错误，502 Bad Gateway，503服务不可用，504网关超时。
HTTPS的握手过程，比HTTP多了TLS协商。这个协商会消耗额外的CPU和网络开销。我建议你在负载均衡器上终结TLS，而不是在后端服务器上。这样能减轻后端压力，也方便统一管理证书。
注意：HTTPS证书有有效期。我见过不止一次，因为证书过期导致线上服务大面积不可用。建议设置证书到期前30天的告警，并定期检查证书链是否完整。
3.4 云上VPC与安全组规则实战
VPC（虚拟私有云）是你在云上的专属网络空间。你可以把它想象成一个独立的机房，里面可以划分子网、配置路由、设置防火墙。安全组，就是VPC里的虚拟防火墙，控制进出云资源的流量。
下面这张图，是我自己总结的VPC核心逻辑。你看一眼，就能明白数据流怎么走。
3.4.1 安全组规则配置实战
安全组规则，说白了就是“谁可以访问我的哪个端口”。配置时，我建议你遵循最小权限原则：只开放必要的端口，只允许必要的源IP或源安全组。
下面是一个典型的Web应用安全组配置示例：
# 安全组：SG-Web
# 入站规则
# 允许来自负载均衡的HTTP流量
Protocol: TCP
Port: 80
Source: sg-xxxxx (负载均衡的安全组ID)
# 允许来自负载均衡的HTTPS流量
Protocol: TCP
Port: 443
Source: sg-xxxxx (负载均衡的安全组ID)
# 允许运维人员SSH登录（限制源IP）
Protocol: TCP
Port: 22
Source: 203.0.113.0/24 (公司公网IP段)
# 出站规则（默认允许所有流量）
Protocol: All
Port: All
Destination: 0.0.0.0/0实战技巧：我习惯用安全组引用安全组的方式，而不是直接写IP。比如，Web层的安全组只允许来自负载均衡安全组的流量。这样，即使负载均衡的IP变了，规则也不用改。另外，别忘了给数据库层单独配一个安全组，只允许来自Web层安全组的流量。
3.4.2 网络ACL vs 安全组
很多新手分不清网络ACL和安全组的区别。我直接给你列个对比表：
| 特性 | 安全组 | 网络ACL |
|---|---|---|
| 作用范围 | 实例级别（如EC2、ENI） | 子网级别 |
| 状态 | 有状态（自动允许回程流量） | 无状态（需显式配置入站和出站规则） |
| 规则顺序 | 所有规则都评估（允许优先） | 按编号从小到大评估（匹配即停） |
| 默认行为 | 隐式拒绝所有入站，允许所有出站 | 允许所有入站和出站（需手动修改） |
| 使用场景 | 精细控制单个服务的访问 | 子网级别的全局防护（如封禁某个IP段） |
注意：网络ACL是无状态的。如果你配置了入站规则允许HTTP，但忘了配出站规则允许响应流量，客户端能发请求，但收不到响应。我曾经因为这个坑，排查了整整两个小时。所以，用网络ACL时，一定要成对配置入站和出站规则。
3.4.3 实战：搭建一个三层Web架构
咱们来一个完整的实战。假设你要在云上部署一个Web应用，包含负载均衡、Web服务器、数据库。网络架构如下：
- 创建VPC：CIDR为10.0.0.0/16。
- 创建子网：
- 公有子网A：10.0.1.0/24（放负载均衡和Web服务器）
- 公有子网B：10.0.2.0/24（放Web服务器，用于高可用）
- 私有子网C：10.0.3.0/24（放数据库）
- 配置路由表：
- 公有子网的路由表指向Internet网关。
- 私有子网的路由表只指向本地。
- 配置安全组：
- SG-ALB：允许来自0.0.0.0/0的80和443端口。
- SG-Web：允许来自SG-ALB的80端口，允许来自公司IP的22端口。
- SG-DB：允许来自SG-Web的3306端口（MySQL）。
- 部署服务：启动EC2实例，关联对应的安全组。
验证命令：
# 从Web服务器测试数据库连通性
telnet 10.0.3.10 3306
# 从本地测试Web服务
curl -I https://your-domain.com
# 查看安全组规则是否生效
aws ec2 describe-security-groups --group-ids sg-xxxxx嗯，到这里，网络基础和安全组配置的核心内容就讲完了。你想想看，这些知识其实都是环环相扣的。理解了TCP/IP，你就能看懂DNS解析；理解了HTTP，你就能配置好安全组规则。多动手，多踩坑，慢慢就熟练了。