📚 课程目录第3章网络与安全基础

3. 网络与安全基础：网络分层模型、HTTP/HTTPS、常见网络协议与基础安全知识

网络是程序运行的骨架，安全是程序生存的底线。无论是开发 Web 应用、移动端 App，还是嵌入式设备固件，程序员都必须理解数据从一台主机到达另一台主机的完整路径，以及在此过程中可能遭遇的威胁与应对手段。本章从网络分层模型出发，逐步拆解 HTTP/HTTPS 协议细节，梳理常见网络协议的应用场景，最后建立基础安全知识框架，帮助读者形成“分层理解、逐层排查、安全前置”的工程思维。

3.1 网络分层模型：从 OSI 到 TCP/IP

3.1.1 核心原理：为什么需要分层

网络通信是一个极其复杂的过程，涉及物理信号传输、数据校验、路由寻址、会话管理、数据表示等多个维度。如果将所有逻辑写在一个协议中，任何改动都会牵一发而动全身。分层模型的核心思想是“每层只解决一类问题，层与层之间通过标准接口通信”。这样既降低了实现复杂度，又允许各层独立演进——例如，底层从铜缆升级为光纤，上层应用完全无感知。

国际标准化组织（ISO）提出的 OSI 七层模型是理论参考，而实际互联网运行在 TCP/IP 四层模型之上。两者的对应关系如下：

OSI 七层	TCP/IP 四层	典型协议/设备	程序员关注点
应用层（7）	应用层	HTTP、HTTPS、DNS、FTP、SSH	API 设计、数据格式、状态码
表示层（6）		SSL/TLS、字符编码、压缩	加密、序列化（JSON/XML）
会话层（5）		Session、Cookie、Socket 连接管理	登录态保持、断线重连
传输层（4）	传输层	TCP、UDP	端口号、可靠传输、流量控制
网络层（3）	网络层	IP、ICMP、路由器	IP 地址、子网掩码、路由
数据链路层（2）	链路层	以太网、MAC、ARP、交换机	MAC 地址、帧、冲突域
物理层（1）	链路层	网线、光纤、集线器	信号、比特率、双工模式

3.1.2 数据封装与解封装流程

当浏览器请求一个网页时，数据从应用层逐层向下传递，每一层都会在原始数据前添加自己的头部信息（部分协议还会添加尾部），这个过程称为封装。接收方则从物理层向上逐层剥离头部，还原出原始数据，称为解封装。

以访问 https://example.com 为例，发送端的封装过程如下：

应用层：浏览器构造 HTTP 请求报文（请求行、请求头、请求体）。
传输层：TCP 协议将 HTTP 报文作为数据，添加 TCP 头部（源端口 54321、目的端口 443、序列号、校验和），形成 TCP 报文段。
网络层：IP 协议添加 IP 头部（源 IP 192.168.1.10、目的 IP 93.184.216.34），形成 IP 数据报。
链路层：以太网协议添加 MAC 头部（源 MAC、目的 MAC 为默认网关的 MAC），形成以太网帧。
物理层：将帧转换为比特流，通过网线或 Wi-Fi 发送。

排障启示：当网络出现问题时，遵循“自下而上”的排查顺序——先检查物理层（网线是否松动、Wi-Fi 是否连接），再检查链路层（ARP 是否解析成功），然后检查网络层（能否 Ping 通网关），接着检查传输层（端口是否开放），最后才检查应用层（HTTP 状态码）。这比盲目重启路由器高效得多。

3.1.3 案例拆解：一次访问超时的分层排查

场景：某开发环境中的前端页面请求后端 API 时，浏览器报错 net::ERR_CONNECTION_TIMED_OUT。后端服务确认已启动并监听 8080 端口。

排查过程：

排查层级	操作命令	结果分析
物理/链路层	`ipconfig`（Windows）或 `ifconfig`（Linux）	确认本机 IP 为 192.168.1.20，网关 192.168.1.1，MAC 地址正常
网络层	`ping 192.168.1.1` → 通；`ping 后端IP` → 不通	网关可达，但到后端主机路由不通，可能是防火墙拦截或主机不在同一网段
传输层	`telnet 后端IP 8080` → 无法连接	端口未开放或服务未监听
应用层	登录后端主机执行 `netstat -anp \| grep 8080`	发现服务只监听了 `127.0.0.1:8080`，未监听 `0.0.0.0:8080`

根因与修复：后端服务启动时绑定了回环地址，导致外部无法访问。修改启动配置为监听 0.0.0.0:8080 后，问题解决。

复盘经验：分层模型不仅是理论，更是排障的“地图”。每一层都有对应的诊断工具（ping、traceroute、telnet、curl、netstat），掌握这些工具能快速缩小问题范围。

3.1.4 常见误区与总结

误区一：认为 OSI 七层是实际运行的协议。实际上互联网核心是 TCP/IP 四层模型，OSI 更多用于教学和概念对照。
误区二：混淆“端口”与“服务”。端口是传输层的概念，一个端口只能被一个进程监听，但一个进程可以监听多个端口。
误区三：忽略 MTU（最大传输单元）。当数据包超过链路层 MTU（通常 1500 字节）时，IP 层会分片，可能导致性能下降或丢包。

  核心记忆：“数据自上而下封装，自下而上解封装；排查自下而上，优化自上而下。”

3.2 HTTP/HTTPS 协议详解

3.2.1 核心原理：HTTP 的无状态与请求-响应模型

HTTP（HyperText Transfer Protocol）是 Web 世界的通用语言。它基于请求-响应模型：客户端发起请求，服务器返回响应。HTTP 协议本身是无状态的——服务器不会自动记住之前的请求来自谁，每次请求都是独立的。为了维持用户登录状态，引入了 Cookie 和 Session 机制。

一个典型的 HTTP 请求报文包含三个部分：

POST /api/login HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Content-Length: 42

{"username":"alice","password":"secret"}

响应报文同样包含状态行、响应头和响应体：

HTTP/1.1 200 OK
Content-Type: application/json
Set-Cookie: session_id=abc123; HttpOnly; Path=/

{"code":0,"message":"success","data":{"":"..."}}

HTTP 状态码是程序员必须掌握的基础知识，按类别划分：

状态码范围	类别	常见示例	程序员行动
1xx	信息性	100 Continue	较少直接处理
2xx	成功	200 OK、201 Created、204 No Content	正常处理响应体
3xx	重定向	301 Moved Permanently、302 Found、304 Not Modified	处理 Location 头，浏览器自动跳转
4xx	客户端错误	400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found、429 Too Many Requests	检查请求参数、认证信息、权限
5xx	服务器错误	500 Internal Server Error、502 Bad Gateway、503 Service Unavailable	查看服务器日志，检查依赖服务

3.2.2 HTTPS：在 HTTP 之上加一层安全壳

HTTP 以明文传输数据，在公网环境中极易被窃听、篡改或冒充。HTTPS（HTTP Secure）的本质是 HTTP + TLS/SSL。TLS 协议在 TCP 之上、HTTP 之下，提供三大安全保证：

机密性：通过对称加密（如 AES）加密数据，防止窃听。
完整性：通过消息认证码（MAC）检测数据是否被篡改。
身份认证：通过数字证书验证服务器身份，防止中间人冒充。

HTTPS 握手过程（TLS 1.2 简化版）如下：

客户端发送 ClientHello，包含支持的 TLS 版本、加密套件列表、随机数。
服务器回复 ServerHello，选定加密套件，并发送数字证书（含公钥）和随机数。
客户端验证证书链（由 CA 签发、未过期、域名匹配），生成预主密钥，用服务器公钥加密后发送。
双方基于预主密钥和随机数计算出会话密钥（对称密钥）。
双方发送 Finished 消息，握手完成，之后所有应用数据均用会话密钥加密。

安全提醒：HTTPS 并非安全。如果客户端未正确验证证书（例如忽略证书警告），中间人攻击依然可能成功。此外，TLS 1.0/1.1 已被证明不安全，应至少使用 TLS 1.2 或 TLS 1.3。

3.2.3 案例拆解：从 HTTP 升级到 HTTPS 的完整过程

背景：某电商平台原先使用 HTTP 提供服务，用户登录密码和支付信息均明文传输。安全审计发现，在公共 Wi-Fi 环境下，攻击者可通过 ARP 欺骗截获数据包，直接读取用户密码。

目标：全站启用 HTTPS，并保证兼容旧客户端。

实施步骤：

申请证书：购买或使用 Let's Encrypt 免费证书，生成私钥和 CSR（证书签名请求）。
配置 Web 服务器：以 Nginx 为例，修改配置监听 443 端口，并配置证书路径。
强制跳转：将 80 端口的所有请求 301 重定向到 HTTPS。
更新应用内链接：将代码中所有 http:// 硬编码改为 https:// 或使用协议相对 URL //。
HSTS 策略：添加 Strict-Transport-Security 响应头，强制浏览器自动使用 HTTPS。
验证：使用 curl -v https://example.com 检查证书链，使用 openssl s_client -connect example.com:443 查看加密套件。

结果对比：升级后，抓包工具（如 Wireshark）只能看到密文，无法还原明文内容。同时，搜索引擎对 HTTPS 站点有排名加权，SEO 也得到提升。

代价与风险：HTTPS 握手增加了 1-2 个 RTT（往返时间），对性能有轻微影响。可通过启用 TLS 会话复用、OCSP Stapling 和 HTTP/2 来缓解。

3.2.4 常见误区与总结

误区一：认为 HTTPS 加密后就可以忽略请求头中的敏感信息。实际上 URL 路径和查询参数在代理日志中可能被记录，敏感信息应放在请求体或 Header 中。
误区二：混淆 401 与 403。401 表示“未认证”，需要提供凭证；403 表示“已认证但无权限”。
误区三：忽略 Cookie 的安全属性。应设置 Secure（仅 HTTPS 发送）、HttpOnly（禁止 JS 读取）和 SameSite（防 CSRF）。

  实践建议：新项目一律默认 HTTPS；使用 HTTP/2 需基于 HTTPS；API 设计时明确状态码语义，避免一律返回 200 再包一层 code 字段。

3.3 常见网络协议与基础安全知识

3.3.1 核心原理：DNS、DHCP、FTP、SSH 的角色

除了 HTTP/HTTPS，程序员日常工作中还会频繁接触以下协议：

协议	默认端口	传输层	主要用途	安全注意事项
DNS	53	UDP（主）/TCP（辅）	域名解析为 IP	DNS 劫持、缓存投毒；建议使用 DNSSEC
DHCP	67/68	UDP	自动分配 IP、网关、DNS	DHCP 欺骗攻击；建议启用 DHCP Snooping
FTP	21	TCP	文件上传/下载	明文传输账号密码；应使用 SFTP 或 FTPS
SSH	22	TCP	远程登录、安全文件传输	使用密钥认证替代密码；禁用 root 直接登录
ICMP	—	网络层	Ping 测试连通性	可能被用于 Ping 洪水攻击

DNS 是互联网的“电话簿”，其解析流程为：浏览器缓存 → 操作系统 hosts 文件 → 本地 DNS 服务器 → 根域名服务器 → 顶级域名服务器 → 权威域名服务器。理解这一链路有助于排查“域名解析慢”或“解析到错误 IP”的问题。

3.3.2 基础安全知识：威胁模型与防护手段

基础安全知识不是要求每个程序员都成为安全专家，而是建立威胁建模意识。常见的 Web 攻击类型及防护措施如下：

SQL 注入：攻击者在输入框提交恶意 SQL 片段，拼接进后端查询语句。防护：使用参数化查询（PreparedStatement）、ORM 框架、输入白名单校验。
XSS（跨站脚本）：攻击者注入 JavaScript 代码，窃取用户 Cookie 或执行恶意操作。防护：输出编码（HTML Entity）、CSP（内容安全策略）、HttpOnly Cookie。
CSRF（跨站请求伪造）：诱导用户浏览器向已登录的网站发送恶意请求。防护：CSRF 、SameSite Cookie、校验 Referer 头。
DoS/DDoS：通过大量请求耗尽服务器资源。防护：限流、负载均衡、CDN 清洗、防火墙规则。
中间人攻击：攻击者拦截并篡改通信双方的数据。防护：全站 HTTPS、证书固定（Certificate Pinning）、双向 TLS。

最小权限原则：给每个用户、每个服务、每个分配恰好够用的权限。例如，数据库账号不应使用 root，而应创建仅拥有 SELECT/INSERT 权限的专用账号。

3.3.3 案例拆解：一次 DNS 劫持的发现与处置

背景：某公司内部员工反馈访问公司官网时，页面被跳转到赌博网站。安全团队介入调查。

初始现象：部分员工电脑访问 www.company.com 时，浏览器地址栏变为 http://evil.com，且页面内容异常。使用 ping www.company.com 解析出的 IP 为 203.0.113.66，而正常 IP 应为 198.51.100.23。

分析过程：

检查本机 hosts 文件（C:\Windows\System32\drivers\etc\hosts），未发现异常条目。
使用 nslookup www.company.com 8.8.8.8（公共 DNS）解析，结果正确；使用 nslookup www.company.com 192.168.1.1（本地 DNS）解析，结果指向恶意 IP。
判断为本地 DNS 服务器被污染或缓存投毒。
检查路由器配置，发现 DNS 设置被改为 203.0.113.1（恶意 DNS 服务器）。

处置步骤：

修改路由器 DNS 为可信公共 DNS（如 223.5.5.5 或 8.8.8.8）。
清除本地 DNS 缓存：ipconfig /flushdns。
修改所有设备的管理员默认密码，防止再次被入侵。
部署 DNSSEC 验证 DNS 响应完整性。

复盘经验：DNS 劫持往往从路由器或本地 DNS 入手。程序员应养成使用 nslookup 对比不同 DNS 解析结果的习惯，并定期检查路由器配置。

3.3.4 常见误区与总结

误区一：认为“内网安全，不需要加密”。内网同样存在 ARP 欺骗、恶意脚本等威胁，敏感数据在内网传输也应加密。
误区二：忽略依赖库的安全漏洞。使用 npm audit、pip check 等工具定期扫描依赖。
误区三：将安全仅视为运维的职责。开发阶段就应进行安全编码，例如使用 ORM 防注入、对输出进行编码。

  安全基线：① 所有外部通信使用 HTTPS/TLS；② 所有用户输入视为不可信；③ 所有错误日志不打印敏感信息（密码、）；④ 定期更新依赖和系统补丁；⑤ 遵循最小权限原则。

网络与安全是程序员的“基础设施素养”。理解分层模型能让你快速定位问题，掌握 HTTP/HTTPS 能让你设计出健壮的接口，熟悉常见协议能让你在复杂环境中游刃有余，而建立安全思维则能让你交付的产品经得起考验。建议读者在本地用 Wireshark 抓包观察一次完整的 HTTP 请求，再用 openssl 命令模拟一次 TLS 握手，将本章知识转化为肌肉记忆。